Translating Eloquent fields with MySQL’s native JSON type


Since version 5.7.8, MySQL has supported a native JSON data type. Since I’m a bit of a weirdo who finds structured data formats interesting, I wanted to experiment with its different uses in the context of a web application. One potential use-case I thought of was using it for internationalisation – storing different text translations for a field.

Let’s take a look at how internationalisation is typically done in a web application and how it could be done through the use of MySQL’s native JSON type. Since I’m uncreative, I’ll be using Laravel and an age-old blog posts example. We’ll keep it simple and say the requirement is that the titles and body content of our posts need to be multilingual. If you want to jump straight to the proof of concept, here’s the GitHub repository.

The boring, traditional way

Normally we’d achieve this by creating two database tables for our posts. The first table contains only language-neutral data: things like primary keys, fields that are the same across languages, etc. The second table contains the localised text, stored against the relevant ISO code of the language it represents. In a typical Laravel migration class, that might look like this:

When we want to retrieve a post in a specific language, we’d execute a query that joins the post_translations table in order to grab the localised text.

This is a tried and true method, and arguably the best since it follows database normalisation principles. But it doesn’t use JSON, and any JavaScript developer will tell you that JSON is cool.

The JSON way

We can achieve the same thing using MySQL’s native JSON data type by changing our migration to the following.

Since we’ll now be storing the different localised text strings in the same table as the object, we can drop the post_translations table. We’ve made the title and content fields take JSON, which will have the following structure:

To retrieve blog posts in a particular language, our query now changes to take advantage of Laravel 5.2’s support of JSON:

This is a much simpler query that requires no joins. In the background, Laravel is executing a query taking advantage of MySQL’s native JSON path syntax:

Automating the translations

This is great and all, but it doesn’t help us much in a real application. Laravel’s DB facade returns stdClass objects as results, not our nice Eloquent models. We’ll also likely want to default to a specific language depending on the locale specified in our application’s config, and fall back to another if it’s not available. To help with this, we’ll create a trait that can be used by our Eloquent models to automatically retrieve the correct translation for a model field. Dump the code below into Translatable.php, somewhere in your project.

What we’re doing above is overriding Illuminate\Database\Eloquent\Model‘s implementation of getAttribute() with our own. The getAttribute() method will be executed on each access to the model’s fields. We’ll check if the field we’re accessing has translations and if it has, we’ll return the correct one based on the locale setting defined in the application’s config. If there’s no entry for that locale, we’ll use the fallback locale, and as a last resort we’ll just return an empty string.

All that’s left is hooking this trait up to a model.

You’ll notice that just useing the trait isn’t enough – we also have to tell the getAttribute() method what model fields are translatable. Also, we have to use the $casts property to let Laravel know that it should save this field as JSON when it persists to MySQL.

Saving or updating a post with translated fields becomes super easy.

Check out the GitHub repository to see it in a working Laravel application.

Are you convinced?

I’ll leave this one up to you. Personally, I’m not convinced enough in this approach to drop the translation text lookup table for a JSON field. I’m not a fan of having to retrieve and re-save every language’s translation when adding/removing one translation.

That being said, the proof of concept does indeed prove that this method works. And I do like the idea of not requiring a translations lookup table for every translatable object. Whether or not those positives outweigh the negatives depends on your own project requirements and your personal opinion as a developer (a cop-out answer, I know!).

About the author


Chris is a software engineer from Scotland. He can usually be found working on web applications for Intouch Insight using Laravel and Angular, but tends to dabble a lot with other technologies in his free time.

Recent Posts