L20n/Paradigms
For those of you who never interacted with localization too much, the current stage of UI localization technology is pretty static. While content localization gets significant fundings and R&D from companies like Microsoft, Google or Apple, with bloom of text2speech and speech2text and machine translation technologies all around, UI localization is left behind.
The major concepts in UI localization that remain untouched for decades now are pretty simple - you separate content from view (in MVC approach), and store it in an external resource that is a plain key-value pair list (the reference connotation being an english string).
This concept is fundamentally flawed at its core, since languages are so vastly different from one another, that it is impossible to find a single one that could serve as a common denominator, and using American English for that is particularly limiting due to its fairly simple grammatical nature.
The result of this binding-to-en-US is often invisible for majority of localization work. Vast majority of UI strings are simple and can be 1-to-1 matched to the source string. Most of "Open", "Close", "Cancel" etc. are in that category.
But the remaining strings, even if there are only a few of them per app, are actually crucial for the quality of the software. Those are the sensitive strings that make or break user experience. Those are the strings that describe complex concepts like notifications, status of the application, updates from external sources. Ability to properly express the information is a major issue with the current-generation frameworks because what localizers usually need is some form of string selection.
By that we mean a form of using some factors like variables from the developer, available space, time of the day, available space or gender of the user, which of the available strings should be used in this particular case.
With current generation of technologies, the only way to do that is to request such branch selection from the developer. It means that developer has to introduce additional code to facilitate this complexity, which puts the logic in the wrong place and makes changing and updating it particularly inconvenient while at the same time increasing the cost of code maintenance. Eventually, each such process is also multiplied in terms of additive cost by the number of locales, because each branch selection means increase of string complexity for *all* locales, even when only one needs this particular feature.
That makes the whole system unsustainable, as increasing complexity in running code with growing number of locales having unique requirements quickly becomes impossible to maintain for developers and localizers alike. In result both sides usually try to avoid this painful process and prefer to lower the quality of the user interface where possible.
Paradigm shift
The major paradigm shift introduced by L20n is that we move this branch selection away from the developer into the hands of localizers. It means that its now up to the localizers if she needs a single string, or multiple variants and how to choose which one to use.
This shift makes cleaner, easier to maintain running code (no IF… ELSE…), It keeps the communication between developers and localizers simple (the L20n API always return strings, making localization choices opaque from dev perspective) It isolates language complexity, preventing it from leaking onto other locales.
In principle, it means that a localizers chooses how many variants of the string she wants to prepare, and instruments L20n on how to select. That may sound simple, but no existing localization framework allows for anything like that (except of messageFormat to some extent) and it enables unprecedented power for the localizers to prepare clean and natural translations.
On top of this major shift, there are more differences and patterns that we consistently built into the API to encourage writing clean multilingual code. Core of our API is asynchronous which makes it easy to negotiate startup sequences, switch languages on fly, extend language coverage with language packs, react to changes in the environment, update translations and fallback gracefully in case of errors.