Language pack support for fluent in gecko

RESOLVED FIXED

Status

defect
RESOLVED FIXED
3 years ago
10 months ago

People

(Reporter: Pike, Unassigned)

Tracking

(Blocks 1 bug)

Details

(Whiteboard: [gecko-l20n])

(Reporter)

Description

3 years ago
We want support for l20n in language packs.

We'll need a good place to call into L10nRegistry.registerSource, http://hg.mozilla.org/projects/larch/file/tip/toolkit/modules/L10nRegistry.jsm#l167.

Probably also need an API to undo that on addon disabling.

CCing rhelmer and Standard8 to see if they find the golden spot in the add-on install code flow where we'd want to do that. So far, we're all kinda puzzled on how this works for chrome.manifest addons.

Status quo of our build process is that our files are in the xpi, in /localizations/AB_CD and /browser/localizations/AB_CD.

There are no entries to any of the control files like install.rdf, bootstrap.js, or chrome.manifest.

We shouldn't do chrome.manifest, though, that much I know, 'cause the files we have shouldn't be available through the chrome registry.
Blocks: 1291693
Context:

We're introducing a new registry for l10n resources that will avoid chrome registry. Over time we will want to deprecate our use of chrome registry for l10n.

Our registry currently is using XHR to load resource:/// files from toolkit and browser, and we have a mechanism that allows us to add new, so called, 'sources'.

Each langpack will be a source and when we need a resource, we'll want to know if that resource is available in the langpack.

So, the way I see our needs for L10nRegistry:

 - we need a way to ask Gecko from L10nRegistry at startup which langpacks are currently installed in which versions
 - we need a way for L10nRegistry to learn that a new langpack has been installed
 - we need a way for L10nRegistry to learn that a langpack has been uninstalled

Eventually:
 - we'll need a way for L10nRegistry to learn what langpacks are available in which versions
 - we'll need a way to trigger langpack download/installation

In terms of what metadata we will want to have it is:

 - languages in the langpack (there may be more than one)
 - version of each language (based on the timestamp of the commit based on which the langpack has been built)
 - path to the resources in the langpack

I'm not very familiar with how addons work, so I'm not sure how such path will look like. I know that when we look for toolkit resources we do "resource:///gre/localization/{locale}/*".

NI'ing people :pike pointed as potential sources of knowledge for us.
Flags: needinfo?(standard8)
Flags: needinfo?(rhelmer)
I'm not at all familiar with the add-on code. If Rob can't help, then probably your best bet is Dave Townsend or Benjamin Smedberg.
Flags: needinfo?(standard8)
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #1)
> Context:
> 
> We're introducing a new registry for l10n resources that will avoid chrome
> registry. Over time we will want to deprecate our use of chrome registry for
> l10n.
> 
> Our registry currently is using XHR to load resource:/// files from toolkit
> and browser, and we have a mechanism that allows us to add new, so called,
> 'sources'.
> 
> Each langpack will be a source and when we need a resource, we'll want to
> know if that resource is available in the langpack.
> 
> So, the way I see our needs for L10nRegistry:
> 
>  - we need a way to ask Gecko from L10nRegistry at startup which langpacks
> are currently installed in which versions
>  - we need a way for L10nRegistry to learn that a new langpack has been
> installed
>  - we need a way for L10nRegistry to learn that a langpack has been
> uninstalled
> 
> Eventually:
>  - we'll need a way for L10nRegistry to learn what langpacks are available
> in which versions
>  - we'll need a way to trigger langpack download/installation
> 
> In terms of what metadata we will want to have it is:
> 
>  - languages in the langpack (there may be more than one)
>  - version of each language (based on the timestamp of the commit based on
> which the langpack has been built)
>  - path to the resources in the langpack
> 
> I'm not very familiar with how addons work, so I'm not sure how such path
> will look like. I know that when we look for toolkit resources we do
> "resource:///gre/localization/{locale}/*".
> 
> NI'ing people :pike pointed as potential sources of knowledge for us.

Sorry for the delay responding to your needinfo - did you get the answers you need in IRC with Mossop and myself the other day?
Flags: needinfo?(rhelmer) → needinfo?(l10n)
Duplicate of this bug: 1335517
(Reporter)

Comment 5

2 years ago
(In reply to Robert Helmer [:rhelmer] from comment #3)
> Sorry for the delay responding to your needinfo - did you get the answers
> you need in IRC with Mossop and myself the other day?

Redirecting to gandalf.
Flags: needinfo?(l10n) → needinfo?(gandalf)
I'll have to look at it more this week before I answer.

Also, here's the design doc for how we did it for FxOS: https://github.com/stasm/spec/blob/master/webapp-langpacks.markdown
No longer blocks: 1332207
Depends on: 1332207
No longer blocks: 1280688
No longer blocks: 1333980
Depends on: 1347802
Flags: needinfo?(gandalf)
No longer blocks: 1365426
No longer depends on: 1347802, 1347803
Is there still work to do on this bug? Also, should it be renamed (l20n -> Fluent) to avoid confusion?
Flags: needinfo?(l10n)
(Reporter)

Comment 8

10 months ago
Yes, this is done.
Status: NEW → RESOLVED
Last Resolved: 10 months ago
Flags: needinfo?(l10n)
Resolution: --- → FIXED
Summary: Language pack support for l20n in gecko → Language pack support for fluent in gecko
You need to log in before you can comment on or make changes to this bug.