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: mrk translate outside the content but in scope

Hi all,

As I was trying to implement a simple pseudo-translation command in our library, I've run into some problem about how to handle the
translate feature in <mrk>:

For the <segment element we have the following definition for the translate attribute:

When used in any other admissible structural element:
The value of the translate attribute of its parent element.

But annotation can be placed in ignorable elements. And one of the fairly common uses for <ignorable> is to store things such as
opening and closing codes that enclose the whole content of the segment, allowing for "cleaner" segments. Annotations may get the
same treatment. Another way to get such unit is when a segmenter puts breaks as close as possible to the text. The bottom line is
nothing prevent you to get a unit like this:

  <unit id="1">
   <segment id="s1">
    <source>T-Sentence 1.</source>
    <source> <sm id="m1" translate="no"/></source>
   <segment id="s2">
    <source>NT-Sentence 2.</source>
    <source><em start="m1" /></source>
   <segment id="s3">
    <source>T-Sentence 3.</source>

So in such case a tool would get a default of translate='yes' for the segment s2 while the content is clearly intended (and coded)
to be non-translatable.

The solution would be to change the definition so the default first takes into account the translate state at the end of the
previous segment or ignorable element. Note that this is potentially difficult to implement: you may have to look inside all
previous siblings of a <segment> to get its default translate value.

I do realize this comment/question is outside the comment period and (I think) is not related to any of the open comments we have.
So technically it should not be addressed until the next round of comments. But hopefully OASIS process has some better way to
address cases like that.


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