Bug 93661

Created attachment 120945 [details] [review]
mc-wait-for-name: Call setlocale in main function

Ping ... This is a trivial patch but didn't get reviewed in 6 months.

(In reply to Ting-Wei Lan from comment #2)
> Ping ... This is a trivial patch but didn't get reviewed in 6 months.

Sorry about that, the previous developers retired and I hadn't learned that I should subscribe to the bug list.

Though would you have an example local and locale environment variables that would let me test the patch?

I usually just have mine set to en_US.UTF-8

Yes, the result can be reproduced on FreeBSD by setting locale to zh_TW.UTF-8.

This patch looks like a hack... Why should the app force a specific locale? It's not so trivial imho, we should investigate it further.

(In reply to George Kiagiadakis from comment #5)
> This patch looks like a hack... Why should the app force a specific locale?
> It's not so trivial imho, we should investigate it further.

This is not a hack. This is the most common way for applications to support multiple languages. GTK+ automatically does the call for applications when gtk_init() is called. Calling setlocale with an empty string means the application doesn't force a specific locale but read values from environment variables. If a C program doesn't call setlocale, its locale is "C" or "POSIX", which is a minimal locale that has poor support for languages other than English.

(In reply to Ting-Wei Lan from comment #6)
> This is not a hack. This is the most common way for applications to support
> multiple languages. GTK+ automatically does the call for applications when
> gtk_init() is called. Calling setlocale with an empty string means the
> application doesn't force a specific locale but read values from environment
> variables. If a C program doesn't call setlocale, its locale is "C" or
> "POSIX", which is a minimal locale that has poor support for languages other
> than English.

Sorry, it seems you are right about that. I am still a bit puzzled, though... mc-wait-for-name doesn't have any translated messages, does it? So the "C" locale should work and display the English messages from the code.

$ LC_ALL=zh_TW.UTF-8 ./util/mc-wait-for-name  --help
Usage:
  mc-wait-for-name [OPTION...] - wait for a bus name

...

Looks fine without the patch... (on linux, though... is FreeBSD different regarding locales?)

(In reply to George Kiagiadakis from comment #7)
> Sorry, it seems you are right about that. I am still a bit puzzled,
> though... mc-wait-for-name doesn't have any translated messages, does it? So
> the "C" locale should work and display the English messages from the code.

mc-wait-for-name itself doesn't have translated messages, but it uses GOptionContext from GLib, which has translated messages.

(In reply to George Kiagiadakis from comment #8)
> $ LC_ALL=zh_TW.UTF-8 ./util/mc-wait-for-name  --help
> Usage:
>   mc-wait-for-name [OPTION...] - wait for a bus name
> 
> ...
> 
> Looks fine without the patch... (on linux, though... is FreeBSD different
> regarding locales?)

No, words like "Usage" and "OPTION" should be translated to Chinese. On Linux, it simply prints untranslated messages, which is still acceptable. However, on FreeBSD, it prints translated messages with all Chinese characters replaced by question marks, which is not readable.


Broken output on FreeBSD:

???
  mc-wait-for-name [???] - wait for a bus name

?????
  -h, --help          ???????

???????
  --activate=NAME     Activate NAME before waiting for the other name


Expected output:

用法：
  mc-wait-for-name [選項…] - wait for a bus name

說明選項：
  -h, --help          顯示說明的選項

應用程式選項：
  --activate=NAME     Activate NAME before waiting for the other name

Got it, sorry for being a pain here. I've pushed it in the 5.16 (stable) branch. I'll merge it to master soon.


commit c5589bdc4ded0382adf6ba9ffc5c27f8a6e0568d
Author: Ting-Wei Lan <lantw@src.gnome.org>
Date:   Mon Jan 11 15:07:56 2016 +0800

    mc-wait-for-name: Call setlocale in main function
    
    It is required to correctly show translated messages on some locales.
    
    https://bugs.freedesktop.org/show_bug.cgi?id=93661