kernel32: Partially implement GetGeoInfo()

[Dmitry Timoshkov]

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?

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

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

-- 
Dmitry.