Excluding files from the generate command

[morpheus7CS]

Hi @yassinedoghri,

I wonder if there is an option to exclude certain pages from being built in other languages.

Let's say I have a personal website. Here are the imaginary routes for the default locale:

• /
• /blog/
• /blog/<slug>/
• /about/

Now, I would like to have the same structure in a different language, but without:

• /blog/
• /blog/<slug>/

Is there a way to specify the routes that I want to skip in generating the i18n pages?

The dirty solution is of course to generate everything and manually remove what you don't need, but I'm wondering if there is a better way around it.

Thanks,
g

[yassinedoghri]

Hey @morpheus7CS, thank you for the question!

Is there a way to specify the routes that I want to skip in generating the i18n pages?

I'm afraid there isn't. Though, this is an interesting use case! I'll try taking a step back and hopefully explain my train of thought.

---

Let's say an article is written in english (the default language) and there is no localization in another language (eg. french).

What would be the best UX for a person navigating in the french website?

1. Get a 404 on the french article?
2. Get redirected to the english version?
3. Get the english article even though it's not written in french?
   --- ie. The surrounding UI is in french, but the article is in english.

A few issues to take into consideration for each option:

1. Users would miss the chance to read the article if they are able to understand english or using an automatic translation tool.
2. Users would be confused as to why they're getting a non french text. And after reading the article (if they can), they would have to go back to the french version.
3. Users would be confused as to why they're getting a non french text.

I think the first and second options are not good and they would push towards bad practices in terms of UX (404, redirects, giving users no choice and risk losing them).

Ultimately, I think that the best option is the third one, remains the issue with the confusion though.

The solution would be to add a banner on top of the article stating that the article is not translated in french. Also, technically, the non translated article would need to be wrapped in an html tag with the lang attribute (to specify the language switch in regards to the html lang attribute).

---

The third option can be implemented today as you'd have to keep the generated pages as is. I've done that myself with a website I manage (https://castopod.org) on the french legal notice page.

Though, because it's not as critical as blog articles, I haven't added the banner to prevent users from being confused, nor the lang attribute (yet!) 😅

This brings new questions I haven't thought of previously:

1. How could astro-i18next tell which pages or articles are not translated?
2. Should there be a helper Banner component to push towards best practices?
3. Should best practices for i18n be documented on astro-i18next?

Hopefully I answered your question! Note that maybe there are things I'm missing and I'm open to any suggestion 🙂

[morpheus7CS]

Hey @yassinedoghri,

once again, I think you highlighted the problem quite well, therefore I can only respond to some of the issues you have highlighted:

How could astro-i18next tell which pages or articles are not translated?

I kinda like what Statamic does in terms of creating relationships between translated pieces of content in different locales.
https://statamic.dev/tips/localizing-entries#entry-origins

Let's say we have one template for the /about/ page, which would generate:

• /about/
• /<locale>/about

When generating the content in different languages, you are already creating the folder structure and setting changeLanguage(<locale>). If their route is localized, you also already store the relationships between certain pages. Perhaps, there is a chance to set additional frontmatter there as well, which allows you to do the switching?

By the looks of your demo site, you also are already enabling switching between pages by using the <LanguageSelector>component in a smart way - if the page has a version in a different locale, you are re-routing the user to the correct entry, no matter whether the slug is different.

Here's how I imagine it working in practice.

1. Current default stays - everything is generated in all locales.

2. User has the ability to set paths that shouldn't be generated in certain locales - a good option for this seems to be extending the routes: {...}object within the existing config - this removes the need for manual removal of files you wish didn't exist.Alternative approach can be setting a (function) value in the individual front-matter of an entry.

3. User can specify a setting within the config, which sets the expected behavior of the <LanguageSelector> component:
   a) default is the same
   b) if the translated version doesn't exist, changing the language should point to the root for a locale.
   c) if you only wish to create a page, which won't exist in the default locale, you should do so manually within the generated locale folder.

4. The banner component seems like a helpful addition if someone would still like to bring in blog entries in another language and politely apologize to the visitor that the articles are not in the expected language.
   If not, you have two options:

• not generating the routes by mechanisms of the second point
• displaying a custom text - e.g. "We only write our articles in English and here's a link to a similar page in other languages"

There's also another thing, which I believe is somewhat buried in this:

There is a chance that a user would like to have the en and frversion of the home page to look different from each other. If I understand the current model, the default locale version would be copied into the secondary locale on every generation, overriding potential manual changes to that page and the user having to catch this when committing it to version control/deploying it.

Hope this helped clarify why I believe this is an important feature to build, and one I'm slightly amazed that i18next doesn't already solve in the original package, allowing you to hook into the functionality. (or maybe it does and I'm not aware of it)

Let me know what you think and if I skipped any important points from your original response.

Kind regards,
g