kernel32: Partially implement GetGeoInfo()

Nikolay Sivov nsivov at
Mon Jul 7 22:45:55 CDT 2014

On 07/08/2014 07:32 AM, Dmitry Timoshkov wrote:
> Nikolay Sivov <nsivov at> 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:
>> 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.

More information about the wine-devel mailing list