[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Resolution proposal/Call for Dissent Re: [xliff] mrk translate outside the content but in scope
This annotation overrides the translate
attribute set at the <segment>
level.
New text:
This annotation has precedence over the translate
attribute values inherited from the <unit>
level
Hi David, all,
Possibly. That may be the case for <sc> and <ec> too.
> possibly adding a constraint enforcing the <em/>
> to come logically after their <sm/>.
I didn't have a set expectation.
>> I put the question marks because it wasn't clear
>> to me what was the result of your algorithm. Now I know.
>
> Good, and is it the same as yours?
When computing the state of translate in a segment one must take account both the segment and the ignorable elements into account as
>> - Set the bottom of the stack to the translate
>> value of the part:
>> - For a segment: the resolved translate value of
> the segment
>> - For an ignorable: the resolved translate value
>> of the parent unit.
>
> I don't think so, ignorable is not translatabale no matter what,
> it can just hold pieces of annotations that can flip parts
> outside of itself.
part of a whole, otherwise you simply cannot end up with the correct result.
Note also that ignorable element contains whatever the Extractors or Modifiers deem appropriate (whitespace and inline codes most of
the time). While its content is not expected to be translatable text, it may need to be adapted in some cases, for example to remove
whitespace between segments in some languages, or to adjust whitespace when re-ordering the target.
>> Technically I don't think this is enforced by a constraint or a PR.
>
> I think we do not have this, I propose to add this to the <sm/>I tend to agree.
> and <em/> descriptions.
> I think we should say for <sm/> that it MUST have a closing <em/>
> within the enclosing unit (and vice versa)
> AND
> that <em/> must come logically after its corresponding <sm/>
But other really need to look at all this and have opinions.
Possibly. But let's just make sure we don't add repeated warnings, notes, PRs all over the place. As a general guideline we should
> I'd also add a warning that the order attribute has to be considered
> in target for determining the logical order..
be concise. In my experience, overwhelming the reader with repeated information often leads to confusion and make things look more
complex than they are. The Segmentation Modification section is an example of that. I'll get to that at some point.
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]