Thanks David,
I’ll read that section you mentioned.
Regards,
Ingo.
From: Dr. David Filip [mailto:]
Sent: 07 September 2015 17:49
To: Yves Savourel
Cc: Ingo Prause;
Subject: Re: [xliff] Ignorables
Sure, barring the segmentation being protected on higher levels, but this is also covered in the resegmentation PRs
http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#segmentationModification
Dr. David Filip
=======================
OASIS XLIFF TC Secretary, Editor, and Liaison Officer
LRC | CNGL | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
http://www.cngl.ie/profile/?i=452
mailto:
On Mon, Sep 7, 2015 at 4:01 PM, Yves Savourel <> 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
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: Ingo Prause [mailto:]
Sent: Monday, September 7, 2015 7:50 AM
To: Yves Savourel <>;
Subject: RE: [xliff] Ignorables
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.
From: Yves
Savourel [mailto:]
Sent: 07 September 2015 14:36
To: Ingo Prause;
Subject: RE: [xliff] Ignorables
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
From:
[mailto:]
On Behalf Of Ingo Prause
Sent: Monday, September 7, 2015 7:05 AM
To:
Subject: [xliff] Ignorables
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.
