This is the fourth day of my participation in the First Challenge 2022

I joined the new company a few months ago and took over the international needs of my colleagues. After several months of work, I found that internationalization looks easy, but it is very difficult in practice.

Because internationalization is a series of projects, it needs to be considered by all team members in each process of the iterative development of the entire product.

This paper looks at the problems encountered in the process of internationalization from the perspective of front-end development.

What is internationalization?

How to understand internationalization? In a narrow sense, this refers to the ability of the product to provide copywriting in other countries than the local one. To be more precise, internationalization is the ability of products and services to adapt to different countries and regions and penetrate their markets. Internationalization is abbreviated as I18n (initial I, middle 18 characters, and trailing N) for ease of catch-up.

A good product internationalization should be considered from the beginning of the product design and should be considered in the iterative design development. This can greatly reduce the time and effort required to modify the design and code later to support more languages.

But in fact, domestic companies’ products are mainly targeted at domestic users. They are hesitant to go to sea and do not expect much from the business. Of course, as the domestic market has become saturated, companies have tried to take their products overseas — and some of them have been successful, like TikTok. In general, domestic products do not take internationalization very seriously at the beginning of design.

The most common situation is that when the product development has reached a certain level, the international demand comes into being when they want to try to enter the overseas market. This demand is often long-term and requires a little bit of system transformation.

That’s what happened to me. The reason is that a customer has an overseas department and wants to support English.

Determine the user’s language

To achieve internationalization, you first need to determine the user’s language.

For browsers, the front end can retrieve the user’s language through navigator.language, and the back end can be determined by the accept-language header field of the HTTP request. Of course, the user’s own language should also be taken into account.

There are many scenarios to consider:

  • The user sets the language;
  • The user does not set the language.
  • An interface that does not require user validation;
  • The language in which messages received by users should be displayed;
  • Load language packs on demand. The solution can be found in one of my old posts: Front-end internationalization: How to implement on-demand loading of language packages?

Language standards

Unfortunately, internationalization has no standard for language identifiers, which can cause a lot of problems in our development.

For example, the identifiers of simplified Chinese characters can be zh, zh_CN, and zh-cn. Everyone has different understanding and may choose different standards. When communicating with colleagues, additional work needs to be done: converting language identifiers of different standards.

This problem can also occur with third-party libraries that involve internationalization.

So we need to set a standard and demand that everyone on the team follow it. It is recommended to refer to the standard used by popular internationalization libraries, namely the BCP 47 language markup.

style

Different languages express the same meaning, need different amount of text, which leads to the length of the text is not fixed. This requires consideration during visual design and development.

When I took over the internationalization requirements, I found that the past visual design and development did not take internationalization into account.

For example, some buttons, only two Chinese character width, development write dead width, let the text center. However, after the translation into English needs to be internationalized, we find that the width is no longer fit. We need to change the button to no width and set the padding to adapt to the text.

Some of them were fixed in width and might have to be redesigned after internationalization. Finally, the designer said let’s add an ellipsis to the truncated text so you can see the full text in tooltip. This is rather awkward.

To summarize a few points to note when considering internationalization in design and development:

  • Consider possible line breaks;
  • Try not to use fixed widths;
  • When designing lists, think vertical rather than horizontal;
  • Consider the whitespace case, which is for the Spaces between words. In Flex layouts, whitespace is ignored and requires special treatment.

Copywriting maintenance

Internationalization is more troublesome copy maintenance work.

In theory we need to put different languages in different JSON files, such as zh-cn. JSON and en-us. JSON. They all have the same key, and then the value is different. After the language pack is loaded on demand, we can get text confirmation or confirm in the code by t(‘confirm’).

One solution is for programmers to manually add, delete and modify the fields of THE JSON file, which is prone to conflicts when submitting codes, and the product cannot directly configure the copy, which will cause some communication costs if programmers are needed.

There is a better solution, and the one my company uses is an online collaboration form, where we maintain a table with different country identifier fields on which development and products can configure copywriting for different countries. Once the changes are made, the developer will pull the table contents and convert them to JSON files.

However, both schemes share some of the same problems:

  1. Some abandoned copies were not deleted, mainly because they did not dare to delete for fear of problems. One solution is to scan the project code and remove unused copy, but only if the key we use is not dynamic so that we don’t miss anything.

  2. Reuse or semantic. Some copywriting may be repeated in multiple modules, and in theory they could all use the same copywriting ID to reduce file size. But maybe after a while, one module changes its copy, causing other modules to change their copy that didn’t need to change. You can have different modules use their own keys, but with redundancy of file data. Reuse versus semantics, that’s a question to consider.

  3. Difficult to manage. It’s harder to find out who accidentally deleted a line or field.

  4. Repeat the question. Multiple identical keys appear, and only one of them is retained when the JSON data is read.

other

  • The component library designed by your own company also needs to take internationalization into account. If you don’t, you have to manually pass in a copy for every place you use it, and the development experience is terrible.
  • Money, time and other habits. If you are a local, you may not be able to tell if the copy is reasonable.
  • Error messages returned by back-end interfaces are also internationalized.

Product internationalization is a system engineering, every process of development needs to be considered, need to consider a lot of details. It looks like just replacement copy, but there are quite a few sub-scenarios and scenarios involved.

My article is only about the replacement of copywriting, which is internationalization in a narrow sense. A truly qualified internationalization should also consider such non-technical things as user habits, different operations for different countries and so on.