Nikolay Sivov nsivov@codeweavers.com wrote:
[0001-kernel32-Partially-implement-GetGeoInfo.patch text/x-patch (32.2KB)]
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().
On 07/07/2014 06:58 AM, Dmitry Timoshkov wrote:
Nikolay Sivov nsivov@codeweavers.com wrote:
[0001-kernel32-Partially-implement-GetGeoInfo.patch text/x-patch (32.2KB)]
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.
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 GEO_RFC1766 -> LOCALE_SISO639LANGNAME (mlang uses this mapping) GEO_LCID -> mapped lcid GEO_FRIENDLYNAME -> something appropriate GEO_OFFICIALNAME -> something appropriate
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.
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.
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.
-
Dmitry Timoshkov -
Nikolay Sivov