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] RE: XLIFF Support Survey Draft


I support including detailed segmentation questions

On Nov 17, 2015 1:19 PM, "Patrik Mazanek" <pmazanek@sdl.com> wrote:

Yes this really looks like the sort of questions I would like to know answers forJ

 


 
www.sdl.com


SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us.

SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK.

From: Lucia Morado Vazquez [mailto:Lucia.Morado@unige.ch]
Sent: Friday, November 13, 2015 3:51 PM
To: Patrik Mazanek <pmazanek@sdl.com>; xliff@lists.oasis-open.org
Subject: RE: XLIFF Support Survey Draft

 

Dear Patrik,

 

Thank you very much for your feedback. I have reviewed the 4.8 section of the spec where segmentation is addressed.

Here are the questions (based on all the defined processing requirements) that I could come up with:

 

Segmentation Section

[s1] Can your tool perform segmentation operations?

[s2] [if your tool is a writer] If your tool sets explicit order on <target> elements, does it also check for conflicts with implicit order?

[s3] [if your tool is a modifier] If your tool modifies the segmentation, do you preserve the integrity of the inline codes?

[s4] [if your tool is a modifier] If your tool modifies the segmentation, do you move or join <segment> elements or their data across units?

[s5] [if your tool is a modifier] If your tool performs a split operation, can it split <segment> or <ignorable> elements that have their canResegment value resolved to no?

[s6] [if your tool is a modifier] If your tool performs a split operation, do all your new <segment> or <ignorable> elements and their <source> and <target> children have the same attribute values as the original elements they were created from (except for the id, order, state and subState attributes)? [maybe too long and complicated?]

[s7] [if your tool is a modifier] If your tool performs a split operation, do all the new id attributes follow the <segment> or <ignorable> id constraints? [maybe not necessary?]

[s8] [if your tool is a modifier] If your tool performs a split operation, can your tool modify the value of the state attribute if it was not set as initial?

[s9] [if your tool is a modifier] If your tool performs a join operation, can it join <segment> or <ignorable> elements that have the value of the canResegment attribute set to no?

[s10] [if your tool is a modifier or a merger] If your tool performs a join operation, can your tool join two elements (<segment> or <ignorable>) if their <target> have non-consecutive order values?

[s11] [if your tool is a modifier or a merger] If your tool performs a join operation on <segment> or <ignorable> elements, does your tool carry over all the attributes of their <source> and <target> elements in the resulting joined elements?

[s12] [if your tool is a modifier or a merger] If your tool performs a join operation on <segment> or <ignorable> elements with different values of the state attributes, does your tool set the state attribute of the joined element to the “earliest” of the values specified in the original <segment> elements?

[s13] [if your tool is a modifier or a merger] If your tool performs a join operation on <segment> or <ignorable> elements with a subState attribute which is not associated with the state attribute selected to be used in the joined segment, does the joined <segment> have a subState attribute?  [too complicated?]

[s14] [if your tool is a modifier or a merger] If your tool performs a join operation on <segment> or <ignorable> elements with different xml:space values, does your tool set the <source> and <target> elements of the joined element to xml:space="preserve"?

[s15] [if your tool is a modifier or a merger] If your tool performs a join or a split operation. If any <segment> or <ignorable> element of the <unit> had a <target> child with an order attribute prior to the segmentation modification, does your tool examine the <target> child of all <segment> and <ignorable> elements in the <unit> and , if necessary, does it update their order attributes to preserve the ordering of the target content prior the segmentation modification? [too complicated? split in two?]

 

I can add a specific section for segmentation on the survey to include these questions, they might be too many though. They only apply to tools that are classified as modifiers and mergers (following the agent classification defined in the spec), for other tools they will not be shown (only the first one will be shown for all tools).

 

Regards,

Lucía

 

 

 

 

 

 

De : Patrik Mazanek [mailto:pmazanek@sdl.com]
Envoyé : vendredi 13 novembre 2015 09:55
À : Lucia M
orado Vazquez; xliff@lists.oasis-open.org
Objet : RE: XLIFF Support Survey Draft

 

HI,

It looks really great – could you please add one more question regarding segments?

With XLIFF 1.2 I saw that absolute majority of the tools had problems when the segmentation information was added. As parallel to this, I would like to know if the tools will have problems when number of segments will change (split/merge of segments).

Regards

Patrik

 


 
www.sdl.com

 

 

SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us.

SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK.

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Lucia Morado Vazquez
Sent: Wednesday, November 11, 2015 10:52 AM
To: xliff@lists.oasis-open.org
Subject: [xliff] XLIFF Support Survey Draft

 

Dear all XLIFF TC members,

 

In the XLIFF Promotion and Liaison subcommittee we have been working on a new survey to gather XLIFF 2.0 support between tool developers.

I have created a draft that can be consulted on the following url:

 

https://www.unige.ch/outils/limesurveyfac/traduction-interpretation/index.php/survey/index/sid/831562/newtest/Y/lang/en

 

If you have the time, could you review the draft of the survey before next TC meeting? Your input is very valuable and much appreciated.

 

Regards,

 

Lucía

 

 

 

Ps You can see below the original message explaining P&L subcommittee members how the survey was created:

 

 

 

As announced in the last P&L subcommittee meeting, we have been working on the set of questions for the XLIFF 2.0 support survey.

 

I have created a document where you could review the questions, those based on constraints or processing requirements of the spec begin with a different numbering system (starting from [101]…). https://docs.google.com/document/d/1cV2re9dZuVJMfDWKT6vaSGicwZF8ewS_GqkcpXMkZpU/edit?usp=sharing

I have followed the following logic to enunciate the questions:

must/required/must not/discourage/does not need  ->  does your tool…

may/ should/ should not   ->   can your tool…

I have also prepared another document from the spec for you to see the relationship between the specific processing requirement or constraint and the number of question (they are in red, you can just make a quick search by question number). https://docs.google.com/document/d/1lzV6T7Z8ectbTKx0XgGfD11-kb6FHLwP512okRQzSXo/edit?usp=sharing There were some processing requirements and constraints that I could not turn into questions, I have turned them in red, so you can easily spot them on that same document. I have not included any question from sections 4.7, 4.8 and 4.9.

 

If you have the time, could you review the draft of the survey? Your input is very valuable and much appreciated. Once it will be reviewed, I will create the survey in an online system and it will be tested before launching the survey.

 

Thank you very much,

 

Lucia

 

 

 

Click here to report this email as spam.

 

This message has been scanned for malware by Websense. www.websense.com



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