L20n/Roadmap/Next

Overview

L20n.Next is a catch-all bucket that will collect all ideas for L20n development that has been considered mature enough that we know how we'll fit them into L20n.

Items from this list will be the base for the next releases of L20n and will be moved to roadmap of a given release.

You can assume that all of the items here were marked as important and that noone else is working on them, so feel free to pick any one that you're interested in and start working on it! Use localization-20 group or #pontoon IRC channel on irc.mozilla.org if you have any questions.

Features

• Gettext-mode - in content-heavy scenarios it would be reasonable to sacrifice some of the flexibility of L20n to get easy development process and since it requires only a minor change in L20n format (to allow entity IDs to be strings) such use scenario should be evaluated for cases like web templates (django/jinja, PHP) etc.
• Default value - If an entity is an object or a list we currently do not offer a way to mark one of its values as "default" which means that if we change the syntax of the entity we have to adjust all the references to it. It would be worth considering having a special flag on each object/list value to mark which value should be returned if none is being specified by the caller. On the other hand, maybe entity index is sufficient?
• Dependencies - LOL resource may have some external dependencies that have not been met by LOL itself. It may be provided by other LOL or by a developer. We should make it easy to understand which entities/attributes are required and which values have to be provided by other resources. Then we should make it easy to see which combinations of resources are self-sufficient and which have external dependencies that have to be provided from the developer.
• PHP bindings - full blow PHP module for l20n operations
• I18n/ICU bindings - L20n should work with ICU for I18n operations like date formatting, numbers etc.
• Meta Data - We should investigating using comments or other forms of meta data for LOL resources and entities for things like developer->localizer communication, localizer->localizer communication, QA status and potentially entity version numberings.
• Move helper functions outside of compiled LOL resources - we currently bundle a set of helper functions inside j20n and p20n files. We should consider injecting them into context instead.
• Multi-locale LOLs - storing multiple locales inside a single LOL may be valuable for multiple reasons. The main one is that it tells us which version of the string did the localize corresponds to and this way we can easily notice when the translation is obsolete.
• System info - L20n should provide some variables as part of each context that can aid localization process. things like date, time, day of the week, platform etc.
• Dynamic resource pooling - similarly to Common Pool we should think on how to provide ability for an app to update its translation dynamically from a server.
• CSS bindings - allows for limited CSS styling from within of localization (box width/height etc.)
• Java bindings - needed for NativeUI for Mobile.
• #include - LOL's should be able to include other LOLs for macro reusability

Back to L20n home