MHonArc v2.5.0b2 -->
xliff message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [xliff] Re: SPAM - RE: [xliff] HTML Inline codes
... and another view. This relates to how we handle these instances in SDLX.
[1] In SDLX, we ultimately replace <br> with the unicode character 0x2028.
The segmentation rules can then be used to determine whether to segment on
this character. An alternative is to use <x ctype="lb"/> and again allow the
segmenting application to make the decision.
[2] Inline codes are ALWAYS inline. However, we may choose to "optimise out"
matching inline codes if there is no text between these codes and the
segment start/end when presenting the text for translation. So the example
below becomes
<source><g id="1" ctype="bold">Sample text.</g></source>
However, we would only present "Sample text." to the translator for
translation. (Actually, in this case, we would make the text bold as well).
Personally, I don't think you should ever make inline codes "external" in
the XLIFF filter ... that should be left to the XLIFF editor to decide
whether to present them to the translator. After all, the formatting of the
text could have some bearing on the translation.
David Pooley
Software Architect
SDL International