Re: PO-based Documentation Translation

[Danilo Segan <dsegan gmx net>]

среда, 01. октобар 2003. 15:15:05 CEST — Tim Foster написа:
> The better approach, is to segment the text at a sentence level :  
> this can be very hard[1], but is ultimately worth it. That would give  
> you the messages :
[snip]
> How's that for a major gain in productivity !?

Yes, I see your point. It would really help in some cases, and there  
are major benefits. Still, translation of documentation requires (to  
me) a bit more freedom than just sentence-for-sentence (yes, I may  
choose to translate one sentence to two, or one to a 'blank').  
Paragraphs seem to be logical choice since they're usually categorised  
as being 'one idea' or 'one thought', so it's most easily to follow it  
if it's all together, reorder sentences, or whatever (imagine a  
translation where you need to reorder sentences 'a' and 'b', so you  
get:
 msgid "a"
 msgstr "b-translated"

 msgid "b"
 msgstr "a-translated"
I don't think I want to make use of TM and fuzzy matching in this  
case :-)

> 
> (It's worked very well for us)

Certainly, I believe it would work great in most cases, but there is  
simply a small number of cases where it would not work at all. And  
that's what bothers me. Yes, benefits are huge, but what to do when you  
get stuck in one of those situations?

You lose trust in TM matching, you get a harder job to make out what's  
the meaning of the sentence.

Is there really a solution that would have some benefits, but wouldn't  
have any drawbacks? I doubt there is, so we use the 'closest  
approximate' we can.

Still, that means that I'm all for new tools, new technologies, and  
doing the job better. But until I try them, it's all theoretical and we  
may discuss it at length, surely.

> The price to switch is me getting this stuff made available, and the
> price to entry is either learning a new tool, or coming up with modes
> for existing editors to support the format. (Personally, I really
> wouldn't want to hand edit XLIFF files)

Ah well then, I'm eagerly awaiting for you to provide this stuff ;-)

> Our editor doesn't really do gender, but can cope with contexts : we
> can tell the user from what project a fuzzy or exact match came from,  
> we can show the user any comments from the original source file, that  
> sort of thing. We can also do things like list the "approval" status  
> of a translation. There's bits of XLIFF we haven't yet taken  
> advantage of, such as using special markup for abbreviations,  
> formulas, that sort of thing. (though already, we mark can some text  
> as "untranslatable" - our editor can then protect those fields from  
> editing)

I must wonder: how does 'your editor' cope with word reordering? (Yes,  
I admit that I don't know what are 'fields' in context of one message  
for translation, so that probably bring more misunderstanding :-)

Theoretically, at least things like printf format specifiers should  
also be marked "untranslatable", but it requires support in an editor,  
of course. I just cannot conceive how one would do that except for  
splitting the translation into 'fields/objects' that can be moved  
around -- yet, this approach has many drawbacks on speed (how does one  
move them? using a mouse? that would be real slow; using keyboard?)

> Yes : nothing's impossible ! (What an optimist I am :-)
> 
> The question to ask is, how good is what you're using, and if you're
> going to change, what level of change do you want to accept ?

As a translator, I'm willing to accept even the biggest of changes. Of  
course, precondition is that I lose nothing (plural-forms, fuzzy  
matching, etc). I can cope with tools change (though it would be bad  
for my Emacs-following religion :-), process change and format change.

Still, I think there's a bit more of a problem -- how to make all the  
developers switch to using new stuff? It is hard enough to make them  
use ngettext properly, which is a really trivial change ;-)

Cheers,
Danilo