This shows that the strings will have to be stored in resources so that they can be translated. Yes. It seems that some languages use the US-English friendly names (US obviously but for example, arabic too). Others (like japanese and hebrew) have their own friendly names. Should Wine default to US-English in case of a missing translations then? I don't know actually know how turn this into a translation-based approach? Is there some previous work I could mimic perhaps?
It seems to me that it's the missing name case that should be considered broken. Yes, Kosovo may not have been the best choice for the test. I think there are other universally unavailable candidates such as Europe or Africa and I shall add a test case for that.
-aaro ________________________________ From: Alexandre Julliard <julliard(a)winehq.org> Sent: Monday, March 23, 2020 1:18 PM To: Aaro Altonen <a.altonen(a)hotmail.com> Cc: wine-devel(a)winehq.org <wine-devel(a)winehq.org> Subject: Re: [PATCH] kernelbase: Implement GEO_FRIENDLYNAME for GetGeoInfoW() Aaro Altonen <a.altonen(a)hotmail.com> writes:
+ if ((LANGIDFROMLCID(GetSystemDefaultLCID()) != MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US)) || + (LANGIDFROMLCID(GetThreadLocale()) != MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US))) + { + skip("Non US-English locale\n"); + }
This shows that the strings will have to be stored in resources so that they can be translated.
+ else + { + buffA[0] = 0; + ret = pGetGeoInfoA(203, GEO_FRIENDLYNAME, buffA, 20, 0); + ok(ret == 7, "got %d, expected 7\n", ret); + ok(!strcmp(buffA, "Russia"), "got %s, expected Russia\n", buffA); + + /* Kosovo does not have a friendly name (except on win10) */ + SetLastError(0xdeadbeef); + buffA[0] = 0; + ret = pGetGeoInfoA(9914689, GEO_FRIENDLYNAME, buffA, 20, 0); + ok(ret == 0 || broken(ret == 7) /* win10 */, "got %d, expected 0\n", ret);
It seems to me that it's the missing name case that should be considered broken. -- Alexandre Julliard julliard(a)winehq.org