L20n is a proposed method for localisation in the Mozilla project. https://wiki.mozilla.org/L20n
Here we collect some comments about the possibility of l20n support in our tools.
Our tools are based on the idea of units. Each unit has an associated (source, target) pair, possibly containing more, like comments, state, etc. We prefer to build our richer tools against bilingual formats like PO Files, XLIFF, Qt .ts, etc. and provide converters to these formats when we want to support guide/monolingual formats. Pootle also implements its own bilingual format in its database.
l20n is based on the idea of entity soup, or object soup. Files are (at least in the first iteration) monolingual, and each language defines a set of objects which can contain one or more presentation forms of an entity/string, to vary it according to gender, case, declension, plural, time of day, etc. A language can define extra entities to help in constructing others by “factoring out” things, if you will. The structure of each object is left to the programmer for the target language to define.
Our tools work on the principle of units. A unit being in its simplest form a source to target mapping, in other words the English source text plus the target translation make a unit. Our code has, for a long time now, a good understanding of units that don’t have a one to one mapping. In PO those are plural units. This is where N source strings map to M target strings. We currently only have 1-M and 2-M mappings for Qt and PO files. l20n introduces N-M mappings which we don’t currently support.
l20n is of course working around an idea of translation objects not strings. But I think the string metaphor works in most cases to ease explanation.
The closest thing we have to this is plural support by means of multistrings.
l20n is pretty powerful with the ability to arbitrarily make up functions/macros that then map to the correct string to use in the translation. In PO the number of possible (plural) strings is mapped before you begin, l20n potentially has any arbitrary mapping.
We could write a simple converter to another format for simple string based objects without further structure, but that doesn’t expose the power of l20n yet, and doesn’t handle complexity in the source text if it was present.
The problems above really highlight the approach we’d take to implement l20n in our tools.
At this point we have a usable translation tool for l20n. The next steps would be about making that support more robust. Each of these would really be determined closer to the time.
We’re now really at a position where we’ve solved things up to point 4 above. Addressing issues in point 5 and 6 would be the next steps.