
In this article I will share with you the practical experience gained over many years of creating installers in Famatech. Under the cut - theoretical calculations and practical instructions on how to create an installer that prompts the user to select the installation language and installs the product in the selected language, painlessly and “by Feng Shui”, compatible with the “Windows Logo Testing”. At the same time exclusively free solutions are used.
Why do you need a multilingual installer?
Before turning to the technical part, I will spread a little thought over the tree and tell you why we need all these shamanistic dances with a tambourine. So, what does a typical Windows installer look like? This .msi or .exe file, which at startup wonders where and what we will put, puts it whenever possible, creates shortcuts where it can and runs the installed program - so that the user can use it immediately. Familiar sight, is not it? So the installer looks up until the developer is faced with the task of making a localized version in all its glory. Russian, German, Chinese ... For users really want.
And if, as a rule, there are no problems with the program itself, the installer puts the developer before a rather interesting choice. What are the options?
- The simplest solution is to make a handful of installers, each of which will have a user interface in the desired language and install the program with the necessary files and settings so that it also displays its interface in the same language. Unfortunately, the method has a small minus: as the number of localizations increases, it becomes not very convenient to manage 30+ installers. Plus, a funny moment pops up: if a user finds a program through a search, then he is more likely to download it, if it says next to her that she supports his language. Alas, not everyone knows English.
- You can make one installer and automatically select the program language at startup. This is the case, for example, of the 64-bit version of the popular 7-zip utility. Alas, this method also has a number of disadvantages. First, users who do not know English simply cannot cope with the interface of the installer itself. Secondly, the program selects the language at startup, often based on system settings that do not always correspond to what the user really wants. As a result, the program often does not guess and shows the interface is not in the language that adversely affects such delicate matter as user experience.
- A good solution would be to suggest the user to choose the language of the installer and the program when the installer starts. But here we are waiting for purely technological difficulties: the Windows type of installers preferred for MSI does not support this possibility in principle, and the use of Innosetup / Nsis leads to another problem - when certifying the program for Windows Logo, Microsoft strongly asks the installer in the form of MSI . Plus, MSI form-factor installers are very fond of large companies that use them to automatically update and deploy programs to thousands of computers with one click.
')
Honestly do MSI, who would speak with the user in their chosen language, it is impossible. But you can use the "military trick" and use the technique that you all saw in the installers of such large companies as Adobe or DrWeb: the installer is an .exe file, which, when launched, offers to choose a language, then extracts .msi from itself, a number of strange manipulations, and then the installation goes on in the selected language. The most popular type of "military tricks" is the order-bearing and strongly deserved program of InstallShield. She and MSI will do it, and in .exe it will pack it, and it will attach the language selection menu itself. Everything in it is good, except for the price - about five thousand dollars for the workplace. Not that expensive (we have a couple of licenses), but scalability suffers. You can’t install such an installer in open source, and you don’t give a freelancer honestly. But you can do without InstallShield, only with the help of free software, a shaman tambourine and a pair of spells.
Model Multilingual Program
To begin with we will make the simple multilingual program which we will put. The simplest and most visual way is to use the free Qt framework, in which multilingualism is made out of the box very well. Download and install everything to build the program
here . Set the QTDIR environment variable to the folder where “bin \ qmake.exe” is installed (for the latest Qt version with the default installation it will be “C: \ QtSDK \ Desktop \ Qt \ 4.7.3 \ mingw”) and the MINGWDIR environment variable on the folder where “bin \ mingw32-make.exe” is installed (for the latest version of Qt, it will be “C: \ QtSDK \ mingw” during the default installation). These environment variables are needed by my build script in order to build everything correctly with one click :).
I have already prepared the program itself: we take the source code
here , unpack it somewhere and run the batch file with the saying name “build.bat”. This batch file will compile a demo program from sources and put the result in "% TEMP% \ multilang_test". If we go into this folder, we will see the executable file of our program, several Qt libraries and a localization file in Russian with a profound extension “qm”. By running the program and using the top menu, we can switch the language between English and Russian on the fly. In order for the installer to tell the program what language it will speak, the first time a special registry key is provided, “HKCU \ Software \ my_company \ multilang_app \ lang_cur”, which can be set to 0 for the English interface language and 1 for Russian :

