High-level i18n API, for easier DX for simple needs
The i18n support/guide was focused on full flexibility for advanced i18n needs. But for simpler i18n use cases there should be an easier DX.
Write a comment about your i18n use case: the more use cases we collect, the better.
Use case example: https://github.com/brillout/vite-plugin-ssr/issues/341#issuecomment-1621682334.
- my first concern was generation of
sitemap.xmlwith recommended best practice for localization xml tags. I wasn't able to do so using the vite-plugin-sitemap, a more stripped down version of vite-plugin-pages-sitemap both of which do not implement nested<link lang="..">within the<loc>tag as they should.
My half ass to write a vite-plugin on top of sitemap (being used by afforementiond vite plugins) is far from perfect. Ideally it should:
- Auto discover routes to be included in sitemap.xml
- Implement sitemap's localized type
- Implement prerender as well as ssr sitemap.xml
- The second concern is regarding localized url: a redirect from
http://www.domain.tldtohttps://www.domain.tld/locale/. The docs suggest using aurlLogicalwhich should overrideurlOriginalinternally but it's not working for me. Providing urlLogical on top of urlOriginal I get 404's, otherwise it works as when simply providing the stripped down urlOriginal without locale.
pageContextInit = {
urlOriginal: req.originalUrl,
urlLogical: req.originalUrl.replace(`/${locale}`, '') || '/', //doesn't work (404)
locale
}
pageContextInit = {
urlOriginal: req.originalUrl.replace(`/${locale}`, '') || '/', // This does
locale
}
@3dyuval Please create a new GitHub discussion for each topic/issue. This ticket is the wrong place as it's about an enhancement.
Labeling as low-prio as it isn't a blocker: the current design seems to be working well (albeit with a cumbersome DX). After all blockers are implemented we can bump its priority.