Quoting Axel Hecht (2014-09-19 14:26:28)
> On 9/18/14 8:57 PM, Staś Małolepszy wrote:
> > The Env API: Do we need env.register?
> > =====================================
> >
> > The initialization process of an env can be described in three stages:
> >
> > 1. create an Env instance:
> >
> > var env = new Env('http://example.com');
> >
> > 2. register the available and the default languages taken from
> > a manifest:
> >
> > env.register(manifest).then(…);
> >
> > This step is async because in the future we will want to query the
> > language package service about any additional languages available
> > for this app, or updates to the existing ones.
>
> These two seem to have a very narrow focus on gaia-style web apps. It'd
> be good to understand how these would work in plain-websites, or even
> server-side js.
The vernacular might be Gaia-inspired, but this should work the same
for regular websites and server-side. The manifest is just a JSON
describing the available and the default languages, with their
versions.
Take a look at the tests, which are run in node:
https://github.com/stasm/l20n.js/blob/newapi/tests/lib/env/langs_test.js
https://github.com/stasm/l20n.js/blob/immutable/tests/lib/env/langs_test.js
> > 3. negotiate the user's preferred languages and compute the list
> > of
> > supported languages:
> >
> > env.request(navigator.languages);
> >
> > This step can be sync if we're using our own langnego shim
> > (Intl.prioritizeLocales); or it could be forced to be async for a)
> > consistency with the rest of the API and b) future compatibility
> > with an asynchronous language negotiator (Worker thread, Settings
> > API etc.).
>
> This is the API where apps and web sites would hook in that want to
> manage their own language choice?
>
> Also, how would they trigger a runtime switch of language?
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.
> > Apart from the above actions, it should also be possible to create
> > new
> > contexts once we have an Env instance. Contexts should have access to
> > env's supported languages so that the correct resources can be fetched.
> >
> > var ctx = env.require(['res1.{locale}.l20n', 'res2.{locale}.l20n']);
> > ctx.get('foo').then(function(val) {
> > console.log(val);
> > });
>
> I'm not a big fan of single Array arguments, unless there's optional
> arguments involved.
Email #3 adds another argument.
> I'm wondering, which API names have you thrown out for require()?
> Mostly asking because it's such an overloaded term in JS already.
True. It used to be called getContext. I considered createContext to
emphasize the fact that there's no caching of contexts going on.
I chose the 'require' name to comply with my self-imposed prototyping
method: methods should describe what they do in one word.
> I think I prefer #3, too, also because it's not just a matter of
> calling methods in different order, but also one of calling methods
> multiple times with different arguments.
Good point!
Overall, I'm liking the "X or a promise" polymorphism; promises excel
at it and I think it makes the API cleaner.
-stas
--
@stas
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
