Skip to content

Clarify routing logic config instruction#13879

Open
sanscontext wants to merge 2 commits into
withastro:mainfrom
sanscontext:patch-1
Open

Clarify routing logic config instruction#13879
sanscontext wants to merge 2 commits into
withastro:mainfrom
sanscontext:patch-1

Conversation

@sanscontext
Copy link
Copy Markdown

Description (required)

Reordering the sentence to be a little clearer about what you're doing in this step. (I need to make a fast-follow edit to s/local/locale)

First-time contributor to Astro Docs

👋 Hi, I'm SansContext on the Astro Discord. (I mostly hang out in #starlight )

@netlify
Copy link
Copy Markdown

netlify Bot commented May 12, 2026

Deploy Preview for astro-docs-2 ready!

Built without sensitive environment variables

Name Link
🔨 Latest commit 32e1603
🔍 Latest deploy log https://app.netlify.com/projects/astro-docs-2/deploys/6a03a4800ef5be0008f719f3
😎 Deploy Preview https://deploy-preview-13879--astro-docs-2.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
🤖 Make changes Run an agent on this branch

To edit notification comments on pull requests, go to your Netlify project configuration.

@astrobot-houston
Copy link
Copy Markdown
Contributor

Hello! Thank you for opening your first PR to Astro’s Docs! 🎉

Here’s what will happen next:

  1. Our GitHub bots will run to check your changes.
    If they spot any broken links you will see some error messages on this PR.
    Don’t hesitate to ask any questions if you’re not sure what these mean!

  2. In a few minutes, you’ll be able to see a preview of your changes on Netlify 🥳.

  3. One or more of our maintainers will take a look and may ask you to make changes.
    We try to be responsive, but don’t worry if this takes a few days.

@astrobot-houston
Copy link
Copy Markdown
Contributor

astrobot-houston commented May 12, 2026

Lunaria Status Overview

🌑 This pull request will not trigger status changes.

Learn more

Lunaria automatically ignores changes on specific PRs by adding a ignored keyword in its title. Found: i18nIgnore.

You can change this by either removing the keyword above from the PR's title, or modifying the ignoreKeywords property in your Lunaria configuration file.

Tracked Files

Note

The notes below indicate what would happen if the pull request is merged when triggering status changes. Since a ignored keyword was found in the PR's title, the status changes indicated below won't be applied.

File Note
en/guides/internationalization.mdx Source changed, localizations will be marked as outdated.
Warnings reference
Icon Description
🔄️ The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

Comment thread src/content/docs/en/guides/internationalization.mdx Outdated
Copy link
Copy Markdown
Member

@ArmandPhilippot ArmandPhilippot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your contribution! We usually expect an issue or a discussion first when things are unclear... But you're right, the sentence was rather heavy.

You missed a parentheses, and I also suggested to simplify that sentence even more. Let me know if you think this matches your intent!

Edit: and because the wording affects the translations, we don't need i18nIgnore here. Except really obvious typo this is rarely useful because the English wording can affect how this is translated. So, I updated the PR title.

## Configure i18n routing

Both a list of all supported languages ([`locales`](/en/reference/configuration-reference/#i18nlocales)) and a default language ([`defaultLocale`](/en/reference/configuration-reference/#i18ndefaultlocale)), which must be one of the languages listed in `locales`, need to be specified in an `i18n` configuration object. Additionally, you can configure more specific routing and fallback behavior to match your desired URLs.
When you create an `i18n` configuration object, you must specify both a list of all supported languages ([`locales`](/en/reference/configuration-reference/#i18nlocales)), and set one of the locales in the list as the default language ([`defaultLocale`](/en/reference/configuration-reference/#i18ndefaultlocale). You can also configure more specific routing and fallback behavior to match your desired URLs.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about something like this? Do you think it's easier to read/understand?

Suggested change
When you create an `i18n` configuration object, you must specify both a list of all supported languages ([`locales`](/en/reference/configuration-reference/#i18nlocales)), and set one of the locales in the list as the default language ([`defaultLocale`](/en/reference/configuration-reference/#i18ndefaultlocale). You can also configure more specific routing and fallback behavior to match your desired URLs.
In your [`i18n` configuration](/en/reference/configuration-reference/#i18n), specify both a list of all supported [`locales`](/en/reference/configuration-reference/#i18nlocales) and a [`defaultLocale`](/en/reference/configuration-reference/#i18ndefaultlocale) present in that list. Additionally, you can configure more specific routing and fallback behavior to match your desired URLs.

My thinking is to improve the consistency at the same time. We usually don't use "languages (locales)" but "locales" directly (e.g. Custom locale paths), I don't see any reason to make an exception here. And, we can remove some words to make the sentence shorter and more direct.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally think it makes sense to hint that a "locale" represents a language, for readers who are just setting this up for the first time. However, I was mostly leaving it in because it was already there.

This specific phrasing adds more complex words and sentence structure in the service of lowering word count, but my background is in writing for Global English and this isn't my style guide. ¯_(ツ)_/¯

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This specific phrasing adds more complex words and sentence structure

I'm not a native speaker, but I would say it's the other way around? Shorter and direct sentences are easier to parse. And a tool like the Hemingway App seems to say the same when comparing both sentences.

I personally think it makes sense to hint that a "locale" represents a language

Alright, I don't have a strong opinion on this.

Suggested change
When you create an `i18n` configuration object, you must specify both a list of all supported languages ([`locales`](/en/reference/configuration-reference/#i18nlocales)), and set one of the locales in the list as the default language ([`defaultLocale`](/en/reference/configuration-reference/#i18ndefaultlocale). You can also configure more specific routing and fallback behavior to match your desired URLs.
In your [`i18n` configuration](/en/reference/configuration-reference/#i18n), specify both a list of all supported languages ([`locales`](/en/reference/configuration-reference/#i18nlocales)) and a default language ([`defaultLocale`](/en/reference/configuration-reference/#i18ndefaultlocale)) present in that list. Additionally, you can configure more specific routing and fallback behavior to match your desired URLs.

If you don't like this, do not hesitate to suggest something else. But, "When you create" and "you must" seem superfluous to me and an imperative style should be used instead.

this isn't my style guide

Well, you can read more about our style guide in Astro Docs Docs 😄

@ArmandPhilippot ArmandPhilippot changed the title Clarify routing logic config instruction [i18nIgnore] Clarify routing logic config instruction May 13, 2026
@ArmandPhilippot ArmandPhilippot added the improve or update documentation Enhance / update existing documentation (e.g. add example, improve description, update for changes) label May 13, 2026
@sanscontext
Copy link
Copy Markdown
Author

Sorry about the missed paren. I really wish Github had better syntax highlighting in the editor! I didn't have time to do a full checkout to edit it in my IDE, but wanted to fix this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

improve or update documentation Enhance / update existing documentation (e.g. add example, improve description, update for changes)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants