That’s not a matter of using Damned Lies source code, it’s a matter of using its XML files with information about release sets, modules, languages and teams. Damned Lies’ source code includes both python code and those if XML files. When a developer branches its module, he announces it in the gnome-18n mailing list, and Claude Paroz updates the XML file in the Damned Lies source code, which quickly gets built to the server l10n.gnome.org. (Edit: now I found the part where Danilo proposed using data.py. I’ll leave it for you guys to decide )

The releases file could be use to check is the release name is valid, or to provide a list of avaliable releases. But most of the time the translator will choose the release without it. And there is a file for each the release/language, providing a lot of useful information: which is the correct branch for each module, where the files are located, whether if there are any errors, and so on.

I don’t really see why I would take code out of damned-lies for parsing what’s really a rather simple XML document.

What happens when a translator doesn’t have svn access, then? It should just produce the changed version and send it to someone? (I am finding it hard to see how resolving conflicts in PO files can be reduced for people using only anonymous access just by not using patches, but maybe I’m just thinking like a programmer.)

Eg. there is actually http://l10n.gnome.org/po/sr/releases.xml which is a post-processed variant of releases.xml.in with Serbian translations (you can also find other language translations, or use the generic http://l10n.gnome.org/po/C/releases.xml).

Also, Damned-Lies provides separate per-language XML files which contain direct links to translated PO files (or empty POT files when there is no translation), which can be fetched from eg. http://l10n.gnome.org/languages/sr/gnome-2-22.xml (and respectively for other languages). This is where you can get an always updated PO file from the <path> element (so no need to bother yourself with merging steps above—that’s what damned-lies does for you), and a path where a PO file should be uploaded (<svnpath> element).

I imagine a command-line script would work like:

$ get-pofile --lang sr --module=all # both could be defaults, i.e. lang from LANG environment variable
$ get-pofile --lang sr --module=epiphany --branch=gnome-2-22 # and we could have an env-var for default branch too (fallback to trunk if there is no such branch)
$ commit-pofile --update-trunk epiphany.gnome-2-22.sr.po

If you really want to parse releases.xml (though I believe it’s not necessary), you can make use of data.py in damned-lies itself.

So let’s see what we have as a series of operations:

A. The translator calls tsfx (or whatever it’s called) and supplies:
A project ID, such as “gnome-2-22″
A language code, such as “pt”
B. tsfx goes away and:
Retrieves releases.xml.in
Finds the list of modules and their branch IDs for the given project ID (e.g. module atk branch gnome-2-14, module gail branch gnome-2-18…)
For each of these modules, fetches http://l10n.gnome.org/POT/module.branch/module.branch.language.po where branch is HEAD if it’s trunk and the branch id otherwise; it fetches this file with the svn metadata intact so that it may be checked back in. (This may be accomplished if no other way is available by checking it out to a directory on its own under ~/.cache and hard linking the .po to the destination directory.)

C. The translator does funky stuff as appropriate to the .po files.

D. Either tsfx generates a patchset, for people who don’t have svn access…

E. Or it
Goes through and checks in each changed .po file with an appropriate comment in po/ChangeLog in the same svn revision.
Does the same again, only for trunk, if we weren’t using trunk.

Is that a fair summary?

Take a look at this shot message catalog, for instance. It wasn’t touched in years, and two of the translated messages are not part of the source code anymore. If I check out the module and run intltool-update pt_BR, I’ll get a new message catalog, refreshed to mirror the translatable content of the source code. That’s what the autotools do when the module is been installed, so the installed MO file has only the other two, current, messages.

Now, let’s suppose there a new message to be translated. Again, the message catalog in the repository will continue untouched, unless I commit something new. If I just check out the message catalog, I’ll get a PO file with 4 translated messages (100%), even if two are obsolete, and even if now there’s a hypothetical new message in the source code. To get this untranslated new message in the message catalog, I have to check out the entire module and run intltool-update pt_BR. That’s a lot of useless downloading! So, Damned Lies does that for us. It checks out everything, runs intltool-update, and provides the conveniently updated translations for download. When I say “updated”, I mean the PO file has the same messages as the source code; the message catalogs Damned Lies provides have the same translations as those in SVN. As an example, this is the same message catalog as in the previous example, but updated by Damned Lies. Of course, it’s completely translated, because the “new message” was hypothetical.

This is why we can commit translations to trunk and to branch at the same time. When we do that, we worry about completely translating branch, and about not losing anyting when we start working in trunk. When I focus on a branch (say, gnome-2-22) I don’t care if trunk is completely translated, because nobody is using it anyway. When we start focusing on trunk (say, near GNOME 2.24) we will use the intltool-update’d version of the same translation we committed to branch.

Suppose I committed some fixes in a branch, and other improvements in another branch (or trunk, whatever). It’s really hard to merge the two translations. intltool-update (and msgmerge, for which intltool-update is a warper) changes almost everything in the PO file except for the translated messages. Translators are aware of that, it’s sort of a fact of life. You are welcome to circumvent this at any time, but it’s not a priority.

I was going to ask whether I should wait to implement this until the next version of svn, but I see there’s a workaround given there.