On Friday, June 10, 2016 at 10:37:04 AM UTC-7, Gijs Kruitbosch wrote:
> This async-ness will not be acceptable in all circumstances. As a
> somewhat random example: how would we localize the 'slow script' dialog,
> for which we have to pause script and then show the dialog?
Agree, there are exceptions, and we may have to provide sync version (which
will have limited functionality) for such cases.
For this particular case, the way we approached it in FxOS was to do something
like replacing:
window.alert(l10n.get("slowScriptTitle"));
with:
l10n.formatValue("slowScriptTitle").then(val => window.alert(val));
Would that not work?
> Another example: in docshell, some error page URLs are currently generated
> synchronously in some circumstances (invalid host/uris, for instance).
> Making such a location change asynchronous just because of localization
> is going to break a *lot* of assumptions, not to mention require
> rewriting a bunch of yucky docshell code that will then probably break
> some more assumptions...
Yay! :)
If you're saying that we're generating URLs with localized messages in them,
then I'd question to design...
But as I said, we may have to provide a compatibility layer where we'll have
sync variant for those scenarios and discourage it for new code.
> It's much easier to just say "we'll make
> everything async" when you have a greenfield project like b2g than to
> retrospectively jam it into 20 years of history (ie Gecko).
It probably is, but you don't want to know how much time it took me to
transition even the relatively young project from sync to async! ;)
> Not all JS and C++ code that will want to localize things has access to
> a document object, and for all consumers to have to create one just to
> use localization features would be cumbersome (and, as I understand it,
> would not work without also inserting all the stringbundle things you'd
> need). Please can we make sure that we have a pure-JS/C++ API that is
> usable without having to have a document? (Currently, you can create
> nsIStringBundle instances via XPCOM, and PluralForm can be used as a jsm
> but not from C++, which also already causes headaches.)
We'll definitely have pure JS code. We're going to land JSM code, and as I
said, Intl stuff (like PluralRules) will be available straight from
SpiderMonkey (Intl.PluralRules). Although in L20n world, as an engineer you
won't ever need to use PluralRules manually :)
For C++, we may wrap the JS API and expose it in C++, but we may also try to
migrate l10n in C++ up the layer and make C++ code carry l10nIds, and JS UI
code localize them.
> I'm quite worried some of this won't be workable. For instance, XUL
> panels make decisions about how big they need to be based on their
> contents. We'll need to ensure that the content in such panels is
> present and localized before attempting to show the panel. We can't just
> add the attributes, show the panel, and hope for the best. If we insert
> extra turns of the event loop in here because we're ending up waiting
> for localization, that'll make it harder to deal with state changes (I
> clicked this button twice, is the popup open or closed? etc. etc.)
That's a great point. As I said in my previous email I'd love a way to prevent
frame creation until JS init code is done.
We may also decide to move the MutationObserver part in Gecko to ContentSink,
or design an API that we'll plug into our DOM that will work better for us than
Mutation Observer.
So far MO works well and gives us the results we need.
> This is still problematic in terms of markup though. It's not uncommon
> to have 3 or more DTDs in a file, and I can just use an entity without
> asking what bundle it's from. Having to specify it for any "non-main"
> bundle would be problematic. Why can't we just fall back to using the
> other available bundles?
By default you will have all your "DTD"s in the "main" bundle, and we'll loop
over them to localize your elements. So that works the way you expect it.
On top of that, you'll be able to also specify more bundles with more source
files. That's where named ones come in.
Thanks,
zb.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
