Re: kernel32: Allow the prefered language to be different from the prefered locale on Mac OS X. [take3]
Wait, wait... On Dec 12, 2006, at 6:55 AM, Pierre d'Herbemont wrote:
This time with Alexandre suggestion to use directly parse_locale_name.
We still leave the possibility not to use the System preferences language if LC_MESSAGES env variable LC_MESSAGES was set to a value different than the default ("C").
Pierre. --- dlls/kernel32/locale.c | 37 ++++++++++++++++++++++++++++++++++++- 1 files changed, 36 insertions(+), 1 deletions(-) diff --git a/dlls/kernel32/locale.c b/dlls/kernel32/locale.c index 8792623..c70e08c 100644 --- a/dlls/kernel32/locale.c +++ b/dlls/kernel32/locale.c @@ -2832,11 +2839,39 @@ void LOCALE_Init(void) unix_cp = CP_UTF8; /* default to utf-8 even if we don't get a valid locale */ setenv( "LANG", user_locale, 0 ); TRACE( "setting locale to '%s'\n", user_locale ); -#endif + + /* We still want to set the retrieve the prefered language as choosen in + System Preferences.app, because it can differ from CFLocaleCopyCurrent(). + */ + all_locales = CFLocaleCopyAvailableLocaleIdentifiers(); + preferred_locales = CFBundleCopyLocalizationsForPreferences ( all_locales, NULL );
I thought I explained that exactly the above combination of calls produces unusable results. For example, for me it produces "en_ZW" -- English (Zimbabwe). In System Preferences, I have set "English" (no country) as my preferred language and U.S. for other locale settings. In other words, it is picking a random country.
+ if (preferred_locales) + { + if (CFArrayGetCount( preferred_locales )) + user_language_string_ref = CFArrayGetValueAtIndex ( preferred_locales, 0 ); + CFRelease( preferred_locales ); + } + CFRelease( all_locales ); +#endif /* __APPLE__ */ + setlocale( LC_ALL, "" );
unix_cp = setup_unix_locales(); if (!lcid_LC_MESSAGES) lcid_LC_MESSAGES = lcid_LC_CTYPE; +#ifdef __APPLE__ + /* Override lcid_LC_MESSAGES with user_language if LC_MESSAGES is set to default */ + if (lcid_LC_MESSAGES == lcid_LC_CTYPE && user_language_string_ref) + { + struct locale_name locale_name; + WCHAR buffer[128]; + CFStringGetCString( user_language_string_ref, user_locale, sizeof(user_locale), kCFStringEncodingUTF8 ); + strcpynAtoW( buffer, user_locale, sizeof(buffer)/sizeof (WCHAR) ); + parse_locale_name( buffer, &locale_name ); + lcid_LC_MESSAGES = locale_name.lcid; + TRACE( "setting lcid_LC_MESSAGES to '%s'\n", user_locale ); + } +#endif + NtSetDefaultUILanguage( LANGIDFROMLCID(lcid_LC_MESSAGES) ); NtSetDefaultLocale( TRUE, lcid_LC_MESSAGES ); NtSetDefaultLocale( FALSE, lcid_LC_CTYPE );
On Dec 13, 2006, at 4:46 PM, Ken Thomases wrote:
Wait, wait...
On Dec 12, 2006, at 6:55 AM, Pierre d'Herbemont wrote:
+ all_locales = CFLocaleCopyAvailableLocaleIdentifiers(); + preferred_locales = CFBundleCopyLocalizationsForPreferences ( all_locales, NULL );
I thought I explained that exactly the above combination of calls produces unusable results. For example, for me it produces "en_ZW" -- English (Zimbabwe). In System Preferences, I have set "English" (no country) as my preferred language and U.S. for other locale settings.
In other words, it is picking a random country.
Ok, sorry for misreading, I though you get the random country with the previous 'opendir' code. But it is weird: here on Mac OS X 10.4.8 CFLocaleCopyAvailableLocaleIdentifiers() returns [2], which contains 'en', and with "defaults read -g AppleLanguages" reporting [1], I get user_language_string_ref pointing 'en'. I don't understand if CFBundleCopyLocalizationsForPreferences does a bseach, why 'en' is not matched on your system. If it is really picking a random country, I think we should directly get user_language_string_ref from the preferences. Thanks, Pierre. [1] (en, fr, es, de, ja, it, nl, sv, nb, da, fi, pt, "zh-Hans", "zh- Hant", ko) [2] ( af, "af_ZA", am, "am_ET", ar, "ar_AE", "ar_BH", "ar_DZ", "ar_EG", "ar_IN", "ar_IQ", "ar_JO", "ar_KW", "ar_LB", "ar_LY", "ar_MA", "ar_OM", "ar_QA", "ar_SA", "ar_SD", "ar_SY", "ar_TN", "ar_YE", be, "be_BY", bg, "bg_BG", bn, "bn_IN", ca, "ca_ES", cs, "cs_CZ", cy, "cy_GB", da, "da_DK", de, "de_AT", "de_BE", "de_CH", "de_DE", "de_LU", el, "el_GR", en, "en_AU", "en_BE", "en_BW", "en_CA", "en_GB", "en_HK", "en_IE", "en_IN", "en_MT", "en_NZ", "en_PH", "en_PK", "en_SG", "en_US", "en_US_POSIX", "en_VI", "en_ZA", "en_ZW", eo, es, "es_AR", "es_BO", "es_CL", "es_CO", "es_CR", "es_DO", "es_EC", "es_ES", "es_GT", "es_HN", "es_MX", "es_NI", "es_PA", "es_PE", "es_PR", "es_PY", "es_SV", "es_US", "es_UY", "es_VE", et, "et_EE", eu, "eu_ES", fa, "fa_AF", "fa_IR", fi, "fi_FI", fo, "fo_FO", fr, "fr_BE", "fr_CA", "fr_CH", "fr_FR", "fr_LU", ga, "ga_IE", gl, "gl_ES", gu, "gu_IN", gv, "gv_GB", haw, "haw_US", he, "he_IL", hi, "hi_IN", hr, "hr_HR", hu, "hu_HU", hy, "hy_AM", "hy_AM_REVISED", id, "id_ID", is, "is_IS", it, "it_CH", "it_IT", ja, "ja_JP", kk, "kk_KZ", kl, "kl_GL", kn, "kn_IN", ko, "ko_KR", kok, "kok_IN", kw, "kw_GB", lt, "lt_LT", lv, "lv_LV", mk, "mk_MK", ml, "ml_IN", mr, "mr_IN", ms, "ms_BN", "ms_MY", mt, "mt_MT", nb, "nb_NO", nl, "nl_BE", "nl_NL", nn, "nn_NO", om, "om_ET", "om_KE", or, "or_IN", pa, "pa_IN", pl, "pl_PL", ps, "ps_AF", pt, "pt_BR", "pt_PT", ro, "ro_RO", ru, "ru_RU", "ru_UA", sk, "sk_SK", sl, "sl_SI", so, "so_DJ", "so_ET", "so_KE", "so_SO", sq, "sq_AL", sr, "sr_Cyrl", "sr_Cyrl_YU", "sr_Latn", "sr_Latn_YU", "sr_YU", sv, "sv_FI", "sv_SE", sw, "sw_KE", "sw_TZ", ta, "ta_IN", te, "te_IN", th, "th_TH", ti, "ti_ER", "ti_ET", tr, "tr_TR", uk, "uk_UA", vi, "vi_VN", zh, "zh_Hans", "zh_Hans_CN", "zh_Hans_SG", "zh_Hant", "zh_Hant_HK", "zh_Hant_MO", "zh_Hant_TW" )
On Dec 13, 2006, at 12:02 PM, Pierre d'Herbemont wrote:
On Dec 13, 2006, at 4:46 PM, Ken Thomases wrote:
Wait, wait...
On Dec 12, 2006, at 6:55 AM, Pierre d'Herbemont wrote:
+ all_locales = CFLocaleCopyAvailableLocaleIdentifiers(); + preferred_locales = CFBundleCopyLocalizationsForPreferences ( all_locales, NULL );
I thought I explained that exactly the above combination of calls produces unusable results. For example, for me it produces "en_ZW" -- English (Zimbabwe). In System Preferences, I have set "English" (no country) as my preferred language and U.S. for other locale settings.
In other words, it is picking a random country.
Ok, sorry for misreading, I though you get the random country with the previous 'opendir' code.
But it is weird: here on Mac OS X 10.4.8 CFLocaleCopyAvailableLocaleIdentifiers() returns [2], which contains 'en', and with "defaults read -g AppleLanguages" reporting [1], I get user_language_string_ref pointing 'en'. I don't understand if CFBundleCopyLocalizationsForPreferences does a bseach, why 'en' is not matched on your system.
If it is really picking a random country, I think we should directly get user_language_string_ref from the preferences.
D'oh! My bad. I had a wrong notion in my head, which is that we were going to filter out elements from the CFLocaleCopyAvailableLocaleIdentifiers array which didn't have country codes. In that case, my preferred language doesn't appear verbatim and CFBundleCopyLocalizationsForPreferences picks one of the half-matching entries more or less at random. However, since Alexandre's suggestion means we don't have to do that filtering, then your code is fine. Sorry for the false alarm. -Ken
participants (2)
-
Ken Thomases -
Pierre d'Herbemont