feat(i18n): domain with lookup table

[ematipico]

Changes

Relative RFC change: withastro/roadmap@713fce7

This PR adds the basic logic for supporting the new routing strategy called domain. We require a new routing strategy because Astro needs to make assumptions** in order to provide the correct user experience.

This assumption is that the localised folders must be at the root - src/pages folder. With that, the logic works as follow: during the build phase, we add to the manifest a new information called domainLookupTable. This table is a map that will look like this:

const domainLookupTable = {
	"https://fr.example.com": "fr",
	"https://example.pt": "pt",
}

It's essentially the configuration of i18n.domains, reversed :)

This table maps what we are supposed to get from the server to the correct route. When we extract the correct route, we can load and render the component for that route.

In a server environment, Astro will work with the following headers:

• X-Forwarded-Host
• Host as fallback of X-Forwarded-Host
• X-Forwarded-Proto

If Astro can't crate a URL from those heasers, it will return a 404. I believe this is an important information and I will make sure to add it to the RFC later.

I will have to do some testing, even on a serverless environment and check if that information is available. I want to do more testing after merging this PR.

Closes PLT-1218

Testing

I added some basic testing to show the feature, although I want to add more tests in another PR.

Docs

/cc @withastro/maintainers-docs for feedback!

[changeset-bot]

⚠️ No Changeset found

Latest commit: 28f5a7c

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[matthewp]

Added a review comment, thinking that having a full lookup table for all routes won't work.

[sarah11918]

I have some questions about how this works to be sure I understand:

1. if you select routingStrategy: "domain", what happens to the URLs for your defaultLocale? Does it depend on whether you're using a /[defaultLocale]/ folder structure? Does it make any assumptions by default?
2. Is it correct to assume that for non-default locales, which will all be written in /locale/ folders, that the URLs will be prefixed if you don't specifically add them to domains? So, it's possible for a site to have a mixture of e.g. example.com/fr/ and es.example.com?
3. is domains ignored if routingStrategy is set to one of the two other options? Could it cause problems to have domains configured if you do NOT have domain set as your routing strategy?
4. Does the order of domains and routingStrategy matter in the i18n configuration? Could someone run into trouble if these are not in the proper order?
5. Looking at the example below, routingStrategy is outside of the object containing the other config options. In the docs, we show it as inside this object. Can you confirm which should be correct?

Thanks!

[ematipico]

1. Yeah, there are assumptions. If you want to map a locale to a domain, the locale folder must be at src/pages/[locale]. The same goes for the defaultLocale. If the default locale isn't mapped to a domain, there aren't any assumptions. Although we are still evaluating the behaviour of defaultLocale, so it's possible we will change it soon.
2. Yes, that is correct.
3. No, that will be an error. For example, if you have i18n.domains and routingStategy: "prefix-always", Astro will throw a validation nerror.
4. No, the order doesn't matter.
5. Mmmmh, routingStategy is inside the i18n, same goes for domains. Are you referring to something else?

[sarah11918]

I'm also pointing out that #9099 was merged without my seeing it, which becomes confusing because now those docs changes do not show up as new here.

[ematipico]

I'm also pointing out that #9099 was merged without my seeing it, which becomes confusing because now those docs changes do not show up as new here.

Don't worry Sarah, I haven't requested your review for that PR on purpose. I will loop you in when I require your review. These PR aren't published yet on main.

[sarah11918]

But you did request me on this one which has those changes in it already, so I'll just point out that it's very difficult for me to look at these individual pieces in isolation like this. These concepts don't exist independently from each other, and much of documentation is about how the whole picture works and the pieces fit together.

Should I not be looking at this one yet?

Edit: Sorry, I realized that "PTAL" is pretty broad, and maybe you weren't asking me to edit these yet, but maybe to give feedback or comment? As you saw, I couldn't really look at wording until it was clearer to me how things worked. Maybe PTAL in this case was actually Please Throw Your Questions At Me Now! I should have asked you to clarify what I was taking a look at/for and what would be helpful for you!

(I'm sorry, I just got confused seeing docs merged that I hadn't seen related to this, and didn't know that I wasn't supposed to pay attention to them, because we're always trying to document all the features in relation to each other. So if it's there, I'm going to check that it's all consistent!)

[matthewp]

lgtm!