| David,
You raise an interesting point. Since the translation context often does include higher-level formatting (to see how the text functions in situ), it would be useful to pass on that “minimal context” (as you call it). The question is how to do so based on the information that gets passed to the XLIFF file. Maybe some higher-level elements can be passed along, like <li> if we know that they can be represented atomically. E.g., we know that the mapping says <li>, so we actually map it so <ul><li> [insert content here]</li></ul>. Such a scheme would allow marginally more sophistication than wrapping everything in <p> tags. What it still wouldn't allow is reconstructing the context in a table or some other considerably more complex structure that would normally be considered a wrapper around the content you are trying to get to. Do you see a good way to pass that sort of structure through and allow it for previews without also “gumming up” the XLIFF?
I do agree that it would be nice to do, if the price in complexity is not too high.
-Arle
On Feb 25, 2012, at 07:42 , Dr. David Filip wrote: Arle, I see your rationale for limiting the html previews up to <p> roughly. And it might be a good scope for core.. Still I remember how tremendously useful xslt rendered previews were (and are) in WorldServer, and these were of course "page wide" overviews, but this is the minimal context that the translator needs. I agree it might get tricky, but it should be well worth it..
Rgds dF
======================= LRC | CNGL | LT-Web | CSIS University of Limerick, Ireland telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
On Tue, Feb 21, 2012 at 18:01, Arle Lommel <alommel@gala-global.org> wrote:
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
|