Some of GetGeoInfo is sorta broken

by Michael S. Kaplan, published on 2005/10/12 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/10/12/479817.aspx


Remember back when I was going on in time zones and locations and keyboards about how we could use GEOID values for everything? And then Mihai helped me realize that GEOID support is not quite done?

Well, we were digging into things again and realized there are some more problems here.

Let's take a look at the prototype for GetGeoInfo:

int GetGeoInfo(
  GEOID GeoId,         // location identifier
  GEOTYPE GeoType,     // type of information requested
  LPTSTR lpGeoData,    // buffer for results
  int cchData,         // size of buffer
  LANGID language      // language id
);

Now obviously the GeoId parameter is the GEOID you are querying about. That part is fine.

The language parameter is basically broken:

Now these latter two cases, if you pass 0 then it does not use the user default UI language (as GetUserDefaultUILanguage would return) -- it uses the user default langid (as GetUserDefaultLangId would return). In other words the default user locale. This is usually not noticed since actual resources are loaded with that FindResourceExW call, which I think might pick up the thread locale if that FindResourceEx text is accurate:

wLanguage

[in] Specifies the language of the resource. If this parameter is MAKELANGID(LANG_NEUTRAL, SUBLANG_NEUTRAL), the current language associated with the calling thread is used.

But we all know how I feel about the thread locale, don't we? :-)

Ok, we have one useless parameter and at least four useless SYSGEOTYPE values. I am going to go out on a limb and suggest that this is a good function to steer clear of, unless you are using one of the other SYSGEOTYPE values. And avoid the language parameter if you can....

 

This post brought to you by "ش" (U+0634, a.k.a. ARABIC LETTER SHEEN)


# Nick Lamb on 12 Oct 2005 6:39 AM:

"a GEOID and LANGID that do not match"

RFC 1766 doesn't have a notion of matching countries and languages. The API here makes sense technically. To make up an RFC 1766 language tag from ISO codes you want a language (e.g. Japanese, "ja") and a country code (e.g. the United Kingdom, "GB"). In Windows programmers may have these opaque numeric IDs for everything - so it makes sense on the surface to map (LANGID, GEOID) -> (RFC 1766)

However, although the API makes sense, it's not clear what possible real world /use/ it is. RFC 1766 can represent a British dialect of Japanese, but it's more likely that Japanese speakers in the UK are using the same language as their counterparts in Japan. The constructor described for Windows language IDs already seems to understand the idea of dialects and other variants, albeit in a rather primitive way. Is there a way to ask directly for the RFC1766 representation of a Windows LANGID?

# Michael S. Kaplan on 12 Oct 2005 6:43 AM:

Hi Nick --

You can ask for the various ISO names (639 and 3166) which together make a nice first cut at an RFC1766 or even RFC3066 name, but toget them toether you have to look to Vista....

referenced by

2008/03/22 GetGeoInfo is a mostly useless bloody waste of a function that only a "B" Ark Golgafrincham could love

go to newer or older post, or back to index or month or day