Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add LocalePrefix never option #388

Merged
merged 6 commits into from
Jul 18, 2023

Conversation

boris-arkenaar
Copy link
Contributor

fixes #366

@vercel
Copy link

vercel bot commented Jul 7, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
example-next-13-next-auth ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jul 18, 2023 6:03am
next-intl-docs ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jul 18, 2023 6:03am
next-intl-example-next-13 ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jul 18, 2023 6:03am

@vercel
Copy link

vercel bot commented Jul 7, 2023

@boris-arkenaar is attempting to deploy a commit to the next-intl Team on Vercel.

A member of the Team first needs to authorize it.

@boris-arkenaar
Copy link
Contributor Author

@amannn Could you do a review?

Copy link
Owner

@amannn amannn left a comment

Choose a reason for hiding this comment

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

What a fantastic PR, thank you for the great work! 🙌

I've played a bit with the example-next-13 app in this repo to test the new option and everything looks good to me. It seems like when you continuously switch the locale, at some point Next.js will returned a cached response, which will result in the cookie not being updated. I think there's a chance that the situation here will improve with #149, once we integrate createServerContext. But for the time being this should be fine and I think for a natural user flow (i.e. not randomly switching between languages), this shouldn't be an issue.

I've published a prerelease of this feature:

next-intl@2.18.0-alpha.1

Would you like to try this out in your app to see if everything works as expected there?

});

it('rewrites requests for other locales at a nested path', () => {
middleware(createMockRequest('/list', 'de'));
Copy link
Owner

Choose a reason for hiding this comment

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

Can you also include some tests where the accept-language header and the cookie value don't match while no locale is in the pathname? The cookie value should have precedence in this case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Of course.

configWithDefaults.localePrefix === 'never' ||
(hasMatchedDefaultLocale &&
(configWithDefaults.localePrefix === 'as-needed' ||
configWithDefaults.domains))
Copy link
Owner

Choose a reason for hiding this comment

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

I'm wondering what we should do with the alternate links in case of localePrefix: 'never' (see L198 below).

SEO is not really an issue here, but maybe some assistive technology will still read the header.

Here's an example for /about when I have NEXT_LOCALE=de:

Link: 
<http://localhost:3000/about>; rel="alternate"; hreflang="en",
<http://localhost:3000/de/about>; rel="alternate"; hreflang="de",
<http://localhost:3000/about>; rel="alternate"; hreflang="x-default"

This seems somewhat off, probably we should adjust the links to match this:

Link: 
<http://localhost:3000/about>; rel="alternate"; hreflang="de",
<http://localhost:3000/en/about>; rel="alternate"; hreflang="en",
<http://localhost:3000/about>; rel="alternate"; hreflang="x-default"

Would you mind looking into this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Alternate links don't really make sense in this case, since the URL won't set or change the current locale, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Or you could actually. It's some 'hidden' functionality at the moment I believe. When you go to a URL prefixed with a locale it will set that locale in the cookie and redirect to the URL without the locale prefix.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe more explicit then, like this?

Link: 
<http://localhost:3000/de/about>; rel="alternate"; hreflang="de",
<http://localhost:3000/en/about>; rel="alternate"; hreflang="en",
<http://localhost:3000/about>; rel="alternate"; hreflang="x-default"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Cannot find anything about screen readers and the use of alternate link headers though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe leave it out for locale prefix never?

Copy link
Owner

Choose a reason for hiding this comment

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

Sure, that's the other option. Fine by me, but we should mention it in the docs then!

Copy link
Owner

Choose a reason for hiding this comment

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

Disabling the alternate links and a brief mention in the docs would be the last part missing here, afterwards we can release this!

```

In this case all requests for all locales will be rewritten internally.

Copy link
Owner

Choose a reason for hiding this comment

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

Well written 👌

@boris-arkenaar
Copy link
Contributor Author

Would you like to try this out in your app to see if everything works as expected there?

Thanks for the pre-release. Tested with my app. Seems to be working well here as well!

@boris-arkenaar
Copy link
Contributor Author

Oh, wait. Still running my custom middleware. Let me set it up properly now.

@boris-arkenaar
Copy link
Contributor Author

Got it. Seems to work great :)

@amannn
Copy link
Owner

amannn commented Jul 17, 2023

@boris-arkenaar Do you have the time to complete this or can I help with something? (see the last open point)

@boris-arkenaar
Copy link
Contributor Author

@amannn You mean about the alternate links? Missed that comment. I can update that soon.

@amannn
Copy link
Owner

amannn commented Jul 17, 2023

@boris-arkenaar Yep, correct! Thank you so much! 🙌

@boris-arkenaar
Copy link
Contributor Author

@amannn Updated code and docs. Wanted to add some tests as well, but couldn't figure out how to mock/spy on getAlternateLinksHeaderValue.

 - A little bit less usage of callout in the docs (we already have so many)
 - Minor wording fixes in middleware docs
 - Fix mock behavior in middleware
 - Add tests for alternate links in middleware
@amannn
Copy link
Owner

amannn commented Jul 18, 2023

@amannn Updated code and docs. Wanted to add some tests as well, but couldn't figure out how to mock/spy on getAlternateLinksHeaderValue.

Thank you so much! I've added a commit with minor fixes, including a fix for the mock behavior in the middleware and tests for the alternate links.

Will merge and release this once CI is green, thank you so much for the great contribution! 🙌

@amannn amannn merged commit 92ec33a into amannn:main Jul 18, 2023
@boris-arkenaar boris-arkenaar deleted the feat/locale-prefix-never branch July 18, 2023 11:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Option to not have the locale anywhere in the URL
2 participants