Comment 5 for bug 570740

The issue is due to how intltool-extract works. When an element value is extracted, it is not parsed and copied exactly as originally written in the po file. If the same value is in an attribute, the entities are correctly replaced with the corresponding character.

There are two solutions.

-- 1. Extracting the right value --
One workaround consists in removing the element value from the translatable strings (but keep it in the inx file), and set a fake translatable attribute with the same value:
<param name="help-dimension1" type="description" _value="Force Dimension must be set as &lt;width&gt;x&lt;height&gt;">Force Dimension must be set as &lt;width&gt;x&lt;height&gt;</param>

Which in the po file will show as:
#: ../share/extensions/webslicer_create_rect.inx.h:11
msgid "Force Dimension must be set as <width>x<height>"
msgstr ""

And the string will be correctly translated in the UI.

Ok, now we have another issue. After compiling inkscape, "make" calls the po/check-markup perl script to detect markup errors in the translations. And since <width> and <height> are not valid markups, it returns some verbose and annoying warnings (one warning per string and translation file...). While these warnings can be useful when updating a po file, they are not when compiling. Thus I suggest that we remove this step (but keep the errors, of course) in Makefile.am and comment the po string so that the translators know it must be ignored.

-- 2. Removing the < and > characters --
We could also modify the original string in order to remove the < and > characters. That's what I've done (not committed yet) with scour.inx, with its author agreement ("<g>" is now "group"). But in the <width>x<height> case, I see no other convenient way to write it.

Except if someone has a better workaround or a fix, I'm going to apply solution 1 for the webslicer extension and solution 2 for the scour one.
Any other idea?