Re: PO-based Documentation Translation

[Tim Foster <Tim Foster Sun COM>]

Hi Ole,

Ole Laursen wrote:

>>Before you know it, you've re-implemented XLIFF, and have actually made
>>the process more complicated for everyone involved since yours are the
>>only tools that can make sense of the format.
>>    
>>
>
>That's true, but you could have build those things into the editor
>tool instead of the file format, couldn't you?
>  
>
Yes, I guess you could, but the point of XLIFF is that it encapsulates 
the entire localisation process : meaning that once you have an XLIFF 
file that's been populated with fuzzy matches, or glossary hits, or even 
machine translations, the translator can then work on that file offline, 
anywhere, with any editing application that understands the format.

Even if you don't have any of those translation aids, when you express 
stuff in XLIFF, you're putting the burden of understanding the source 
format on the shoulders of the person writing the XLIFF filter, and the 
translator can concentrate on translating the text.

By requiring the editing application to be tied to the TM system, the 
terminology system and the MT system all through a special editor, 
you're really limiting your options and flexibility.

With XLIFF, you can have multiple tools, all adding their value to the 
XLIFF file as it's passed along the tool chain : a few fuzzy matches 
from a TM system here, a couple of MT matches there - even passing XLIFF 
files through statistics systems along the way, to see just what sort of 
translation re-use you're getting across projects, find out which 
documentation has changed the most since the last release[1], that sort 
of thing... then of course, you can load it in an XLIFF aware editor, 
translate the segments, and pass the results back into the TM database 
and start again.

Of course, nothing stops you having an fully online, connected editor 
either, but it's nice to have the option not to - being locked to a GUI 
is a sad state of affairs :-)


>Your editor
>
>  > http://www.netsoc.ucd.ie/~timf/Screenshot-TransEditor.png
>
>may be good for your internal translation team, but I wouldn't touch
>it with a firestick. It can't be as good as Emacs for editing text.
>
Each to his own I guess[2]. For what it's worth, we consulted with a lot 
of small and large translation companies when building the editor, and 
listened to them carefully as to what things they wanted to see in it. 
Right now, to translate Sun software/docs, people have to use our editor 
and so far, nobody's complained about it's lack of features. (Our editor 
gets used internal to Sun, and when we outsource our translation work to 
external companies)


>I wish I had more spare time. Hacking on an XLIFF mode for Emacs
>sounds like a fun project,
>  
>
Well, I've been itching for a reason to go learn LISP (I should say 
"re-learn", did a bit of it in university) - maybe now's my chance :-)


    cheers,
          tim

[1] These would only be changes that affect translation - intelligent 
diff, if you like. Since you're abstracting the content from the 
formatting, pretty-printing a souce docbook file won't cause any change 
in the translation status of translated versions of that document : if 
you pass that reformatted document through our tools, and it's already 
been fully translated and in the database before, you'll get a fully 
translated document out the other end.

[2] Actually, I'm a casual xemacs user too - it used to be my main 
development IDE till Netbeans got fast enough for me to switch : I tend 
to use xemacs still for large files, and for sgml when I can't be 
bothered to start up Adept...