[xliff-tools] Another question on PO and XLIFF

[Tim Foster]

Hey Yves,

On Tue, 2005-05-03 at 13:11, Yves Savourel wrote:
> But the big difference is that in extracting an HTML to XLIFF you would not use xml:space='preserve', so preserving the <br> is
> needed.

Okay, that makes sense, but...

> I would expect the XLIFF content to have the text as close as possible to the real output

Where do you draw the line between the text that was presented for
translation originally, and any rendering that gets done on the
translated text further downstream ? (that's the problem/thought-process
I'm wrestling with - and haven't quite worked out yet)

eg. "This is \n text" vs.
    "This is &my-own-defined-newline; text"
    "This is ${0} text"
    "This is $${${}$}}$} text" (using an absurd example, probably from
OOo, eh David ;-)

- does each XLIFF filter need to understand the intricacies of the
source file format in order to best suit the translator ? Well, in an
ideal world, yes definitely it should -

but at some point, it becomes quite difficult to implement this. (esp.
when it's not at all clear in the source format how to differentiate
between the formatting-codes used : letting the translator decide what
they mean is the regrettable outcome)

Likewise, replacement text, and all those other "tricky" translation
issues we're discussing at the moment in other forums, does their XLIFF
form need to try to do all the rendering that the underlying message
libraries take care of (like converting "\n" into '\n', in the case of
gettext) I'm taking the view that it shouldn't and that tools that show
the XLIFF file to translators need to do this step.

>  to make it easier on the translators. They
> will be much happier with this:

Right, but if we could do that in the editor (rendering the string
cleverly for translation), then we could still preserve the difference
between two different strings :

"This is \n text"
and
"This is 
 text"

in the XLIFF representation, losing no information. [ I see from a
recent email that Asgeir has just sent, that gettext sees no difference
between those strings. hmmm I'm not sure I agree ]

I agree it's a tough one to call.

> > We're currently wrapping "\n" in <it> tags at the moment 
> > (will change that as soon as we move to XLIFF 1.1 and will adopt <g> instead)
> 
> Don't you mean <x/> (or <ph>)?

Erk. The xliff-po representation guide seems to be recommending <g>
instead of <x> or <ph> (either way, we (Sun/open source xliff filter
once it's released) have to do work to move from <it> to whatever is
recommended)

	cheers,
			tim

-- 
Tim Foster - Tools Engineer, Software Globalisation
http://sunweb.ireland/~timf http://blogs.sun.com/timf
http://www.netsoc.ucd.ie/~timf