Actually I think there is a small wording issue here: The resegmentation PR says: Only <segment> or <ignorable> elements that have their canResegment value resolved to yes MAY be split. And Only <segment> or <ignorable> elements that have their canResegment value resolved to yes MAY be join with other elements. Which seems to assume ignorable has a canResegment attribute. But that is not the case. We may want to re-word this (without changing the meaning). So Ingo, I would say: - If the parent unit of the two ignorable elements resolves to ‘yes’ (i.e. is set to ‘yes’ or inherits ‘yes’) then you can join the two ignorable (following the PRs for a join operation) - If the parent unit of the two ignorable elements resolves to ‘no’ (i.e. is set to ‘no’ or inherits ‘no’) then you cannot join the two ignorable elements. Cheers, -yves From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip Sent: Monday, September 7, 2015 10:49 AM To: Yves Savourel <ysavourel@enlaso.com> Cc: Ingo Prause <iprause@sdl.com>; xliff@lists.oasis-open.org Subject: Re: [xliff] Ignorables Sure, barring the segmentation being protected on higher levels, but this is also covered in the resegmentation PRs
======================= OASIS XLIFF TC Secretary, Editor, and Liaison Officer University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 On Mon, Sep 7, 2015 at 4:01 PM, Yves Savourel <ysavourel@enlaso.com> wrote: Hum, it’s a good question. There is a canResegment attribute that could prevent segments to be re-segmented. But its definition doesn’t explicitly applies to ignorable elements. So I’m not sure for that case. Input from other implementers would be great. But for sure if there is no such attribute set to no on the parent unit, then yes, you can re-organize the ignorable elements. -yves Hi Yves, Thank you for your answer. One more question – if you have two ignorables side-by-side, may they be merged together, or must they always remain independent items. Thanks, Ingo. ![]() 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. |
Hi Ingo, Yes, you can have ignorable elements mixed anywhere with segment elements, including several side-by-side. Usually ignorable would be used for non-translatabled “things” between segments. There are to some degree the equivalent of the possible spans of content between <mrk mtype='seg'> of 1.2. They have the same model as a <segment>, so you need to take them into account for any operation that goes across all the parts of a <unit>, like re-ordering segments, computing non-translatable spans of content (the source of one ignorable can have a <sm translate='no'> that ends in two segments after for example), etc. I hope this helps, -yves Hi, I have a question about ignorables. Can you have two ignorables side-by-side (or would you usually just have one at start/between segments/or at end and what are the processing requirements for ignorables? Thanks, Ingo. Ingo Prause | Principal Developer | SDL | (t) +353 (01) 20 50 305 SDL Global Solutions (Ireland) Limited | La Vallee House, Upper Dargle Road, Bray, Co. Wicklow, Ireland | Registered in Ireland, Number 135925 ![]() 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. |
This message has been scanned for malware by Websense. www.websense.com Click here to report this email as spam.
|