Have you ever been in a situation where you needed to implement a system in Laravel which supports Eloquent Models in multiple languages? I sure have, and since you are reading this, you might have too. This being a common problem, my initial approach was, of course, to search for a package for it. Much to my surprise, there were some packages available but none of them were really what I was looking for, and I was left to come up with a solution of my own. At that time, my schedule was rather cramped and I had resorted to implementing a one-time solution for that project, but the idea of creating a package for the named problem had lingered with me ever since.
Fast forward several months, and here I am with my shiny new package, a package called Laravel Model Translation (granted, I could have been more creative with the name). It strives to achieve a high level of flexibility in storing translations, and also deviate from Laravel’s existing convention and API as little as possible. In other words, it let’s you store translations however you like, in whatever permanent storage engine you like, and still let’s you work with your translations like this:
$post = BlogPost::find(1); // An instance of the BlogPost model
$post->title = 'Naslov na srpskom';
$post->title = 'Title in English';
$post->title; // Returns 'Title in English';
$post->setLanguage('rs')->title; // Returns 'Naslov na srpskom'
Pretty Eloquent (pun intended), right? But how is this achieved, you may wonder? The package is designed as a driver-based system which allows you to create your own drivers for storing translations, and thus decide on how you would like them to be stored. It also contains a trait called
Translatable which has all the code needed for communicating with the drivers and allowing you to use the minimalist, Laravel-like syntax seen in the snippet above. To read more on the package’s inner-works and how to use it, check out the GitHub repo and its wiki pages.
So when might you use this package? Let’s say you’re building a Laravel application with a MySQL database, but you wanted to store your translations in a Mongo database (don’t know why you’d do that, just imagine it). All you’d have to do is install the package and implement a driver, and the rest would be handled automatically. It would take you a dozen minutes to set this up and be all set. Let’s say that after a few months you decided using Mongo was ridiculous and wanted to migrate your translations to MySQL. Piece of cake, you wouldn’t even have to implement a driver as the package comes with a MySQL driver prepacked, you’d just have to set the driver up, which would take you something between the time needed to boil and egg and the time needed to take a shower, and then migrate your translations. MySQL, along with JSON, are first-party packages available within the package that require little to no configuration at all. Pretty neat, ha?
I could keep ranting on and on about the benefits of this package, but I wouldn’t take up more of your time here. I’d just suggest you visit the repo linked two paragraphs earlier, and read more thoroughly about it there.