Default language

[kichik]

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]

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?

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:

code:


!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]

Can you please create a Wiki page for this code?

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]

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.

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]

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.

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

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]

Good tip, I will adjust my plugin as soon as I find the time.

Thanks!

[bhaelochon]

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]

Just to keep you all up-to-date on this one, I plan to implement it for 2.12.

[onad]

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]

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.