Include languages into manifest #208

krampstudio · 2014-05-27T12:22:06Z

It would be also nice to be able to know which languages the web app supports.

anssiko · 2014-05-27T12:44:46Z

Could you elaborate the use case a bit? The lang attribute (as defined by the HTML spec) can be used on any HTML element. Commonly this is applied to the html element (e.g. <html lang="en">).

krampstudio · 2014-05-27T12:56:10Z

One of the use case could be a multilingual webapp, with an entry point by language. The user agents could load the entry point regarding the language of the user.

{
    "languages" : {
         "en" : {
              "url"  : "http://domain.tld/en/index.html"
         },
         "fr" : {
              "url"  : "http://domain.tld/fr/index.html"
         }
    }
}

anssiko · 2014-05-27T13:25:21Z

@krampstudio Thanks, that clarifies the use case.

@marcoscaceres Perhaps you could share your learnings with the Widgets language tag?

marcoscaceres · 2014-05-27T16:20:39Z

I think we want to see how people solve this in the wild first. Most sites allow the user to set the language using the apps UI. Like this:

And this:

So, changing language, one can just change the <link> language:

function updateLang(langCode){
    document.querySelector("link[rel=manifest]").href = "manifest.php?lang=" + langCode;
    document.querySelector("link[rel=manifest]").hreflang = langCode;
}

Or, "manifest_" + langCode +".json" or whatever. Including every language in the manifest file might make it bloated and hard to maintain.

marcoscaceres · 2014-05-27T16:27:12Z

Marking as feature request - just a note that the original spec included a locales member, a default-locale member, and text about i18n.

marcoscaceres · 2014-05-28T13:06:40Z

A great little alternative i18n model over in #211. I like it! 👍

marcoscaceres · 2014-06-09T22:17:24Z

Closing this bug in favor or #211.

stasm · 2014-07-23T09:25:23Z

As I mentioned in #211 (link to comment), a canonical list of available languages is great to have for client-side language negotiation.

In order to negotiate languages, three pieces of information are needed: the list of all languages the app is available in, the list of languages the user speaks, in order of preference, and the default language of the app in case there is no intersection between the first two sets.

A dedicated property could look like this:

{
    "name": "Foo",
    "default_locale": "en-US",
    "locales": [ "fr", "pl" ]
}

The default locale can but it doesn't have to be specified in the locales key.

In certain scenarios it would be useful if the array could be changed to a dict specifying versions of available languages. Together with @zbraniecki, I have been prototyping a client-side service in Gecko to provide localizations externally to the app. The goal is to be able to add more languages and update localizations independent of the app. We call it the language package service. Having the available languages versioned allows the service to be smart about localizations it can provide. If no versions are given (like in the example above), the service will assume that all localizations bundled with the app are up to date.

In the following example, French is up-to-date with the version of the app (it has all the new strings introduced in this version). -4 denotes the revision of the translation. Polish, however, has not been updated since version 1.8.4. This information could be used by a language package service in the client—the service would check if it has a newer version of Polish available and use it instead of the localization bundled with the app.

{
    "name": "Foo",
    "version": "2.0.3",
    "default_locale": "en-US",
    "locales": {
        "fr": "2.0.3-4",
        "pl": "1.8.4-7"
    }
}

