This is a spin-off from bug 150131. Currently, Mozilla uses LC_MESSAGES (when HAVE_I18N_LC_MESSAGES is set at the configuration stage) in nsLocaleService::GetLocaleComponentForUserAgent instead of LC_CTYPE. However, I don't think this is not a good use of LC_MESSAGES. Often times, people set LC_MESSAGES to C/POSIX/en_US while setting other LC_*'s to values for their native languages (e.g. ja_JP, ko_KR, ru_RU, etc). Why? Because the quality of the translation is not so good for a number of commercial and non-commercial command line utils and GUI programs to extent that a number of people find it more comfortable to work with English menus, error messages, help and so forth. (see bug 150131) than with translated ones. Anyway, Mozilla determines the character repertoire of the current locale based on the value of LC_MESSAGES instead of LC_CTYPE. This leads to an unexpected surprise when LC_MESSAGES is set to C while LC_CTYPE is set to, say, ja_JP. Japanese string is not rendered properly in the window title bar because Japanese characters are considered outside the character repertoire of the current locale determined based on LC_MESSAGES instead of LC_CTYPE. This is not consistent with what people expect. LC_MESSAGES is NOT expected to have any influence on the character repertoire of the current locale. LC_CTYPE IS !!
The patch is in the cross-platform and I am not sure about the impact of the patch. cc ftang and others for their opinion.
Code issue, qa -> firstname.lastname@example.org for now, please reassign if needed.
QA Contact: ruixu → yokoyama
Wow, this code was written by tague in 1999. Frank: do you understand what it does?
Marking NEW so it gets some patch loving.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: LC_CTYPE should be used instead of LC_MESSAGES to determine the char. repertoire → [PATCH] LC_CTYPE should be used instead of LC_MESSAGES to determine the char. repertoire
A good discussion about LC_CTYPE vs. LC_MESSAGES: http://xfree86.org/pipermail/fonts/2002-July/001838.html
assign to ftang. I am not a right owner for this.
Assignee: yokoyama → ftang
To make decsion, we need to understand what this code will impact. From my understanding: this code will impact GetLocaleComponentForUserAgent and then getUILangCountry in nsAppRunner. This is code added by tao in March 31. reassign to tao. I am not sure which way is better or not. Just want to clearify that reassign this to tao does not mean I think this is a bug nor do I think it is an invalid request. Future study by tao is needed
Assignee: ftang → tao
Hi, Bob: please reassign these i18n/l10n/l12y bugs accordingly. thx!
Assignee: tao → bobj
You need to log in before you can comment on or make changes to this bug.