Ibexa DXP Discussions

Community discussion forum for developers working with Ibexa DXP

Front-End Translations

Is anyone handling their front end interface translations in an efficient way that doesn’t require constant developer resources?

I know that the JMS Translation Bundle is being used and it has a back-end admin interface for editing and creating translations that doesn’t require editing the YML files directly. However, this interface is not locked down behind a login system and is only recommended to be run in a development environment since it is writing directly to those files. So I get why this would not be a great idea to enable this. We are using platform.sh so we would have to enable Read/Write permissions on those translations folder and ignore them in git. That would mean we would need a way to pull down those translations locally to keep in sync.

I have left out an important part which is adding new translations to the TWIG templates. That would always remain a back-end developers job to edit that source code to apply new translations. What I am look for is adding new language translations so we have the front-end twig edits in English in place but when we bring on French or German we would want to create new translations only in the YML file.

I hope that makes sense. There are times where translations need to be modified and with the platform.sh set-up that would require a full environment rebuild for something pretty basic. If this is a true developer task then so be it but I’m investigating if there is another option.


Hi @travis.raup!

Maybe you should look how we handle translations for the admin interface for eZ Platform.
Here is a post describing the approach of in-context translation: How to help to translate eZ Platform v2

We are using crowdin: https://crowdin.com/project/ezplatform.

Regarding platform.sh, you won’t have the choice to deploy every time there is a change on the repo.

Hope this helps.

1 Like

Thanks @sylvain.guittard

I really like that approach to use crowdin. We could manage the translations there and then export the yml/xlf files and commit them to the project’s repository. That seems pretty solid. It would take discipline that no one would ever manually edit those translations files directly in a development environment. The source of truth for the translations would reside in crowdin.

You are right about platform.sh there is no choice about the re-deploy for repo changes. Which is the whole point of platform.sh. I originally had thought maybe these translations could be in a database however that doesn’t seem efficient.

1 Like