http://bugs.winehq.org/show_bug.cgi?id=23124
Summary: Philippine English locale defaults to wrong SUBLANG Product: Wine Version: unspecified Platform: All OS/Version: All Status: NEW Keywords: download, source Severity: trivial Priority: P4 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: kennybobs@o2.co.uk
I understand that following 1.2 .po file are going to be used, so this should be easier to resolve then.
Philippine English follows American English rules, but currently defaults to pick up SUBLANG_NEUTRAL which is British English. It should be picking up SUBLANG_DEFAULT for American English.
I'm not sure if this can be changed before the introduction of .po files but it's not urgent.
http://en.wikipedia.org/wiki/Philippine_English
http://bugs.winehq.org/show_bug.cgi?id=23124
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|download | Platform|All |Other OS/Version|All |other
--- Comment #1 from Dmitry Timoshkov dmitry@codeweavers.com 2010-06-12 01:15:14 --- .po files usage has nothing to do with this. You would need to add a separate translation for Philippines into .rc files, just like for the UK one.
http://bugs.winehq.org/show_bug.cgi?id=23124
--- Comment #2 from Ken Sharp kennybobs@o2.co.uk 2010-06-12 08:38:47 --- My point being there's no point in running through all the translations if we're moving over to .po files and all the work will have been wasted.
If not, I'll happily do it.
Is it possible to make Philippines English pick up LANG_DEFAULT instead of LANG_NEUTRAL? It will save a lot of duplication.
I should also point out that Zimbabwe use South African English but I don't think that will be a problem.
http://bugs.winehq.org/show_bug.cgi?id=23124
Paul Vriens Paul.Vriens.Wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Vriens.Wine@gmail.com
--- Comment #3 from Paul Vriens Paul.Vriens.Wine@gmail.com 2010-06-12 09:07:42 --- No translation work will be wasted. All current translations will be converted to po files.
http://bugs.winehq.org/show_bug.cgi?id=23124
--- Comment #4 from Dmitry Timoshkov dmitry@codeweavers.com 2010-06-12 23:22:54 --- (In reply to comment #2)
My point being there's no point in running through all the translations if we're moving over to .po files and all the work will have been wasted.
Translations for the .po files will still be copied into .rc files, and compiled with the resource compiler because they need to be accessible as PE resources. Introducing .po is just a way to help with translations using native tools, not a replacement for .rc files.
Is it possible to make Philippines English pick up LANG_DEFAULT instead of LANG_NEUTRAL? It will save a lot of duplication.
I don't see a way. #including another .rc won't work because of conflicting LANGUAGE statements.
http://bugs.winehq.org/show_bug.cgi?id=23124
--- Comment #5 from Ken Sharp kennybobs@o2.co.uk 2010-06-13 10:16:18 --- (In reply to comment #4)
Is it possible to make Philippines English pick up LANG_DEFAULT instead of LANG_NEUTRAL? It will save a lot of duplication.
I don't see a way. #including another .rc won't work because of conflicting LANGUAGE statements.
I've tried looking through parts of the source to see where LANG_ENGLISH defaults to SUBLANG_NEUTRAL then SUBLANG_DEFAULT but I can't find it. Of course, I've just realised that it might a case that LANG_* defaults to SUBLANG_NEUTRAL and SUBLANG_DEFAULT. If the latter is the case then this definitely can't be done and I'll simply add SUBLANG_ENGLISH_PHILIPPINES to the .rc files.
Can someone confirm which is the case? Thanks.
http://bugs.winehq.org/show_bug.cgi?id=23124
--- Comment #6 from Ken Sharp kennybobs@o2.co.uk 2010-11-24 21:12:18 CST --- Any news on the .po file movement?
http://bugs.winehq.org/show_bug.cgi?id=23124
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fgouget@codeweavers.com
--- Comment #7 from François Gouget fgouget@codeweavers.com 2010-11-27 07:36:43 CST --- The switch to po files has been discussed at WineConf. The plan is to start with the menu and string resources.
The dialogs are a harder problem as they need geometry information. So after the above step the plan is to generate all dialogs where the geometry does not change and only keep the others in the rc files. The last step will be to generate geometry at compile time but that will require more work.
However none of this has any impact on this bug.
You said:
but currently defaults to pick up SUBLANG_NEUTRAL which is British English
This is false (from winnt.h): #define SUBLANG_NEUTRAL 0x00 #define SUBLANG_DEFAULT 0x01 #define SUBLANG_ENGLISH_US 0x01 #define SUBLANG_ENGLISH_UK 0x02
So what you should see is Philippine English using either the SUBLANG_NEUTRAL strings, but the strings being neutral they should work fine for Philippine English, or the the American English SUBLANG_DEFAULT strings. Only a few files have SUBLANG_NEUTRAL strings so it should be easy to review and fix them if they are not neutral: dlls/comdlg32/cdlg_En.rc dlls/shdoclc/En.rc dlls/hhctrl.ocx/En.rc programs/wordpad/En.rc programs/regedit/En.rc programs/wineconsole/wineconsole_En.rc programs/winhlp32/En.rc programs/winhlp32/En.rc programs/winecfg/En.rc
If that doe snot help fixing the problem, could you provide a specific example of a string which is wrong and where it appears?
http://bugs.winehq.org/show_bug.cgi?id=23124
--- Comment #8 from François Gouget fgouget@codeweavers.com 2011-08-25 16:48:44 CDT --- I think this can be closed now...
http://bugs.winehq.org/show_bug.cgi?id=23124
--- Comment #9 from Ken Sharp kennybobs@o2.co.uk 2011-08-31 15:06:59 CDT --- I don't think the issue has been resolved.
A solution would be to correct all the translations for the slight variations [-ise/-ize is permanently under dispute].
http://bugs.winehq.org/show_bug.cgi?id=23124
--- Comment #10 from François Gouget fgouget@codeweavers.com 2011-09-01 03:31:53 CDT --- Can you submit patches (or at least attach them here so we know what we're talking about)?
http://bugs.winehq.org/show_bug.cgi?id=23124
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|wine-bugs@winehq.org |kennybobs@o2.co.uk
--- Comment #11 from Ken Sharp kennybobs@o2.co.uk 2011-10-24 14:38:21 CDT --- http://www.winehq.org/pipermail/wine-devel/2011-October/092952.html
http://bugs.winehq.org/show_bug.cgi?id=23124
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEW AssignedTo|kennybobs@o2.co.uk |wine-bugs@winehq.org
--- Comment #12 from Ken Sharp kennybobs@o2.co.uk 2012-06-13 09:19:29 CDT --- Using $(LN_S) should solve this but I have no idea how to do this. configure.ac is a minefield.
http://bugs.winehq.org/show_bug.cgi?id=23124
--- Comment #13 from François Gouget fgouget@codeweavers.com 2012-06-14 09:46:30 CDT --- I added en_PH.UTF8 to my list of locales and if I run 'LANG=en_PH.UTF8 ./wine winecfg.exe', in the About tab I get the British spelling of 'license', that is 'licence'. So this confirms that there is an issue.
However the issue persists even after applying the attached patch to create an en_PH.po file that symlinks to en_US.po. I'm not sure this approach is right in the first place but it does not seem to work :-(
http://bugs.winehq.org/show_bug.cgi?id=23124
--- Comment #14 from François Gouget fgouget@codeweavers.com 2012-06-14 09:47:32 CDT --- Created attachment 40542 --> http://bugs.winehq.org/attachment.cgi?id=40542 Create an en_PH.po symlink
http://bugs.winehq.org/show_bug.cgi?id=23124
--- Comment #15 from Ken Sharp kennybobs@o2.co.uk 2012-06-14 12:49:31 CDT --- Indeed I see the same thing. A .mo file is created so the compilation seems happy with it but the translations are not read.
Is there a debug channel that can be snooped to see what's going on?
http://bugs.winehq.org/show_bug.cgi?id=23124
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #40542|0 |1 is obsolete| |
--- Comment #16 from Ken Sharp kennybobs@o2.co.uk 2013-07-30 18:04:54 CDT --- Created attachment 45456 --> http://bugs.winehq.org/attachment.cgi?id=45456 po: Add English (Philippines) resource
This patch *appears* to work (in Linux). I emphasize *appears* because the only way I can really test it is to use LANG=en_PH.UTF-8 (which my system claims to support). The problem with that being if this LANG is not recognised then it appears to default to en_US.UTF-8 (SUBLANG_DEFAULT?) anyway.
For example:
"LANG=Bacon.BBC2 winecfg" will show the US translations (probably due to this being the SUBLANG_DEFAULT in winecfg.rc).
Testing with en_ZA and en_NZ the British translations are correctly shown so PERHAPS using en_PH is working correctly here, but I simply cannot be sure. I need some way to snoop what is actually happening to be certain that the correct translations are being used.
However:
(Before patch) LANG=en_PH.UTF-8 = British spellings (After patch) LANG=en_PH.UTF-8 = American spellings
Again, this may only be in appearance. It could be that this has effectively broken the translation and it is simply defaulting to SUBLANG_DEFAULT.
If correct, this patch will need testing in other environments too, I imagine (specifically for $(LN_S) compatibility, although $(LN_S) is used in other places). Testing with Cygwin may actually offer a clue as to what is happening. I don't have an environment to test that at the moment.
http://bugs.winehq.org/show_bug.cgi?id=23124
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, integration Status|NEW |ASSIGNED Platform|Other |x86-64 AssignedTo|wine-bugs@winehq.org |kennybobs@o2.co.uk OS/Version|other |Linux
--- Comment #17 from Ken Sharp kennybobs@o2.co.uk 2013-07-31 20:21:17 CDT --- In hindsight the test is obvious:
+$(top_srcdir)/po/en_PH.po: $(top_srcdir)/po/fr.po + $(LN_S) fr.po $@
LANG=en_PH.utf-8 then shows all French translations. In other words: it works.
Cygwin has all kinds of problems so I cannot test there. http://forum.winehq.org/viewtopic.php?f=2&t=19488
I could install PC-BSD and test on that but there isn't really any reason why that shouldn't work. Will try in the next few days. Ditto with OpenIndiana.
One thing I am wondering though, is if this is bad practice:
$(top_srcdir)/po/en_PH.po: $(top_srcdir)/po/en_US.po $(LN_S) -f en_US.po $@
It should work (it does on Linux) and it forces an overwrite of any existing en_PH.po without having to do a "make clean".
http://bugs.winehq.org/show_bug.cgi?id=23124
--- Comment #18 from Ken Sharp kennybobs@o2.co.uk 2013-08-04 16:29:21 CDT --- http://www.winehq.org/pipermail/wine-devel/2013-August/100725.html
http://bugs.winehq.org/show_bug.cgi?id=23124
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
--- Comment #19 from Ken Sharp kennybobs@o2.co.uk 2013-08-09 12:35:44 CDT --- Tested on:
Ubuntu Linux AMD64 (ext4) All good.
Debian kFreeBSD i386 (UFS) All good.
OpenIndiana AMD64 (ZFS) All good.
Cygwin i386 (NTFS) "Symlink" is created but the compile fails generally. Couldn't test.
Patch sent. http://www.winehq.org/pipermail/wine-patches/2013-August/125760.html http://source.winehq.org/patches/data/97833
https://bugs.winehq.org/show_bug.cgi?id=23124
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=23124
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|integration |localization
https://bugs.winehq.org/show_bug.cgi?id=23124
--- Comment #20 from Ken Sharp imwellcushtymelike@gmail.com --- I tried simply linking en_PH.po to en_US.po but this fails compilation on FAT32 (when the source is cloned).
Things have changed a fair bit since the last time I looked at this.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla