Quoting Staś Małolepszy (2014-09-19 17:29:24)
> Quoting Staś Małolepszy (2014-09-19 15:49:49)
> > So this is what my email #3 is about :) I've had this idea of
> > letting the developer handle language switching entirely: either by
> > listening to window.onlanguagechange, or by maintaining their own
> > setting store and keeping the user's preferred language there.
> >
> > If the env doesn't have the 'supported language' state, then we don't
> > have to worry about it in the API.
>
> That said, I think it could make sense to include language-switching
> facilities in the HTML bindings, for instance.
I wanted to see how easy it would be to implement HTML bindings using
the new API. So I did it :)
You can find the code in the bindings/ directories of my branches:
https://github.com/stasm/l20n.js/tree/newapi
https://github.com/stasm/l20n.js/tree/immutable
Open examples/regular.html in the browser to see it in action.
Since the current HTML bindings logic is rather complex, I simplified
it significantly by making the following changes and consessions:
- the synchronous mozL10n.get method returns 'xxx',
- the synchronous mozL10n.readyState property is always 'complete',
- removed waiting for document.readyState === 'interactive' in favor
of using the defer attribute for l10n.js,
- the mutation observer works,
- language switching works,
- no support for pretranslation via GAIA_PRETRANSLATE=1,
- no support for JSON resources nor inline <meta> manifests via
GAIA_INLINE_LOCALES=1,
- mozL10n.once and mozL10n.ready wait for the default ctx to fetch the
resources for the first supported language; (I also experimented
with just waiting for the language negotiation, but the perf seemed
worse; I'll keep checking if it makes sense to change).
The two most interesting implementation differences were:
- language switching on newapi: I needed to add a way to reset
contexts associated with the env,
- language switching on immutable: each language change creates a new
context,
- mutation observers: it's necessary to pass the observer all the way
down to the function which inserts the translated value in order to
disconnect it temporarily for each translated element.
Overall, I really liked working with this API. It's atomic; it doesn't
do too much and the things it does are limited to small parts of the
logic. It plays nicely with other Web APIs. My current preference
goes to the 'immutable' branch for its greater simplicity and even less
magic.
Performance testing
-------------------
I made the same changes in the current shared/js/l10n.js to even out
the odds in perf testing. I tested with the following commands with
RUNS=5:
GAIA_OPTIMIZE=0 GAIA_CONCAT_LOCALES=0 APP=settings make install-gaia
APP=settings make test-perf
The baseline is the current l10n.js with the above changes applied:
settings (ms) Mean Stdev
------------------------- ---- -----
moz-chrome-dom-loaded 1925 466
moz-chrome-interactive 1925 466
moz-app-visually-complete 3391 458
moz-content-interactive 3391 459
moz-app-loaded 5565 472
settings Base newapi Δ
------------------------- ---- ------ ----
moz-chrome-dom-loaded 1925 1789 -135
moz-chrome-interactive 1925 1790 -135
moz-app-visually-complete 3391 3625 234
moz-content-interactive 3391 3626 234
moz-app-loaded 5565 6028 463
settings Base immutable Δ
------------------------- ---- --------- ---
moz-chrome-dom-loaded 1925 1927 2
moz-chrome-interactive 1925 1927 2
moz-app-visually-complete 3391 3517 126
moz-content-interactive 3391 3517 126
moz-app-loaded 5565 5886 321
I'm not sure yet why immutable scores slower on moz-chrome-* events,
but appears to perform better than newapi on others. I'll continue to
investigate the performance.
-stas
--
@stas
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
