High-level i18n API, for easier DX for simple needs

[brillout]

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: #341 (comment).

[3dyuval]

1. my first concern was generation of sitemap.xml with 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

2. The second concern is regarding localized url: a redirect from http://www.domain.tld to https://www.domain.tld/locale/. The docs suggest using a urlLogical which should override urlOriginal internally 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.

my working example

    pageContextInit = {
      urlOriginal: req.originalUrl,
      urlLogical: req.originalUrl.replace(`/${locale}`, '') || '/',  //doesn't work (404)
      locale
    }
  
  
   pageContextInit = {
      urlOriginal: req.originalUrl.replace(`/${locale}`, '') || '/', // This does
      locale
    }

[brillout]

@3dyuval Please create a new GitHub discussion for each topic/issue. This ticket is the wrong place as it's about an enhancement.

[brillout]

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.