To internationalize your Doctrine entities, you have basically 2 ways:
- Add a locale field to your entity and manage many instances that locale. Simplest way, but can create unwanted information duplication.
- Split your entity in two, with a translatable entity that contains common fields not related to translation and a dedicated one, a translation entity that contains only translations fields
You can and should use both ways in the same application according to the need of the entity.
If for the first and simplest way, you don’t need a bundle, for the second way, you have differents potential. Ordered from the oldest to newest:
GedmoDoctrineExtension - StofDoctrineExtensionsBundle The most know solution. Back early 2012, this is the first solution I used. You can ease its install with the StofDoctrineExtensionsBundle. But be carreful, I don’t recommend and support anymore its Translatable feature. I’m not a fan of its old and buggy implementation and I advice to wait for the 2.4 release.
KnpDoctrineBehaviors A less popular solution but very nice use of PHP5.4 traits and easy to understand. Back early 2013, this was the second solution I used. KnpLabs do good bundles (KnpMenu, KnpPaginator, …) and I advice you to use this bundle.
A2lixI18nDoctrineBundle Middle in 2013, I developed my own solution, inspired by the Knp one but with use of Doctrine Filters to try another approach. Give it a try if you doesn’t need the fallback locale feature. And yes, adding tests are always plan…
PrezentDoctrineTranslatableBundle End of 2013, another solution inspired by the Knp one come out but with some performances boost by the use of the metadata caching. I always need give it a try, but from what I’ve seen in the code and documentation, it seems all good!
These 3 last solutions (and the incoming 2.4 version of GedmoDoctrineExtension) store data in database in the same way, so you can switch from one solution to another easily.
For manage edition of all locales at the same time, I published end of 2012, the A2lixTranslationFormBundle The last version is only compatible with these 3 last solutions again.
I published a simple demo on GitHub where you can test A2lixI18nDoctrineBundle or KnpDoctrineBehaviors independently with a custom backend but also with Sonata Admin, both use A2lixTranslationFormBundle. PrezentDoctrineTranslatableBundle is plan too.
You’ll note that Sonata work like a breeze with A2lixI18nDoctrineBundle, but some problems stay to fix with KnpDoctrineBehaviors about filtering the search in all locales by default and not the current locale. A basic locale switcher is include in the right top corner for Sonata.
This Demo include use a fork of SonataAdmin (PR 2262) and a fork of Sonata Exporter (PR 41), both to manage magic method __call. Hope theses PRs will be merged, otherwise, it can work but with a more verbose version of translatable entities…
Have a look at A2lixTranslationForm additional features for additional features too. I’ll see to complete the demo.