Lost in Translation

Once upon a time, in the dim, primordial past of software development, a lot of software could only "speak" one human language at a time.

Each country or region needed its own version. In some cases, internationally relevant features were retrofitted onto the shipping English language product.

In other cases, the English and international versions might be completely separate products, perhaps sharing some basic code but often sharing little more than the product's name.

In either case, whether making such changes retroactively to a shipping product or developing parallel versions, the result was usually a lengthy, expensive product cycle.

 

¯\_(ツ)_/¯

<h1> I’m a hardcoded string lol<h1>

 

String text = "Hola soy texto"

Mistakes are easy to make; and the translated code often does not function as expected, because its authors made assumptions about things like the language of the UI, the length or position of English words (which change when translated to other languages), etc.

 

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). 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 Berlin or Tokyo as it does for our US-based customers. Properly enabled software is the answer here, not a barrage of unique, mono-lingual applications.

Internationalization is a complex problem. Natural languages differ in so many ways that it is hard to provide tools for solving all problems at once

Pluralization

 

es-MX            en-US

Muebles        ->     Furniture

Peces              ->     Fish

Child | Children

Currencies

 

es-MX            es-ES

$5,892.99    ->    5.892,99€

 

en-US            en-GB
$11.95        ->    £11.95

It is important to look at a variety of markets that your product will foreseeably enter In a commercial setting, the benefit from localization is access to more markets.

For example In the early 1980s, Lotus 1-2-3 took 2 years to separate program code and text and lost the market lead in Europe over Microsoft Multiplan.

 

A long time ago...

If your application could be useful regardless of where in the world it is used, or the target users span multiple countries, regions or languages, why make it more difficult to reach them?

  • Not using I18n from the beginning makes it time consuming and expensive to support additional languages if the need ever arises.

 

  • i18n usually entails large spreadsheets, product freezes, a lot of back-and-forth between developers and linguists

 

  • Such delays and expenses eat into the profits from releases (both monetarily and in terms of lost opportunities).

twitter.com

facebook.com

As you work on your various projects, please keep the following catchy phrases in mind:

 

  • One code base for the world

  • English is just another language

  • Build l18n Into Your Process, Not the Other Way Around

 

and also...

Can't Read, Wont Buy.

Points Travel I18n Implementation 🚀

Current Translation Workflow

placeholder (?)

  • Agent and Devs editing translations at the same time

Developer

Babel / Parsel Tounge

Translation Tool-ish

📂

Babel Translation Workflow

👩🏼‍💻

👩🏾‍💼

automatically

MANUALLY 💅🏿

  • One source for translations
  • Agents and Devs can coexist
  • Scalable to multiple products
  • Can be shared with translation agency

Questions? 🤷🏾‍♂️

Thanks!✨

Made with Slides.com