kernel32: Allow the prefered language to be different from the prefered locale on Mac OS X. [take3]

[Ken Thomases]

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