tostermann
30th August 2013 22:12 UTC
Globalization of a NSIS installer
Over the past several years, I have developed a NSIS installer with several custom pages which utilize MUI macros, installOptions, and custom code. Now, I am trying to globalize my installer, but I have not found many good options.
I would like to find an option that utilizes resource files that can be trigged by a server's default language. I found the below solution, but I have had some problems with it.
http://nsis.sourceforge.net/Adding_L...s_as_resources
Issue1:
Is there a way to call a macro outside a section or function so that I can load a custom message for items like !define MUI_WELCOMEPAGE_TITLE? I always get the error -- "Can't add entry, No section or function is open!
Issue2:
If anyone has used this solution, have you found a way to add more than one .res file to the NSIS header in order to use different message tables based on a server's default language at runtime and not compile time.
Am I headed down the right path or is there a better solution than the ones that I have found? Basically, I don't want a user to have to choice a language at installation, and I don't want a bunch of different language specific variable strings in my .nsh and nsi files.
Thanks in advance for any help or advice you can provide.
T.Slappy
2nd September 2013 08:50 UTC
Use combination of LangString(s) and !define(s).
Create all necessary texts somewhere in the beginning of installations - e.g. after .onInit function.
You can use LangString(s) and !define(s) together to build whole sentences e.g.:
StrCpy $0 "$(ThisIs_LangString)${APP_NAME}"
LangString(s) are automatically 'translated' -> the appropriate value is taken by NSIS during runtime - based on the language user selects.
tostermann
3rd September 2013 22:53 UTC
Thanks T. Slappy
Thanks for your response to my thread/questions. I was aware of the use of LanguageStrings; however, I don’t want to have the user select a language. I want the language to be driven off the Default Language Id of the server. I also don't want to have different strings for the various languages coded inside my installer files. I have a large installer with several custom pages and many messages to globalize. I am looking for a resource file based solution so that the file(s) can be sent out to be translated, and the translator won't need to modify the source code NSIS (.nsh, nsi, and ini) files).
Does anyone know of any such option to be used in NSIS?
tostermann
3rd September 2013 22:59 UTC
Thanks for your response to my thread/questions. I was aware of the use of LanguageStrings; however, I don’t want to have the user select a language. I want the language to be driven off the Default Language Id of the server. I also don't want to have different strings for the various languages coded inside my installer files. I have a large installer with several custom pages and many messages to globalize. I am looking for a resource file based solution so that the file(s) can be sent out to be translated, and the translator won't need to modify the source code NSIS (.nsh, nsi, and ini) files.
Does anyone know of any such option to be used in NSIS?
Anders
4th September 2013 02:01 UTC
You can append data to the end of the .exe without breaking the CRC check. Read the data with the NSIS File* instructions...