OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xliff-comment] Thought in allowing other namespaces in segments


Hi everyone,

One thought in that topic:

One of the features of using only a standard set of XLIFF inline element
inside segments is that it allows to control any text that is inside tags.
For example, when using only XHTML elements in a segment how would we be
able to isolate the text of the ALT attribute in the following example?

<source>Click <html:img src='button.png' alt='Start Button'/> to
start.</source>

It would require the tool to know about what attribute is translatable in
HTML, or other XML namespaces as if we allow XHTML I don't see why we
wouldn't allow others vocabularies.

In the current XLIFF syntax we can isolate the data:

<source>Click <ph id='1'>&lt;img src='button.png' alt='<sub>Start
Button</sub>'/></ph> to start.</source>

In my mind, this is not the only problem with allowing extensibility in
segment content, but this one may be a good illustration of how using a
standard tag set to encapsulate the inline codes makes the format more
portable from tool to tool.

Just a thought.
-yves

PS: Actually, in my opinion, using <sub> isn't cool: the best way is to
extract the text into a separate segment so it could be leveraged regardless
where it's located and the initial segment could also be leveraged
independently of the content of ALT. And that also illustrate the fact that
'things' need to be done to the inline codes to be really re-usable in
translation tools.

-ys



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC