i18n: No localization model; [I18N-ISSUE-412]

[kenchris]

Raised by Addison Philips (I18N-ISSUE-412)

http://www.w3.org/TR/2015/WD-appmanifest-20150212/

Having read the entire document, I can't find any mention of localizbility. There is no way to indicate in the manifest the language of any of the language bearing metadata (name, short_name, etc.) nor a way to indicate different language versions of external resources (such as paths to icons). This seems like a serious oversight in the design and is not consistent with other packaging schemes.

Please note that this was previously discussed on your mailing list in response to my note [1], with a number of helpful responses by Marcos Caceres and others, such as [2].

[1] https://lists.w3.org/Archives/Public/public-i18n-core/2015JanMar/0068.html
[2] https://lists.w3.org/Archives/Public/public-i18n-core/2015JanMar/0071.html

[marcoscaceres]

This should be handled by lang.

[dontcallmedom]

testing notification of I18N-WG-labeled issues

[r0b5t4]

Having read the documents linked from OP, I am still not quite satisfied. My concern is that the manifest contains locale-dependent records as well as -independent ones. Would you suggest to generate manifest files for all the languages in which e.g. the app name is translated into?

My use-case is the creation of installable packages from web apps, based on manifest information.

[marcoscaceres]

Having read the documents linked from OP, I am still not quite satisfied. My concern is that the manifest contains locale-dependent records as well as -independent ones. Would you suggest to generate manifest files for all the languages in which e.g. the app name is translated into?

Yes, that is the current suggestion. The assumption is a developer would do that on the server.

My use-case is the creation of installable packages from web apps, based on manifest information.

Packaged web applications have not traditionally been the target of this specification - hence the missing localization features.

Is that target for you Crosswalk + Cordova? If so, would it make sense to instead of the configuration document format of Cordova (it supports rich localization features both at the configuration file level, and using a particular directory structure).

[r0b5t4]

Related to Crosswalk, but not Cordova. I am a bit reluctant to have yet another (i18n supporting) format that I can generate the manifests from, this kind of metadata is exactly what I was hoping to use the manifest for as a canonical format in the first place.

Otherwise I might just something along the lines of
<prefix>_names: { lang: text } and
<prefix>_short_names: { lang: text }.

[marcoscaceres]

@kenchris, wdyt? worth reviving this?... it seems like a significant part of this work will be as a canonical format to target other platforms + packaged apps. Will be bit annoyed if we end up recreating W3C widgets tho.

[kenchris]

I think it is worth it, but let's only localize what actually makes sense to localize... like start_url might make sense, but icons might not (unless that is a strong use-case supported by existing app stores)

[marcoscaceres]

I don't think mix and match is an option. We tried that with widgets and it ended in sadness and confusion.

[aphillips]

@kenchris Actually, icons are often localized. Not as often as app titles, but it is not infrequent.

@marcoscaceres I don't know that it ended in sadness and confusion, but the model Widgets uses was somewhat complex (more so because there were actually TWO models--one in the configuration file and other that used directory structure)

I don't care for the "solution" of generating multiple manifests because there doesn't seem to be a mechanism in place for finding out about which manifests are available and selecting the "right" one for the job (aka "language negotiation")... and I note that in my day job I have apps that are localized into several languages and don't have a different start_url for each language.

[marcoscaceres]

@marcoscaceres I don't know that it ended in sadness and confusion, but the model Widgets uses was somewhat complex (more so because there were actually TWO models--one in the configuration file and other that used directory structure)

Oh, what I meant to say was that the "mix and matching" (some could be lolcalized, some could not) of the element localization model became confusing. Overall, I think the model was awesome. The mistake was just not making everything localizable. I also think the directory localization model was great.

I don't care for the "solution" of generating multiple manifests because there doesn't seem to be a mechanism in place for finding out about which manifests are available and selecting the "right" one for the job (aka "language negotiation")... and I note that in my day job I have apps that are localized into several languages and don't have a different start_url for each language.

Agree. This is also what I'm worried about. I'm working with Mozilla's content services team, who currently targets 26 languages with their products, and they also just localize using geoip on the server (not great, but good enough in most cases).

[marcoscaceres]

Closing as dup of #323