An alternative notation could look like the following (I'm not sure how stable default_locale already is and if it can be changed at this point):

{
    "name": "Foo",
    "version": "2.0.3",
    "languages": {
        "default": "en-US",
        "available": {
            "fr": "2.0.3-4",
            "pl": "1.8.4-7"
        }
    }
}

nuxodin · 2014-09-20T00:49:10Z

Why not only "languages"? the order of the langeages-array is given so the first is the default-language:

{
    "name": "Foo",
    "version": "2.0.3",
    "languages": ["en","fr","it"]
}

simple and easy

marcoscaceres · 2014-09-23T20:35:23Z

If the language negotiation is going to be done client-side by JS, then it doesn't belong in the manifest. The things in the manifest should only be used at the UA level, not at the JS level (though the effects of the manifest are then reflected in the browsing environment through JS or CSS as appropriate).

chaals · 2014-10-27T13:58:45Z

using the ordering so the first is the default seems reasonable in practice.

if there are different versions for different languages, we should apply the same model (as in issue #211 ) to the version property as to other stuff, no?

e.g.
{ version: {
"ru" : "3.2.2",
"fr" : "2.0.3",
"pl" : "1.8.4",
"en" : "2.0.2" } }

(using the implication that Russian is the default version)

chaals · 2014-10-27T14:00:08Z

Hmm. Do we need a property for languages, or can we just extract that from the manifest by looking at what it mentions and taking the union?

(We also don't have, and probably don't need, a way of saying whether a given localisation is complete.)

stasm · 2014-10-27T14:11:20Z

@marcoscaceres You're right, I used a mental shortcut. What I meant was that the information about available languages is useful for client-side language negotiation. The W3C manifest could be—in my mind—a good place to store this information. It would need to be parsed and exposed to client-side JS by the UA in form of an API, e.g. document.languages.available and document.languages.default.

Such document.languages API could use the browser's getW3CManifest method proposed in bug 1077620. I'm not sure, however, if I should assume that the plan is to automatically fetch the manifest for every webpage. It would be helpful to have the information about the languages available right away, when the document is being parsed, so that the client-side code can negotiate languages ASAP and display the right translations to the user.

One way to get around this would be to allow for certain information to be inlined into the document's source HTML, much like CSS allows for inline style definitions. Currently in Firefox OS, for instance, we found that it was good for performance to inline the languages data in form of <meta> elements.

Do you know if there are any plans to provide any kind of inlining mechanism for W3C manifests?

stasm · 2014-10-27T15:15:00Z

(document.languages.available is just an example; I think a more likely API design would be a Promise-returning function which would only start downloading the manifest when called.)

zbraniecki · 2014-10-27T15:34:31Z

@chaals Unfortunately, object keys are not guaranteed to have their keys order preserved. We need a separate key for that.

marcoscaceres · 2014-11-03T20:16:33Z

@stasm the problem is that there is no guarantee that the manifest will be downloaded at all - ever. It's a low priority resource and some user agents may opt to not download it until it is actually needed, such as when the user takes explicit action to "install" the application (thus it's deliberately unreliable). Even if we include localized content (e.g., name), that content would only be applicable at install time. It also puts the developer into a race condition, having to wait for the manifest to be downloaded an applied: even in the best case, this happens after the load event has fired (again, by design).

For this reason, this resource is not appropriate, IMO, to use for localizing applications. A better approach would be to use a library and dynamically d/l localized strings and content as needed: or just include the relevant information inline via script tags (or XHR'ing a different JSON document specifically for localization purposes).

Does that make sense?

chaals · 2014-11-04T18:29:31Z

reply@
notifications@

D'uh. Right :S

27.10.2014, 16:34, "Zibi Braniecki" notifications@github.com:

@chaals Unfortunately, object keys are not guaranteed to have their keys order preserved. We need a separate key for that.

—
Reply to this email directly or view it on GitHub.

Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com

stasm · 2014-11-08T02:03:55Z

@marcoscaceres Thank you for providing more context about when the manifest could be downloaded—and if at all. I can see now why a user-land localization library should not try to get rely the information about the available and the default languages directly from the manifest.

There is a use-case which I think still justifies storing this information in the manifest instead of in a separate resource which would be XHR'ed by the localization library. We are currently investigating language packages (or language bundles) for Firefox OS apps which would allow extending language coverage of other apps. During an installation of an app, the information about the available languages carried in the manifest would be stored by the user agent. Then, a language bundle could modify that saved information by adding more languages to the list. A user-land localization library would then need an API exposed by the user agent to retrieve the list of all available languages for a given app. (In Firefox OS, that could be a method of the mozApps API). You can find more information in the spec draft that I'm working on.

PaulKinlan · 2014-11-11T13:18:46Z

I am just writing some good practices based on the API surface area that we ahve today (cc @mounirlamouri and @marcosc) and I was thinking: Do we need to actually do anything at all?

As a developer I have full control over what is returned to the UA from my server. I can look at the languages accepted in the fetch for the manifest, and return a localized one if needs be, I could also pass in a query string value if I really really wanted to. We can also mitigate some of the caching issues when the user changes system language by Vary: Accept-Language

The open question is, if keeping the original language on the app (such as when it is on the homescreen) is a massive problem if the user has changed languages after installing?

My experience managing languages in Chrome Apps makes me want to avoid adding any complexity or bloat to the manifest and I feel that we have a "reasonable" story as of today for serving the user the correct manifest at time of install.

kenchris · 2014-11-11T14:23:10Z

I think the web platform already get a notification when the system language changes. Potentially we could treat that as a good time to mark the manifest info as dirty?

raucao · 2014-11-11T15:23:05Z

I feel that we have a "reasonable" story as of today for serving the user the correct manifest at time of install.

That might be the case, if manifests would be used and accessed only at the time of installation. What about other use cases though, like e.g. app catalogs, app search results, etc.? For these it might be really useful to be able to index what languages an app supports.

marcoscaceres · 2014-11-11T17:16:58Z

@kenchris wrote:

I think the web platform already get a notification when the system language changes.

There is navigator.languages and body.onlanguageschange. Of course, this depends on the page being opened or a SW set up to listen for the change event. It will require some gymnastics.

Potentially we could treat that as a good time to mark the manifest info as dirty?

You don't need to treat it as dirty. One can then update link's href like I proposed here: #208 (comment)

I'd like to echo what @PaulKinlan + I think we need to get a bit of implementation experience to see what issues come up as this gets rolled out over the next year. @skddc, I assume indexing of supported languages would work exactly as it does today: by actually providing the app in those languages, rather than claiming an applications supports some particular set of language (i.e., crawlers index and make decisions on actual content, not on metadata claims which are easy to forge or get wrong).

marcoscaceres · 2015-01-09T03:52:22Z

I'd like to close this issue to allow us to roll out an initial version of the spec. We can then begin gathering feedback and seeing how people adapt manifests to different languages in the wild. We have a good set of possible solutions, which we can easily add to the spec and implementations once we see what happens on the web.

marcoscaceres added the Feature Request label May 27, 2014

marcoscaceres added this to the Future version milestone May 27, 2014

marcoscaceres modified the milestone: Future version May 27, 2014

jasnell mentioned this issue May 28, 2014

Allow name to be a String or Language Map #211

Closed

marcoscaceres mentioned this issue May 30, 2014

What is the expectation re manifest "localization"? #212

Closed

marcoscaceres added V2 labels May 30, 2014

marcoscaceres closed this as completed Jun 9, 2014

marcoscaceres reopened this Jul 23, 2014

marcoscaceres removed the i18n label Nov 5, 2014

marcoscaceres added P3 and removed P2 labels Nov 18, 2014

marcoscaceres closed this as completed Jan 9, 2015

fallaciousreasoning mentioned this issue Feb 6, 2020

i18n support #848

Closed

xfq mentioned this issue Jun 2, 2020

i18n: Multiple manifest links with different hreflang? #892

Open

aarongustafson mentioned this issue Mar 30, 2021

Add optional translations member #676

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Include languages into manifest #208

Include languages into manifest #208

krampstudio commented May 27, 2014

anssiko commented May 27, 2014

krampstudio commented May 27, 2014

anssiko commented May 27, 2014

marcoscaceres commented May 27, 2014

marcoscaceres commented May 27, 2014

marcoscaceres commented May 28, 2014

marcoscaceres commented Jun 9, 2014

stasm commented Jul 23, 2014

nuxodin commented Sep 20, 2014

marcoscaceres commented Sep 23, 2014

chaals commented Oct 27, 2014

chaals commented Oct 27, 2014

stasm commented Oct 27, 2014

stasm commented Oct 27, 2014

zbraniecki commented Oct 27, 2014

marcoscaceres commented Nov 3, 2014

chaals commented Nov 4, 2014

stasm commented Nov 8, 2014

PaulKinlan commented Nov 11, 2014

kenchris commented Nov 11, 2014

raucao commented Nov 11, 2014

marcoscaceres commented Nov 11, 2014

marcoscaceres commented Jan 9, 2015

Include languages into manifest #208

Include languages into manifest #208

Comments

krampstudio commented May 27, 2014

anssiko commented May 27, 2014

krampstudio commented May 27, 2014

anssiko commented May 27, 2014

marcoscaceres commented May 27, 2014

marcoscaceres commented May 27, 2014

marcoscaceres commented May 28, 2014

marcoscaceres commented Jun 9, 2014

stasm commented Jul 23, 2014

nuxodin commented Sep 20, 2014

marcoscaceres commented Sep 23, 2014

chaals commented Oct 27, 2014

chaals commented Oct 27, 2014

stasm commented Oct 27, 2014

stasm commented Oct 27, 2014

zbraniecki commented Oct 27, 2014

marcoscaceres commented Nov 3, 2014

chaals commented Nov 4, 2014

stasm commented Nov 8, 2014

PaulKinlan commented Nov 11, 2014

kenchris commented Nov 11, 2014

raucao commented Nov 11, 2014

marcoscaceres commented Nov 11, 2014

marcoscaceres commented Jan 9, 2015