kernel32: Partially implement GetGeoInfo()

[Nikolay Sivov]

On 07/08/2014 04:49 AM, Dmitry Timoshkov wrote:
> Nikolay Sivov <nsivov at codeweavers.com> wrote:
>
>>> Some of this info already exists in the locale data under dlls/kernel32/nls
>>> and returned by GetLocaleInfo(), probably it would be a good idea to add
>>> missing geo data there as well (auto-generate from the public source) and
>>> use it from inside of GetGeoInfo().
>> This patch implements geotypes that don't belong to nls, meaning they
>> don't depend on locale.
>> Other types like friendly name and country name as localized, and I'll
>> plan to add them to nls files.
> 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.
> GEO_RFC1766 -> LOCALE_SISO639LANGNAME (mlang uses this mapping)
This one doesn't work like that, it's synthesized from location and 
specified langid.

> 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.