Re: PO-based Documentation Translation

[Gudmund Areskoug <fta algonet se>]

Hi,

Tim Foster wrote:
> In terms of saving time and money, sentence segmentation is fantastic
> and works for us.

just thinking out loud: does fine granularity segmentation have to 
be reflected in the file format (po/xliff), to be put to use?

Couldn't that part just as well take place in 
msgmerge/pretranslation and inline DB/compendia queries during the 
translation process?

I can see that reflecting segmentation et al. when one translator 
gets to continue somebody elses work makes sense, and possibly in 
some other situations, but are those situations relevant here (I 
don't know)?

What I think might enhance productivity and QA, would be increased 
use of hirarchically marking up terminology (in DB's and compendia), 
and increased use of (clever) assembling of the portions where match 
differences were found. And perhaps a more verbose or precise usage 
of "fuzzy". This is IMHO and experience where fine granularity is 
put to its best use.

There's probably some good reason for having segmentation reflected 
in the files, so can you please elaborate on it Tim? Tool 
compatibility/portability?

BTW: I know Trados has a large commercial market segment, but IMHO 
it's not a tool in particular where too much could be learnt 
(granted it's been a while since I tried it and dumped it).

Heretic thought: if there are tools for it, why not let the 
translator/translation team use whichever format they want?

I guess there may be elements in xliff that can be incorporated in 
po, but perhaps the same holds true the other way around: I'd be 
interested to see where in the xliff files you stored the context 
normally found in a po file. And how is plural handling solved? Do 
you have a sample (e. g. some part of a UI po + corresponding xliff)?

Other than that: is it possible not to welcome Suns editor, should 
it be released? :)

BR,
Gudmund