Translate Toolkit & Pootle

Tools to help you make your software local

User Tools

Version Control

Version control and networking / distribution are important topics for Pootle / Wordforge. This particularly relates to the 'file server' and 'distributed translation management' aspects.

For instructions on the current abilities of Pootle, see version control.


It would be great if Pootle could handle the following:

  • tracking upstream version control - updating from a central CVS, sending changes back
  • tracking changes made locally (and who made them)
  • being able to synchronise between different Pootle servers (or a local offline Pootle)

If we break down the needs, they tend to fall into two parts - workflow, and distribution


  • history per message rather than per file is nice (user x suggested string y, which was approved by z, etc)
  • history of messages, ability to revert (but this relates more to the review cycle than requiring a full history all the time)
  • integration with review cycle - what changes has user x made to this string? (again, usually only useful during the review cycle)
  • therefore relates to rights and workflow (which have their own interesting challenges in a distributed setting)


Two cases:

  • Being able to relate changes to an upstream version control repository
  • Being able to relate changes between Pootle servers

Pootle servers have a further two cases:

  • Wanting to push messages around as quickly as possible where connectivity is good
  • Being able to take things offline, work on them (in a translathon / locally for a dialup user), and then push them back

Proposed plan

Xliff already has scope for handling multiple translations of strings etc, we should use this for workflow. On the other hand, its good to keep a full history as well. But storing per-message history in a version control repository might be overkill (especially if we don't need it).

  • use Xliff to store stuff in the current work cycle
  • Use version control to store 'checkpoints'
  • collapse once a work cycle is complete so we don't keep hundreds of old strings in the Xliff file

For example, once a work cycle is complete, we could commit the current Xliff with all the proposed strings and their resolutions. When a new work cycle starts, we could start dropping the strings from the previous work cycle for any strings that are changed. So at the end of the new work cycle, any unchanged strings will retain their history from the previous cycle, but changed strings will contain just the current work cycle's history. At the end of the new work cycle, we commit again to the repository… This way we always have a file with VC info and we can get more from the VC server.

This would give us no data loss (we can get the full history for any work phase by retrieving the last version), and hopefully simplicity in the current storage.

Using Xliff for workflow as its intended also fits well into the general Wordforge philosophy…

For the underlying version control, we could use something like bzr or Mercurial.

The design here needs to be tightened up somewhat…

Requirements for upstream version control

  • pulling the latest version
  • merging changes intelligently, and requiring user intervention (through workflow) as neccessary
  • being able to push changes.

It may be easiest to require the person with upstream commit rights to have a local Pootle installation (so they can use their login details etc). In this case that scenario needs to be well thought through…

Requirements for offline scenario

  • being able to do offline changes locally and then merge to an upstream repository

Requirements for live server-to-server talking

  • it would be nice if servers are connected to have all changes sent in both directions to prevent conflicts
  • we probably need a definitive master / slave idea to make sure we don't lose anything
  • we need to be able to recover from disconnection (using the offline communication) - checksums / version numbers needed

Rights in a distributed setting

We need:

  • a system of global identification
  • the ability to list which other hosts are trusted for authentication
  • the ability to delegate rights (if permitted) between servers and/or associate user ids between servers
  • has rights for translation (with delegate) for af on
  • is associated by with
  • delegates translation rights for af on to
  • has a mirror of af on, changes are mirrored

Further investigation

We also need to decide how much of this is overkill :-)


  • XMPP (jabber) is a nice way to send Xliff to and fro as its basically a XML streaming technology
  • HTTP posts could be a nice option as thats how things are transferred from a browser
  • openid or such like as a (standard) means of federating identity
  • on the other hand jabber ids can be used as a indentity
  • XMPP has an advantage with disconnected transport perhaps (though this may require a local jabber server)


  • How do we handle PO format? It won't do a lot of the Xliff stuff
  • We could allow using local Xliff for upstream PO to enable all this work stuff, converting on the fly as neccessary
  • We could transport all PO files in XLIFF. Only works for people with XLIFF editors though. That way the messages are stored in XLIFF but the associated PO is in the skeleton (or the XLIFF could contain the XLIFF representation of the PO file per the spec…)
  • For people with PO editors, we could still provide the file as PO, and just incorporate changes to the XLIFF file when it is returned


Currently we call the command line programs, but there are alternatives:


There are two modules call PyCVS - which is a wrapper to the CVS commandline, and which is an implementation of the CVS protocol. There is also an implementation like this in the Python Demo directory.