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:
If we break down the needs, they tend to fall into two parts - workflow, and distribution
Two cases:
Pootle servers have a further two cases:
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).
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...
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...
We need:
We also need to decide how much of this is overkill
Currently we call the command line programs, but there are alternatives:
There are two modules call PyCVS - http://software.cnx.rice.edu/downloads/python/pycvs/ which is a wrapper to the CVS commandline, and http://pycvs.sourceforge.net/ which is an implementation of the CVS protocol. There is also an implementation like this in the Python Demo directory.