0
votes

The Django-based web application I'm working on is translated to a few different languages. So far we've used gettext/PO files for translating static files (text in code and templates, static pages); CMS pages and texts stored in the DB are translated via the admin interfaces.

This common setup works well for us developers but is not favored by our translators who'd rather always use their translation tools (with PO files) instead of using the admin interface.

Now that more and more of our content is migrated from the code to the database we tried using gettext for texts stored in the DB. While the idea sounds good the workflow around it is quite cumbersome:

  1. Editor changes English text in the admin interface
  2. Developer runs command to extract messages on a host that is connected to the production DB
  3. PO file is sent to translators
  4. Translator sends file back to developers when she's done with the translation
  5. Developer compiles mo files, checks it in the code base and deploys

While some of the steps could be automated by using a service like Transifex I don't see how to get around the last step. Having to deploy as a result of a database change sounds wrong.

Has anybody been able to come up with a sane gettext-based translation workflow for web applications that does not require deployments?

1

1 Answers

1
votes

We use Django-rosetta (which has an added benefit to not care where the PO entries are coming from) to manage most of our i18n needs. In regards to what you are asking here is the workflow we ended up with:

  1. Translator logs into rosetta using its own admin interface
  2. Rosetta parses all po files and renders the page to edit translations
  3. Every time users hits save, rosetta restarts itself along with django and all changes are now live and applied
  4. If the translator goes back to django they will see how their new strings look like
  5. If the translator prefers to use their own PO editing software they can but then they have to provide us with the new version which we discourage

We wrote some scripts to help us with additional automation steps, but this setup has worked exceptionally well. We have even integrated (after some custom modifications to rosetta code) our non django based system into rosetta for easy translations.