You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to properly reflect i18n nature of the application vite-pwa-plugin should support a multidimensional manifest object where each key will be related to the application locale:
Next I, as a developer, will be able able to dynamically point to different file based on the currently selected locale using useHeade composable updating the link
<!-- 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">
<!-- If Spanish is detected, the script will load this instead -->
<link rel="manifest" href="/path.../es.manifest.json">
Bonus point
Integrating the above switching with additional options that would define the locale strategy might also be a good idea. e.g. one of the options might be:
pwa: {
i18n: {
strategy: 'route'
}
}
this will assume the language detection should be handled based on the application route, which should also be a default option since this is the most common way for taking i18n on the web.
The text was updated successfully, but these errors were encountered:
Current behavior:
At the moment Nuxt PWA module supports a single-dimensional set of properties that only assumes 1 possible language for generated manifest.
How should it be
In order to properly reflect i18n nature of the application vite-pwa-plugin should support a multidimensional manifest object where each key will be related to the application locale:
Specifying manifest options in the above way should result in the generation of 3 manifest files:
Next I, as a developer, will be able able to dynamically point to different file based on the currently selected locale using useHeade composable updating the link
Bonus point
Integrating the above switching with additional options that would define the locale strategy might also be a good idea. e.g. one of the options might be:
this will assume the language detection should be handled based on the application route, which should also be a default option since this is the most common way for taking i18n on the web.
The text was updated successfully, but these errors were encountered: