Feedback on Browser Extensions i18n

[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.

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.

This would allow us to start using FTL in Web Extensions without
reinventing the whole workflow and the loading story.

What do you think about this meet-them-half-way approach?

Staś

[zbran...@mozilla.com]

On Thursday, August 17, 2017 at 9:04:23 AM UTC-7, Staś Małolepszy wrote:
> 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.

Good point.

I believe it's worth considering fallback enabled approach to be at least as useful as sync, for example when naming things.
I'd like to consider it to avoid ending with "get" and "getAsync" if "get" and "async will become the most common ones in the future.

> 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.

I don't believe we have to push for API compatibility. The standardization process is a perfect place to revisit the API decisions with an open mind and willingness to break things.
Whatever ends up getting standardized will be different from webextensions API as of today and will require changes to extensions.
We shouldn't change things without purpose, but I don't think we have to sacrifice the API quality for compatibility

> 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.
>
> This would allow us to start using FTL in Web Extensions without
> reinventing the whole workflow and the loading story.
>
> What do you think about this meet-them-half-way approach?

I'm for it. This sounds good.

The only thing is the function name. I'd like to think about the name for the sync which plays well with us potentially adding fallback-enabled async one later.

so, if we go for `getFormattedMessage` for the sync, then would the async be `formatMessage`? Or should we aim for `formatMessageSync` and `formatMessage`?

zb.

[Axel Hecht]

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