GNOME Bugzilla – Bug 106549
popt --help messages not translated
Last modified: 2006-05-23 15:49:56 UTC
The popt --help messages (poptOptions.descrip) are marked for translation with N_, and most have translations in the .po files, but they are never translated with _().
This has been fixed by a patch from Hidetoshi Tajima from Sun. There's a closed dupe in here somewhere.
And I'm on crack. That was a similar fix in gnomecc.
Care to point out where they should be _() marked or whip up a patch?
Created attachment 20136 [details] [review] Proposed patch.
The author's misassumption was that popt does some gettext magic, so he just added gettext_noop calls - but this assumption was wrong. regs, Chris
*** Bug 106561 has been marked as a duplicate of this bug. ***
*** Bug 106563 has been marked as a duplicate of this bug. ***
I don't see why you've gone marking dups willy nilly... your patch doesn't appear to translate any strings that originate outside libgnome (if that's even possible).
This problem is a bit tricky since the --help message is composed of many strings: - libgnome-specific (inter alia --load-modules) <1> - popt-specific (Help options) <2> - application-specific (Application options) <3> - external stuff (GTK+, Session managment) <4> <1> is covered by this patch, <2> is up to popt, <3> and <4> are weird: If the application calls setlocale (LC_ALL, ""); and binds the text domain before calling gnome_program_init, everything is translated, including <3> and <4>. If not, nothing is translated. Therefore I propose to add a setlocale (LC_ALL, ""); call to gnome_program_init - if an application wants to prevent i18n, it would have to call setlocale (LC_ALL, "C");. regs, Chris
Created attachment 20141 [details] [review] Proposed patch for 2nd issue, seems to work. --help output from all libgnome-dependant apps is translated.
> If the application calls setlocale (LC_ALL, ""); and binds the text > domain before calling gnome_program_init, everything is translated, > including <3> and <4>. Not true. Take gedit for instance. The messages are marked translatable, but are never translated, regardless of whether setlocale() is called. static const struct poptOption options [] = { { "debug-utils", '\0', POPT_ARG_NONE, &debug_utils, 0, N_("Show utility debugging messages."), NULL }, { "debug-metadata", '\0', POPT_ARG_NONE, &debug_utils, 0, N_("Show metadata debugging messages."), NULL }, [...] }; int main (int argc, char **argv) { [...] program = gnome_program_init ("gedit", VERSION, [...] GNOME_PARAM_POPT_TABLE, options, [...] NULL); [...] }
Please, apply the patch and try again. For me it didn't work before applying it, now it works. regs, Chris
[I think this should be given high priority, since all Gnome applications are affected by this.] Calling setlocale(LC_ALL, "") or similar *before* the popt parses --help option is definitely required, but, this only is not enough. Indeed, when you build gedit on late CVS and run it in non-UTF-8 locales, the help options are printed to the stdout in two different encodings and some are left untranslated while their Japanese translations do exist and have been installed. Below is how they actually happens in ja_JP.eucJP locale, and the causes of the happenings. - gedit's "Application options", encoded in eucJP gedit main rouline calls gnome_program_init() and then bind_textdomain_codeset() for gedit's message catalog, so when popt parses --help messages, gettext returns locale's encoded strings. (See gedit/gedit/gedit2.c). - "GTK+", non-translated. This is normal.There is no po/mo for GTK+... - "Bonobo activation Support", non-translated. These translations are in libbonobo-2.0 message catalog, so bindtextdomain ("libbonobo-2.0", LIBGNOME_LOCALEDIR); has to be called somewhere. - "GNOME GConf support", "Gnome Library" options, encoded in UTF-8 These two are from libgnome's message catalog, which has been already bound to "UTF-8". (gnome-init.c). - "Session Management", non-translated. This is from libgnomeui's gnome-client.c, but libgnomeui's message catalog is not bound to the domain yet. - "GNOME GUI Library", non-translated. This is from libgnomeui's gnome-ui-init.c, but libgnomeui's message catalog is not bound to the domain yet. I'll attach a patch to fix these problems and make gedit's --help messages all printed in the locale's encoding. Note that the change made to bind "libbonobo-2.0" to "UTF-8" is nasty hack. This perhaps should be done in libbonobo's public function, which can be called from libgnome's gnome_program_init(). Also, a lot of apps should be changed so that they don't bindtextcodeset to UTF-8 when --help option is given. A hack in gnome_program_init() to do this for all apps will be preferable than chaning all app's codes.
Created attachment 20301 [details] [review] A combined patch for libgnome/libgnomeui/libbonobo
Ah, while preparing the attached patch, I found putting bindtextdomain into bobobo_activation_preinit() would work, so what I said was nasty in the previous comment does not exist in the patch. please review and let me know if they are okay to commit to the HEAD.
Someone needs to review this and/or commit.
I've committed this. However, it doesn't look like the words "Help options" and "Application options" are being translated, so I'm not closing this bug yet.
Anders: Please apply my first patch from 09/20/03. It should work. regs, Chris
I tried it at first, but it didn't work. For some weird reason it does now though. Thanks!
--- libgnome/libgnome/gnome-init.c 23 Sep 2003 20:18:44 -0000 1.106 +++ libgnome/libgnome/gnome-init.c 26 Sep 2003 00:39:40 -0000 +#if 0 #ifdef HAVE_BIND_TEXTDOMAIN_CODESET bind_textdomain_codeset (GETTEXT_PACKAGE, "UTF-8"); #endif - +#endif This part of the patch breaks gnome-panel when it tries to get translations from libgnome. My default charset is ISO8859-1, and when gnome-panel gets translated strings from libgnome, it seems to get them encoded in ISO8859-1, which doesn't work at all when trying to put it in a GTK+ label. To reproduce it, launch gnome-panel witha non utf8 locale, open the panel run dialog, type a non existing name in it. I get an error message about gnome-panel not being able to create the dialog instead of a translated message saying the specified location doesn't exist.
I've put back the bindtextdomain_codeset call. However, I'm going to keep this bug open until we have a system where we can print out the --help strings in the locale encoding.
Comment on attachment 20301 [details] [review] A combined patch for libgnome/libgnomeui/libbonobo This was committed as far as I know.
I still see english output from 1) and 2) here even with all bits commited. 2) could very well be because popt isn't translated to nb_NO, but 1) should have been working, right?
1) is still broken here. Anyone know what's up? The first patch attached here also seems to have been applied. Why is it marked obsolete then?
(In reply to comment #21) > I've put back the bindtextdomain_codeset call. However, I'm going to > keep this bug open until we have a system where we can print out the > --help strings in the locale encoding. We have that system now since this works when using goption argument parsing (well, once the patch from bug 335159 is checked in).
The patch went in so I'm closing this bug.