Lost in translation
A long time ago, in a software development galaxy not so far away, software could only “speak” one human language at a time.
And for a time, it was good.
Everything worked well until “X” software tool started to become popular among specific countries or regions that needed their own version. Software had to become polyglot for international users.
This was quite a challenge back in those days because in some cases, internationally relevant features were retrofitted onto the english version of the product or even worse, the product was developed in a parallel fashion: one in english and the other in another language.
English and international versions could’ve might been completely separate products that only shared the same name. This was particularly the case with Asian versions of a product developed in North America or Europe. In any case, the result was usually a lengthy, expensive product cycle.
Who hasn’t work on a project where all the texts that are displayed in the views are written directly in the program’s source code, just like this:
<h1> I’m a hardcoded string 😛 </h1>Imagine replacing all hardcoded text from an entire codebase?
Successfully translating an application can be quite difficult, expensive and time-consuming. It usually entails large spreadsheets ☠ and a lot of back-and-forth between clients, developers and linguists.
Even if we manage to succesfully translate our application, sometimes the translated text does not function as expected. Assumptions like the length or position of text are made using the English languague as a base, that usually breaks the design when it is translated to another languague.
To create a truly globally accessible product, developers and biz owners have to make a commitment to solving for worldwide customers.
Developers call this practice internationalization (often abbreviated to “i18n,” because there are 18 letters between the ‘I’ and the ’n’ in the word) and localization (l10n, same logic 10 letters between the ‘L’ and the ’n’ ).
But what’s all this?
Internationalization: is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language.Localization: refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a locale).
The goal is to make applications feel just as native for users in Mexico or Tokyo as it does for english speakers.
Properly enabled software is the answer here, not a barrage of unique, mono-lingual applications.
Wonderful! But It’s not all a bed of roses, i18n and l10n are also a complex problem.
Natural languages differ in so many ways: there’s that pesky problem of morphology (the way words are structured), syntax (the way sentences are composed) and semantics (the way in which those sentences convey meaning) that can differ a lot from one language to another that it is hard to solve all problems at once.
Luckily for us, modern web frameworks already provide tools to tackle this kind of problems, like the I18n gem included in Ruby on Rails or react-intl for react .
Even if an application is only ever intended to be used by speakers of one language or locale, not considering I18n from the beggining of product’s development makes it is expensive and time consuming to support additional languages if the need ever arises.
If your application could be useful regardless of where in the world it is used, or your target users span multiple countries, regions or languages, why make it more difficult to reach them?
Any delays and expenses from not bringing i18n into your development process can be expensive in terms of money and opportunities. For example, in the early 1980s, Lotus 1–2–3 (A spreadsheet-like software) took 2 years to separate program code and texts and lost the market lead in Europe over Microsoft Multiplan. It is important to look at a variety of markets that your product will foreseeably enter.
Properly enabled software can help turn localization from a chaotic and expensive game of “catch up” into a smooth, well-oiled machine.
As you work on your various projects, please considering the following statements in mind:
- One code base for the world
- English is just another language
- Build I18n into your Process, not the other way around
and the most important:
- Can’t read, wont buy.
References:
https://www-archive.mozilla.org/docs/refList/i18n/
https://bjoernkw.com/2013/06/30/i18n-is-a-hard-and-largely-unsolved-problem/
https://en.wikipedia.org/wiki/Internationalization_and_localization
