zbran...@mozilla.com
unread,Nov 4, 2015, 12:31:09 PM11/4/15You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to mozilla-...@lists.mozilla.org
Hi Gaiaers!
I'd like to start a new tradition of providing you with a summary of work that has been done during the a given cycle in my module[*].
It may be surprising for people less familiar with complexity of the l10n ecosystem to notice that our L10n team has been so visible in the number of commits - both me and :stas accruing over 120 commits in this cycle placing us both in top 20 commiters.
The reason is: L10n is complex. It's also severely under-developed compared to most layers of modern app systems. And that is both, a curse and a blessing. A curse because we have no-one to learn from. Nobody has figured it out, no GUI toolkit has a good l10n system and we're with l10n more or less where the webdev world was with HTML4 and PHP.
The blessing is that we have an opportunity at Mozilla to push the state of the whole industry. It's a niche where with limited resources that we have, we can make the Web Stack better than any other stack.
I humbly believe that we are doing it, and 2.5 is an important milestone on that route.
The biggest accomplishment of this cycle for us is the introduction and deployment of new L10n API. This API is based on years of research work by an L10n team in Mozilla led by Axel Hecht. When we took over L10n module in Firefox OS, we started moving the module and refactoring the codebase to work in the paradigms of that approach.
And at the beginning of 2.5 cycle Stas landed revision 3 of our API in Gaia source. Right now it's opt-in: the code needs to link to shared/js/intl/l20n.js to use it.
For the rest of the cycle we improved the new codebase vastly improving performance and memory consumption. At this point L20n 3.0 beats the previous API in features, security, performance and memory.
This, and a lot of refactoring of the code to be more asynchronous, allowed us to move the first four Gaia applications to it - Music, FM, SMS and FTU are fully transitioned and running on top of the new API.
Other highlights:
* Significant improvements in our test coverage, asynchronous non-racy APIs and security of HTML l10n
* Huge progress in reduction of our technical debt. We removed thousands of lines of complex JS code replacing them with simple declarative HTML attributes
* DOM Overlays API allows us to localize Document Fragments
* Bidi markers make composed localized strings work well in LTR/RTL scenarios
* We transitioned whole Gaia to use Intl API for date and time formatting which significantly improves Firefox OS user experience in non-latin based languages
* We moved to use the same Intl API in our composed localization strings for number formatting, so any numbers passed to l10n as variables will be formatted properly for the current locale
* After trying multiple solutions we settled on an amazing module bundler internally, rollup.js, which helped us save memory.
* We leveraged the new internal architecture to properly use client-service bridge architecture in multi-view apps (see Music)
* Made our build system much more strict about l10n errors allowing us to catch many potential race conditions with localization resources
* Introduced first experimental version of our future localization format - l20n
* We deployed mozIntl API that is a staging ground for future JavaScript Intl API
* Lots of work on ECMA TC39 group to get a lot of features needed for Firefox OS into Intl API rev. 3 (ES7).
* migrated our pseudo-locales to work well with Intl API (following Google pseudo-locales rather than Microsoft pseudo-locales)
* We're helping with a lot of performance related work, with both me and :stas becoming peers of the Performance Module and improving our ability to make Gaia apps start fast in any locale
* We are working with JS/Gecko and Gonk teams to fix long standing time/timezone/date problems to make our platform work well across timezones.
* deprecation of the old l10n_date.js library in favor of Intl API and mozIntl
* removal of over 400 calls to the deprecated mozL10n.get method!
* some ground work to enable our whole build/l10n workflow to handle our new l10n format
That's a lot of work. Over 120 commits in gaia 2.5 is just the visible part of the iceberg with over 300 commits to our l20n.js repository and lots of work going to various l10n/intl polyfills, ECMA specs and other repos.
With 2.5 being done, we already started working on 2.6 cycle which we're very excited about because it feels like we have less and less of cleanup work, and we start to work on real improvements and new features! We still have some debt, but we believe 2.6 may be *the* cycle in which we'll finish that part of our work.
So, what's in our plans? Here are some teasers:
* Final rush to remove all mozL10n.get calls (almost 500 calls to remove). Most of that work is in System and Communications
* Integration tests - we now have a framework for that and we can start testing our HTML/DOM API in the browser
* Move (almost) all apps to l20n.js and deprecate l10n.js
* Introduce declarative Intl API for HTML
* Try to remove build time optimizations for l10n
* More work on advancing Intl API and getting 3rd edition of ECMA 402 to have everything we learned we need to make Firefox OS look good
* Start using our new localization format and introduce new l10n features that it allows for
* Move language packs to our build system
* We are starting to look at Web Extensions and browser.html and poke them with a probing stick
* We are experimenting with exposing l20n.js 3.x to the Web community. Supporting some older browsers like IE11 is the current crux.
I don't know how many of those goals we will be able to accomplish in this cycle and how many will have to catch the next train, but with those features, I believe that we will have the best multi locale UI platform in the World. And that's a goal worth pursuing!
Thank you to all reviewers, committers, allies, RTL team, and the amazing sheriffs who had to back out a few eagerly landed patches. We're working on it! :)
zb.
[*] I believe it would be valuable for us to start providing such per-cycle summaries rather than per-quarter summaries. Quarters are artifacts of our management structure, not our project structure.