kernel32: Allow the prefered language to be different from the
prefered locale on Mac OS X. [take3]
ken at codeweavers.com
Wed Dec 13 12:20:01 CST 2006
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 , which
> contains 'en', and with "defaults read -g AppleLanguages" reporting
> , 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.
More information about the wine-devel