The struggles of internationalising a web app

Let’s get this straight: for so many startups, translation is the least of the problems. It’s unusual for a web app, especially if it is created in the United States, to have features for internationalising user-generated content right from the start.

A web app should take care of internationalisation at 3 levels.

The first level is the front end, that is, the texts that appear to visitors and users of the web app. The web app may be available in one or more languages. The decision to offer multiple languages depends on the internationalisation strategy of the company that developed the web app.

As an Italian user, I appreciate web apps that allow me to choose Italian as the interface language. However, because I am a translator, I also know how and with what care translations are done. So appreciation lasts only a few seconds. Then I set everything back to English. Joking aside, this first level of internationalisation is contemplated by almost every web app I know. In addition to English, there is at least another language (Spanish, Chinese, Russian, French, German, etc.) depending on the markets the company wants to reach. Companies with a more international focus offer their web app in 4, 5 or even more languages.

The second level is about user-generated content. Strictly speaking, user-generated content includes comments, reviews, ratings, photos (and their captions), posts, forum interventions, etc. In this article, however, I am referring to content strictly related to the main function of the site, such as:

• if the web app is for creating a CV, then I mean the CV
• if the web app is for generating images, then I mean the images
• if the web app is for designing and publish a website, the user’s website
• if the web app is for publishing an online course, the online course
• etc.

In these cases, the web app should consider that user-generated content will not necessarily be created in the language of the interface. For example, if I am visiting the English version of a CV creation site, I may want to create my CV in French, Italian or any other language.

This level of internationalisation is also almost always contemplated by the web app developer. It would be counterproductive if - continuing the previous example - when creating a CV in Arabic, the web app was unable to show Arabic characters or showed the texts from left to right instead of right to left.

The efforts of Unicode Consortium and the use of Unicode standard by nearly all web apps have contributed greatly to making sites and apps compatible with almost any language.

Without going into further details of character sets and their encodings, a fascinating and complex field that I will keep for another occasion, just remember that Unicode is the system that allows all devices (computers, phones, tablets, etc.) to share or exchange text written in any language (or almost).

How does it do that? Since computers, after all, only understand numbers, Unicode assigns a unique number to each character, regardless of the platform, program, or language.

You may have heard of UTF-8.

The difference between Unicode and UTF-8 is the following: Unicode is a character set (you can imagine it as a huge table where each character corresponds to a number), while UTF-8 is the encoding of this table, i.e. the way numbers are converted into binary code to be understood by the computer.

The pain points come with the third level of internationalisation, the one related to the possibility of converting user-generated content from one language to another, i.e. the translation of user-generated content.

The majority of web apps that I know of, have countless features related to content creation, but are lacking on the translation side of the content itself.

Ideally, the web app should have a mechanism for:

• exporting translatable content
• importing the content once it has been translated
• automatically translating all translatable content

Going back to the CV example, does the web app allow me to translate comfortably into English the CV I’ve created in Italian?

In my experience, this comfort is almost never achieved.

Le tendenze attuali nella localizzazione di software includono l’uso crescente della traduzione automatica basata o meno sull’intelligenza artificiale, il collegamento con strumenti di traduzione assistita per migliorare l'efficienza dei traduttori umani e lo sviluppo di soluzioni di internazionalizzazione integrate che facilitano la gestione dei contenuti multilingue all'interno delle web app.

While it is true that some web apps allow content to be automatically translated by connecting to Google Translate or DeepL, it is very rare to find web apps that have thought about the translation of user-generated content from the beginning.

Even highly popular programs, such as WordPress or Moodle do not have native functions to present their contents in multiple languages (note, I’m not referring to the interface, which is translated into countless languages).

The reasons behind this apparent oversight can be many and more than legitimate, upon closer inspection.

First, many web apps are created in the United States and are designed primarily for its very large home market, so the option to make the app multilingual is not a strategic priority.

Another aspect, of no small importance, is the complexity of the mechanisms of data export-import.

Whatever the user-generated content is, the moment you allow it to be exported in an editable format (the content must be editable in order to be translated), you run the risk of it being manipulated in the wrong way and not being able to import it back into the system. Therefore, many companies deliberately avoid adding such features to their web apps.

Furthermore, although the translation industry has long conceived at least one standard for exchanging data between applications, the XLIFF format, not all developers know and use this standard. Creating a web app following localization best practices involves additional effort that few companies are willing to put in.

This being the case, when a user needs to translate the content he has generated, he is forced to look for tricks and detours. The issue would be of little consequence if the problem only occurred at the private user level.

However, many web apps are also used at the enterprise level. Many businesses, especially family businesses, prefer to use tools initially designed for end consumers, both for economic reasons and for convenience and habit.

È frequente quindi trovare opuscoli aziendali, presentazioni commerciali, brochure e cataloghi creati con Canva, oppure sondaggi per i clienti creati con Surveymonkey, siti aziendali realizzati con Squarespace o Wix, diagrammi e schemi con Diagrams.net e via dicendo.

When this content needs to be transmitted to an importer or trade delegation overseas or to be adapted for a foreign audience, what happens?

After being initially bewildered, when you find out that you can’t translate the content, two possible scenarios open up:

1. duplicate the content and translate it into the web app
2. export the content, translate it and then manually enter the translation

➡ The most popular solution is to duplicate the content and overwrite the text with the translation.

However, for this to happen, the user who created the content must know the foreign language. Otherwise, you will have to give an external translator access to the web app. But not all web apps are designed to be multiuser or for collaborative projects, so the latter step may be difficult or impossible.

➡ If the first solution is not viable, the alternative is exporting the content to send it to the translator.

Web apps used to create images or graphic design projects almost always have an option to export to PDF. Once you have downloaded this PDF, you send it to the translator. The translator will then return a Word file with the translated text, which someone will then have to manually insert into a copy of the original document. In addition to PDF format some web apps, a small minority, also allow editable formats to be exported. An example is Diagrams.net which allows you to save a diagram in XML format, which can be opened and edited and then imported back into the application.

Clearly, if the web app is used to create websites or complex multimedia content, exporting is nearly impossible and alternative tactics will be needed, as we have explained for example for Squarespace.

What conclusions can be drawn from this brief analysis?

1. If you are designing a web app, you should carefully consider your target market, and consider the 3 levels of internationalisation described above, if they serve your purposes.
2. If you use a web app, you should check before intensive use what translation features are available, especially if you use it for business or commercial purposes.
3. If you need to translate user-generated content from a web app, you should know the best process (native or alternative) and propose it to the translation client.