[PATCH] With corrected documentation

[Martin Geisler]

Ingo Proetel <proetel at aicas.de> writes:

> Am 11.08.2011 23:54, schrieb timeless:
>> I'm not sure you really want to mix untranslated text with foreign languages.
>> 
>> It's likely to get horribly messy for RTL languages.
>> 
> It looks like we have three options:
>
> - separate texts for translation and untranslated commands (my last patch)
>   This gives translators several strings for translation without much
> context.
>
> - one text for all options but including untranslated commands (what I
> described below)
>   This gives translators one text with the full context (questions and
> all possible replies) but requires commands stay untranslated.
>
> - one text for all options without command and go back using indices as
> return value
>   This seems the best solution for translators full context and no
> further requirements (except that the sequence of command helps stays
> the same.) But for programmers it gets hard to figure out which index
> corresponds to what command.

I don't think it is an advantage to put all the options into one big
text. Two disadvantages are that it requires more re-translation is we
ever update the English text and that it will add more "syntax" to the
string seen by the translators since they will have to recognize that
some parts of the string must be left unchanged.

Having each option in its own translatable string is fine. The
translators will have the needed context since the strings will end up
near each other in the .po file.

So go with something where we have

  [('abort', _('Should we &abort?')),
   ('ignore', _('&Ignore the error'))]

in the source so that programmers can match on 'abort' and 'ignore'
afterwards (untranslated) and translators can translate the two strings,
keeping the characters marked with '&' consistent.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/