Thanks, Yves, I can see the issue and have suggested to Bryan that he puts it on agenda tomorrow.
Leaving the administrative issue of a late comment aside for now..
The issue you outline is more general in the sense that you do not even need to use an ignorable to get into the described issue.
You can have a non-translatable span starting with an <sm> in the 1st segment running through the 2nd segment, and terminating within the 3rd segment with an <em> tied to the <sm>. This is again a situation where the default value of the segment translate should be overridden with the value from the (non-well formed) marked span.
So I believe that the general solution is to say that recursively inherited defaults on <segment> and <mrk> need to be checked against possible <sm>/<em> overrides within the unit.
Rgds
dF
Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto:
On Mon, Oct 28, 2013 at 3:36 PM, Yves Savourel <> wrote:
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>
</segment>
<ignorable>
<source> <sm id="m1" translate="no"/></source>
</ignorable>
<segment id="s2">
<source>NT-Sentence 2.</source>
</segment>
<ignorable>
<source><em start="m1" /></source>
</ignorable>
<segment id="s3">
<source>T-Sentence 3.</source>
</segment>
</unit>
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.
Cheers,
-yves
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
