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