Do you mean create N different field, for every language
Description_EN
Description_IT
Description_FR
Description_ES
Do you mean this??
But is not better to have a single field in DB and use this field for manage translation with external file? I mean that field in DB is a variable for a function that translates from variable to right language. What do you think?
I’m facing a similar situation with a website I’m starting to build. I think @orey’s solution is better but only if one is absolutely sure that no more languages beyond the initial 5-10 will be supported. If more languages may be needed afterward then I would use @nineinchnick’s approach.
I think in the end the language structures should be invisible to the application logic. That is, you set current language somewhere and all the components shouldn’t rely on knowing that value, just like with using Yii::t() for labels.
Using ORey’s solution, there could be a getter for an attribute that would read the value from the proper one.
Using a relation in the database there could be a condition in the default scope that would make sure only one row would be returned for the current language. And that one row could be further wrapped in a getter to avoid reading it like an array with one element.