[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] ITS: Preserve space and Language Information
Hi David, all,
While in some cases (like multiple spaces between sentences) using <ignorable> with xml:space could be a solution, that can’t solve all use cases, and, as pointed out, that will cause trouble when re-segmenting.
The other solution (using inline codes to store spans of white-spaces) looks like asking for troubles: The main reason for such complicated option would be because xml:space can’t be set in <mrk>. It would also not solve the xml:lang case. In general we do not want to encourage using more inline codes.
I think the simplest and most comprehensive solution is to have its:space and its:lang defined and behaving just like xml:space and xml:lang, but with the sm-specific scope. That doesn’t preclude anyone to use the other options if they really want to go that road.
It simply means that if you want to handle Preserve Space or Language Information at the inline level, you have to support that part of the ITS module (which is really not complicated when you already have to handle xml:space and xml:lang for the Core). That means one cannot guarantee those features will be preserved by Core-only processors. But it’s already the case in 2.0.
From: Dr. David Filip [mailto:David.Filip@ul.ie]
I was thinking about two possible solutions.
One of them would be as you propose to introduce its attributes that could work with empty markers as span delimiters.
Another way would be to use the fact that the two relevant XML namespace attributes are still available on <source> and <target>
Not sure if this is an omission, probably not as we have PR for resegmentation accounting for that.
This would be somewhat restrictive but would have the advantage that the related mark up would be always well formed
I tried to write up such restrictive solution for Preserve Space in the Current Working draft.
It also notes that you can use originalData to preserve whitespace..
I copy paste it here:
Indicates how to handle whitespace in a given content portion. See [ITS] Preserve Space for details.
Whitespace handling at the structural level is indicated with xml:space in XLIFF Core and extensions:
Extraction of preserved whitespace at the structural level
<listing xml:space='preserve'>Line 1
<unit id='1' xml:space='preserve'>
It is not possble to use [XML namespace] on XLIFF inline elements. It is advised that mixed Preserve Space behavior is NOT used inline in source formats. In case of extraction of source format inline elements with mixed Preserve Space behavior, it is advised to extract all discernable portions with uniform whitespace handling into different <unit> elements that can have their whitespace handling set independently.
Whitespace handling can be also set independently for text segments and ignorable text portions within an Extracted unit and for the source ad target language within the same <segment> or <ignorable> element using the optional xml:space attribute at the <source> and <target> elements. However, mixed whitespace handling behavior is not likely to survive Segmentation Modification. So this method is not advised unless the <segment> elements are protected by the canResegment flag value set to or inhrited as no.
Preserved whitespaces can be also extracted as original data stored outside of the translatable content at the unit level and referenced from placeholder codes. It is importnat to note that the value of the xml:space attribute is restricted to preserve on the <data> element.
Extraction of preserved whitespaces as referenced original data
<span xml:space='preserve'>Item 1 Item 2 Item n+1
</span> are all used to build Item n+2.
<data id="d1"><span xml:space='preserve'></data>
<data id="d3"> </data>
<source><pc id="1" dataRefStart="d1" dataRefEnd="d2">Item 1<ph id="2" dataRef="d3">Item 2<ph id="2" dataRef="d3">Item n+1<ph id="2" dataRef="d4"></pc> are all used to build Item n+2.</source>
Not sure really which solution is better, but I'd say we should explore both..
On Thu, Oct 23, 2014 at 1:41 PM, Yves Savourel <email@example.com> wrote: