Using Git for translations

Git is a distributed control version system, and it is widely used for maintaining source code in libre software projects.
Git can track changes to any text file (not only source code), so may be used also to maintain text-based documentation files and translation files.
In this post I will present some tanslation projects (GNOME, The Ruby tutorial, Drupal and LibreOffice), and how they use Git in that context.


GNOME is one of the desktop systems available for GNU/Linux. GNOME includes a window manager, file browser, text editors, media players and many other applications.

All the GNOME tools and programs are hosted in the GNOME git repositories:
They use “.po” files to translate the different tools. You can find a small guide for GNOME translators (a complete guide is also available), on how to use git to clone the repo of the program that they want to translate, find the .po file to change, commit the changes and push the improved file (if you have no permissions to write in the GNOME repositories, you can upload your file to the translators web interface Damned Lies for revision and approval).

As you can see, the management of translations in GNOME is quite similar to the managment of the source code. (Of course you should subscribe to the corresponding member list, and read the reference docs (for the Spanish team, for example, you can find all you need in the Spanish Team web site).

Ruby on Rails Tutorial (book and examples)

The Ruby on Rails tutorial  book consist in a HTML book plus Ruby examples, writen by Michael Hartl. The HTML source of the Rails Tutorial book is available under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License, and source code of examples are licensed under MIT License and the Beerware License. The author maintains the project in GitHub and provides instructions to anybody wanting to collaborate in translating the book to any language.

Basically, you need to know that there is a branch of the project for each different language, and the HTML files for the book are in /public/book folder. So you clone the repository, start to track the branch you are going to collaborate (or request to create a new one), change the HTML files, commit and push your changes.

This is a different approach from the GNOME style: in GNOME projects, there is a file for each translation (the *.po files), so there are no different branches for different languages, since they don’t touch the same files. In Ruby tutorial, many files are changed, so a branch for each language is a good way for structuring the repository and organizing contributions.


Drupal is a content management system written in PHP. It was using CVS as control version system but in the beginning of 2011 they migrated to Git. Along with this change, other different (but related) decision was made: start to use their own web platform to manage translations. You can find more information including the reasons for this decision in Maintainer’s December 2010 newsletter and in this post.
This approach separates the “code development” and the “translation development”. The main positive aspect is that you can attract many new translators that are Drupal users but don’t know anything about developing, git and PO files. On the other hand, if anybody goes to the git repositories to get all the drupal code, she will not find the translation files there.


LibreOffice is an office suite based on OpenOffice. It uses a web platform for translations: a Pootle server. However, it a slightly different approach from Drupal: they also host the .po files within the source code. How is this coordinated? PO files for each supported language are stored in the source code in the module called ‘translations‘. That module is maintaned by Andras Timar, who gets translations from Pootle or from alternative sources before releases and push them to git. When the source code changes affecting the templates for translations (new strings added, or string removed, in original English language), Andras Timar contacts TDF Pootle administrators to update the templates.

I am sure there are many other ways to use git for maintaining translations. I will keep investigating but if you know anyone, please leave a comment and I will update this post.

About larjona

My name is Laura Arjona Reina, I am a libre software user and fan of the free culture. If you want to contact me you can write an email to larjona [at] larjona [dot] net I am @larjona at in the social network. --- Me llamo Laura Arjona Reina, soy usuaria de software libre y fan de la cultura libre. Si quieres contactar conmigo puedes escribir a larjona [en] larjona [punto] net Soy @larjona en el servidor, de la red social
This entry was posted in Uncategorized and tagged , , , , , , , , . Bookmark the permalink.

3 Responses to Using Git for translations

  1. Thomas Zahreddin says:

    drupal uses a own translation server – you could call it the pootle of drupal:

    There are better ways to handle translations, than as .po-files in git repositories imho.

    • larjona says:

      I agree with you, the web platforms for translators are great. I was just wondering how these mechanisms were integrated (or not) with the version control system used for the rest of the project files.
      Thank you for reading!

  2. Vanessa says:

    I use something else for translations: It’s very handy with its reference language and translation memory features.

Comments are closed.