L20n/Characteristics
There's no point in doing something new without a characteristics list, so here it goes.
Open
We still need to find out what this means exactly, but we're
- taking suggestions
- not limited to Mozilla
I (Axel) don't believe in permissive licenses on specification documents, though. Suggestions welcome.
Separate application and localization logic
Looking at existing discussions out there on supporting complex languages, the major hurdle seems to be the blurry line between application logic and the localization part. Blurring that line makes complexity from the language side leak into the application logic, and makes limitations in the application logic limit the localizations. See L20n/Background for more details on this, and L20n/Control flow for how this changes the flow of control and information.
Plural and grammatical forms
L20n is designed to handle both plural and other grammatical forms inside the l20n architecture, thus hiding any complexity in a particular language from the application logic.
Implementation language agnostic
By introducing a well specified boundary between l20n architecture and application logic, there's a clearly defined meta-API which consists of set up a localization context and get a specific string in that context. Language mappings will be specified to map those meta-APIs to the appropriate concepts of the application programming language.
Flexible Fallback path
There are two major scenarios for which implementing a fallback path for non-localized content is a major boost to efficiency.
- creating new localizations
- maintaining variants of existing localizations
The two concepts are somewhat different in the meaning and will likely be handled differently in the case of missing strings at runtime, but technically, it merely says "I have this other working locale, use that if I suck". For both variants, falling back to English may be an alternative, but it usually isn't the first choice. In the case of variants, it's not even a good second choice.
Designed for version control systems
I call it a feature, others call it a bug. The file format to hold the localizations is designed to be efficient and meaningful in the context of version control systems and VCS-based toolchains used in most software projects. This is a compromise, and burdens processes based on mailing single files back and forth.
