Untranslatable strings

Patch committed in bzr revision 9387.
I've also added another forgotten string in measure.inx.

Character entities are already used in at least scour.inx, without problem.
The difference here is that we have a long word containing a normal characters and entities mix...
I won't have time to investigate until tomorrow evening. Tell me if you find a clue.

Regards.

> Patch committed in bzr revision 9387.
> I've also added another forgotten string in measure.inx.

Thanks!

> Character entities are already used in at least scour.inx, without problem.

Hmm, I noticed that the string in scour.inx is also not localized in my system.

My system environment is as follows:
=============================================================================
When you report a trouble about building SVN version of inkscape,
Please report following information about distro and tools version, too.

--1. distribution------------------------------------------------------------
distro: Cannot find distribution information
Terminating....

--> ArchLinux x86_64

--2. tools-------------------------------------------------------------------
/usr/bin/m4: m4 (GNU M4) 1.4.14
/usr/bin/autoconf: autoconf (GNU Autoconf) 2.65
/usr/bin/autoheader: autoheader (GNU Autoconf) 2.65
/usr/bin/automake: automake (GNU automake) 1.11.1
automake-1.7: not found
automake-1.8: not found
automake-1.9: not found
/usr/bin/aclocal: aclocal (GNU automake) 1.11.1
aclocal-1.7: not found
aclocal-1.8: not found
aclocal-1.9: not found
/usr/bin/intltoolize: intltoolize (GNU intltool) 0.41.1
/usr/bin/gettextize: /usr/bin/gettextize (GNU gettext-tools) 0.17

--3. environment variables---------------------------------------------------
LDFLAGS=-Wl,--hash-style=gnu -Wl,--as-needed
GLADE_PIXMAP_PATH=:
MAKEFLAGS=-j5
LD_LIBRARY_PATH=/usr/lib/libfakeroot:/usr/lib64/libfakeroot:/usr/lib32/libfakeroot
GLADE_MODULE_PATH=:
CXXFLAGS=-g -O0 -Wall -I/usr/include/ImageMagick
MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins
PATH=/home/hashimo/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/share/java/apache-ant/bin:/usr/bin/perlbin/site:/usr/bin/perlbin/vendor:/usr/bin/perlbin/core
LANG=ja_JP.UTF-8
CFLAGS=-g -O0 -Wall -I/usr/include/ImageMagick
GTK_PATH=:/usr/lib/gtk-2.0
PKG_CONFIG_PATH=/usr/lib/pkgconfig
WINDOWPATH=7
GLADE_CATALOG_PATH=:
LIBGLADE_MODULE_PATH=:/usr/lib/libglade/2.0

=============================================================================

> Hmm, I noticed that the string in scour.inx is also not localized in my system.

Yes, you're right, it affects all character entities.
I've replaced the affected line directly in my fr.po file with: "Force Dimension must be set as \"<width>x<height>\"" and it works correctly. But since it's a manual workaround, it's not safe at all.

The problem with entities is that they are parsed before being compared to the translation file, and thus find no matching string. And the XML parser doesn't like it if we use < and > directly in the extension INX file...

Still investigating.

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?

Committed in bzr revision 9409.