RFC: How to translate help topics.

[Alexander Belchenko]

INADA Naoki пишет:
> Thank you for all.
> 
>> Yes, and Rosetta does not guarantee the same order of translatable chunks as
>> they exists in the original PO file. I think this is BAD BAD BAD thing for
>> single text splitted into chunks. And I'm -1 on this.
> 
> I didn't know that. It's a big disadvantage of splitting help per paragraph..

I can't be 100% sure but as qbzr/explorer i18n stuff maitnainer I was 
always puzzled why POT file generated by xgettext and the one 
imported/exported from LP is different. Maybe it's fixed now, we need to 
double check.

So, it will be nice to have some confirmation to prove that I'm wrong 
from actual Rosetta developers/maintainers. Because I could be wrong.


> Though, we should not split help topic, or split more big chunks.
> Help topics is written in reST. So "\n"*2 and "\n"*3 makes same output.
> Now I use "\n\n" as a chunk separator. Can we use "\n"*3 instead?
> 
> Mercurial guys starts with big text and be suffered by changing one sentence
> makes whole translated text is disabled. I think we should have some way to
> manage changes of help and help translaters.

That's always problem with gettext. It cannot be solved in any easy way.

If you have splitted command help into 3 chunks

A
B
C

and in English you'll have

A(en)
B(en)
C(en)

Then people have translated them into some language and it becomes

A(lang)
B(lang)
C(lang)

Then original B chunk has changed 1 line, then you got in runtime

A(lang)
B(eng)
C(lang)

Is it good? Of course it depends on the real situation and how tightly 
paragraps coupled together. What's better: have a mix of English + 
Translation or don't have translation at all, but have consistent 
English text? IMO it depends.

What if B part has important text and without understanding that text 
it'll be hard to understand the C part? I don't see any good workaround 
here. That's all or nothing, always, with gettext. Translations should 
be always up-to-date, otherwise you'll have one problem of other.

I don't have good answer here. But we have to decide now and improve 
later, in any case.


> 
> 
> On Sat, May 7, 2011 at 1:23 AM, Alexander Belchenko <bialix at ukr.net> wrote:
>> John Arbash Meinel пишет:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>
>>> ....
>>>> Advantage of text file over gettext is translaters can focus
>>>> translating one topic. And we can history with bzr.
>>>>
>>>> Advantage of gettext is traceablity on changes in English document.
>>>> Splitting help topic per paragraph helps translaters to follow
>>>> changes in English.
>>>>
>>>> Any thoughts?
>>>>
>>> I like the idea of having a full text file, but the most important thing
>>> is how do translators *want* to do the translations. Many people seem to
>>> like Rosetta (Launchpad's interface), but that seems mostly tuned for
>>> translating a UI (small clumps of text, 1-sentence, maybe 1-paragraph,
>>> not a document).
>> Yes, and Rosetta does not guarantee the same order of translatable chunks as
>> they exists in the original PO file. I think this is BAD BAD BAD thing for
>> single text splitted into chunks. And I'm -1 on this.
>>
>>> help-topics are meant to be a discussion about something. As such, I
>>> think breaking them into single sentences would lead to a disjointed
>>> view. (Sort of like using translate.google.com gives something readable,
>>> barely understandable, but certainly not how a native speaker would say
>>> it.)
>> Exactly +1e6
>>
>>> So for big groups of text, I would think you'd want to keep it together.
>>> But maybe I'm wrong. I know we're still not completely sure how the "bzr
>>> help command" text is going to get translated. Though it seems that
>>> we'll use something like gettext() to actually do the lookup and get the
>>> translated content to the user.
>> No, in my opinion: it should be kept together.
>>
>> Also, please note that if you want to have good-quality translations then
>> using Rosetta is not the good deal anyway: you have to restrict translate to
>> the special trusted team otherwise you'll have so bad translations, so
>> believe me -- english will be the better choice then.
>>
>> Therefore if you will restrict translations to dedicated team then it does
>> not matter if that team should use only LP or has to get txt files from
>> branch -- that's not really a question. It's a matter of required process,
>> isn't it?
>>
>>
>>
>> --
>> All the dude wanted was his rug back
>>
> 
> 
>