[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff-comment] using xliff to translate html
Hello Brian, >> Readability of the inline marked up text. Yes, the <bpt>, <ept>, <it> and <ph> elements make the segment much larger than the original, even if you strip them down to the minimal (only an id attribute). It's also especially true when the original file is an SGML or an XML file as all the '<' and '&' of the code parts need to be escaped. That is, alas, the price to pay for having the codes pre-parsed and in the segment itself. As you pointed out one solution for this is to use the <g> and <x/> elements instead. But it has the drawback to not give access to the original code. I think an XLIFF-enabled tool should be able to provide a display that remove any clutter from the translator view. The tools that would have more issues with this would be the tools enabled for XML only, which don't know what to do with the content of <bpt> etc. except that they should be protected. Some of those tools, like TagEditor from Trados have option to reduce the display of tags to almost nothing on screen, so --at least in some cases-- the bulk of <bpt>-like elements is not too much of a problem there. The worst case senarios would be when you translate an XLIFF file in a format where everything is visible, like when adding a color-coded RTF layer to a XLIFF and working with in in Word. >> Using the <g> tag. The <g> and <x/> tags are meant to be used a little bit differently than the example you gave. The original codes is not inside the XLIFF content (i.e. not in other <trans-unit> elements). Instead, it resides in the skeleton, the file where the non-localizable parts of the original file are kept. How you do store them there is completely up to the filter creating the XLIFF document. For the time being XLIFF provides only: 1) a way to either embed the skeleton in the XLIFF document (<internal-file>) or externalize it (<external-file>). 2) a way to link the <g> and <x/> elements back to the corresponding their codes in the skeleton (by using the id attribute). So to reuse your example, the segment would look like: <source>Some text in <g id="g2">bold</g>, <g id="g3">italic</g>, <g id="g2"><g id="g3">bold and italic</g></g>, and a <g id="g4">link</g>.</source> [Note that unlike in your example, the <p> element would not be part of the inline codes as it's a "structural" code and shouldn't be in the segment (or it would cause problem if you wanted to leverage the segment somewhere else).] As for the original codes ("<b>", "</b>", "<i>", etc.) they would be somewhere in the skeleton. The main drawback with this mechanism is that, because there is currently no standard way to represent the skeleton, only tools knowing the given type of skeleton created are able to access the original codes if they need to. The others are left with whatever information is in the <g> and <x/> elements. Will we have a standard skeleton format (as John also asked in his email yesterday)? There has some talks about it in the TC meetings, but so far nothing has been decided. Cheers, -yves
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]