GNOME Bugzilla – Bug 114190
Non-ASCII message in gnome-applets gives xgettext warning and msgmerge error
Last modified: 2005-08-15 01:46:10 UTC
From accessx-status/applet.c:843: glyph_pixbuf = accessx_status_applet_get_glyph_pixbuf (sapplet, widget, pixbuf, fg, bg, N_("æ")); This gives the following xgettext warning: xgettext: warning: The following msgid contains non-ASCII characters. This will cause problems to translators who use a character encoding different from yours. Consider using a pure ASCII msgid instead. æ xgettext: invalid multibyte sequence xgettext: invalid multibyte sequence xgettext: invalid multibyte sequence xgettext: invalid multibyte sequence Using non-ASCII characters in messages marked for translation is not allowed by gettext. Please see http://developer.gnome.org/doc/tutorials/gnome-i18n/developer.html#use-ascii.
Bill: we now have a bugzilla catagory for the accessx applet. We should probably put you as the default owner of this catagory.
Failed to mention that msgmerge also ends with an error after the xgettext warnings.
Sorry to leave this one hanging, (quick) fix in CVS (removed l10n macro from non-ASCII string). Will fix "properly" with en_ locale soon... thanks.
Created attachment 20151 [details] [review] Escape ae character properly, mark it for translation again, add neccessary stuff to POTFILES.in.
Christian N: I didn't know gettext strings could contain non-ASCII characters... if your fix is acceptable to the rest of the i18n and l10n teams, then I prefer it, but it's not obvious that everyone will agree that it's right. Menthos? what do you think?
The use of UTF-8 in gettext messages requires both a very recent intltool (intltool >= 0.27) and a recent GNU gettext version (GNU gettext >= 0.12). See bug 99005 for some discussion. Other intltool versions and gettext implementations are AFAIK not supporting UTF-8 inside msgids, and will give warnings and errors when compiling the po catalogs. Hence, if the above requirements aren't acceptable, I still think we should very much avoid using UTF-8 inside gettext messages.
I think we should apply cneumair's patch now. Jody, is that OK with you?
I would really like to see this go in soon, being a Unicode geek and all. :)
Is the patch working[tm] ?, Kevin can i commit ?
We would need to do a configure check for gettext. I don't even have gettext >= .12. Christian: Is gettext >= .12 required by any other gnome modules? What do you suggest?
> Is gettext >= .12 required by any other gnome modules? Not that I know of. Gnumeric HEAD depends on it, but then it isn't part of the GNOME desktop release either. > What do you suggest? Difficult to know, as I don't even know what this character is used for (the presence of a translator comment would surely help).
translator comment should be /* a representative single character resulting when 'AltGr' is pressed; this character is used to indicate that AltGr (also known as ISO_Level_Shift) is active. */ Permission to apply patch which adds this comment requested.
pinging maintainer again... permission to apply comment patch above requested.
Uhh, Bill, _you_ are the maintainer ;) Why do you need permission? For which patch?
Hi Kevin: OK, I didn't know I had maintainer rights in perpetuity to this applet just 'cause I wrote it. Sounds good - I'll make the change. I will however post patches before doing anything significant to the applet in future.
Please also note that we're in string freeze... changing now needs approval.
Christian: the patch applies a comment, it does not change a string. I do not see why this requires permission.
The only patch I can see in this report (patch 20151) adds a new message.
See my comment above: I wrote "permission to apply patch which adds this comment", meaning _a_ patch which applied the comment, not permission to add the previous patch. The patch was so trivial I put it inline in my comment. The translator comment has now been added. However the string has _not_ been marked for translation. I think that should wait until 2.8, when lots of build tools will be upgraded, IIRC. It doesn't look like there's agreement about requiring gettext 0.12 in 2.6.
Comment on attachment 20151 [details] [review] Escape ae character properly, mark it for translation again, add neccessary stuff to POTFILES.in. This patch is being marked as 'committed'; however, there appears to be some confusion about 'comment' and 'string'. Anyone want to clarify this?
patch was _not_ committed. Possibly can commit something like it to HEAD (not 2.6), with the appropriate configure.in changes to require gettext 0.12.
When escaping the string do we also need gettext 0.12 ?
Yes. Gettext understands C-style escaped characters, and gettext < 0.12 will still bork if it finds one which indicate a character outside the 7-bit ASCII range. So escaping makes no difference.
What is the status of this bug? Surely this is resolved through the gettext/intltool requirements of GNOME2.8/2.10?
Ping!
I think this can be closed. I cannot reproduce the original problem with current tools.