Am 17.08.17 um 18:03 schrieb Staś Małolepszy:
Zibi opened up an issue in the Browser Extensions spec repo:
https://github.com/browserext/browserext/issues/54
Before I comment there, I'd like to have a discussion here to align
our views on the subject.
Zibi's message makes it sound like Project Fluent's paradigm is async.
The relevant quote is:
In the paradigm we propose, getMessage should not be a sync operation. Client
side localization may use fallbacks in which case they should be loaded lazily
and that in turn means that the API should be async.
I disagree. There's nothing in Project Fluent that requires or forces
async. Moreover I don't think async should be an explicit goal for us.
Fallback messages may be procured on build time or they may be loaded
synchronously or they can be ignored/replaced by the identifier.
I think we should have strong opinions on fallback, with the full
richness of l20n. Per-string fallback, with full knowledge of which
language a string is supposed to be in, etc.
Having sync IO might not be all that bad in webextensions, though, as
they're in their own process anyway, right?
The real shortcoming of i18n.getMessage as I see it is that it doesn't
allow any form of branching. No plurals, no genders. Even the fact
that it uses positional arguments is probably OK. Not ideal, but
acceptable.
Given how well implemented the i18n API has become across modern
browsers, I'd like to think how we can improve the existing API within
the constraints of the current, sync paradigm. The existing API solved
a number of challenges: translation loading, CSS localization, and
manifest localization to name a few.
Perhaps there's an avenue here for us to consider: introduce a sync
sister-method called getFormattedMessage(id, namedArgs) which uses the
same logic for translation loading but uses messages.ftl files rather
than message.json? In CSS and manifest files, the __FTL_ prefix could
be used similar to the current __MSG_ one.
What context would this use? Also, do we need to provide different hooks
for ftl vs json, or could we just try both?
This would allow us to start using FTL in Web Extensions without
reinventing the whole workflow and the loading story.
I'm not sure we should forgo both explicit contexts and declarative use
of fluent/l20n.
What do you think about this meet-them-half-way approach?
I'd prefer an opinionated approach, with a clear end goal. I think the
current i18n api is already a "meeth the half way" thing, with "works
for me" things added to them (bet the CSS stuff got added that way).
Meeting that half way might end up nowhere.
Axel
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
