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