kernel32: Partially implement GetGeoInfo()

[Nikolay Sivov]

On 07/08/2014 07:32 AM, Dmitry Timoshkov wrote:
> Nikolay Sivov <nsivov at codeweavers.com> wrote:
>
>>> Wouldn't it be easier to just map geo id to locale id instead of creating
>>> a completely separate data set? That way mapping between locale and geo
>>> info would look something like this:
>>>
>>> GEO_ISO2 -> LOCALE_SISO3166CTRYNAME
>>> GEO_ISO3 -> LOCALE_SABBREVCTRYNAME
>> Well, you don't have locale info for all supported locations.
>
> Is it possible to add new ones as needed?

My understanding is that multiple locations can map to same default 
language, and there's not enough sublangs defined to describe them all.
So I don't think it's possible. See locations 352 or 114 for example.

>
>>> GEO_RFC1766 -> LOCALE_SISO639LANGNAME (mlang uses this mapping)
>> This one doesn't work like that, it's synthesized from location and
>> specified langid.
>
> Yeah, mlang uses lowercased LOCALE_SISO639LANGNAME+LOCALE_SISO3166CTRYNAME.
>

In GetGeoInfo() you can get a rfc1766 name like zh-us or fr-us for example.

>>> GEO_FRIENDLYNAME -> something appropriate
>>> GEO_OFFICIALNAME -> something appropriate
>>>
>> What's appropriate for that is to add ~300*2 localized strings for each
>> locale Wine supports, and that's where we need nls files.
>>
>> We also need to support the rest of types, like GEO_LATITUDE/LONGITUDE
>> and GET_ISO_UN_NUMBER. Both are mapped by location id, so even if it'd
>> be possible to reuse something we already have (and I don't think it is)
>> we still need a mapping table for the rest of supported data.
>
> Well, nothing prevents you from adding missing data. And still a centralized
> storage would be much better IMO.
>

It's probably better, but I don't see how it could be done in this case.
And having partial support for a subset of locations is not okay.

Actually we could do this other way around, storing location id in nls 
file and use it to get ISO2/ISO3 name using GetGeoInfo once implemented.