Towards a GNOME CLI translation management tool
April 8, 2009
In Designing a command-line translation tool for GNOME, I described how a CLI translation management tool would be used to ease the work of a translator with commit access. The discussion was continued with Leonardo‘s post Parsing damned-lies’ releases.xml.in in the command line.
The stage we are now is that we have a tool (not official GNOME tool, but rather at beta testing phase!) that can manage the repositories for us, so that the checking out and committing can be fairly automated. The source is available at http://github.com/simos/intltool-manage-vcs/.
We show two working examples.
Let’s say we want to update the documentation for gcalctool. We run
$ ./intltool-manage-vcs --language el --release gnome-2-26 \ --username simos --module gcalctool --transtype doc --init Release : gnome-2-26 Language : el Category: admin-tools Category: dev-tools Category: dev-platform Category: desktop Module: gcalctool, Branch: gnome-2-26 Download completed successfully.
$ _
In the PO/ subdirectory there is a PO file for gcalctool. We update it using our favourite translation tool, and then
$ ./intltool-manage-vcs --language Greek --commit Sending el/el.po Transmitting file data . Committed revision 2475.
$ _
Let’s see another example. We want to update the gnome-games documentation. These are several individual PO files, for each of the games.
$ ./intltool-manage-vcs --language el --release gnome-2-26 \ --username simos --module gnome-games --transtype doc --init Release : gnome-2-26 Language : el Category: admin-tools Category: dev-tools Category: dev-platform Category: desktop Module: gnome-games, Branch: gnome-2-26 Download completed successfully. $ _
There are several files,
$ ls PO
aisleriot.gnome-2-26.el.po gnibbles.gnome-2-26.el.po
gnotravex.gnome-2-26.el.po README
blackjack.gnome-2-26.el.po gnobots2.gnome-2-26.el.po
gnotski.gnome-2-26.el.po same-gnome.gnome-2-26.el.po
glchess.gnome-2-26.el.po gnome-sudoku.gnome-2-26.el.po
gtali.gnome-2-26.el.po START
glines.gnome-2-26.el.po gnometris.gnome-2-26.el.po
iagno.gnome-2-26.el.po gnect.gnome-2-26.el.po
gnomine.gnome-2-26.el.po mahjongg.gnome-2-26.el.po
$ _
We enter the PO/ subdirectory and we update those files we wish. We can also run scripts on the PO files. For example, all these documentation files contain the same fragment of the FDL license, so we can translate the license once, and then merge automatically to all translations.
Finally,
$ ./intltool-manage-vcs --language Greek --commit Sending el/el.po Transmitting file data . Committed revision 9014. Sending el/el.po Transmitting file data . Committed revision 9015. Sending el/el.po Transmitting file data . Committed revision 9016. $ _
In the above example, we updated the documentation of three of the games.
Here are tips when using this tool
- There is a –dry-run option that is useful when experimenting or trying for the first time.
- You can filter which group of a release to download, based on category. Existing categories are desktop, admin-tools, dev-tools, dev-platform. Also, on translation type, either documentation or UI (if you do not specify, we get both). On module, by providing the module name.
And the current limitations
- We currently only support SVN. This will change once the repositories move to git.gnome.org, in about two weeks time.
- You need to have at least an initial translation (currently, the script does not svn add files). To be fixed once we move to git.
- We do not currently update ChangeLog files. That’s why gnome-games is so cool for these experiments. Due to the git move, we would not need to mess with ChangeLog files.
- We are dependent on the http://l10n.gnome.org/languages/el/gnome-2-26/xml URLs (replace el with your language). These URLs expose the release modules information in a nice XML file. Previously, the information used to exist in an XML file in the repository of damned-lies. Now, the information lies in the mysql database of damned-lies+vertimus, and is exposed through the above type of URL.
- Due to the previous point, we commit to branch or trunk, depending on what is available in the latest release (gnome-2-26). That means, my translation fixes in gnome-games have not made it to trunk (HEAD). This is something that can be fixed with a workaround. It would be actually cool to use this tool to commit to both gnome-2-xx and master at the same time.
- We currently do not deal with figures.
Considering that damned-lies+vertimus will be having commit functionality soon, I think that having more than one option for easy commiting translations is good.
April 8, 2009 at 1:22 pm
Nice work!
April 8, 2009 at 2:13 pm
Excellent work Simos.
I think it’d be very interesting to see the tool interoperate with Transifex too. Ideally it should use Tx’s commit mechnism, which would reduce the code quite a bit, and allow submission to any VCS backend.
April 10, 2009 at 12:12 am
Thanks Philip, Dimitris.
Dimitris, regarding Transifex, I believe that it is of the interest of GNOME to have several options for the committing of translations.
Technically, you would need a new GNOME git account and a facility that would allow language team coordinators to delegate the committing of translations through Transifex. That is, a language team coordinator would enable the committing of translations through this additional avenue.
My primary view of this script is to have permanent local repositories of a whole GNOME release (about 2GB), and the script would allow to bring under a single directory all PO files. Having the same interface to submit translations through Transifex would be another big plus.
April 21, 2009 at 2:20 am
I’m glad you put this together, and I’m really looking forward to use your tool with Git. By the way, how does our script handle branches?
April 21, 2009 at 10:42 am
@Leonardo:
The script is being updated, and I think at this stage it is useful for those that are willing to look at the Python code.
Having said that, you can use the script now to create clones for, let’s say, gnome-2-26 with a single command. Then, you can run with ‘–update-vcs’ which will go through the local repositories and do ‘git pull –rebase’ for you. It takes 8 and a half minutes on my system to go through the 93 modules, if no changes are there.
Regarding branches: We use full clones. When commiting, we check through the release that was specified if a module is at ‘master’ (we then commit to ‘master’ only), or if a branch is specified, we commit to both branch + ‘master’. This shall be added soon to the script.