- NSIS Discussion
- Default language
Archive: Default language
kichik
12th October 2005 14:13 UTC
Default language
According to bug report #1324734, we should be using the UI's language as the default language. There's no technical difficulty involved and the suggested behavior is feasible. However, I'm not so sure that's the right thing to do.
As far as I can tell, most users use the English UI, but set their locale to their local language. In this, they might appreciate the installer automatically choosing their local language. However, the bug report does bring up a valid point, saying that the installer should, at least by default, follow the rest of the UI.
So, what do you think?
iceman_k
12th October 2005 15:53 UTC
However, the UI behavior is not necessarily consistent.
Case in point- change the locale to German (Germany) and then open the Calendar applet. The UI is in English but the months are displayed in German.
So which is correct?
apmolyneux
12th October 2005 16:30 UTC
I was the original submitter of that bug, and just in case anybody is interested (other than myself and a few of my customers) here's the workaround script I wrote. Sorry it's a bit of a mess - I've just got out of the "get it working" phase and haven't got around to tidying it up yet:
!define sysOSVERSIONINFO '(i, i, i, i, i, &t128) i'
!define sysGetVersionEx 'kernel32::GetVersionExA(i) i'
!define sysVER_PLATFORM_WIN32_NT 2
!macro SetUILanguage UN
Function ${UN}SetUILanguage
Push $R0
Push $R1
Push $R2
; Call GetUserDefaultUILanguage (if available)
; $R0 = GetUserDefaultUILanguage()
System::Call 'kernel32::GetUserDefaultUILanguage() i.r10'
StrCmp $R0 "error" OldFashionedWay Finish
OldFashionedWay:
; Check the Windows version
; $R0 = new OSVERSIONINFO(148, 0, 0, 0, 0, "")
System::Call '*${sysOSVERSIONINFO}(148,0,0,0,0,"") .r10'
; GetVersionEx($R0)
System::Call '${sysGetVersionEx}(r10)'
; $R1 = $R0->dwPlatformId
System::Call "*$R0(i ., i ., i ., i ., i .r11)"
; delete $R0
System::Free $R0
IntCmp $R1 ${sysVER_PLATFORM_WIN32_NT} PlatformIsNT
; We're running on DOS-based Windows
StrCpy $R0 "Control Panel\desktop\ResourceLocale"
StrCpy $R1 ""
GoTo GetLCIDFromHKCU
PlatformIsNT:
; We're running on Windows NT
StrCpy $R0 ".DEFAULT\Control Panel\International"
StrCpy $R1 "Locale"
GetLCIDFromHKU:
ReadRegStr $R2 HKU $R0 $R1
GoTo GetLangIDFromLCID
GetLCIDFromHKCU:
ReadRegStr $R2 HKCU $R0 $R1
GetLangIDFromLCID:
StrCpy $R2 "0x$R2"
IntOp $R0 $R2 & 0xffff
Finish:
StrCpy $LANGUAGE $R0
Pop $R2
Pop $R1
Pop $R0
FunctionEnd
!macroend
!insertmacro SetUILanguage ""
!insertmacro SetUILanguage "un."
To see this in action, call SetUILanguage from .onInit, and un.SetUILanguage from un.onInit.
Basically, it just tries to call GetUserDefaultUILanguage() (available on Windows ME, Windows 2000 and later). If that doesn't work, it does some Registry trawling to find the same information.
Comments welcome!
Cheers,
Andrew
kichik
15th October 2005 14:55 UTC
Can you please create a Wiki page for this code?
apmolyneux
17th October 2005 13:26 UTC
Originally posted by kichik
Can you please create a Wiki page for this code?
Done - it's
here.
That version of the code is slightly updated. The code I posted here sets $LANGUAGE based on the whole language identifier. The code on the Wiki trims off the sublanguage identifier, because that seemed to cause NSIS to get it wrong. I'm working on a bug report for that one.
Cheers,
Andrew
onad
18th October 2005 10:54 UTC
Why not implement both options and let the NSIS scriptwriter decide what he/she thinks is best?
Personally I set the language to the language of the OS GUI.
The idea is simple:
"If the user can use the PC he sure can read the OS GUI language in some form... thus also an installer in this language."
Well, since one of my installers was used by total +300.000 people in GB, FR, ES, NL, TK, DE without any install language complaint... While mostly really using XP in French, Spanish, English and German
NOTE:
Why bother the installer user whith language questions if not needed. One of the goals of NSIS is to make installation simple, preventing un-neccesairy questions.
BTW:
If this language is not available embededed in the installer I set to English with an option for the installation user to choose.
apmolyneux
18th October 2005 11:18 UTC
Originally posted by onad
Personally I set the language to the language of the OS GUI.
You mean you use a script workaround like I do? If so, I'd be interested to know if your solution is similar to mine.
Cheers,
Andrew
onad
18th October 2005 20:25 UTC
Yep, I do, actually at a given point I needed a solution NOW, so I started of my venture in writing a plugin.
Happy as I was what I created, I thought: I'm surlely not the only one so posted the solution incl. examples on the Wiki:
Your solution is nice, thanks! But take care accessin the registry directly, I prefer API calls of an OS, You know MS might decide to change the registry names at will.. (Windows Vista?)
I'm sure you could alter your code doing the same as my plugin.
Wiki MoreInfo Multilanguage and OS GUI language here.
http://nsis.sourceforge.net/wiki/MoreInfo_plug-in
FYI: Next month Vista Beta 2 I will do a Windows Vista compatibility test.
For now, my heavy task is still getting makensis to work under FreeBSD (POSIX) so I can automet my builds.
apmolyneux
19th October 2005 12:01 UTC
Originally posted by onad
Your solution is nice, thanks! But take care accessin the registry directly, I prefer API calls of an OS, You know MS might decide to change the registry names at will.. (Windows Vista?)
My code should work fine on Vista. It tries to call the API function first - the Registry-based solution is only used if the API function isn't available (e.g. on Windows 95/98 and NT 4.0). So long as MS don't decide to
remove the GetUserDefaultUILanguage() API function in Vista, it should be OK.
As far as I know, there's no other way to get the UI language on "legacy" Windows versions. I'll take a look at your code to see how you do it.
Cheers,
Andrew
apmolyneux
19th October 2005 12:12 UTC
onad:
I just took a look at your code. I see you're getting the language of USER.EXE, which is good thinking and will work for legacy Windows versions.
However, it won't work properly for users who are running the MUI (Multilingual User Interface) version of Windows 2000 or XP. USER.EXE is always "English (US)" in a MUI environment. I'm told the Enterprise and Ultimate versions of Vista will also be MUI.
You should modify your code to try calling GetUserDefaultUILanguage first, and use the USER.EXE method as the fallback for old Windows versions.
Documentation for GetUserDefaultUILanguage is here:
http://msdn.microsoft.com/library/de...l/nls_5c85.asp
Cheers,
Andrew
onad
9th November 2005 00:16 UTC
Good tip, I will adjust my plugin as soon as I find the time.
Thanks!
bhaelochon
17th November 2005 21:56 UTC
Originally posted by iceman_k
However, the UI behavior is not necessarily consistent.
Case in point- change the locale to German (Germany) and then open the Calendar applet. The UI is in English but the months are displayed in German.
So which is correct?
The UI behavior
is consistent, though. No labels, menus, or message boxes--collectively, the "UI"--are modified at all. The selection only affects numbers, currencies, times, dates, and input locales; i.e. the other items in the Regional Options CP applet; i.e. the key areas of Windows that, when changed, make it possible to use an English version in a non-English environment.
Originally posted by kichik
However, the bug report does bring up a valid point, saying that the installer should, at least by default, follow the rest of the UI.
And it's that point that clinches my decision to vote to use the UI language as the default. Word, Excel, IE, If we want our users to be able to use the locale language, we should utilize the LangDLL plug-in.
kichik
20th November 2005 18:39 UTC
Just to keep you all up-to-date on this one, I plan to implement it for 2.12.
onad
21st November 2005 10:55 UTC
Great,
Then my Moreinfo Plugin will be obsolete for the language part, good. Maybe you can reuse some of the moreinfo text of the wikipage.
kichik
30th December 2005 15:48 UTC
Not in time for 2.12, but the change has finally been made. It'll be available in 2.13 and the next nightly build.