RE: [xliff] Best way to mark up an image in XLIFF 2.0?

[Yves Savourel <ysavourel@enlaso.com>]

Hi Bryan,

Again, I think you are talking about two different things:


--- 1) being able to use the fs attribute

You are using the content of <data> to generate your HTML preview (and find its plain-textness distasteful) because you have no other way to access the image URL. But this is because the core does not have any provision for this.

In short: it's a bit unfair to blame the core for not providing the information it's not suppose to provide.

Maybe the real problem is that fs should belong to its own module and provide additional features that make it work properly in an interoperable way.
For example: I doubt very much than the href value you will find in the original img tag will always be conveniently set to work out with your extracted files: The value may have a full or relative path that will not work with the files after extraction.

I think FS is not really useable as it is defined today. And the reason is because it tries to "fit" into the core. In my opinion it should be its own module and should have a standardized way to store the path of the images to display in the HTML preview. This would also allow tools generating FS markup to possibly convert images in not-easily displayable format used in various formats (InDesign, Word, etc.) into nicer .png/.jpg useable with HTML, and ship those with the XLIFF documents.

In short: the FS feature should be interoperable, not dig into the original data that may or actually may not be there.

For instance you could imagine something like this:

<unit id="1" fs:elem="p">
 <segment>
  <source>This is a test <ph id="1" nid="222"/> to see how to embed images.</source>
 </segment>
  <originalData>
     <data id="222"> fs:image="big-happy-smile.jpg">&lt;img src=big-happy-smile></data>
  </originalData>
 </unit>
<unit>

- XSL friendly
- not dependent on the original file format
- works even if the original data is omitted


--- 2) having escaped XML/HTML in the XLIFF <data> element.

As Rodolfo noted, it's an old well-known aspect of XLIFF.
Sure, we could allow for XML in <data>, but that comes with a whole set of new problems. Rodolfo mentioned some of them.

As you mentioned, having custom namespaces in the skeleton should allow you to build extraction/merge that are quite XML-friendly.

Cheers,
-yves