Extensions: Multiline descriptions not translatable without xml:space="preserve"

Bug #1668115 reported by Patrick Storz
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
Low
Patrick Storz
0.92.x
Fix Released
Low
Patrick Storz

Bug Description

(follow up for bug #980527)

If a description spans multiple lines, i.e.

  <description>
    I want to
    use multiple lines
    and whitespace
  </description>

it is not properly translated by gettext.

The reason is, that gettext removes whitespace in such a case and the string "I want to use multiple lines and whitespace" ends up in the "inkscape.pot" file.

Now to prevent exactly this issue one can set the 'xml:space="preserve"' attribute on the "description" which solves the issue by telling gettext to preserve all line breaks and other whitespace.

So far for the gettext side...
Inkscape is less picky. It *always* shows the text as if 'xml:space="preserve"' was specified. That is Inkscape *never* removes whitespace and always shows the string exactly as it's stored in the XML file. This is also the reason why the translation fails: Inkscape requests the translation for a string with newline characters and possibly repeated spaces and tabs, which gettext can't match.

This behavior leaves us with two quirks:
- If an extension author does not specify 'xml:space="preserve"' the message is untranslatable which is unexpected.
- The 'xml:space="preserve"' attribute has no real effect on the rendering of the string. It is more of a "workaround" for the described translation problem and does nothing beyond that.

Therefore I suggest two possible fixes:

1. The "proper" way to deal with this would be to make Inkscape actually respect the 'xml:space="preserve"' attribute when rendering the "description". This would mean that the sample above would in fact be shown as "I want to use multiple lines and whitespace" as Inkscape would remove any whitespace. This is the default for web browsers and the like and is also how Inkscape would render multiline text in a <text> node.

2. As this changes behavior it could change the appearance of some "description"s (obviously this would also be exactly those strings that are untranslatable right now). If this is something we really don't want one could solve it by keeping the behavior of Inkscape constant and simply implement a workaround for the gettext translation. This would effectively render the 'xml:space="preserve"' attribute useless as it would not offer any functionality.

Personally I'd certainly prefer option 1. as it solves all ambiguities and makes the 'xml:space="preserve"' attribute do something useful. Let me know if I should go ahead and implement this change!

Patrick Storz (ede123)
description: updated
Changed in inkscape:
assignee: nobody → Eduard Braun (eduard-braun2)
tags: added: extensions
Revision history for this message
Patrick Storz (ede123) wrote :

Here's a patch addressing the translation issue.

With the patch applied "description"s should be properly translated regardless whether xml:space="preserve" is specified or not.

Also it fixes/improves the following:
- Account for cases where the <param> node has multiple children (this can be the case if comments are included in the .inx file wich are interleaved with the text content but also if e.g. <br/> tags are used). Inkscape will now concatenate all (text-only) children of the <param> node.
- Allow <br/> to be used to produce a line break in descriptions.

Changed in inkscape:
status: New → In Progress
Revision history for this message
Patrick Storz (ede123) wrote :

Pushed to trunk in
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/15607

I suggest to also apply to 0.92.x branch to achieve consistent behavior in the stable branch and trunk. It slightly changes behavior but I guess the gain outweighs potential compatibility concerns, especially as it only affects the specific cases that resulted in untranslatable content before.

jazzynico (jazzynico)
Changed in inkscape:
importance: Undecided → Low
milestone: none → 0.93
status: In Progress → Fix Committed
Revision history for this message
Patrick Storz (ede123) wrote :

I went ahead and pushed to 0.92.x
http://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/revision/15413

Please test and let me know if you encounter any issues, so we can fix them in time for the release.

Revision history for this message
chr[] (chr0x07) wrote :

Hi

That change causes translation bugs, see screenshot (export to hpgl)

Some inx files uses this dummy:

<param name="space" type="description">&#xa0;</param>

and I am puzzled. Why is this translated?

<_param>should be translated</_param>

<param>but this not, no?</param>

Revision history for this message
Patrick Storz (ede123) wrote :

Not a regression but actually a bug that went unnoticed so far!

The changes here only made the issue visible as "&#xa0;" (non-breaking space) is now properly treated as unnecessary whitespace and therefore removed if 'xml:space="preserve"' is not specified. Therefore the description ended up as an empty string "" which is an invalid string to translate (the .po format stores meta information in the empty string which is what your screenshot shows).

Fixed in
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/15636
Descriptions are now only translated if the underscored version (<_param>) is used.

Revision history for this message
Patrick Storz (ede123) wrote :

Also committed in
http://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/revision/15418

Please feel free to thoroughly test those changes in case there are any other issues that went unnoticed so far.

Revision history for this message
chr[] (chr0x07) wrote :

Hi

I tested trunk and 0.92:

translation bugs gone,
<br/> works

Patrick Storz (ede123)
tags: added: extensions-plugins
removed: extensions
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.