Hi everyone,
Would anyone mind looking at the attached patch?
It adds the English (Philippines) resource by linking (or copying) the English (US) resource. See http://bugs.winehq.org/show_bug.cgi?id=23124
Actually, the attached version links to fr.po (French) to make testing much easier. The final won't do that. It's explained in the bug.
I have tested this successfully in Linux only. I wanted to test others but:
Cygwin 1.7.22: creates its own "symlink" but no translations are built at all. Compilation is basically broken.
PC-BSD 9.1: complains about gettext although the config.log seems to complain about gm4. I gave up.
OpenIndiana: can't seem to find its own packages. Gave up.
Debian kFreeBSD: all sorts of problems in VBox. Might try again later.
So clearly I've had no luck on other platforms.
If anyone else could quickly test it, that would be great!
Thanks to Austin and François for the help thus far.
Of course, all feedback welcome.
TIA,
Ken
On Sun, 4 Aug 2013, Ken Sharp wrote:
Hi everyone,
Would anyone mind looking at the attached patch?
I wonder if this is something that could be handled at the NLS level instead. Maybe in dlls/kernel32/nls/enp.nls. Would LOCALE_SNAME "en-PH" be relevant here? Or would it make sense to add a setting to map en_PH to en_US somehow?
Otherwise the symlink approach sounds fine by me.
On 05/08/13 10:41, Francois Gouget wrote:
On Sun, 4 Aug 2013, Ken Sharp wrote:
Hi everyone,
Would anyone mind looking at the attached patch?
I wonder if this is something that could be handled at the NLS level instead. Maybe in dlls/kernel32/nls/enp.nls. Would LOCALE_SNAME "en-PH" be relevant here? Or would it make sense to add a setting to map en_PH to en_US somehow?
Otherwise the symlink approach sounds fine by me.
I had a look in the kernel but I couldn't see any way to do it. If it can be done then that would be great. It would avoid creating an extra .mo, although that isn't the end of the world.
I tried
diff --git a/include/winnt.rh b/include/winnt.rh index 1013a24..45896ad 100644 --- a/include/winnt.rh +++ b/include/winnt.rh @@ -247,7 +247,7 @@ #define SUBLANG_ENGLISH_BELIZE 0x0a #define SUBLANG_ENGLISH_TRINIDAD 0x0b #define SUBLANG_ENGLISH_ZIMBABWE 0x0c -#define SUBLANG_ENGLISH_PHILIPPINES 0x0d +#define SUBLANG_ENGLISH_PHILIPPINES SUBLANG_DEFAULT #define SUBLANG_ENGLISH_INDIA 0x10 #define SUBLANG_ENGLISH_MALAYSIA 0x11 #define SUBLANG_ENGLISH_SINGAPORE 0x12
or
+#define SUBLANG_ENGLISH_PHILIPPINES SUBLANG_ENGLISH_US
but this simply causes confusion.
/home/test/wine-git/dlls/kernel32/nls/enp.nls:26:109: Error: Stringtable ID 88 already in use
One problem to note is that if it maps everything to _DEFAULT or _US then it will lose details like
LOCALE_SENGCOUNTRY "Republic of the Philippines" LOCALE_SENGCURRNAME "Philippine Peso" LOCALE_SINTLSYMBOL "PHP" LOCALE_SISO3166CTRYNAME "PH" LOCALE_SLANGUAGE "English (Philippines)"
which of course would not be correct. Linking POs does avoid this.
As an aside:
#define SUBLANG_SINDHI_PAKISTAN SUBLANG_SINDHI_AFGHANISTAN
This may cause problems if these languages are ever implemented. Not sure if Wine handles these differently.
On 05/08/13 12:00, Ken Sharp wrote:
As an aside:
#define SUBLANG_SINDHI_PAKISTAN SUBLANG_SINDHI_AFGHANISTAN
This may cause problems if these languages are ever implemented. Not sure if Wine handles these differently.
And then, of course, I realise that these are probably the same languages and will never need to be implemented separately.
#define SUBLANG_ENGLISH_IRELAND SUBLANG_ENGLISH_EIRE #define SUBLANG_HAUSA_NIGERIA SUBLANG_HAUSA_NIGERIA_LATIN #define SUBLANG_LAO_LAO_PDR SUBLANG_LAO_LAO #define SUBLANG_PORTUGUESE_PORTUGAL SUBLANG_PORTUGUESE #define SUBLANG_SWAHILI SUBLANG_SWAHILI_KENYA #define SUBLANG_SWEDISH_SWEDEN SUBLANG_SWEDISH #define SUBLANG_SYRIAC SUBLANG_SYRIAC_SYRIA
-
Francois Gouget -
Ken Sharp