1580816 - Allow built-in extensions to access language packs

Status: RESOLVED FIXED

(Core :: Internationalization, enhancement)

Description

[Andrew Swan [:aswan]]

As part of transforming things like screenshots and webcompat-reporter into built-in extensions, we can stop shipping their translations as json files in the extension and just use strings from the app or language pack. This can be done fairly simply by exposing our existing document.l10n interface to privileged extensions.

Comment 1

[Andrew Swan [:aswan]]

Attachment: Bug 1580816 Part 1: Add isPrivileged to WebExtensionPolicy

Comment 2

[Andrew Swan [:aswan]]

Attachment: Bug 1580816 Part 2: Expose document.l10n to privileged extensions

Comment 3

[Andrew Swan [:aswan]]

On phabricator, zombie commented:

I couldn't find context for the decision to expose internal Fluent DOM api to (system) extensions, did we give up the public extension api?

Moving the conversation here since I think discussion about the context and motivation for the bug is more appropriate here than on phabricator.

I assume by "public extension api" you mean making the existing browser.i18n.* interface work with fluent? I think there's a choice between doing that and proceeding with the fluent dom api (document.l10n etc). I don't think anybody has made an explicit decision about which of those options to pursue, but it looks like some of our system addons are already written in a way that anticipates document.l10n, for instance:
https://searchfox.org/mozilla-central/rev/878bbf3cb8897a208454df27535f3522ab482cf2/browser/extensions/screenshots/selector/ui.js#277-286
https://searchfox.org/mozilla-central/rev/878bbf3cb8897a208454df27535f3522ab482cf2/browser/extensions/webcompat/about-compat/aboutCompat.html#16,20,26

