RE: [xliff] XLIFF 2.0 Core

["Rodolfo M. Raya" <rmraya@maxprograms.com>]

> -----Original Message-----
> From: Yves Savourel [mailto:ysavourel@translate.com]
> Sent: Friday, April 08, 2011 4:33 PM
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] XLIFF 2.0 Core

> 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?

You can't consider PO sources or software document sources as the main source type for XLIFF files. That could have been the case at the beginning of XLIFF history, but things have changed since then.

My tools deal mostly with documents that have inline formatting, not because I want but because translation industry deals a lot with documents that have formatting information.
 
As I see it, inline elements are a core part of XLIFF standard. 

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.

Regards,
Rodolfo
--
Rodolfo M. Raya   <rmraya@maxprograms.com>
Maxprograms      http://www.maxprograms.com