You always want to believe that the software product you are creating 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, in fact, is the problem?

Let's first look 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? But it’s very simple - it has such a thing as diacritics in it, so you have to use Unicode and you can’t do only the English layout;)

So, what do we need to translate?

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

  1. A suitable 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 the language selects it based on the language version of the operating system, and it is in this language that all are created shortcuts
  2. The application language is selected separately at one of the installer stages
  3. The user must choose which languages ​​he needs to support in the application
  4. After installing the application, it should be possible to select another language of its interface
  
  

  2. How will we do it?

  
  The question of choosing an installer deserves a separate and extensive discussion, but I use NSIS. Therefore, the implementation of the first three paragraphs was possible without problems - multilingual support in NSIS was there initially, I only corrected the language files a little.
  
  Further it is necessary to tell which way I went with language files. In my opinion, the elegant solution was to take a * .xml file for each language, storing all the necessary lines in it. In the executable file, I “sewed” only English, in case the user takes and removes 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 made a mistake, the program will not load it.
  
  XML quite well supports Unicode, it was also a big plus.
  
  

  3. What happened in the end?

  
  As a result, the solution looks like this - in the program folder after installation there is a language folder. It stores language files under the names 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 is the language.xml file, which 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-contained Web server designed for more convenient debugging. He did not offer any active content, he simply generated debugging data. However, there was a date among them ...
  
  What is the problem with the date? In general terms - nothing. When the user makes the request, I pulled out the Accept-Language field from the HTTP request and always knew exactly which language to issue. But, turning the date into a string is performed on the server side. Therefore, 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 would issue a standard file in English from resources.
  
  

  The length of words (lines)

  
  Of course, the same words in different languages ​​are different. Therefore, when creating the application interface, you should remember this. A good example is the English “Unlock” and the Ukrainian “Rozblokuvati”.
  
  

  Difference in numbers

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

  Date difference

  
  Despite the fact that ISO sets the date storage format (YYYY-MM-DD), it is not always so simple and joyful. In Russia, it can be written as DD-MM-YYYY, but in the USA - MM-DD-YYYY.
  
  The general advice regarding numbers and dates will be to format them based on the user's language and in no case to "sew" into the program the self-made mechanism for their processing.
  
  With love,
  maniaque