Hi all, Wanted to give you an update on the current status of L10n/Intl in Gaia.
=== Current Status === I just successfully finished migrating all TV apps to L20n and I migrated as many "Phone" apps to L20n as I could over last months. I believe that at this point all critical apps (like System, Settings, Keyboard etc.) that are likely to be useful for future CD projects or as a base for new apps have really clean L10n API usage and they all rely on L20n.js which is uses the final version of the L10n API. All the code in ./shared/ and ./tv-apps also have all their code refactored and up to the current API standards. On top of that, we have four more elements of the system: - mozIntl[0] is a wrapper on Intl API that gives us access to future Intl API extensions like UnitFormatter, ListFormatter, RelativeTimeFormatter, DurationFormatter etc. - IntlHelper[1] is a small library that simplifies writing code that caches Intl formatter and invalidates them when language/timeformat etc. changes. - L20n Service[2] is an extension of L20n.js library that operates in ServiceWorker which makes us ready for the NGA (and is used by the Music app) - L20n Build[3] System is our plug into Gaia build system that enables us to prepare and optimize Gaia apps. L10n Team (Stas and me) are committed to maintain this code and we will reuse it in other projects so expect us to keep dropping updates to those files and small refactors of code in gaia repository if needed. === What's left === There are several things we did not finish, and they still require work: - There are still apps that rely on obsolete use of mozL10n.get call. It's been a very long ride, but since Firefox OS 1.4 we reduced the number of call of this function from around 1500 to 289 [4]. All of the remaining ones are in ./apps (none in ./shared or ./tv_apps). The biggest offender is ./communications with around 100 of those calls. I don't see us working on that anymore, as it requires good understanding of the app code, deep reviews and requires extra carefulness to avoid regressions and I don't believe we are in a good position to secure that. - There is still code in ./shared that uses l10n.js' `navigator.mozL10n` API instead of l20n.js' `document.l10n`. It's not significant - 10 calls in 6 files, mostly related to ./communications code. We landed a l10n.js-2-l20n.js proxy in L10n.js, which means that code that relies on l10n.js can use l20n.js API, so those should be safe to migrate if anyone is going to work on those. - Because of the use of mozL10n.get, there are still 21 apps in ./apps folder that use l10n.js. We are not going to maintain that library, and if any of those apps will be planned for production, they should migrate to l20n.js before they are released. We'll be happy to help with the transition. === What's next for us === As I said before, we're committed to maintain the L10n/Intl APIs that we developed for Gaia. We believe that they are the best technologies for writing multi-lingual web applications, and we are going to use them for all future projects. I'm not aware of any CD projects that are at the stage of writing production ready code yet, so we expect to use Firefox Desktop components and Firefox OS TV as our driving platforms for now. The next big thing, that we've been putting off for way too long and which has been limiting our localization capabilities is the new file format for L10n. Because our primary target has been Gaia and Gaia originally chose a proprietary modification of the .properties format, L20n.js has been using it so far, but we've always believed that we need a new file syntax that will allow localizers to design better messages and lately, we've been exploring the potential of interactions between localization (messages) and internationalization (date formatting, unit formatting, list formatting, plural forms etc.). We're pretty close to start testing it on localizers and we expect to spend first part of the next quarter on getting our toolchain up to speed, getting tutorials and documentation and making the new syntax work in parallel with .properties. We're also working with TC39 group to move pieces of L20n/mozIntl that we designed for Gaia to EcmaScript 2016 and 2017. If you're working on a project that will need l10n/intl, you can safely rely on the L10n/Intl APIs that I listed above. We're very confident that it's the best technology on the market :) Enjoy hacking the Free Web! zb. [0] https://github.com/mozilla-b2g/gaia/blob/master/shared/js/moz_intl.js [1] https://github.com/mozilla-b2g/gaia/blob/master/shared/js/intl_helper.js [2] https://github.com/mozilla-b2g/gaia/tree/master/shared/js/intl [3] https://github.com/mozilla-b2g/gaia/blob/master/build/l10n/l20n.js [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1020138 _______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
