You always want to believe that the software you create will go beyond the borders of your country. This is on the one hand. On the other hand, the number of difficulties arising for this reason will be very large. In this post I will try to reveal some of them.

0. And what is the problem?

Let's start by looking at the complexity of internationalization. Conventionally, we have a program that is written in Russia and has a Russian interface, so it will need to be translated into any other language, for example, into French.
')
Why is it French in the example? And it's very simple - there is such a thing as accents in it, so you have to use Unicode and you can’t manage only with the English layout;)

So what do we need to translate?

• application interface
  installer (if any)
  
  
  Of course, the current trend is that the installer can often not be used, however, I always consider it a convenient thing to display a license agreement (this is also perfectly consistent with the legislation of Russia). After all, we cannot release our product to the outside world without rules, can we?
  
  We approach the problem. Keep separate versions of the application in different languages ​​is not very convenient. Imagine how much changes you need to make when editing the code, and also remember that it will not be very correct to issue the source code to the translator either. Therefore, we must have one source code.
  
  Another way - resource files, that is, when an application (either in an executable file or in a library) is “stitched” into a language. The question arises - how to identify and select it.
  
  

  1. The right solution

  
  When this problem confronted me, I chose the following internationalization rules:
  1. The installer should allow the user to select the installer language, while the installer window with an invitation to choose a language selects it based on the language version of the operating system, and all the shortcuts are created in this language
  2. The language of the application is selected separately at one of the installer stages.
  3. The user must choose which language support he needs in the application.
  4. After installing the application, it should be possible to select another language for its interface.
  
  

  2. How will we do?

  
  The question of choosing an installer deserves a separate and extensive discussion, but I use NSIS. Therefore, the implementation of the first three points was possible without problems - multilanguage support in NSIS is initially, I just adjusted language files a little.
  
  Next you should tell which way I went with the language files. In my opinion, an elegant solution was to take a * .xml file for each language, storing all the necessary lines in it. In the executable file itself, I “sewed up” only English, in case the user takes and deletes all language files from anger.
  
  XML is also convenient for me because I can quickly check the file for correctness according to the scheme, that is, if the user himself rules the language file and is mistaken, the program will not load it.
  
  XML quite normally supports Unicode, it was also a big plus.
  
  

  3. What was the result?

  
  As a result, the solution looks like this - there is a language folder in the program folder after installation. It stores language files called ru.xml, en-GB.xml, en-US.xml, and so on. The set of language files is determined by the user during installation.
  
  In the program folder there is a language.xml file that contains data for the language selected by the user. The language selection utility copies the XML file from the language folder to the root folder of the program, thereby determining the language.
  
  

  4. Complications

  
  
  

  Web server

  
  Everything would be fine if not one “but” - in my program one of the components contained a self-written Web server designed for easier debugging. He did not offer any active content, just formed debug data. However, among them was the date ...
  
  What is the problem with the date? In general terms - nothing. When the user makes a request, I pulled out the Accept-Language field from the HTTP request and always knew exactly which language to issue. But, turning a date into a string is executed on the server side. Therefore, in order for everything to work correctly, you need to change the language of the processing flow to the language requested by the user's browser.
  
  Then everything will be completely correct.
  
  And of course, I stored the resources of the Web server in separate folders with the names “ru”, “en-GB” and so on. If the language requested by the user was not found there, then I gave out a standard file in English from resources.
  
  

  The length of the words (lines)

  
  Of course, the same words in different languages ​​are different. Therefore, creating an application interface is worth remembering about this. A good example is the English “Unlock” and the Ukrainian “Rozblokuvati”.
  
  

  Difference in numbers

  
  Remember that if in Russian the comma is the separator of the integer and fractional parts of a number, in English, for example, a period. A comma is used to separate thousands, that is, an entry in Russian “1,000,000.00” in English should look like this “1,000,000.00”.
  
  

  The difference in dates

  
  Despite the fact that ISO sets the date storage format (YYYY-MM-DD), it's not always that simple and fun. In Russia, it can be written as DD-MM-YYYY, but in the USA - MM-DD-YYYY.
  
  General advice about numbers and dates will format them based on the user's language and in no case will not “sew” a self-made mechanism of their processing into the program.
  
  With love,
  maniaque