GorillaApe
GorillaApe

Reputation: 3641

Database translations with doctrine

After thinking a lot how to support i18n i came up with one of the accepted solutions to have a seperate table.
Problem with Translatable
I installed Translatable from doctrine extensions as suggested but didnt work as i want and experienced users adviced me against using it. Even when having a seperate table it has the translatable columns in both main table and translations table and stores the values in an eav way. Also in case default locale changes (that happened to me and may happen again) it makes things complicated as default values at main table dont seem to have a specified locale.Also i have several translatable fields (5~).That would result in 5 or even more left joins in case of fallback.

Other Solution
The other solution i thought is having a separate table with translations only for each table and set the default locale and fallback maybe via a postLoad event listener.This way i could call obj.getTitle() without obj.translations['en'].getTitle() ,no need to provide locale.

The problem
The problem with this approach is the fallback.One workaround is during join to add a "WITH locale in ('en','de') for example.This would return lots more data but fallback would work. The other way would be using coalesce but it is impossible for doctrine to map it at entity. Is there any way to implement fallback effiently ?

Upvotes: 2

Views: 6742

Answers (1)

Florian Klein
Florian Klein

Reputation: 8915

You can have a look to https://github.com/KnpLabs/DoctrineBehaviors#translatable, which is the best solution we've found after digging a lot into it.

We're currently using it for many entities, and it works pretty well. You can query translations as any other entitiy, joins, using DQL for example.

And yes, you could easilly imagine a fallback maechanism, using existing api.

Upvotes: 5

Related Questions