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

Hi David, all,

> possibly adding a constraint enforcing the <em/>
> to come logically after their <sm/>.

Possibly. That may be the case for <sc> and <ec> too.

>> 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?

I didn't have a set expectation.

>>  - 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.

When computing the state of translate in a segment one must take account both the segment and the ignorable elements into account as
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/> 
> and <em/> descriptions.
> I think we should say for <sm/> that it MUST have  a closing <em/> 
> within the enclosing unit (and vice versa)
> that <em/> must come logically after its corresponding <sm/>

I tend to agree.
But other really need to look at all this and have opinions.

> I'd also add a warning that the order attribute has to be considered 
> in target for determining the logical order..

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
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.


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