GNOME Bugzilla – Bug 523983
pl_PL locale contains invalid string format macros
Last modified: 2009-05-14 00:30:39 UTC
Steps to reproduce: 1. LC_ALL=pl_PL gcalctool 2. That's all. Stack trace: Dies inside glibc trying to expand 9 passed as int into a (const char *) string. Other information: I will attach a patch that fixes the issue with pl_PL locale. Please check other locales for similar problems.
Created attachment 107869 [details] [review] pl_PL patch Fixes the crasher.
msgfmt --check don't yield because of the "#, no-c-format" line. IMHO, that's the real problem. And xgettext add this line because the string is also found in the glade file, where a % format specifier has no sense (it is replaced in gtk.c). The two problematic strings are: #: ../gcalctool/gtk.c:542 #: ../glade/gcalctool.glade.h:389 #, no-c-format msgid "_Other (%d) ..." msgstr "_Inna (%d) ..." #: ../gcalctool/gtk.c:2921 #: ../glade/gcalctool.glade.h:269 #, no-c-format msgid "Reset to _Default (%d)" msgstr "Przywróć _domyślną (%s)" The quick fix is to correct the pl.po file, but the problem should be fundamentally addressed by removing the format specifiers from the glade file.
Created attachment 107901 [details] [review] Patch including glade correction One solution is to simply remove the translatable property of the affected strings in the glade file.
I've also checked that currently no other locale presents this problem in trunk (after applying the patch). $ for f in *.po; do intltool-update `basename $f .po`; msgfmt -vvc -o /dev/null $f; done
Fixed on HEAD and gnome-2-22 branch :)
Thanks Artur. Now there is just the glade correction left... Lowering the severity, because there should be no more crasher right now.
*** Bug 525266 has been marked as a duplicate of this bug. ***
Closing as this appears to have been fixed some time ago.