GNOME Bugzilla – Bug 696179
folks-inspect, folks-import do not attempt to use translations
Last modified: 2013-03-20 16:55:22 UTC
While confirming whether <https://bugzilla.gnome.org/show_bug.cgi?id=690830#c15> was right, I looked at GNU hello to check how i18n pedants do this sort of thing. It turns out that unless we call setlocale (LC_ALL, "") (or in Vala: Intl.setlocale (LocaleCategory.ALL, "")), the utilities won't actually respect any of the l10n-related environment variables.
Created attachment 239342 [details] [review] folks-inspect, folks-import: initialize localization from the environment Otherwise, $LANG etc. are ignored and we stay in the C locale.
Created attachment 239343 [details] [review] TestCase: set locale from the environment This fixes an annoyance I'd had for a while: UTF-8 arrows etc. in debug messages came out as "?", because until we call setlocale() we're in the C locale, whose character set is ASCII (and some layer of library responds by transcoding our strings into ASCII). With this change, running the tests in en_GB.UTF-8 results in Unicode arrows and more comprehensible output. --- I would also be OK with the resolution being "don't use UTF-8 in debug()".
Review of attachment 239342 [details] [review]: ++
Review of attachment 239343 [details] [review]: ++
(In reply to comment #2) > I would also be OK with the resolution being "don't use UTF-8 in debug()". I wouldn’t! :-P
Comment on attachment 239342 [details] [review] folks-inspect, folks-import: initialize localization from the environment 0f8247ac
Comment on attachment 239343 [details] [review] TestCase: set locale from the environment 93d0f7d
fixed in git for 0.9.2