Date formatting: EN-US for US language people, EN-GB for everyone else?

[jonschmidt]

I am being tasked with seeing how possible this is, or even if it is a terrible idea for some reason. There is a desire to keep the UX as simples as possible (by having EN be the only language option), but then have some intelligence around whether we use US or GB style date formatting.

We use mixed routing, as we have public pages, and internal logged in pages
https://github.com/amannn/next-intl/tree/main/examples/example-app-router-mixed-routing

Is the best thing to add both en-us and en-gb as supported locales, and then use custom prefixes to map them both tn "en"? I would think that might not work, and even if it did, I am not sure how I would achieve en-us only for en-us, and en-gb for everyone else.

[amannn]

Hmm, it sounds like a somewhat blurry mix to me. I understand you want to improve the user experience for different regions, but wouldn't it be odd if you adapt e.g. date formatting to match US cultural preferences but leave text labels in British English? You're making a tradeoff anyway, but leaving the app in a consistent state might make this clear to visitors too, don't you think?

Implementation-wise I think the custom prefixes will probably conflict in this case and not lead to reliable results. You'd probably have to wrap the middleware or provide your own implementation to get this working.

Would it be an option for your app to set the locales up with their own prefix? E.g. Watershed has support for both en-US as well as en-GB—just as an example. You can of course reuse messages across these locales based on the base language (ignoring regional preferences), but you could long-term consider transitioning to adapting messages (and maybe other aspects) too.

[jonschmidt]

Thanks for the quick thoughts. I guess it makes sense for us to alight the locales with what translations we offer, and right now we only offer UK english text, so as a first step we might just try to force en-uk for all people who we want english for. I guess I would follow this? #1727

[amannn]

Yep, I think that sounds reasonable if that's an option for you!

[jonschmidt]

One more question, any tips on how to handle redirects as I migrate to en-gb? Is a redirect from en -> en-gb in next.config the best way? I want to do this carefull as there are certainly urls with /en/ floating around everywhere. Thanks!

Edit: Actually as I test this out, some unexpected things:

If I setup my routing like this

  defaultLocale: "en-GB",

  localePrefix: {
    mode: "as-needed",
    prefixes: {
      "en-GB": "en",
    },
  },

Then when I go to "/", it loads correctly with the en-GB locale.
When I go to "/en", it actually redirects to "/en-GB", but then 404s. If I remove the "prefixes" block, then it does not 404, it loads correctly. Maybe I don't actually need the prefixes block as I am not actually showing the prefix in that case.

When I add a redirect to next.config, the combination of the "custom url prefix" mixed with automatically redirecting seems to be a big problem. As probably expected, I end up with something like this if I also use the custom URL prefix.

/en-GB/en/en-GB/en/en-GB/en/en-GB/en/en-GB/en/en-GB..... etc.

[amannn]

    prefixes: {
      "en-GB": "en",
    },

It seems like you're missing a slash: /en (ref). Maybe I should add error handling for this at some point …