Add proper multilingual support for the manifest.json

Wouldn't this simply mean to make the config values translatable and add the config translation form for such values?
And then use these values for the different paths?

Anyway I'm still not sure how to handle manifest.jsons for such cases correctly in general. Perhaps we should take a look at large multilang websites providing manifest.jsons?

Great idea! No idea, why I didn't think of this...

But we should make clear to the user, that the translation of both "scope" and "start_url" needs to specify the website's language paths. As well as a few other config values. We should really carefully look over each config entry and check if and how a translated value could look like.

Yeah, I think this is an indeed complex and complicated issue we should handle with care. No quick shots.

Ok I did some researching and these are my thoughts on the config keys to translate:

Manifest Settings:

• site_name => Yes
• short_name => Yes
• description => Yes
• categories => Might eventually make sense, there is a list of known categories here: https://www.w3.org/TR/manifest-app-info/#categories-member, but users might want to add language specific categories? Lets further discuss this.
• start_url => Yes, translation could have the different site language prefixes (e.g. "/en" or "mypwa/de").
• scope => Yes, translation could have the different site language prefixes (e.g. "/en" or "mypwa/de").
• lang => Remove this config entirely.
• theme_color => No
• background_color => No
• display => No
• orientation => No
• default_image => No
• cross_origin => No

Service Worker Settings:

• urls_to_cache => Needs further discussion. Currently, these urls are already language prefixed through our serviceworker.js (specifically through "getLanguagePathPrefix()"). BUT It seems like the logic there won't do anything, if the response is prefixed with something like 'myApp/en', since it uses url.pathname.startsWith(`/${langcode}`) to specify the used langcode.
• urls_to_exclude => Needs further discussion, see above.
• offline_page => Yes, translation could have the different site language prefixes (e.g. "/en" or "mypwa/de").
• cache_version => No
• skip_waiting => No

At first look, what do you think about this @Anybody?

Re:

• categories No translation, as it's always EN (technical name)
• lang => Remove this config entirely. => I don't think so, as this might be important for the client. Perhaps we should return the Drupal language value by default, if no value entered, but allow to override the automatism by entering an overwrite string (translatable)?
• urls_to_cache => No (only makes things harder and the list can just be merged)
• urls_to_exclude => No (same as above)

Totally agree with the rest!

lang => Remove this config entirely. => I don't think so

I digress. "lang" isn't used anywhere in the module. But WAIT! This is really unusual... I just wanted to comment, that "lang" is NOT a valid manifest.json member, but it actually is! But for some reason it is only specified in https://www.w3.org/TR/appmanifest/#lang-member but not listed on the mdn page: https://developer.mozilla.org/en-US/docs/Web/Manifest. That is really weird... But I guess we should trust the w3c standard? But I am wondering, if this is even properly implemented for most modern browsers, if it isn't listed as a valid key in the mdn docs...

Furthermore, we should take a look at https://www.w3.org/TR/appmanifest/#dir-member, which is ALSO not listed on the mdn docs... need feedback on this.

I forgot we can use the asterisk inside "urls_to_cache", so I agree, "NO" would be better. BUT we should change the getLanguagePathPrefix() implementation.

Re #8 then I think for now, just make it optional and translatable, so the user can chose to leave it out. Perhaps also add an according descrption. We shouldn't get blocked by that confusing thing, I think. We can improve things later, if it's needed.

PS: But please add an example and link to https://www.w3.org/TR/appmanifest/#lang-member
otherwise it might be unclear which format is expected.

Re #8 then I think for now, just make it optional and translatable, so the user can chose to leave it out

There currently isn't a form element for 'lang' and the config entry isn't used. I'd say we remove it for now. We can reintroduce it later if needed.

All done. I am unsure, if we need to add functionality to the update hook, since a few of these configs were originally translatable.

Furthermore, do we need any description changes? What do you think @Anybody? Please review for now.

Nice, left some final comments.

Especially see #8 abd #9 I guess we had a misunderstanding there.

Re #13 no I think we can leave it as-is.

As just discussed, please also add "dir" with "ltr" as default.

It's just a simple select for the text direction (left to right vs. right to left). For most parts of the world it's ltr. Let's make it a simple select option.

All done, please review once again.

Not sure about not setting a default value for "dir", but not one for "lang", as they are really tidely coupled.

dir=ltr should be fine, I think. Let's take that one. Also makes sense, as it's a select. But yes, you can also leave it empty, as it's an optional setting anyway. Throw a dice ;)

Sorry, setting "auto" is correct. Just had a look into the specification!

@Grevil nice work! Just one last documentation fix!

All other things are RTBC, once tested manually!

Remove the unnecessary "fromUri" calls, please rereview!

Left a comment!

Furthermore, are'nt we missing the config_translation.yml → for the appropriate UI?

@Anybody, you are right!

missing target="_blank"

Unsure about implicitly using target="blank" here. The user can easily decide himself I think.

Never mind, the config_translation.yml already exists and I don't like the implicit "_blank" call, so setting this back to need review.

Explicit "_blank" call totally makes sense to external and especially doc URLs. Discarding the current tab for that is just bad UX. Please add it.

config_translation.yml already existed, nice indeed!

So just the _blank thing, then we're fine!

Done, please review!

Perfect! :)

Automatically closed - issue fixed for 2 weeks with no activity.