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.
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?
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.
I'm wondering, which API names have you thrown out for require()? Mostly
asking because it's such an overloaded term in JS already.
My first doubts are about step #2 and env.register. If we expose it as
a separete method, we open up ways to call it out of order. There are
three solutions to this:
- mantain a state of language registration and throw when env.request
and env.require are called before env.register,
- internally wait for env.register to complete when env.request or
env.require are called (e.g. listen to the
'availablelanguageschange' event or have a promise which fulfills
when the manifest is successfully registered,
- pass the manifest (or a promise resolving to the manifest) to the
Env constructor and not expose env.register as part of the API.
In my WIPs so far I went for the third solution which I think is
elegant: it simplifies the code and avoids hidden magic.
https://github.com/stasm/l20n.js/tree/newapi
The env objects are created like this:
var env = new Env('http://example.com', manifest);
'manifest' can be a JSON or a promise resolving to a JSON. A newly
created env has a 'registered' property which is a promise which
fulfills when the language registration (including fetching the
manifest and querying the langpack service) completes.
In my next email, I'll talk about supported languages and env.request.
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.
Axel
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
