Translation Teams: A Request for Help

Lübbe Onken l.onken at
Mon Jun 27 06:04:53 CDT 2005

C. Michael Pilato wrote:

> Thanks, Steve!  That's actually a pretty cool idea.
> Quick question, though -- I assume the granularity of a entry in the 
> bundle file is like ... a paragraph, or something.  If so, do your 
> translators not find working with chunks of that size and that 
> particular file format unwieldy?

Since I'm the guy who set up the TSVN translation process and takes care 
of the GUI and doc translations (besides translating German myself), I 
think I can tell you a few words about it.

If you use tools like poEdit (multi platform) to work on the .po file 
it's not unwieldy. The .po format itself is kept away from the translator.
* You can always look up the context of a paragraph.
* You get some sanity checks for free.
* You always know which paragraphs are outdated.

The only thing I find annoying are too long paragraphs (msgids). If the 
chunks are small, they are a lot easier to translate. A nice (bad) 
example is the help for 'svn st'. It's almost impossible to spot changes 
in the original without having a visual diff tool and the po Editor open 
side by side.

xml2po plays nice most of the time. Only if you are using own entities 
(like &version; to get your version number everywhere into the docs), 
you can choose between hell and damnation.
Since you don't want that entity to be expanded before creating the .pot 
file, because that would make existing translations obsolete, you 
extract the .pot file without expanding.

A) An example string like:
msgid "&app; &version; release notes"
msgstr "&app; &version; Freigabenotizen"

will always translate, no matter which version the software has.

B) Whereas a string like:
msgid "Subversion 1.2.1 release notes"
msgstr Subversion 1.2.1 Freigabenotizen"

has to be retranslated over and over again.

The problem I ran into with Example A) (and haven't solved yet) is that 
the entities get lost when the translated strings are merged back, so 
the above example would create: "  Freigabenotizen" (two blanks) in the 
output xml file. If haven't figured out why yet, but as I'm tracing 
this, I pick up some python and might finally solve the problem.

Example B) will work, but cause a lot of fuzziness when a version number 

If you don't use entities, everything is fine.

- Lübbe

   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\

More information about the svnbook-dev mailing list