[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re[2]: [TSVN] RFC: Doc Translation management

From: Jean-Marc van Leerdam <developer_at_bemy.demon.nl>
Date: 2005-03-21 12:22:10 CET

Hello Simon,

Monday, March 21, 2005, 11:39:36 AM, you wrote:

>> 1) We could go the GIMP way, split up the docs into lots of smaller
>> sections which contain all languages.

SL> I think that will be difficult to read. I am not quite sure how this
SL> will work, but if you have to skip over
SL> German/French/Dutch/Spanish/Bulgarian to get to Lithuanian it becomes
SL> harder to compare paragraphs, and just as easy to miss something.

Agreed, I don't think that is feasible as soon as more than say 4
translations are available.

>> 2) We could go the KDE way and split up the English documentation
>> into po files, which we then translate and merge back into Language X.
>> + Structure will automatically be consistent.
>> + Reference Ids (Xref) will automatically be consistent.
>> + Easy spotting of untranslated sections (poEdit), Translation status
>> on Web page.
>> + no changes to the english docs necessary.
>> + easy to create Docs in another Language.
>> + Fallback to english is automatically given if a section isn't
>> translated.

SL> That's a lot of plusses. I especially like point 4 ;-)

And another plus: translators get to use a single tool for their
translations.

>> - lot of work to get the first (German) translation up and running
>> again.
>> - (just a guess) translators work out of context, because they only
>> see single paragraphs and not the entire section at a time.

SL> It is a problem, but if we can provide the nightly html output easily on
SL> Berlios, then you only have to wait one day to see the full context, and
SL> the docs don't generally change very fast anyway.

Ideally the translator would need the full-text english version as a
reference, and an easy way to match the .po entries to that text.

>> If we are going to change anything, my clear favourite is option 2. I
>> just want to remind everyone of the boost in UI languages we got,
>> since we simplified the translation.

SL> We do seem to have a lot of willing translators out there - thanks guys.
SL> Translating the doc is a huge task, but it seems that (unlike the
SL> current system) you could do it one chapter/paragraph at a time, with
SL> the rest reverting to english.

SL> If we do that, we _must_ make sure that the english is squeaky clean
SL> before we start. Any changes to the structure, line wrapping, xml tags,
SL> etc. will throw up lots of fuzzy translations. It would be a good idea
SL> to review hacking.txt as well so we can agree on which xml tags we want
SL> to use for what, as it is not entirely consistent.

If most of the xml structure can be kept out of the actual text that
is to be translated, structure changes may have only a small impact.

I am in favor of the PoEdit way, and will attempt to provide a dutch
translation if the .po/.pot for the docs becomes available. (no
guarantees on the delivery timeframe however, I expect quite a few
more strings from the docs than the current 839 strings in the TSVN
.po :-D

Jean-Marc.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Mar 21 12:23:15 2005

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.