#LANGID is 0

Aug 23, 2010 at 11:32 AM


I'm using dotNetInstaller 2.0 for a project. I have 2 top level nodes - one for 1040 and one for !1040. The language_Id properties on these are set to 1040 and 1033 respectfully. I'm expecting that when I refer to the token #LANGID that this is either 1033 or 1040, however it's evaluating as 0. Why is this? I'm not using the language selector and relying on auto-language detection.





Aug 23, 2010 at 12:33 PM

The #LANGID variable is only set by the selector, it's the language chosen by the user. Otherwise it's always zero.

This may be a bit confusing. But once you're in the configuration you already know it's 1033, so having a variable creates an unnecessary level of indirection, imho. Maybe you can convince me otherwise? I am open to changing that - can you describe your usage scenario please?

Aug 23, 2010 at 12:58 PM

So the scenario is that I'm using !1040 as a match rather than a specific locale. I've set the language_id for this node to be 1033 in the configuration file, so that any language detected other than 1040 will be treated as if it were 1033. I now want to use this var (#LANGID)  to pass to my components msi so that it matches the language identified by my rules in the bootstrapper.

I guess I can hard code in my case as I know that !1040 is always 1033, but this starts to create several touch points where I'm having to define LANGID. It would be much better if I could keep the logic for determining LANGID based on rules at the top level, and refer to it using #LANGID lower down. This also makes it easier to copy and paste components nodes in the XML file when setting up new languages without having to update all of my commands parameters with the correct LANGID.

It also just makes logical sense to me to have this available. Whether I choose to have a language selector or not shouldn't affect my ability to refer to the LANGID in my components. As a side-note it would also be nice to have access to the actual (system, user) LANGID.  I haven't got a requirement at the moment, but I can see where it might be useful for passing to other components. 

Aug 23, 2010 at 9:41 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Aug 23, 2010 at 9:50 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Aug 24, 2010 at 12:31 AM

The second half of it was easy, I've added #OSLANGID to build 2.0.4404.0. Try it. I'll look at the other issue.

Aug 26, 2010 at 2:40 PM

Brilliant thank you, the #LangID without language selector as well would be prefect.

Aug 26, 2010 at 3:35 PM

It's already in. I just uploaded build 2.0.4486.0 that also has #OSLOCALE (eg. "en-US").

Here're the things you care about.

  • #6955: Added #OSLANGID substitution variable, operating system language ID.
  • #6620: Added #OSLOCALE substitution variable, operating system ISO language and region (eg. en-US).
  • #6956: #LANGID and #LANGUAGE are always set to the value in the currently executing configuration. #LANGUAGE may be empty, while #LANGID will default to the operating system value.

    Let me know if it works.