Open
Bug 1177203
Opened 10 years ago
Updated 3 years ago
API for loading l10n resources
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
NEW
People
(Reporter: zbraniecki, Unassigned)
Details
Attachments
(1 obsolete file)
We're currently loading l10n resources for the document using client side l10n.js library.
It would be better if we could plug it into Gecko's document loading process alongside with CSS and JS resources.
The way it looks in a document right now:
<html>
<head>
<meta charset="utf-8">
<title data-l10n-id="title"></title>
<link href="style/main.css" rel="stylesheet" type="text/css"></link>
<link href="locales/example.{locale}.l20n" rel="localization"></link>
<script defer src="./js/main.js"></script>
</head>
</html>
Localization engine is a client side library right now, and we want to move it to platform in stages as pieces of the technology mature.
Resource loading is one of the simpler pieces and we believe it's ready to be standardized at least as a Gecko specific API.
We'd like Gecko to initialize the resource loading during document loading. It should be asynchronous and parallelized with style and JS.
That would remove some of the code that we have to manage manually in the library now, initialize resource loading earlier (and in turn result in faster startup) and put l10n resources more on par with other document resources like style and JS.
When the resources is loaded, we'd like it to be reported to a registered listener. For example it could look like this:
document.mozOnL10nResourceLoaded(function(resource) {
});
|
Reporter | |
Comment 1•10 years ago
|
||
Henri, Olli, what do you think about this?
Flags: needinfo?(hsivonen)
Flags: needinfo?(bugs)
|
||
Comment 2•10 years ago
|
||
I guess <link rel="prefetch" ...> doesn't really help here.
|
|
||
Comment 3•10 years ago
|
||
Flags: needinfo?(bugs)
|
|
||
Comment 4•10 years ago
|
||
Comment on attachment 8625995 [details] [diff] [review]
untested, but compiles
Wrong bug.
Attachment #8625995 -
Attachment is obsolete: true
|
||
Comment 5•10 years ago
|
||
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #0)
> document.mozOnL10nResourceLoaded(function(resource) {
> });
If the processing of the resource is scripted anyway, I take it that compared to XHR / fetch(), the feature here is really localization-unspecific:
Initiating and XHR-ish fetch declaratively so that it benefits from speculative parsing, etc.
Correct?
Anne, is something like that already being specced?
Flags: needinfo?(hsivonen) → needinfo?(annevk)
|
||
Comment 6•10 years ago
|
||
This seems very close to https://w3c.github.io/resource-hints/ indeed.
Have we done any kind of outreach to other browsers whether they are interested in standardizing this kind of technology?
Flags: needinfo?(annevk)
|
|
Reporter | |
Comment 7•10 years ago
|
||
(In reply to Henri Sivonen (:hsivonen) from comment #5)
> (In reply to Zibi Braniecki [:gandalf][:zibi] from comment #0)
> > document.mozOnL10nResourceLoaded(function(resource) {
> > });
>
> If the processing of the resource is scripted anyway, I take it that
> compared to XHR / fetch(), the feature here is really
> localization-unspecific:
It is scripted right now. L10n, that we'd like to standardize into WebL10n eventually, is a complex system that we're still developing. We feel fairly safe about some pieces (like this one), while the format of the resource itself is still not ready to be pushed to platform because we iterate over it.
> Initiating and XHR-ish fetch declaratively so that it benefits from
> speculative parsing, etc.
>
> Correct?
Yes. There's one other aspect here that I skipped - we'd like to move language negotiation to the platform as well. It is necessary to select which language resources to load. As you can see the URL for language resource is really an URL template and the locale code for it has to come from langneg.
The language negotiation step looks like this:
1) Engine reads two meta tags:
- <meta name="defaultLanguage" content="en-US">
- <meta name="availableLanguages" content="en-US, fr, de, it">
2) Engine uses a function called "prioritizeLocales" which works in a very similar way to ECMA 402's "LookupSupportedLocales". The proposal for it is here: http://wiki.ecmascript.org/doku.php?id=globalization:prioritizelocales
- availableLanguages comes from the meta tag
- defaultLanguage comes from the meta tag
- requestedLanguages comes from navigator.languages (optionally, if <meta name="requestedLanguages"> is present, we can use it instead - for scenarios where application wants to store user preferred locales.
prioritizeLocales returns a list of ordered available locales that best match user requested locales.
3) Then, the browser initializes downloading of the language resources using {locale: locales[0]}
At some point in the future, when l10n format will be more stable, we will want to standardize it and move it's parsing into platform as well, we just can't do this yet, so some of the hooks between platform and l10n.js may be temporary.
Also, if you have a preference to use different way to store defaultLanguage/availableLanguages instead of <meta> tag, we can use that. That's just what we use right now in the client library.
How does it sound? Should the language negotiation and l10n resource loading be discussed separately or because they are interdependent should I keep it both in this bug?
|
Assignee | |
Updated•7 years ago
|
Component: DOM → DOM: Core & HTML
|
||
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•