Current workflows

Things that work and shouldn’t change

Translators go to Damned lies, browse their way to a page for a given translation to work on. One such page would be e.g. https://l10n.gnome.org/vertimus/gnome-builder/master/po/fr. From that page, they Reserve for translation and download the latest po file. Damned lies watches repositories for string changes and always provides an up to date version of any po file (for any module, branch, language). The translator then completes the translation offline with a dedicated translation software (poedit, Gtranslator, Lokalize…), goes back to the translation page, uses the Upload the new translation action. Translation is now marked as Translated in Damned lies. Reviewers browse their way to a translation with Translated status and Reserve for proofreading. They can view the changes on Damned lies or download the uploaded po file. Damned lies keeps updating (merging) uploaded files too, so they always match changes made to the repository. If the translation needs to be fixed, they can upload files as well. Once review is done and the translation is ready, it is marked as Ready for submission. Committers (a Damned lies role, doesn’t necessarily mean they have push access to git.gnome.org) and language coordinators can then Submit to repository and Damned lies will do the commit.

Users can report typos and other issues on the bug tracker. Translation team members (usually language coordinators and i18n coordinators) can then use the previously described translation workflow to fix the translation and close the bug report.

There are shortcuts in the workflow (e.g. as a language coordinator I can skip the review step when fixing a bug) but that is a detail that doesn’t affect version control or issue tracking.

Things that work but may be improved

Damned lies watches repositories and informs gnome-i18n@ when there’s a potential freeze break. An i18n coordinator will then go to the git repository web interface to check whether the commit is indeed a problem or just a false positive (there are some valid reasons to have strings appear, for instance strings that were not marked for translation by accident). If the commit is a problem, the coordinator reaches out to the developer that committed it and works out a solution (reverting, branching, freeze exception request…).

Things that should change

Some users attach actual patches to their reports. That is an issue because it means we have to interact with the git repository and we usually try to ask the user to the correct way to handle this. Ideally there would be a way to prevent translation contributions in the form of patches (or pull/merge request when the code workflow changes).

Damned lies is not able to commit new translations (i.e. languages for which there’s hasn’t already been a first commit) for help because it doesn’t know how to insert the language code into the HELP_LINGUAS variable.

Expectations

• We are not moving away from Damned lies. It has translation specific features that cannot be replaced with ones that were developed for coders.
• Ideally there would be no need to interact with git at all for most translators.
• Repository browsing is useful to find out what causes an issue or in which context a string is used, but there is no specific requirement for that apart from being able to read source code and commit history.

Other translation management platforms

Damned lies is the only platform that does what it does. Switching to another platform would simply mean losing the features described above.

Those other platforms certainly have other features (e.g. online translations, which means you don’t need to download the po file and use additional software to translate) but we care more about our current features than those.