On Aug 12, 2007, at 12:00 PM, Javier SOLA wrote:
OpenOffice has multiple variable formats, and it is nice that the
program recognises them as units of text that need to be replicated
exactly at the target. XLIFF uses for this the <mrk> in-line tag.
The introduction of the tags must me done by the filters SDF to XLIFF.
Do you mean that the SDF->XLIFF filter will correctly encapsulate the
XML code that SDF escapes ? If yes that is great news!
In case that is what you intend to do, you should be aware that <mrk>
is _not_ the tag to do that:
http://www.oasis-open.org/committees/xliff/documents/xliff-
specification.htm#mrk
<quote>
Marker - The <mrk> element delimits a section of text that has
special meaning, such as a terminological unit, a proper name, an
item that should not be modified, etc. It can be used for various
processing tasks. For example, to indicate to a Machine Translation
tool proper names that should not be translated; for terminology
verification, to mark suspect expressions after a grammar checking.
The <mrk> element is usually not generated by the extraction tool
and it is not part of the tags used to merge the XLIFF file back
into its original format.
</quote>
<mrk> has _nothing_ to do with encapsulation of non translatable
_code_, and as is indicated in the quote, it is _not_ generated by
the extraction tool (or the filter) etc...
If you want to encapsulate the SDF code properly you need to use:
<bpt> and <ept> for code pairs, <it> for isolated code and <sub> for
translatable subflows within the code.
http://www.oasis-open.org/committees/xliff/documents/xliff-
specification.htm#bpt
If your segmentation process (if you have any) puts <bpt>/<ept>
series in different <source> segments then it is sometimes considered
safer to use <ph> (place holders) series instead.
http://www.oasis-open.org/committees/xliff/documents/xliff-
specification.htm#ph
But <mrk> is certainly not the tag to use for non translatable code.
Translation memory must learn to deal with tags.
Translation memories have not waited for the translate-toolkit to
deal with tags. Most translation memory tools already deal with TMX
level 2 to various levels.
So maybe you mean "translate-toolkit must learn to deal with tags" ?
Independently of which tools are being used, I am glad to hear
agreement on the fact that the future of OOo localization is XLIFF.
And it would be even better if the XLIFF could be provided directly
from the original XML and not after a conversion to SDF, which
renders the whole process uselessly complex.
Jean-Christophe Helary
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
