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