RE: [xliff] XLIFF 2.0 Core

[Yves Savourel <ysavourel@translate.com>]

> ... For tools which generate XLIFF files from original source
> files (like a development group creating XLIFF files for 
> translation), I would think that those XLIFF files would need: 
> 1. Read the original source file format to strip out the 
> translatable text to be added to the XLIFF file. 
> ...

Yes. And that makes <unit>/<segment>/etc. part of the core.


> 2. Creating the <target> section would not make sense 
> (other than copying the <source> text to it), because this 
> environment is only working with the source files.

Sure. But I still think <target> should be part of the core. It may just not be used by the producer.


> 3. Understand inline codes in the content. 
> This should be a requirement. I had sent this information to 
> Arle a while back on this topic, with the idea that 
> he would bright this up to the inline tag committee.
> I think the intent of XLIFF is to provide a structured way 
> to represent translatable text from any file format in an 
> easy to process, format-neutral way.

I agree with you on this. Inline codes support should be a requirement.

But some tools like all the gettext-based tools (which are used for many products) don't have such view, at least not with the current PO format. I believe this has led some XLIFF1.2-capable tools to not necessarily support inline codes, or at least not by using an abstract representation for them. They sometimes handle them by directly supporting the specific format's syntax.

While we can certainly require a consumer tool to handle inline codes, I wonder how we can we require a producer tool to generate inline codes. It would require to somehow specify what inline codes are in the different formats. Would that means a tool that generate something like this: "<source>Text in &lt;b>bold&lt;/b>.</source>" is not compliant? A lot of those aspects have to do with the filters. How far should XLIFF try to tell the filters what is code and text?

I'm interested to see how things like this could be put in the processing expectations or the conformance clauses we attached for example to <source>.


On a side note, it would be nice if you could join the inline markup sub-committee David.
One teleconference a month (same day/time as the TC but the second week of the month). Next one is next week.
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff-inline

-ys