I am evaluating nsis. I want to create an installer (using mui2) which will use the provided Unicode strings (for titles, buttons, labels etc.) and not to use any "localization".
For example: the application title contains unicode characters from different languages (let's say: "Λεξικό-Dictionary-Речник" will be the whole title, regardless of the user "language")
Is there a simple way to use the provided exact unicode strings independently of the mui language?
EDIT (as commented) :
The above is about having own Unicode strings for buttons and, in general, UI text (no localization). Is not about any source (or destination) "filename" or "path".
NSIS will not translate the name, just make sure you save the .NSI source file as UTF-8 with BOM/Signature or UTF-16 with a BOM if you use non-ASCII characters.
Unicode True
Name "Λεξικό-Dictionary-Речник"
OutFile "MyInstaller.exe"
InstallDir "$ProgramFiles\$(^Name)"
!include MUI2.nsh
!insertmacro MUI_PAGE_WELCOME
!insertmacro MUI_PAGE_DIRECTORY
!insertmacro MUI_PAGE_INSTFILES
!insertmacro MUI_PAGE_FINISH
!insertmacro MUI_LANGUAGE English
Section
SetOutPath $InstDir
File /r "c:\myfiles\*.*"
SectionEnd
It is also possible to manually construct Unicode characters from Unicode code points:
Section
MessageBox MB_OK "${U+2115}SIS" # DOUBLE-STRUCK CAPITAL N + "SIS"
SectionEnd
The problem was I saved the file as UTF8 (!!!). After saving the file from Notepad as Unicode the problem disappeared.
Related
I have a couple of functions in the NSIS installer. I want to keep them neatly in separate files.
For example, the main section is in the files installer.nsi and now I want to put a function to compare versions in a separate file. How can I do that?
You can make your own include files (just a normal text file with the .nsh extension):
VersionCompare.nsh:
Function MyVersionCompare
# ...
FunctionEnd
Installer.nsi:
Name "MyInstaller"
OutFile "MyInstaller.exe"
!include "VersionCompare.nsh"
Section
Call MyVersionCompare
SectionEnd
I want to report to a Web Service whether the installation completed successfully or not. The identifiers that need to be passed to the service are stored in an uncompressed text file along with the other (compressed) files. Everything works on a successful installation, but when the user cancels the installation, no files are extracted (as expected) and I am unable to find a way to extract a specific file from the archive.
I have considered some other options (writing a custom plugin, parsing through the installer executable file), but I hope there is a cleaner solution.
You can extract files at any point in the installer, in your case probably in .onInstFailed or .onUserAbort:
Function .onInstFailed
InitPluginsDir
SetOutPath $pluginsdir
File something.ext
; Do something with "$pluginsdir\something.ext"
; Note: $pluginsdir is automatically deleted when installer quits...
FunctionEnd
I been using NSIS for simple installers. I am now at a point where i need to install files to a user's specific location. For example, in my case, the palette directory where i need to put the new palettes is C:\Users\Russ\Documents\My Palettes.
How can i determine, automatically, the current user (Russ) when the installer executes. (Or is this something i have to prompt the user for?)
I've looked at other NSIS constants, but couldn't find something particular for this.
My documents is listed in the constants list.
MessageBox mb_ok "$Documents\My Palettes"
I have an installer working with NSIS that I'm updating at the moment. At several points, the installer needs to configure packages by replacing paths or values inside configuration files. Those configuration files have placeholders in them that are replaced by whichever deployment tool I'm using (NSIS for this specific case).
Scripts are mostly PHP scripts written to do some simple tasks that would have been excruciatingly complex in NSIS. For some reason though I keep going back to making my PHP scripts replace the placeholders by themselves instead of doing it in the NSIS script, which just isn't right.
My code looks like:
nsExec::ExecToStack '"$INSTDIR\Php\php.exe" "$INSTDIR\Apache\tools\findport.php"'
pop $1 ; return code
pop $2 ; port number
!insertmacro _ReplaceInFile "Apache\conf\httpd.conf" "APACHE_PORT" "$2"
The _ReplaceInFile macro comes from http://nsis.sourceforge.net/ReplaceInFile and works just fine if I use $INSTDIR instead of $2 in the above example. Showing $2 in a MessageBox shows the port number just fine.
I guess I'm doing something wrong but I can't figure out what it is, and debugging is a pain with NSIS.
Thanks,
I guess the lesson is to always verify paths before blaming the utility functions (Using Process Monitor is a good idea so you can tell if file-system redirection is getting in the way)
I would also like to add that using $instdir to hold anything other than a path is not a good idea since it will strip away invalid path characters behind your back. Use a normal register or a custom variable...
I'm using NSIS to generate a Windows' installer for my application. I'd like a multi-lingual installer. I'm using LangString for specifying strings.
However, the documentation doesn't seem to say how one should encode a non-ASCII character. For example, to use the German word "benötigt" (where the 'o' has an umlaut), how should I encode the ö?
It's just easier to use the Unicode version of NSIS. The entire problem then goes away.
I assume we are talking about the ANSI version of NSIS here...
The 2nd parameter to LangString is the language id (You can generate one with NSIS\Bin\MakeLangId.exe, but since you probably already use the MUI_LANGUAGE macro or LoadLanguageFile, ${LANG_GERMAN} etc will be defined for you)
NSIS does not really care how the string is encoded, but if you have a lot of strings in different languages, it is probably a good idea to put the LangString commands in external files that you can !include. This way you can edit different language files with different codepages and text editors.
If you want to compile the UNICODE strings by the ANSI version of NSIS compiler, then you have to put such strings in separate .nsi file with UCS-2 LE BOM (lookup it with Notepad++) format and directly include that.
I've using particularly english and russian versions of such files at the end of a main.nsi:
!ifdef LANG_ENGLISH
!include "${PROJECT_SRCS_ROOT}\lang_en.nsi"
!endif
!ifdef LANG_RUSSIAN
!include "${PROJECT_SRCS_ROOT}\lang_ru.nsi"
!endif
if you can not use the unicode version of nsis, you could encode your text in latin-1 (ISO 8859-1) which can be used to produce these umlauts as ü,ä,ö