Modifying the generated route URL

[morpheus7CS]

Hi @yassinedoghri,

first, let me thank you for a great plugin and good documentation.

I also have an additional question I would like your input on. Currently, you can specify defaultLocale and locales in the astro-i18next.config.mjs. This works great, I am however wondering if the generated routes can be modified in any way?

Let's say instead of /en/, I would want to have the extended language format, such as /èn-US/, or even something completely random, such as /united-states-of-america/?

Thanks,
g

[yassinedoghri]

Hey @morpheus7CS, thanks for the kind words!

I would want to have the extended language format, such as /èn-US/, or even something completely random, such as /united-states-of-america/?

If you'd like to have the extended language, you could just set en-US (I'm assuming you didn't mean è?) as your defaultLocale and locales.

For the random string however, it is currently not possible, locales should be ISO 639-1 codes + eventually a country code for the region. But it could qualify as a feature request if you'd please share the use case for it.

Currently the routes can be translated, and this would probably be the same logic --> ie. having the en-US translate to united-states-of-america for example.

[morpheus7CS]

Hey @yassinedoghri,

thanks for the quick answer. I'll try to explain what use case I'm looking for.

Coming from Slovenia, we have a top TLD of .si, but the ISO 639-1 locale code of sl. Since the TLD is .si, many assume that a localized version of their website will follow a specific URL "standard" - <domain name>/si/<page-slug>.

Currently, if I would specify the si in the locales array, the URL structure would be correct, but changeLanguage("si") and lang={i18next.language} would specify that the page appears in Sinhalese, not Slovenian.

The other feature I see a lot is companies using the same part of the slug to define not just the language, but perhaps also the market, for example, Stripe, uses /en-gb-si/ to signify that the page is shown in UK English, while presenting the services for Slovenian market.

In talking with @alesvaupotic today, he proposed I could do a work around, and append my "made-up-key" to the end of the array with ISO 639-1 locale codes, but I would still have to manually change all the changeLanguage() calls with a search & replace.

I think having the ability to set some sort of exception, where you could define a key-value pair, which would properly set both URL and appropriate language code would be beneficial. Also, I am not sure whether this is something that i18next already includes and can be leveraged within your package.

Example of such a config (key name sucks, so don't stick with this 😛 ):

export default {
    defaultLocale: "en",
    locales: [
        "en",
        "unicorn",
    ],
    mapURLToLocale: {
        "unicorn": "sl"
    }
};

I have another related thing I would like to have your input on, but I'll open a separate discussion for that one.

Kind regards,
g

[yassinedoghri]

I see, it can be added. But I have some concerns about SEO (specifically with the market example).

For example, google only understands language/region codes.

The problem lies with the HtmlHrefLang component:

1. For the Slovenia example

   <link rel="alternate" hreflang="sl" href="<domain name>/si/<page-slug>" />

2. For the market example, it would be like this

   <link rel="alternate" hreflang="en-gb" href="<domain name>/en-gb/<page-slug>" />
   <link rel="alternate" hreflang="en-gb" href="<domain name>/en-gb-si/<page-slug>" />
   <link rel="alternate" hreflang="en-gb" href="<domain name>/en-gb-fr/<page-slug>" />

These appear to be two different use cases / functionalities. The first one is fairly easy to implement, as it would be just like the route translations but only for a locale. It wouldn't be as you've mentioned though because "unicorn" is not a language/region code.

export default {
  defaultLocale: "en",
  locales: [
    "en",
    "sl",
  ],
  localesMapping: {
    "sl": "si"
  }
};

The second use case is a bit tricky as it wouldn't be a one to one mapping anymore, a locale can be accessible in different markets. This would need a bit more work. Also, not sure what the API would look like for this.

Is it ok for you if I implement only the first use case for now?

[morpheus7CS]

Hey @yassinedoghri,

wanted to take some time and read through your thoughtful reply. What you wrote makes sense and having just the first part would already fulfill my use case.

Thanks a lot.
g