RE: [xliff] XLIFF 2.0 Core

> You can't consider PO sources or software document sources 
> as the main source type for XLIFF files.

I didn't. Sorry if I was unclear. I was just giving examples where dealing with inline codes is done different ways by translation tools; so for some tools makers generating abstract inline codes as most of us in the TC do is not something necessarily obvious.

And I was wondering if the conformance clauses of 2.0 should make this (creating inline codes) a requirement; and if they should, how to go about it (because it seems not possible to me). I think you answer that question.


> As I see it, inline elements are a core part of XLIFF standard.

I could not agree more.


> If a tool generates "<source>Text in &lt;b>bold&lt;/b>.</source>" from 
> a document that clearly requires the use of inline elements, users will 
> hate it and hopefully will not buy that tool.
> You cannot force a tool vendor to use or support inline elements. 
> Nevertheless, you can make inline elements available to all tools.
> Implementers and users will decide what they want.

I'm not sure I get this: The two statements "inline elements are a core part of XLIFF standard" and "You cannot force a tool vendor to use or support inline elements" seem contradictory.

If inline codes are part of the core, then they are part of the minimal set of features a compliant XLIFF tool has to support.
Or I have misunderstood what the XLIFF core means?


To be clear on the inline codes aspect: I think we cannot force a producer tool to generate inline codes, but I think there would be advantages to force consumer tools to support them.

-ys