(actually, upon looking closer, the webcompat case is a document that already has access to the fluent dom api so wouldn't be affected by this patch, but I think its still a useful data point when considering what direction we want to take)

Anyway, my goal with this patch was just to help get screenshots onto fluent. Since the dom api already exists and screenshots essentially polyfills that api but using browser.i18n, I think that with this patch in place, the incremental change to screenshots will be small (maybe even a net reduction in total code!). If we later decide to expose fluent to extensions in a different way, I don't think we will have wasted any significant effort here...

Comment 4

[Axel Hecht [:Pike]]

I think that the document.l10n API is much more powerful than the browser.i18n ones. So I'd love for us to be able to use that.

I'm not convinced that we should try to use Fluent under the hood of browser.i18n.getMessage, in particular because that API only understands positional arguments, while Fluent only understands named arguments.

Are there existing examples on changes to extension APIs that would give us an idea how to reconcile such differences?

Comment 5

[Tomislav Jovanovic :zombie]

(In reply to Andrew Swan [:aswan] from comment #3)

I assume by "public extension api" you mean making the existing browser.i18n.* interface work with fluent? I think there's a choice between doing that and proceeding with the fluent dom api (document.l10n etc). I don't think anybody has made an explicit decision about which of those options to pursue,

Sort of, I meant adding a fluent-derived, more comprehensive localization api for (all) extensions, as I remember overhearing the plan at one point.

I don't have enough context to judge in what form we should be doing that, just wanted to ask if we have a plan here, and if this patch is skating at least in the direction of that puck (!).

Alternatively, are we planning to propose the document.l10n api for some web standards track? Otherwise, it feels weird we would be blindly adding an unprefixed DOM api without such plans.

(In reply to Axel Hecht [:Pike] from comment #4)

Are there existing examples on changes to extension APIs that would give us an idea how to reconcile such differences?

In this context, "changes" would most likely mean adding a new api -- not great unless we're also deprecating the old one, which we're unlikely to be able to do without some cooperation with the Chrome team. That's why I'm asking about plans to standardize any of this, in any shape or form.

Comment 6

[Andrew Swan [:aswan]]

(In reply to Tomislav Jovanovic :zombie from comment #5)

(In reply to Andrew Swan [:aswan] from comment #3)

I assume by "public extension api" you mean making the existing browser.i18n.* interface work with fluent? I think there's a choice between doing that and proceeding with the fluent dom api (document.l10n etc). I don't think anybody has made an explicit decision about which of those options to pursue,

Sort of, I meant adding a fluent-derived, more comprehensive localization api for (all) extensions, as I remember overhearing the plan at one point.

I don't have any idea about any such plans, but in what way is the existing api (document.l10n) insufficient?

I don't have enough context to judge in what form we should be doing that, just wanted to ask if we have a plan here, and if this patch is skating at least in the direction of that puck (!).

I'm not away of any such plans so I propose that we make "expose document.l10n to all extensions" into the plan of record. Maybe the extensions team could discuss this in their weekly meeting tomorrow? However, to stretch your analogy, I think the changes here are small enough that even if the puck lies in some different direction, we're merely gliding slightly toward it, not skating hard in the wrong direction.

Comment 7

[Tomislav Jovanovic :zombie]

(In reply to Andrew Swan [:aswan] from comment #6)

I don't have any idea about any such plans, but in what way is the existing api (document.l10n) insufficient?

Pretty sure you and Kris were talking with Zibi about it at an all hands a year or two ago (way before document.l10n was a thing).

I'm not away of any such plans so I propose that we make "expose document.l10n to all extensions" into the plan of record. Maybe the extensions team could discuss this in their weekly meeting tomorrow? However, to stretch your analogy, I think the changes here are small enough that even if the puck lies in some different direction, we're merely gliding slightly toward it, not skating hard in the wrong direction.

I have nothing against document.l10n being that plan, except that perhaps it may not have been designed with extensions in mind, and the WE team didn't have a chance to provide feedback before the api was already "done".

Zibi, perhaps you can give more context here? Is the document.l10n api considered "done"? Are there plans for some standards track? Have you considered other users, or if not, can you give some thought about suitability for localizing (non-mozilla) extensions?

(also tagging Philipp in case he has some thoughts from public api side)

Comment 8

[Zibi Braniecki [:zbraniecki][:gandalf]]

Is the document.l10n api considered "done"?

No. We're still working on the Fluent DOM API (which document.l10n exposes) and I would not call it "done".

Are there plans for some standards track?

Vague. We do work on Fluent APIs with an intention of proposing them for standardization via Unicode, ECMA402 and possibly WebL10n API.
We do not have resources for that now, and we don't have a strong driver to push yet.

Have you considered other users, or if not, can you give some thought about suitability for localizing (non-mozilla) extensions?

document.l10n - or DocumentL10n [0] +DOMLocalization [1] WebIDL is intended to localize documents and DOM, respectively. It doesn't really matter where the document/DOM is from. If it's in WebExtension it will work all the same.

For non DOM localization, we provide a Localization WebIDL [2] which can be instantiated in a JS context.

The combination of those should work for Web Extensions, but my understanding of WE is too shallow to make any recommendations or evaluate the feasibility here.

[0] https://searchfox.org/mozilla-central/source/dom/chrome-webidl/DocumentL10n.webidl
[1] https://searchfox.org/mozilla-central/source/dom/chrome-webidl/DOMLocalization.webidl
[2] https://searchfox.org/mozilla-central/source/dom/chrome-webidl/Localization.webidl

Comment 9

[Tomislav Jovanovic :zombie]

Thanks for the info, it seems this is all sort of in line with something we would want for extensions, though perhaps not fully ready yest. That makes it a good candidate to expose to system addons in the short run, to have the opportunity to better understand it and more formally review it before making it a public api.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/93caf5f50768
Part 1: Add isPrivileged to WebExtensionPolicy r=zombie

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7038a8280dd1
Part 2: Expose document.l10n to privileged extensions r=mossop

Comment 12

[Raul Gurzau (:RaulG)]

https://hg.mozilla.org/mozilla-central/rev/93caf5f50768

Comment 13

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/7038a8280dd1

Comment 14

[Philipp Kewisch [:Fallen][📱📆]]

Thanks for the tag zombie, I've added this and the meta bug to my list for prioritization. If someone from the l10n team wants to chat about this please do get in touch, I would like to make sure we add this to our planning cycle instead of doing it on the side.