My colleagues know I do more revision than translation work. I’d rather be translating, but it’s important for the translators’ motivation that their work receive the due attention, i. e. that their translations be reviewed and committed as soon as possible. This article describes my routine as a member of the Brazilian GNOME translation team.
When the translation is ready, the translator creates an bug report on GNOME’s bugzilla and attaches the translation. Usually, the file is compressed with gzip, and marked as a patch. Not that it’s really a patch, but marking it so allows me to mark it latter as committed. Once I even found myself on the GNOME bugzilla statistics as one of the top patch reviewers of the week.
I set JHBuild to check out GNOME (currently 2.20)’s modules (programs, libraries etc.) on a particular directory (~/linux/svn/gnome-2-20). Besides being able to compile GNOME on a separate directory (~/linux/opt/gnome-2-20), JHBuild automates the batch source code updates; for single module updates, I prefer using directly the svn command. Each module has its own directory, and the translatable modules have a po directory inside, with a message catalog for each locale (e. g., pt_BR.po) as well as the ChangeLog and the LINGUAS files. When the team translates the module for the first time, we have to add the locale code to the LINGUAS file.
When I get a translation from bugzilla, I save it as pt_BR.po.gz on the corresponding po directory. Then I open the terminal, change to the directory and uncompress the translation (gzip -fd pt_BR.po), overwriting the old message catalog (pt_BR.po) on my hard disk. Next, I update the source code (svn update ..) and update the message catalog according to it (intltool-update pt_BR). Conveniently, the last command also tells me if there’s any untranslated message left. The file the translators get from GNOME translation statistics site was already submitted to this process; I repeat it to catch any update the source code might have received after the translator fetched the catalog.
I use Gvim to review the translations. It might not be easy to learn, or even pretty, but it’s very agile for searches and substitutions. Oh, and I didn’t learn to use Emacs yet 🙂 Instead of reading every single translation, I concentrate on the translator alterations. For that, I run svn diff | less in the terminal, and browse through the altered messages with /^+[^#] (thanks to Aurélio’s regex book). When I change something, I take a note on it with Tomboy, categorizing the changes as Done or To Do. I do small changes right away, but leave the batch editing (e. g., changing the translation of applet from mini-aplicativo to miniaplicativo many times) for latter. At the end of the process I tell the translator about the changes I did.
Sometimes Brazilians say the import thing is not to know, but to have the phone number of whoever knows. Usually I review translations with the IRC open, so that other translators and I can help each other without waiting too long for the answer. When we need to open more the discussion (because we are rethinking the standard, or because we don’t know it), we send the question to our GNOME translation team mailing list, if the issue is restricted to the project, or to the general purpose Brazilian Portuguese free software translation list, if the issue interests other translation teams. Other times, instead of asking other people, I have to check the message context. To discover that, there are plenty of options: peeking at the source code, opening a glade file with the corresponding application, compiling the module to look for the message at the interface, or even searching the web. But, as Andre Kappler said, when an original message is hard to understand, the right thing to do is to open a bug report so that developers will make our lives easier, following the GNOME internationalization tutorial.
After reviewing the translator alterations, I check the whole file with translate-toolkit, particularly with the pofilter --gnome pt_BR.po | less command. This tool frequently warns about errors the translator and I didn’t notice yet, even if it most of the “errors” are in fact good translations. Finally, I spell check the translations with Vim. I changed the message catalog syntax highlight to make Vim check only the translated messages spelling, which increased very much the feature utility. I’m enhancing this modification, and should release it soon.
Before sending the translations, I have to describe them at the corresponding ChangeLog file. I start by using the prepare-ChangeLog.pl script to follow the file’s strict format, and then I add with Vim something like Brazilian Portuguese translation updated by Fulano de Tal <email@example.com>. In the terminal, I run head -n 15 pt_BR.po or sed /^[^#]/q pt_BR.po, to select and translator name and email and insert it in the ChangeLog. After saving the file, I select the recently added lines and run svn commit in the terminal. I set my $EDITOR to /usr/bin/gvim --nofork when I’m on X, so that svn commit uses Vim to ask me for a commit description, where I insert those lines from ChangeLog. While my Subversion client sends the translation to the server, I come back to the bug report (which page was opened all the time) and mark the translation file as committed, and the report as closed. Then I add some nice message, like Committed, thanks!
To avoid unnecessary typing, I stored my commands sequence in ~/.bashrc:
alias myPo="gzip -df pt_BR.po.gz && svn update .. && intltool-update pt_BR && gvim pt_BR.po && svn diff pt_BR.po | less && pofilter --gnome pt_BR.po | less" alias myChangeLog="prepare-ChangeLog.pl && sed /^[^#]/q pt_BR.po && gvim ChangeLog"
And you, how’s your translation routine?
Thanks to Vladimir Melo for the corrections and suggestions.