Staś Małolepszy

The asymmetry of L20n

Asymmetry is a key concept in L20n. Each language is isolated and the localization logic of one language doesn't leak into others.

When discussing L20n features or syntax, it's easy to lose sight of the the key principles that guided its design. It's easy because in order to fully appreciate them, one has to break away from the mindset of a developer (focused on the API) or from the mindset of a localizer (focused on one specific language).

One such principle is asymmetry.

L20n is asymmetric, which means that as long as the identifier stays the same, the localizer is free to do whatever they feel is right and needed in their language—without affecting any other language nor the source code.

Let this sink in for a moment.

L20n's asymmetry results in isolation of languages. If Polish needs declensions, they can use them, but it doesn't mean the developer have to implement them for English too. If French needs genders, they can have them, but it doesn't mean that Basque will have to deal with gender-specific strings in their translations.

Choose what you need

Let's take a look at an example to illustrate this point. English:

<brandName "Firefox">
<about "About {{ brandName }}">

French:

<brandName "Firefox">
<about "À propos de {{ brandName }}">

Polish:

<brandName {
 *nominative: "Firefox",
  locative: "Firefoksie"
}>
<about "O {{ brandName.locative }}">

The Polish localizer can choose (but in fact doesn't have to) to make the translation better by using the grammatical case governed by the "about" preposition (the locative).

Note that neither French nor English are affected. Their translations stay as simple as possible, because neither French nor English require such grammatical construct.

When the developer asks for the value of the about entity, L20n will return a single, grammatically-correct string: About Firefox, À propos de Firefox and O Firefoksie, respectively.

All the localization logic is hidden from the developer and all that matters at the end is a single string, ready to be used in the interface.

Improve freely

L20n's asymmetry is a powerful concept. If languages are isolated, localizers can tinker with the translations and progressively improve them. They can start simple, test, gather feedback from users, go back and change the logic of the translation, without having to resort to filing bugs against the main codebase. All these improvement stay local to the localizer's language and don't affect any other languages.

Let's take a look at a simple example of a pluralized string in English. You can play with it yourself on L20n tinker.

<plural($n) {
  $n == 1 ? "one" : "other"
}>

<message[plural($msg)] {
  one: "{{ $msg }} message",
  other: "{{ $msg }} messages"
}>

This is certainly good enough, but it could still be improved slightly. You might recall the following rule about writing numbers in English:

Spell out single-digit whole numbers. Use numerals for numbers greater than nine.

Let's try to implement this in L20n (tinker):

<plural($n) {
  $n == 1 ? "one" : "other"
}>

<digit($n) {
  $n == 0 ? "no" :
  $n == 1 ? "one" :
  $n == 2 ? "two" :
  $n == 3 ? "three" :
  $n == 4 ? "four" :
  $n == 5 ? "five" :
  $n == 6 ? "six" :
  $n == 7 ? "seven" :
  $n == 8 ? "eight" :
  $n == 9 ? "nine" : 
  $n
}>

<message[plural($msg)] {
  one: "{{ digit($msg) }} message",
  other: "{{ digit($msg) }} messages"
}>

The digit macro is local to the English localization file, so this improvement is local. Polish has less strict rules about numerals, so it might not need an equivalent of the digit macro. (It will need, however, more plural forms.)

Easy things are easy

The motto of L20n that we live and code by is:

Easy things are easy, complex things are possible.

Many of us—people living and breathing localization—are passionate about linguistics and grammar, and it shows. We like to look for hard-to-crack grammatical problems and solve them in L20n. (Check out Axel's educative relative dates in Russian example.)

This might sometimes looks scary if all you're looking for is a simple key-value translation. That's okay! Languages in L20n are isolated, remember? Even if Polish needs some funky logic to get its plural genders right, if you don't need an entity to be complex, don't make it so! L20n still has your back.

Published on 14.08.2013
Permalink: http://informationisart.com/21

Staś Małolepszy

Thoughts about the Internet, the information society, Mozilla and human-computer interactions.

Latest notes