... and the "crippled" multilingual installer
Once the program has turned out, you can make an installer for it. To build the installer, we will use Microsoft's free WiX program (by the way, if memory serves me, this is the first Microsoft project that was submitted to open source). You can download and install it
from here (requires the presence of the .net framework). We also need a program to create the aforementioned bootstrapper - for this purpose we will use the free dotnetinstaller program, which can be downloaded and installed
here . For dotnetinstaller, you need to set the DNIDIR environment variable to the folder where “dotnetinstaller.exe” is installed (for the default installation, this will be “C: \ Program Files \ dotnetinstaller \ bin”).
First we need to do MSI. WiX creates MSI from an XML description, which is fairly simple and has been discussed in detail in a number of articles on the site. In order not to go into details, I prepared an installer project: pick up the source code
here , unpack it somewhere and run a batch file with the saying name “build.bat”, the result of which will be a bunch of intermediate files and the final evolution - the file "% TEMP% \ multilang_test \ multilang_install.exe "- assembled multilanguage installer, running which we will see first the language selection menu, and then the installer interface in the selected language and the installed program in the selected language as well:

How is it going? Consider a sequence of magical actions leading to a result that is not much inferior to Adobe. First, we create English and Russian installers in the MSI format — all you need to do is to specify the WiX command line key "-cultures: en-US" for English and "-cultures: ru-RU" for Russian (see the build batch file).
The resulting MSI installers we want to unpack and run from our bootstrapper, depending on the selected language. In principle, nothing prevents us from putting both MSI into bootstrapper as it is. But it will not be the best solution, since each MSI will keep ALL the files of our program and they differ only in lines of text and what value to write to the registry to set the default language. For small programs and two languages, this is not critical, but if our program files weigh at least a hundred megabytes, and it is localized into three dozen languages, then we probably won't want to create an installation package weighing three gigabytes. Therefore, we will store only one MSI, English in bootstrapper, and for the rest we will store the so-called “transform” - .MST file, which contains the difference between the English installer and the localized one. Such files are usually small in size and can be “applied” to the English MSI during installation in order to “transform” it into a localized one. To create an MST file, use the torch program included in WiX. Curious again study the contents of the .bat file.
Now we have one big MSI file and a small MST to turn it into Russian. Can I put in the bootstrapper? Theoretically, you can, in practice, if you put the files as they are, then again we get problems. This time at the stage of uninstalling the program. Removal of programs installed via MSI is generally done in a rather amusing way: Windows during the installation saves MSI in its folder (by the way, one of the reasons for the desperate growth of the Windows folder), and during the deletion it uses saved MSI. Problems with our files is that the MST Windows cannot save, and by installing the Russian version of the application using a combination of MSI and MST file, we will get potential problems when deleting via Add / Remove Programs: Windows will try to find the MST that participated in the installation, can not do it and much offended. In order not to upset Windows, MST files can be put inside MSI and applied directly from it. To do this, there is a special script on the Microsoft Visual Basic, available
here and prudently placed by me in the archive with the source code of the installer. The use of this script (the curious can again look into the batch file) places the MST in MSI, and, in order to run this MSI in Russian mode, something like this is used:
msiexec / i multilang_install_en.msi TRANSFORMS =: 1049
So, everything is ready - you can collect bootstrapper. As already mentioned, there is a specially trained open source program with the strange name dotnetinstaller. In general, it is intended to create installers that pull the .NET Framework, but it can also create a language selection menu and, depending on the chosen language, extract and run MSI with different command line keys. Like WiX, dotnetinstaller accepts the source in XML format (the project source already created is attached). The project as a whole is quite simple: I specify the dotnetinstaller in it, that I need to make a menu with two languages, call MSI for English as it is, and for Russian, call the transform.
Total
The UTF-8 encoded sources used in my examples are fully commented in Russian and can serve as an example of a minimal multilingual program and a minimal installer to it. Unfortunately, as can be seen from the spells described above, MSI was not originally designed to create multilingual all-in-one installers, so the creation of such installers is a rather complicated process. So, if you do not have an urgent need to be certified on the “Windows Logo” and have MSI for corporate clients, use InnoSetup or NSIS - there the task of creating a multilingual installer is much easier.
It should be noted that the demonstration program and the demonstration installer are greatly simplified and contain only the minimum necessary to demonstrate the techniques described in the article.
I don’t say goodbye for this and wait for comments. All examples are checked, but you understand, everything is possible on user computers. Therefore, if somewhere something does not work - write, correct.
And one more result
The results of applying all of the above can be viewed in our free program
Advanced IP Scanner for scanning local networks. Multilingual installer, dynamic selection of the interface language and so on Feng Shui. Comments on the scanner are also accepted :).