I have been asked in advance why I chose gettext .PO files to store translations and we briefly discussed that issue. gettext was written for translating messages and not neccessarily whole paragraphs of free text. Its key tool used for updating translation sets,
msgmerge, uses fuzzy matching with the intention of producing better results but this tends to fail. There is no notion of versioning and VCSes (or patch queues) need to be integrated into the workflow to retain history and inline markup is still a whole different can of worms (which I need to meditate about). The two selling points for .PO files are its suitability as a key-value store and that there are established tools after all. The other shortcomings have to be overcome by the new tool which will monitor version control and display stale documentation segments (and exports message catalogs along the way).
We had a look at Publican, a publishing system based on DocBook XML. For translations they use .PO files, too — it’s turtles all the way down.
It quickly became apparent that the tool for maintaining document translations will be separate from Sphinx’s core. There are already projects verging into the same direction, eg. Transifex / Txo or Launchpad Translations (which both neglect change tracking and are built for UI translations).
As there has to be at least one public instance on python.org we need to authenticate users. Invitations gained quite a bit of traction and give individual translation communities (groups) the possibility to self-organize. Integration with Roundup (Python’s bug tracker) would be nice-to-have but is not too important for now.
If you want to participate in our IRC meetings, we’ll be in #pocoo Wednesday evening.