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
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)
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
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…
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…
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
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
firstname.lastname@example.org has rights for translation (with delegate) for af on pootle.openoffice.org
email@example.com is associated by pootle.openoffice.org with firstname.lastname@example.org
email@example.com delegates translation rights for af on pootle.openoffice.org to firstname.lastname@example.org
pootle.translate.org.za has a mirror of af on pootle.openoffice.org, changes are mirrored
We also need to decide how much of this is overkill
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: