L20n/Design

Here are some corner stones for the design of l20n.

parameter substitution in the library 

To get the full flexibility needed to make localization both right for a wide variety of languages and attractive to programmers is put the complexity required getting the right string into the localization files and the library. This affects at least plurals and composited messages.

string lookup by symbolic names 

There is some conversion here in practice, as in, the string contexts and markers are providing symbolic lookup, without dropping the English text, though. The English text is really not the right thing to use, in particular if you're writing your software in another language to begin with. The other uses it is abused for are much better handled by tools tailored to do that, like version control systems providing blame functionality.

language agnostic 

In order to make L20n succeed, it needs to be applicable outside of the Mozilla applications context, and even there, it needs to work for DOM, js, and C++ at least.

localize objects, not string 

It turns out that one challenge in localizing applications is keeping things together. Labels and accesskeys, for example. But for things like composing application names and toolkit messages, you want to find the gender of your application name next to your application name. Or the different plural forms don't really spread all over your localization file, they're an array. Localization applies to objects and it uses objects. Thus, L20n provides lists of localizable objects, lol in short, rather than a flock of strings.