Localising a PWA web manifest

Question

Is there a way in which a web manifest can be localised? i.e. having multiple translations of name, description etc...

I have thought of a couple of potential solutions but they each have pretty big drawbacks...

Potential Solution 1 (preferred but not sure if it will work)

Dependant on the locale in the url (example.com/en/foo), load the relative manifest.

For example:

• For example.com/en/foo, load example.com/en/manifest.json
• For example.com/jp/foo, load example.com/jp/manifest.json

Drawbacks

• I don't believe this will actually work as there can only be one manifest per website (as far as I am aware), and I am fairly certain it needs to be in the root
• Even if this is possible, given my application is a statically hosted SPA, I am not entirely sure how I would go about implementing it i.e. I can't dynamically update the link to the manifest before the manifest is loaded by the browser. Maybe I can load the manifest relative to the URI but not 100% sure this will work

Potential Solution 2

Host multiple versions of the PWA (either subdomain or TLD)... For example:

• en.example.com/example.com
• jp.example.com/example.jp
• etc...

Given the manifest is generated by the build process, this would actually be very easy to implement by adding multiple deploy steps to the pipelines. I would then use the environment variables for each deployment to determine the text to be inserted into the manifest.

Drawbacks

• Switching language of the app is not possible (this is a pretty key feature for the client)
• Regardless of how 'easy' it is to implement, it simply doesn't seem right

Anaemic

Answer 1

On the W3C document about the web manifest, I found the following:

It is expected that authors will localize the content of a manifest by using one of the following options:

• Dynamically setting the language: This can include, for instance, asking the end-user what their preferred language is and dynamically adding or replacing the manifest link relationship to the document based on that language preference (e.g., using a URL like "manifest.php?lang=fr").
• Using content-negotiation, or geotargeting, etc. on the server: The server that hosts the web application could attempt to predetermine the end-user's language by using geotargeting or by using content negotiation (e.g., using [RFC7540]'s "Accept-Language" header, or even a custom HTTP header).

This though says what should be done, but not exactly how.

There is currently an open requests about it on Github. Specifically this link argues with the suggestion on W3C site.

I will update the answer with more details as soon as I gather more information.

Google provide a more practical guide to localize the manifest file and maybe can be used as guide for the web manifest.

---

UPDATE

Could you create a small script for your index.html?

You do not need php, but simply Vanilla JS (if you have control over the index.html file) and load a specific manifest file according to the user locale.

<!-- If English is detected, the script will load this into the page -->
<link rel="manifest" href="/path.../en.manifest.json">

<!-- If French is detected, the script will load this instead -->
<link rel="manifest" href="/path.../fr.manifest.json">

Thump

Thank you Francesco, however, I read this documentation and unfortunately it doesn't solve my issue. The PWA I am constructing is static i.e. no backend (can't use PHP), and the other suggested method by the W3C is actually considered really bad practice... I am surprised they are advising it... The solution by Google is only relevant to the Google Play store and does not take into consideration that the app might be installed directly from the browser. Generating a localised manifest is easy, the issue is telling the browser which one to load before it loads the default one... – Anaemic

For instance, if a visitor goes to example.com, my app will redirect the user to example.com/en (using JavaScript). So even if I could load a manifest relative to en, it would be too late because the manifest will have already loaded by the time it redirects the user. +1 for the effort :-D – Anaemic

No worries, I find a very interesting topic. I updated the answer and I will search further. – Thump

Of course, I have built the entire project from scratch so can control any asset. However, if JS is going to update the DOM then this means that the page will have already loaded, thus the manifest will have already loaded and I don't think it can be 'updated'. That said, I haven't actually tried. This was an idea I had before but I didn't think it would work... – Anaemic

I might sound dumb, but is it possible to only link the manifest after the page has loaded, read the user's language setting, then dynamically load the correct manifest.webmanifest? – Unwatched

Answer 2

I definitely wouldn't recommend having multiple static app manifest files (DRY, etc).

Using different URLs for localized manifests is generally considered bad practice. Browsers will see different manifest URLs and consider them unique PWAs (although with the new id property, it might be possible to overcome this today).

Counterintuitively, the best way to proceed with that method would be to have all language versions share the same scope. So a user wouldn't be prompted to install your PWA again if they switch languages.

My implementation at Progressier detects the language server-side using the accept-language header. If the preferred language is one for which my user has a localized version, then it will use that version and dynamically generate the app manifest JSON accordingly. It currently works with the following manifest parameters: name, short_name, description, start_url, screenshots

The advantage of that method is that the URL of the manifest never changes. The drawback is that it's harder to force a specific language to be used programmatically — it just follows the user's language preferences (which isn't a bad thing per se, if you ask me).

However, if that's an important requirement, a possible solution would be to overwrite the accept-language header when the fetch request for the manifest transits through the service worker.

Chipman