Conversation
🦋 Changeset detectedLatest commit: a42d513 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| @@ -1,3 +1,3 @@ | |||
| --- | |||
| return Astro.rewrite("/") | |||
| return Astro.rewrite("/base") | |||
There was a problem hiding this comment.
This was an incorrect rewrite. The fix uncovered this, and I changed it. The fixture contains a base which means doing / should result to a 404 instead.
71e2a41 to
996ad3c
Compare
|
Re: the patch changeset, is it possible that people tried to "work around" this bug, and may have to update their projects now accordingly? e.g. Could someone have written Am waiting to look at the rest of the docs too closely while I see Matthew still asking questions! |
|
@sarah11918 I have updated the changeset regarding the bug fix. |
e0ba330 to
34df8db
Compare
packages/astro/test/fixtures/i18n-routing-fallback/astro.config.mjs
Outdated
Show resolved
Hide resolved
| redirectToDefaultLocale?: boolean; | ||
|
|
||
| /** | ||
| * @docs |
There was a problem hiding this comment.
I have some questions first here @ematipico
Is this top-level i18n config? Is this entry in the correct place? Right now, it would be showing up between two i18n.routing.* entries.
Shouldn't it also be near i18n.fallback? And, this doesn't replace it, but is a separate, same-level configuration? (that's up around line 1567).
I think we should also see an example of both this and fallback configured together in one code sample, since I'm assuming they'd need to work together. Without any i18n.fallback configured, you default to showing 404s for pages that don't exist, so you can't have a strategy?
There was a problem hiding this comment.
Is this top-level i18n config? Is this entry in the correct place? Right now, it would be showing up between two i18n.routing.* entries.
Shouldn't it also be near i18n.fallback? And, this doesn't replace it, but is a separate, same-level configuration? (that's up around line 1567).
It should be i18n.routing.fallbackType. I will update the code, because it's incorrect.
I think we should also see an example of both this and fallback configured together in one code sample, since I'm assuming they'd need to work together. Without any i18n.fallback configured, you default to showing 404s for pages that don't exist, so you can't have a strategy?
I updated the docs with an example here 2447fb9 (#11677)
sarah11918
left a comment
There was a problem hiding this comment.
This looks great @ematipico ! It's so exciting to see this feature continue to develop and allow people to control more and more!
I left some suggestions below for your consideration, so as always, correct what needs correcting and see what you think!
|
Should this be added to the 4.15 milestone? I have it in mine for docs! |
There was a problem hiding this comment.
This looks great @ematipico !
The content here is now good, but I think we could also update i18n.fallback itself now to make sure that there's reference to this additional configuration someone might make besides just setting that.
i18n.fallback is no longer just "the fallback strategy" because the strategy now combines these two (separated in diffrerent parts of the API) settings.
We could update the entry for i18n.fallback to be something like:
An option to configure the fallback language content when navigating to pages that do not exist (e.g. a translated page has not been created).
Use this object to declare a fallback locale route for each language you support. If no fallback is specified, then unavailable pages will return a 404.
You can also optionally configure
i18n.routing.fallbackType, to select whether to execute this fallback content as a redirect (default) or a rewrite.
What do you think about something like this?
I will also note, entirely up to you to consider/ignore as you see fit:
Even though this is a routing action, having it as a configuration on i18n.routing instead of i18n.fallback feels like a clunky/awkward story for docs to tell. I think needing to cross-link these two settings, where one depends on having the other set, because these settings are in different parts of the API feels a bit strange.
If I got to wave my magic wand (and, admitting I know nothing about what's underlying here), i18n.fallback.type (or i18n.fallback.redirect as a boolean, if you're not expecting any other option here) feels like a much more natural thing for users to configure.
I know, and I thought about it at the very beginning. However, |
sarah11918
left a comment
There was a problem hiding this comment.
Just an extra space, but approving for docs! Thank you @ematipico !
Co-authored-by: Bjorn Lu <bjornlu.dev@gmail.com>
Co-authored-by: Sarah Rainsberger <sarah@rainsberger.ca>
Co-authored-by: Sarah Rainsberger <sarah@rainsberger.ca>
Co-authored-by: Sarah Rainsberger <sarah@rainsberger.ca>
Co-authored-by: Sarah Rainsberger <sarah@rainsberger.ca>
4febc1b to
f712640
Compare
Changes
This PR adds a new feature for
i18n. A new configuration calledi18n.routing.fallbackTypeis added. The value of this new field is"redirect" | "rewrite".The
"redirect"variant is the default value and matches the current behaviour of the fallback system. With"rewrite", we use the.rewrite()function that was stabilised two minors agoThis PR also fixes a case where
RenderContent.pathnamewas incorrectly computed. Thepathnameisn't supposed to have thebasein its URL. This led to some issues that were fixed in this PR.Testing
I added new test for the rewrite.
I updated a test for the fix, which contained an incorrect behaviour.
Docs
withastro/docs#9133