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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

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


Subject: RE: [xliff] HTML attributes for at-a-glance feature


Hi Arle, Bryan,

To chime in about the HTML preview:

The inline markup is planned to have a disp attribute that would provide a possible display representation of the original data of the code. This can be used for example when the original code is large and complex, and does not land itself very well to be shown in an editing environment.

How related/overlapping would this be compared to the proposed fs attribute?

Cheers,
-yves


From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Arle Lommel
Sent: Tuesday, February 21, 2012 11:01 AM
To: XLIFF TC
Subject: [xliff] HTML attributes for at-a-glance feature

Bryan,

I really like the idea of being able to store information about HTML preview in the XLIFF file. I think it would be tremendously useful since you cannot, in many cases, reconstruct the rendering intent from the XLIFF file. For example, if I am working with a custom XML format, even encapsulating a tag like <productCode> in the XLIFF is useless unless you have some predefined rendering intent. On the other hand, if the importing tool knows to map that code to a particular, limited set of elements, it would be very useful for everyone downstream.

My thought is that we would need to limit the allowable HTML elements to those that can exist independently within the context of <p>. This would exclude items like <li> that cannot exist in a <p> tag. It would also eliminate <div>, <table>, and many other important HTML elements. My rationale for this scope limitation is that the goal should properly be to provide some idea of formatting to the translator within the segment, not of the whole document structure. Trying to move up the ladder to show more structure would open a can of worms in terms of complexity and requirements for the interpreting agent.

Best,

Arle




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