A workflow proposal for I18n with Git and a non-developer

A few weeks ago we migrated jovoto from Gettext to the new I18n that became available with Rails 2.2.

In the Gettext approach we had the following workflow for collaboration with a translator.

• Add code with new/updated calls to Gettext’s translation methods
• Run rake gettext:updatepo to pull new English strings into the po file
• Put po file on a network share and tell translator to start working
• Wait for translator to finish translations, get the updated file from the network share and commit it all to Git

This approach had some downsides (besides the obviously giant downside of using Gettext).

• There is a gap between the last two steps and the size of this gap can be anything from minutes to days, taking into account that in a small team the translator is not a dedicated translator, but someone who just happens to have a sense of proper language
• After passing a po file to the translator, the po file is somehow ‘locked’ until the translations are done

Now I came up with another approach that takes a little preparation and learning but should save us some time in our daily work. Here’s the preparation part.

• Teach the translator some basic Git and give him access to the repository
• Install the translate plugin
• Setup an instance of your app that can be used for translation work
• create symlinks in your public/ directory that point to your translation files

And here’s the workflow for new/updated texts. For developers.

• Add code with new/updated calls to I18n’s translation method
• Commit your work to Git
• Tell the translator that there is some work to do

For translators.

• git pull
• Access the UI and add/update the translations
• Fetch updated translation files and overwrite local versions
• git diff, just to make sure that all the changes are fine
• git commit, git push, tell the developers