Translation queue

[pharman]

I am considering ways to improve the workflow for maintaining translations. The data grid is cool if you know what you want to do, but our system has thousands of translation strings and 10+ languages so we frequently have missing strings. I am thinking of creating a queue that prompts people to enter missing strings - any thoughts? @cedric-g

[rvanlaak]

On the https://github.com/lexik/LexikTranslationBundle/tree/list_missing_translations branch we are busy to create a way to translate per page request. As Symfony 2.7 has a profiler bag with all translations, that is a really nice scope to start translating from. How does that workflow sound to you?

[cedric-g]

Hi, I agree the grid is not the best to manage more than 4 or 5 languages. An idea would be to replace the grid by 2 div, the left one to list/filter translation key/domain pairs and the right one list/edit the translation for the selected key from the left div.

[rvanlaak]

That all languages are shown in the grid is nice, because it enables the translator to select its own source and target language. Maybe the configured columns could be stored in a cookie, that will make the grid easier to use.

[rvanlaak]

But, maybe there is a need of two extra pages next to the grid:

• Overview page with some simple statistics, so translators can track their process (to solve queue issues)
• Detail page to translate one key. This page should take the active request token filter of the grid and the cookie with active columns into account. So the starting point could always be the grid.

[kminh]

Probably related, how does this bundle currently handle conflicts between translations in the database and ones in the files? Such as changes or removal of messages in files by developers? IMO they are good candidates to be put into the message queue, after running the import command, so translators can review them manually.

It should be easy to handle removed translation keys, but for updated ones we might need another column (e.g. "Original") to compare against.

On the https://github.com/lexik/LexikTranslationBundle/tree/list_missing_translations branch we are busy to create a way to translate per page request. As Symfony 2.7 has a profiler bag with all translations, that is a really nice scope to start translating from. How does that workflow sound to you?

I suppose this feature is only used in dev environment and any new translation keys are added to the files, not database?

[rvanlaak]

The bundle has a DatabaseLoader that overrides the translations from your other loader with the ones from the database.

First I also thought of this bundle as one to only be used in debug environments, but because the translations are cached after the first load from database this actually can also be used in PROD.

My vision on the translation process is that the VCS should be the central place for the translations, so dumping the translations as xliffs and committing the changes should be the way to go. Maybe @cedric-g can document something about the merging process between different environments?

[cedric-g]

@kminh The bundle does not handle conflict, you can use the --force option on the import command to force the bundle to update the database value with the one from file and that's all. In case you removed some translations from your files the bundle won't remove them from the database.

For the list_missing_translations branch, yes this feature will only be available if the debug is enabled. And my first idea was to add new keys into the database (this is not implemented yet).

@Rvanlaak We originaly created the DatabaseLoader to allow one of our custumer to edit translations by himself. And now with this customer the process is like:

• while the development we only create translations files for the main locale.
• we have a kind of pre-production instance the translators of our customer can access to translate the messages.
• we created a script to sync the pre-production and production database once a locale is completely translation.

And of course in production on only load translations from the database:

lexik_translation:
    resources_registration:
        type: database
        managed_locales_only: true

[kminh]

Isn't it faster to load translations from a flat PHP file?

If there's gonna be a missing translations feature (added to the profiler), this would be my workflow (if supported):

• (dev) view missing translations in profiler, translate them on the fly (same UI as https://github.com/adrianolek/AOTranslationBundle) but save them to file (I prefer files, but can be db, configurable). No need for multiple locales, just the default.
• (staging) use the import commands to import translation files from the default locale into DB. Customers make changes to the DB.
• (prod) run a script to invalidate the (staging) translation cache and then sync it with the (prod) translation cache. No more db involved, and this bundle doesn't even need to be activated on (prod).

IMO, the DB is merely an intermediate tool that allows the editing of translations. That's why a queue would be very useful (for updated and removed strings).

Using the above workflow will require backing up the staging server's DB, of course.

[rvanlaak]

Isn't it faster to load translations from a flat PHP file?

Eventually the translations are loaded via the caching layer.

I like your translation flow, but think this bundle should support all types of flows. Improving the import/export command and the translation grid would allow you to arrange your own flow.

[pharman]

Interesting read, I'll keep an eye on the progress of the branch.