Feature: Translated Routes / URLs

[dschoeni]

First of all, thanks a lot for this great library! It helped me replace my piece of custom code that served a similar purpose (and generated the corresponding /[lang]/* routes during static generation, without an additional build step or duplicated templates).

However, one feature that would be particularly great to have: translated routes. I know its mentioned in the docs that this currently isn't possible (also due to compatibility with @astro/sitemap).

Basically, I'm talking about a feature like this: https://github.com/yassinedoghri/astro-i18next#-translate-routes

What would be necessary to make this happen, and where are the challenges? I took a look into the code and got the impression that it might be possible to do, but I guess you already tried and found the hidden challenges ;)

Couldn't we adapt the generated paths in the astro_tmp_pages_ with a supplied config map?

[jlarmstrongiv]

What would be necessary to make this happen, and where are the challenges?

@natemoo-re, a co-creator and core maintainer of Astro said:

I think we'd love to work on a first-party i18n solution! It's a hard thing to generalize, but hopefully we've gathered enough intel from projects like yours and Starlight to start sketching out a plan for an official feature?

In my response, I provided feedback that included translated routes, like /about and /es/acerca-de, which would also need to be integrated with @astrojs/sitemap.

Unfortunately, I have not found any workarounds to make translated routes work. To be more specific @dschoeni

• the getStaticPaths() function only runs once—it’s the same for every locale. That also means that the Astro.props is the same for every locale.
• the astro_tmp_pages_ folders are only generated with the build command. The dev server is able to handle translations of the same sub-url (/es/about and /fr/about) without making copies of the pages folder.

Due to that limitation in this example, I had to call getEntry in the Astro frontmatter, rather than pass the CollectionEntry as Astro.props to the frontmatter from getStaticPaths(). Otherwise, the params and props from getStaticPaths() would always be the English (or defaultLocale) version.

While it is possible to:

• make a routing config
• handle /products/index.astro and /products.astro with other edge cases
• fork, modify, and maintain a custom version of @astrojs/sitemap
• create an example tested on GitHub Actions for multiple platforms
• explain to users the limitations of getStaticPaths() and Astro.props

I believe the best solution is for i18n to be a first-class concern of the Astro framework.

If you can think of any better workarounds @dschoeni, please let me know!

[dschoeni]

First of all, thanks for your extensive reply. We have decided for the time being to not use translated routes, but to keep using astro-i18n-aut because it simplifies and replaces our current piece of custom code. We're using astro-i18n-aut in combination with i18next and astro-i18next which provides some helpful components around translation, as well as handles the loading of our translation files.

The setup works reasonably well for the time being. Maybe when we truly need translated routes, astro will have i18n built in and we can swap everything out for a core-solution.