A few years ago, I met a friend in Nuremberg. During dinner, I asked his wife what she was doing in Germany. The answer was "internationalization." This news surprised me. According to our previous understanding, "internationalization" is mainly to prepare corresponding resource files, and to display different languages for customers in different languages.
According to this line of thinking, the most important thing in "internationalization" is to extract all the words as configurable resources, and don't write them to death. It can be said that once your product can support both Chinese and English languages, you have passed the biggest obstacle to internationalization. Adding support for other languages is like "come more people to eat, just add an extra pair of chopsticks".
In the past few years, I started to internationalize IT phone number list products, and I deeply felt that the difference between "internationalization" and "supporting phone number list English" is 108,000 miles. It can even be said that the relationship between the two is completely irrelevant. . If you feel unimaginable, read the following examples to understand.
1. Example 1: Text
Words are probably the first and only factor that many people think of when they mention "internationalization".
Yes, the first step in internationalization is to support the display of multiple languages. The usual approach in the industry is to make a resource file that contains a unified mapping of various languages. When you need to display, you can directly retrieve the resources of the corresponding language in the resource file, and you can get the corresponding text.
The structure of the resource file looks like this:
Is there a problem with this approach? It seems intuitive, no problem, right?
In fact, there is a problem, the problem is not the content of the text, but the length of the text. In most cases, the text lengths of Chinese and corresponding English are similar, so the space occupied by the display is similar, and the original UI elements will not be affected. But sometimes, the lengths of Chinese and English are very different, and in some cases of tight typesetting, the display will be problematic.
This is not the most troublesome. If the length is not enough, you can wrap the line at the space, which can generally be handled, but the height will change. But for other languages, such as German, the situation is more complicated. German often spells out different words, and if you don't think about it in your typesetting, the end result can be particularly bad.
For example, the German word for "Neuschwanstein Castle" is Neueswanstein. If it is directly replaced, it will look like the following:
The length of Neueswanstein is actually nothing in German. You can find longer ones, such as the following (don't be afraid, in fact, it just means the number 1532): Eintausendfünfhundertzweiunddreißig.
So, if you only translate the text and don't consider the UI layout, you may suffer a big loss. Nowadays, "going to sea" is popular. I have seen many domestic electronic products in Germany that also provide German interfaces, but to be honest, many interfaces are terrible.
Text problems, in addition to display, search will also have problems. Languages other than English, especially those of European countries, often have letters that look like special symbols. For example, Ü, ü, Ä, ä, Ö, ö in German (the above two dots are called Umlaut).
Let's take Ü as an example, it looks like it "should be a letter", it does correspond to a key on the keyboard, and it does have a corresponding Code Point (U+00DC) assigned in the Unicode specification. So, if you type Ü in the "Find" box, will you find all occurrences of Ü?
The answer is: maybe, maybe not.
Under what circumstances can it not? Because there are many special characters in the Unicode specification, such as U+0308, this character is called COMBINING DIAERESIS, which is the "two points". It can be combined with vowels and displayed as one character.
So you see the exact same Ü, either U+00DC or U+0055 U+0308 (U+0055 is a capital U). If you don’t take this into consideration when developing software, you may be scolded by users: you clearly see Ü in the text, but you can’t find it in the search box, what kind of broken software!
2. Example 2: Time
China's time zone is unconventional, and Beijing time is used uniformly across the country, so for many programmers, the "natural" time is unified and simple. If you want to change to another time zone, it's just adding or subtracting a few hours, and you can calculate an extra offset.
For example, Germany uses Berlin time, and the difference between Berlin time and Beijing time is currently 6 hours. If you want to support Berlin time in the system, you can use "Beijing time - 6 hours" every time you access. 6:00 am Beijing time, 0:00 Berlin time; 3:00 pm Beijing time, 9:00 am Berlin time…
Is this enough? Obviously not.
You must know that many countries have "daylight saving time" regulations (in fact, China used to have them). That is to say, at different times of the year, the difference between Berlin time and Beijing time will change. Sometimes 7 hours (winter time), sometimes 6 hours (summer time)!
Also, the switching date between winter time and summer time is not fixed. Winter time is on the last Sunday in October every year, and clocks are set back 1 hour at 3:00 a.m.; daylight saving time is on the last Sunday in March every year, and 2:00 a.m. will always be set forward 1 hour.
If you write your own program to deal with this kind of change, it is estimated to be annoying, and it may not be guaranteed to be correct.
Therefore, many systems have built-in "time zone" settings and related functions to automatically help users convert time. Unfortunately, many programmers don't seem to understand why the "time zone" setting is very important, and they are still used to calculating the offset value by themselves.