This page has been moved to How to use Git for GNOME translators, under the GNOME Translation project. That is the final destination.

What remains in this page is the rest of the discussion regarding i18n and the move to git.

Statistics generation

Damned Lies is already able to track git (along cvs, svn, bzr and hg) modules and to generate stats for them. See e.g. http://l10n.gnome.org/module/avahi/

Translation workflow

For technically-skilled commiters without bandwidth limitations, the current workflow can easily be adapted to git, as far as some basic documentation is written. See the next section below for a walkthrough, using the Git command line tools to commit translations.

However we're still aiming to provide an easier process to lower the barrier to translation workflow, without requiring the knowledge of any source control system. The Transifex tool has paved the way to such a simplified workflow where translators can upload po files, and the server then takes care for the committing process. We aim to reconcile Transifex and Damned Lies in the future, but currently the respective needs of these tools are still somewhat divergent and we're not convinced to be able to merge them in the near future.

The recent integration of the 'Vertimus' functionality in D-L where translators can upload their translated files for review is a real advantage now as the remaining steps for automated commits is quite straight-forward to implement.

Here's some thoughts about a possible implementation of Damned Lies - git integration:

• D-L checkouts and follows local branches (untouched: pull/fast-forward) for each module to generate fresh POT files following the git-commits-list

• D-L checkouts and publishes a '<branch>-translations' branch for each 'followed' branch of each git GNOME module

• po files uploaded on D-L and ready to be committed are committed in the local 'translations' branch
• GNOME modules pull from the D-L 'translations' branch whenever they like, at least once just before every release. (This might be integrated to provided maintainer scripts)
• D-L keeps track about whether specific translations are upstreamed or not (comparison between 'master' and 'translations' branches)

Alternatively, we could also make D-L to push to a central server, but it seems more in the git spirit to host branches with changes which everyone can pull.

ChristianRose: Although I'm not very familiar with DVCS workflows and best practices, as opposed to regular VCS workflows and best practices, I must say I don't like the first approach at all. At least from the description, it delutes the "branch" concept and seems in general like bad configuration management practice:

• It sounds like translations that translators would have thought had been finally "committed" from Damned Lies, and would actually be upstream, would actually be stored in a hidden branch, and not be in the master branch at all. This adds confusion -- things that we would claim had been committed have, for all practical intents and purposes, not been committed.

• Second, and this is even more important, it requires that maintainers remember and do pull translations before a release. Many times adding an extra step that maintainers have to do before a release is a recipe for some people forgetting to do it. This has failed before, in for example the Translation Project, where maintainers are required to manually add the translated contributions to their tree before a release. Many are the modules there where maintainers forget to do exactly that... Why add an extra, possibly unnecessary step in the first place, if we can expect some maintainers will forget it?
• Third, I honestly beleive "commit early" is a good practice in GNOME, in order to catch problems early in the process. If translators keep working through Damned Lies on a special branch, and then "commit" their work there and the work stays there for long, any problems will only be caught by many eyes possibly very much later when (hopefully) the module maintainer finally pulls the translations into a release. Consider a bug where a perfectly syntactically valid po file contains a too wide translated message which doesn't fit in the applications UI at runtime, and therefore breaks the UI. Today, such a bug may be caught early from testers building from SVN trunk, if the po file is committed early, and may be fixed before a release. With this proposal, it would only be available to many testers after a release, not when checking out and testing from the master branch.

I like the second proposal more, where a "commit" actually means that the contribution has been pushed to the master branch.

Furthermore, I think it is important to stress that committing through Damned Lies should be optional. Trusted translators should be able to use command line git, if they so like, in order to push their work, and for those who prefer this workflow, this procedure should not be hindered or made more difficult. We must continue to require that all GNOME modules have their master branches be kept on the same server (git.gnome.org?). If some module maintainers think that the Git move means they can keep their master branch of their GNOME module somewhere else, we have lost, as trusted translators are then blocked by different permissions on different repositories. And no, I do not beleive Transifex is a solution. First, it's not command line. Second, that part aside, in theory it's good, but in practice you can read daily on the fedora-trans-list about modules where trusted translators are effectively blocked from contributing by any other method than patches to bug reports, because of deficiencies in Transifex or how module owners set up (or did not set up) their modules to work with Transifex.