[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Best way to mark up an image in XLIFF 2.0?
Hmmm. Interesting. So if I don’t use a skeleton, and I use
<source> This is a test <someInline idref="222" /> to see how to embed images.</source>
<data id="222"> src="" </data>
I assume I need some inline element to hold the place within the inline (in this case, between the word “test” and the word “ to”) where the idref to the original code goes. What is the actual inline I should use that I’ve nicknamed <someInline>? And if <pc> is not to be used, why is one of its allowed @type values, ‘image”? And how do I retain that the source element’s name is <img>?
And remember, the requirement in this use case is to be XML-friendly. So <data id=”222”> <img src="" /></data> is not a good option.
Or another way of putting it, could somebody please give me an example of the best way to represent:
<p>This is a test <img src="" /> to see how to embed images</p>
. . . in a way that honors the conditions of this use case?
Sent: Tuesday, October 02, 2012 8:40 PM
Subject: [xliff] Best way to mark up an image in XLIFF 2.0?
I looked at the current specification to see how we say images should be represented in XLIFF 2.0. The only reference I see is in sub-flows:
Click to start: <img title="Start button"
src="" alt="Click here to start!"/>
<source>Click here to start!</source>
<source>Click to start: <ph id="1" subFlows="1 2"/></source>
This is all great. But I do not see a recommendation for storing the src="" information.
The name of the image goes to the skeleton or to a <data> element. It is not included in the <ph> element.
Suppose a skeleton is not to be used.
Then the name of the image goes to a <data> element associated with the <ph> you placed in <source>.
Let’s consider a more simple case where no sub-flow information is in play, and let’s say the source is well-formed, spanning code. And we want to choose the most XML-friendly way.
So our choice is to not use <sc>, <ec>, but rather to use <pc>.
<p>This is a test <img src="" /></p>
I wonder if we need to add “x-“ extensibility to inline elements? Or, would we recommend something like this:
The "x-" prefix is applied to attributes. There is no attribute that would hold the information you want to place in the inline element.
<source>This is a test <pc id="img.1" type="image"> big-happy-smile.jpg</pc></source>
<target>This is a test <pc id="img.1" type="image"> big-happy-smile.jpg</pc></target>
If that sample is legal, would we also need to add a lock=”yes”, or something since the content of <pc> could accidentally translated?
Your example does not correspond to a good extraction of the source text. The content of <pc> is fully translatable, the image name should not be there.
I need to know this to provide a robust answer to Yves’ question about the fs attribute.
Your XSL stylesheet will have to process the <ph> element, the associated subflows and the <data> element that contains the image name. It is not practical, I know.
Generating good HTML from an XLIFF file that uses the “fs” attribute as defined so far would require the use of code. An XSL transformation may not be good enough.
Your example is based on an HTML fragment. Images can be included in many other document formats, like Microsoft Word, InDesign or FrameMaker. Generating HTML from these source formats can be very tricky.
Rodolfo M. Raya email@example.com