Bug 93661 - [PATCH] mc-wait-for-name --help shows translated characters as question marks on some locales
Summary: [PATCH] mc-wait-for-name --help shows translated characters as question marks...
Status: RESOLVED FIXED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: mission-control (show other bugs)
Version: unspecified
Hardware: Other FreeBSD
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-11 07:07 UTC by Ting-Wei Lan
Modified: 2016-07-18 17:57 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments
mc-wait-for-name: Call setlocale in main function (945 bytes, patch)
2016-01-11 07:09 UTC, Ting-Wei Lan 		Details | Splinter Review
View All

Description Ting-Wei Lan 2016-01-11 07:07:14 UTC 
Please see the attached patch. mc-wait-for-name should call setlocale in main function in order to correctly show translated messages.

Running 'mc-wait-for-name --help' with zh_TW.UTF-8 locale shows:
???
  mc-wait-for-name [???] - wait for a bus name

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

???????
  --activate=NAME     Activate NAME before waiting for the other name
Comment 1 Ting-Wei Lan 2016-01-11 07:09:49 UTC 
Created attachment 120945 [details] [review]
mc-wait-for-name: Call setlocale in main function
Comment 2 Ting-Wei Lan 2016-07-16 16:13:10 UTC 
Ping ... This is a trivial patch but didn't get reviewed in 6 months.
Comment 3 diane 2016-07-16 17:02:11 UTC 
(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
Comment 4 Ting-Wei Lan 2016-07-16 17:04:48 UTC 
Yes, the result can be reproduced on FreeBSD by setting locale to zh_TW.UTF-8.
Comment 5 George Kiagiadakis 2016-07-16 18:12:40 UTC 
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.
Comment 6 Ting-Wei Lan 2016-07-16 18:39:17 UTC 
(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.
Comment 7 George Kiagiadakis 2016-07-18 14:24:35 UTC 
(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.
Comment 8 George Kiagiadakis 2016-07-18 14:27:49 UTC 
$ 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?)
Comment 9 Ting-Wei Lan 2016-07-18 17:26:16 UTC 
(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
Comment 10 George Kiagiadakis 2016-07-18 17:57:07 UTC 
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

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.