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

Thanks, Yves, most of it makes sense to me, and IMHO as a bottom line it actually does not require a normative change, except possibly adding a constraint enforcing the <em/> to come logically after their <sm/>. Now as I think of it,  we always assume (we e.g. do not allow em to have its own id) that <sm/>/<em> must always go in a pair but I am not sure if we explicitly say that anywhere in the spec..
Detailed answers inline:

Dr. David Filip
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto: david.filip@ul.ie

On Tue, Nov 5, 2013 at 1:01 AM, Yves Savourel <ysavourel@enlaso.com> wrote:
Hi David, all,

> Yves, I am reacting to the use cases inline using
> my proposed algorithm..
> I first thought that yours should produce the same
> results but probably not, as your question marks do not
> seem puzzling to me..

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've tried to implement this and here are my conclusions:

-- We actually do not want to change the current definition with the defaults: they are fine.
I agree 
It's not the default value of the
translate attribute of <segment> that depends on the overrides, it's how the value (set or inherited) is applied to the content.
I agree 

-- What we are missing is a description of how an agent determines the translate state of a text is at any point in the source and
the target content.
IMHO this description should be added as a non normative example, as otherwise it would be pushing an implementation

I'm not sure where that should be added. The translate attribute section is a possible place.
Sounds plausible, will shout if I find a better place.
We could place a warning in the attribute description under the deafault values description aying that these defaults may be overridden by values set in <sm></em> pairs throughout the enclosing unit and that implementers should be careful about that. Your stack algorithm description could come as a possible implementation example, I would try to flesh out my abstract algorithm description, if Bryan or Tom can add an XSLT based example that we be very good.

Here is the algorithm I've tried:

Resolved value = value directly set or obtained by inheritance
Part = a segment or an ignorable element

- Create a stack of translate values
- Push a single value in the stack (the actual value does not matter).

- Get the list of the parts in the unit:
  - for the source content use the parts in the order they are in the document
  - for the target content use the parts in the order set by the target order attributes

- Starting at the first part of the list, for each part:
  - 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.. 
  - Iterate through the content
    - If an opening marker for a Translate Annotation is found:
      - Push the translate value of the annotation at the top of the stack.
    - If a closing marker for a Translate Annotation is found:
      - Remove the corresponding item in the stack

At any time, the top of the stack has the translate value to apply to the current content.

This method has one caveat: The closing markers of each translation annotations must be after its corresponding opening marker.
Technically I don't think this is enforced by a constraint or a PR. It should be OK for the source content. But the target ordering
may introduce some problems if it's not done properly.
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'd also add a warning that the order attribute has to be considered in target for determining the logical order..

There are probably other ways to do it. Hopefully Bryan will come up with a nice way to do it in XSLT.


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:

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