GNOME Bugzilla – Bug 708096
gettext-0.18.3.1 doesn't extract some strings
Last modified: 2013-12-31 21:27:50 UTC
The following strings are not extracted to the POT file when running intltool-update with gettext-0.18.3.1-1.fc20.x86_64: https://git.gnome.org/browse/gnome-shell/tree/js/ui/status/keyboard.js#n403 ("Show Keyboard Layout") https://git.gnome.org/browse/gnome-shell/tree/js/extensionPrefs/main.js#n125 ("There was an error loading the preferences dialog for %s:") https://git.gnome.org/browse/gnome-shell/tree/js/extensionPrefs/main.js#n165 ("Extension")
This is an another string that doesn't get extracted: https://git.gnome.org/browse/gnome-shell/tree/js/extensionPrefs/main.js#n153 ("GNOME Shell Extension Preferences") And more importantly, these two strings get extracted differently using 0.18.3.1 and an older version: https://git.gnome.org/browse/gnome-shell/tree/js/ui/status/power.js#n75 gettext-0.18.3.1 changes \u2236 into "∶" unicode character, so if the translation was done using an older gettext (and 99% are), these strings get fuzzy and appear untranslated in the UI. And that's pretty bad.
Please ignore the issue in power.js, it got fixed by a new gettext on damned-lies. The others are still valid though. :(
fwiw, the behaviour of gettext-0.18.3.1 on the last point is correct. If it doesn't unescape the Unicode escapes then the string is truly untranslated (as determined by what gettext() will return at runtime). No comment on the other issue. Regression in new gettext extraction? Not likely a bug in the shell, in any case.
I've filed a bug in upstream gettext: https://savannah.gnu.org/bugs/index.php?40125
gettext got fixed upstream in master, but in the meantime gjs/gnome-shell stopped using E4X. Oh well.