search

microsoft / XLIFF2-Object-Model

If you’re looking to store localization data and propagate it through your localization pipeline allowing tools to interoperate then you may want to use the XLIFF 2.0 object model. The XLIFF 2.0 object model implements the OASIS Standard for the XLIFF 2.0 specification as defined at http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html.
Other
86 stars 25 forks source link

Additional whitespaces added to segments in generated file #4

Closed ghost closed 8 years ago

ghost commented 8 years ago

When creating an Xliff file from the XliffDocument object with the indentation setting enabled, the library introduces a number of whitespace and newline characters in order to pretty-print the Xliff document.

If the or element contains at the beginning an inline element, then the output file will have the inline element on a new line.

Example:

<segment>
    <source><pc id="pc5">spanning code t2</pc></source>
    <target>target here</target>
</segment>

If we deserialize this Xliff document and serialize it back using the library, then the snippet will be written in the following way:

<segment>
    <source>
                     <pc id="pc5">spanning code t2</pc>             
</source>
    <target>target here</target>
</segment>

There should be no whitespaces added before or after the element.

chrismar77 commented 8 years ago

I think this one is by design because that whitespace should be ignored unless the source element has xml:space="preserve". If you have text before the pc tag, you won't end up with that whitespace. It's only when the inner xml is an XmlElement that this spacing happens.

Having said that, we'll investigate further and report back our findings.

RyanKing77 commented 8 years ago

In the attached zip are two files: a.xlf contains the original source without spaces. b.xlf contains the round-tripped output of a.xlf that shows the spaces added.

The round-trip of b.xlf looks identical to the original b.xlf so this is not a recursive problem. Since xml:space is not specified then "default" is implied which means that whitespace should not be preserved. Thus, we think a.xlf and b.xlf are semantically equivalent and this is not a bug.

examples.zip