Just reminding ourselves that docs will have to be VERY LOUD about saying that your defaultLocale must be set, and even your default languages files need to be under a /[lang]/ folder.

Since there's no config option to indicate true to use this feature and it will just be enabled by default with the object, I'm just checking that the expected behaviour is:

• if no i18n config object is found, then none of this routing strategy applies.
• if an i18 config object is found, THEN all these rules kick in

I just want to make sure there's no way that a "normal" Astro site, not intending to use these features, could somehow 404 on the index page. 😄

Yes, all the existing tests are passing, and there hasn't been a regression so far; this means that i18n routing rules are only triggered when opting in.

Plus, we have an extensive configuration validation suite for defaultLocale and locales.

This means that, for example, the docs website can update Astro without regressions because i18n routing is opt-in only.

I find the naming of these options not super clear. In particular “other” begs the question “other from WHAT?”

Got some context from @sarah11918 that the reason not to choose something simple like:

interface i18n {
	prefixAllLocales: boolean; // (default: false)
	// or
	prefixDefaultLocale: boolean; // (default: false)
	// or
	prefix: 'all-locales' | 'non-default-locales';
}

is because we want to expand this option later to also take control of a subdomain routing strategy (fr.example.com vs example.com/fr/).

In this case, I’d argue that on top the “other” being vague, “prefix” also doesn’t have an established meaning (is fr. a prefix in a subdomain?).

Maybe something like the following could work?

routingStrategy: 'subpath-all' | 'subpath-non-default' | 'subdomain-all' | 'subdomain-non-default';

So we have subpath vs subdomain to distinguish those and all vs non-default instead of always vs other to distinguish what subset uses the path/subdomain strategy.

A further alternative (assuming there aren’t other combinations I’m unaware of) would be:

interface i18n {
	routing: {
		prefixDefaultLocale?: boolean; // default: false
		strategy?: 'subdomain' | 'subpath'; // default: 'subpath' 
	}
}

That would avoid trying to shoehorn two separate concerns (do we prefix default locale? do we use subpath or subdomain?) into one enum string. This would be my preferred option I think.

Sorry if I’ve missed some context or discussion — this feature is so big I find it hard to get a clear picture.

Thank you @delucis , and don't worry if you missed the discussion/context.

That's excellent feedback, thank you. The reason why I used "prefix" is because it seems to be the most common term used in this context. Personally, I don't like it because it introduces a new terminology that isn't very clear in the space of "routing and internationalization".

I will have more context and information once domain support is clearer.

I would like to avoid breaking down the feature in too many flags because they are a footgun, and they become more difficult to maintain. They essentially become a matrix. In fact, base, trailingSlash and build.format are very difficult to maintain together.

I can see have at most two properties, as you suggested, but like this:

interface i18n {
	routingStrategy: {
		subUrl?: 'suburl-all' | 'suburl-non-default',
		subDomain?: 'subdomain-all' | 'subdomain-non-default'
	}
}

I used "URL" because that's what the users see, and "path" is misleading because it can be used for files too.

This could allow us to have support cases like this:

• en.example.com/
• en.example.com/en-au

FYI, if we agree on something, I don't plan to apply this change in this PR. I would like to apply these changes after we ship the experimental release.

What do you think?

I’ll move this discussion to the RFC too 👍