how to add the lang folder to the baseLanguage.

[preetamslot]

Hi,
my current page structure is like this:

[lang]
 - about.astro
 - news.astro
 - contact.astro
 - index.astro
index.astro (homepage default lang or redirect to user locale)

So except for the homepage in baseLanguage I always add the [lang] to every URL.
How can I do this?

(in my setup the HeadHrefLangs & LanguageSelector won't work.)

I would like not to have a structure like this:

[lang]
 - about.astro
 - news.astro
 - contact.astro
 - index.astro
about.astro
news.astro
contact.astro
index.astro

Thanks!

[yassinedoghri]

Hey, thanks for reporting the issue!

This is a concern I've had since the beginning and haven't figured out a way to automate it yet!

I've thought about generating the language files during build time but there are some limitations with Astro's integration API. I'll have to take some time in finding my way around them.

I'll try working on it this weekend and post my progress here 🙂

[yassinedoghri]

Alright, I've thought about this and I think I have a solution I can work with.

IMO, the best Developer Experience is not to have to think about this at all by having a folder structure as you would in any non localized Astro project like so:

pages
|-- about.astro
|-- news.astro
|-- contact.astro
└-- index.astro

Also, you shouldn't think about switching the language with i18next.changeLanguage(i18next.options.supportedLngs[0]);.

👉 astro-i18next would do the heavy lifting on both language files and language switching logic.

This would be possible using a CLI command that generates the code for you:

astro-i18next generate

☝️ This command, would produce:

pages
├-- [lang]
|    |-- about.astro
|    |-- news.astro
|    |-- contact.astro
|    └-- index.astro
|-- about.astro
|-- news.astro
|-- contact.astro
└-- index.astro

This would be possible in 2 steps:

1. Create the astro-i18next generate command, responsible of going through the pages folder and generating the [lang] folder with the language switch logic. Now that I think of it, it may be easier (best?) to generate each supported locale in a different folder instead of the dynamic routes for starters.
   --> code injection and astro files creation is easily done using the @astrojs/compiler

2. Call the astro-i18next generate command during build time to have localized pages and all language switching logic included with the build.

👉 I've started implementing this, and will work on it further next weekend.

[preetamslot]

Sounds good!
But what if the structure is deeper like with a blog collection?

pages
├-- news
|    |-- [...slug].astro
|    |-- [page].astro
|-- about.astro
|-- [...page].astro
|-- contact.astro
└-- index.astro

Then the getStaticPaths for a news item or a dynamic page can get more complicated.
I use NetlifyCms where all translations are stored in a single mdx file but not all fields are translated.
So on every [lang] route, I merge the language to access all the fields.

How would the astro-i18next generate know what to do?

[lang] route

export async function getStaticPaths () {
const allNews= await Astro.glob("../../../../data/news/*.mdx");
 
  let params = [];

  return await Promise.all(
    locales
      .filter((locale) => locale !== i18next.options.supportedLngs[0])
      .map(async (lang) => {
        const news = getTranslation(allNews, lang) 
        news.map((newsItem, index) => {
          params.push({
            params: { lang: lang, slug: newsItem.slug },
            props: { content: newsItem},
          });
        });
        return params;
      })
  );
}

original route

export async function getStaticPaths () {
const allNews= await Astro.glob("../../../data/news/*.mdx");
 
  let params = [];

  return await Promise.all(
    locales
      .filter((locale) => locale == i18next.options.supportedLngs[0])
      .map(async (lang) => {
        const news = getTranslation(allNews, lang) 
        news.map((newsItem, index) => {
          params.push({
            params: {slug: newsItem.slug },
            props: { content: newsItem},
          });
        });
        return params;
      })
  );
}

Thanks!

[yassinedoghri]

Sounds good! But what if the structure is deeper like with a blog collection?
[...]
How would the astro-i18next generate know what to do?

That's the catch when trying to have a dynamic route for languages! So, first, the easiest thing to do is to discard using getStaticPaths to declare localized routes.

Instead, astro-i18next generate would generate each declared locale in its own folder. For example, let's say we have 3 languages (fr, es, en), english being the default language:

# base pages translated using the `t()` function / `<Trans />` component
pages
├-- news
|    |-- [...slug].astro
|    |-- [page].astro
|-- about.astro
|-- [...page].astro
|-- contact.astro
└-- index.astro

astro-i18next generate would generate the following at build time:

pages
├-- fr
|    ├-- news
|    |    |-- [...slug].astro
|    |    └-- [page].astro
|    |-- about.astro
|    |-- [...page].astro
|    |-- contact.astro
|    └-- index.astro
├-- es
|    ├-- news
|    |    |-- [...slug].astro
|    |    └-- [page].astro
|    |-- about.astro
|    |-- [...page].astro
|    |-- contact.astro
|    └-- index.astro
├-- news
|    |-- [...slug].astro
|    └-- [page].astro
|-- about.astro
|-- [...page].astro
|-- contact.astro
└-- index.astro

And would add the following lines to the pages' frontmatter so as not to touch to the getStaticPaths logic:

---
import i18next from "i18next";
 
i18next.changeLanguage(<language code goes here>);

[...]
--- 

I think that in terms of DX, this is the best. Apart from having to replace the text with translation keys, you wouldn't have to do anything else.

And eventually, this also unlocks some other cool features, like what if we'd like to translate the routes? astro-i18next generate could also replace the file names for each language.

Anyways, haven't worked out the details yet, hopefully I can get something working this weekend 🤞

[github-actions]

🎉 This issue has been resolved in version 1.0.0-beta.4 🎉

The release is available on:

• npm package (@beta dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[yassinedoghri]

As the github-actions bot said, 1.0.0-beta.4 was just released with the first version of the npx astro-i18next generate command.

I had a blast working on this, learned a lot! Thanks for your feedback @preetamslot, I've added you as a contributor in the README.md. Hope you don't mind 🙂