We have it split in our applications. We work with standard language files, and all developers create the english versions only. We have a backend admin module that can import these into the database, and automatically mark the delta's to aid the translators. They use the admin interface to make translations, which in turn will generate new lang files for the language they have translated to.
The application is unware, it just loads the lang file, or falls back to english if it doesn't exist.
It's imho a lot more transparent (to both the application and the development teams) then an integration in models.
Also, you have covered the model aspect, but the rest of the applications need translations too (text on views not related to DB fields, menu items, error messages, etc), and your solution doesn't cover that.
I understand your concerns, but this is especially for dynamic data, so this applies for something that changes often. For example a multilingual webshop. In that case the translations must be edited quickly.
But I am know thinking about something other than this implementation, because this way the mentioned editing cannot be don easily and the cached data can easily get inconsistent.
Anyway I would like to use the Lang class, but I think in a webshop with 50000 products loading the lang files takes too much memory.
So now I am trying with the EAV implementation.
My basic problem is the amount of data, and the possibility of quick editing. And using either Lang files or cache these problems are not solved.
In that case it's not a language string, so you shouldn't treat it as such. It's an intergral part of the design, it is application data. In this case a product that has descriptions in multiple languages. If it was only a single description, you would not have considered putting that description in a lang solution for a second.
This should be dealt with in your database design. Create products->has_many->descriptions, and make descriptions with a compound PK which is constructed from the product id and the language code (so product 1 has descriptions 1-EN, 1-FR, 1-DE and so on).
In your relationship definitions, include the selected language code as a condition, which you update at runtime (when you know the users language selection). This will make sure that the ORM will automatically filter on the correct language.
Donate
