Closed Bug 1677173 Opened 11 months ago Closed 8 months ago

Attribute xml:space="preserve" is lost when translating XLIFF strings


(Webtools Graveyard :: Pontoon, defect, P2)


(Not tracked)



(Reporter: flod, Assigned: mathjazz)


I'm not exactly sure what the right behavior should be here, but:

  • All strings for the VPN client are marked with xml:space="preserve".
  • When I translate them in Pontoon, the attribute is lost.

Example of commit from Pontoon:

I would expect attributes in the source string to be kept in the translation.

Right now, the automation extracting new strings is also adding these attributes back (example).

Priority: -- → P2

I tried to dig a bit deeper.

Managing xml:space

I think this might have larger functionality implications

SDL does different things with whitespaces depending on that value. It's unclear what happens to the target element (I assume the attribute is maintained).

Is the XLIFF exported by QT libraries incorrect?

Looking at examples from Transifex and others, I noticed that the xml:space attribute is defined on the <trans-unit>, not on the <source> within.

The XLIFF 1.2 specs have xml:space attribute as optional on:

  • <file>
  • <group>
  • <trans-unit>
  • <alt-trans>

There's no mention of <source>.

I think we should morph this bug into a more generic "Handle xml:space in XLIFF file", and fix the VPN string as part of the export automation.


Seems like this is indeed a bug on the VPN export side.

We don't have that problem in Firefox for iOS for example, which introduced the xml:space="preserve" attribute as part of the migration to latest Xcode tools. Note that it rightfully puts the attribute in the <trans-unit> element:

If we'll need to add the ability to manage space differently based on the value of the xml:space attribute, we should file a separate bug for that.

Assignee: nobody → m
Closed: 8 months ago
Resolution: --- → INVALID
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.