clerk/javascript

[Next App Router] i18n not work on `clerkMiddleware`

linkscope opened this issue · 6 comments

linkscope commented

Preliminary Checks

Reproduction

https://codesandbox.io/p/devbox/clerk-i18n-demo-hclv27

Publishable key

pk_test_c2V0dGxpbmcta2l0LTg0LmNsZXJrLmFjY291bnRzLmRldiQ

Description

Hey, I found an issue: when using i18n, if you control the routing permissions in middleware.ts, the jump page will not be converted to i18n language, but if you use `` popups, it will be mapped normally to the i18n language. I've provided a minimal demo, hopefully it can solve this problem.

thanks, team

middleware.ts

import { clerkMiddleware, createRouteMatcher } from '@clerk/nextjs/server'
 
const protectedRoutes = createRouteMatcher(['/'])
 
export default clerkMiddleware((auth, req) => {
  if (protectedRoutes(req)) {
    auth().protect()
  }
})
 
export const config = {
  matcher: ['/((?!.+.[w]+$|_next).*)', '/', '/(api|trpc)(.*)'],
}

app/layout.ts

import { ClerkProvider } from '@clerk/nextjs'
import { zhCN } from '@clerk/localizations'

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode
}>) {
  return (
    <ClerkProvider localization={zhCN}>
      <html lang="en">
        <body>{children}</body>
      </html>
    </ClerkProvider>
  )
}

Environment

System:
    OS: macOS 14.4.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 3.65 GB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.12.2 - ~/Library/Caches/fnm_multishells/9236_1715349853493/bin/node
    npm: 10.5.0 - ~/Library/Caches/fnm_multishells/9236_1715349853493/bin/npm
    pnpm: 9.0.6 - ~/Library/Caches/fnm_multishells/9236_1715349853493/bin/pnpm
  Browsers:
    Chrome: 124.0.6367.156
    Safari: 17.4.1
  npmPackages:
    @babel/preset-react: ^7.24.1 => 7.24.1
    @clerk/localizations: ^2.3.0 => 2.3.0
    @clerk/nextjs: ^5.0.6 => 5.0.6
    @eslint/eslintrc: ^3.0.2 => 3.0.2
    @radix-ui/react-slot: ^1.0.2 => 1.0.2
    @types/node: ^20 => 20.12.9
    @types/react: ^18 => 18.3.1
    @types/react-dom: ^18 => 18.3.0
    @typescript-eslint/eslint-plugin: ^7.8.0 => 7.8.0
    @typescript-eslint/parser: ^7.8.0 => 7.8.0
    autoprefixer: ^10.4.19 => 10.4.19
    class-variance-authority: ^0.7.0 => 0.7.0
    clsx: ^2.1.1 => 2.1.1
    eslint: ^8.57.0 => 8.57.0
    eslint-config-alloy: ^5.1.2 => 5.1.2
    eslint-config-next: 14.2.3 => 14.2.3
    eslint-plugin-react: ^7.34.1 => 7.34.1
    eslint-plugin-tailwindcss: ^3.15.1 => 3.15.1
    lucide-react: ^0.378.0 => 0.378.0
    next: ^14.2.3 => 14.2.3
    postcss: ^8.4.38 => 8.4.38
    prettier: ^3.2.5 => 3.2.5
    react: ^18 => 18.3.1
    react-dom: ^18 => 18.3.1
    tailwind-merge: ^2.3.0 => 2.3.0
    tailwindcss: ^3.4.3 => 3.4.3
    tailwindcss-animate: ^1.0.7 => 1.0.7
    typescript: ^5.4.5 => 5.4.5
jescalan commented

Hey there @linkscope - it looks like you are using the account portal in you reproduction (you refer to this as the jump page) - we don't currently support i18n for account portal login pages. I'd recommend using a custom sign in page to get localization working for you. Hope this helps!

linkscope commented

@jescalan Thanks your answer! Can the <SignIn> component expose a locale field? That way I can just configure it to reuse the UI. also I noticed that after registering through a social connection, I get redirected to an account setup page, I've set the forceRedirectUrl field but it still does this, is there any way to redirect to the home page?

jescalan commented

The SignIn component will use the locale that is provided on ClerkProvider automatically 😁

As far as the account setup page, I'm guessing this is part of your sign up flow, and the social provider was unable to provide all the required info. If you set up your app to require things like name, username, etc, these followup pages must be completed before the user is actually signed up, then the redirect will happen after. If the signup is complete, the forceRedirectUrl should work correctly.

linkscope commented

Hey @jescalan Thanks for your patience in answering! Another thing I'm confused about is the inconsistent behavior between browsers, for example in Chrome sign in/up is the account portal, but in Safari it's a popup, in Safari there's not even a need to customize the sign in/up page (since it's already mapped by the normal i18n mapping), so is it possible to standardize all the behaviors to be the same as Safari in a subsequent update? That would be a bit better I think.

If you set up your app to require things like name, username, etc, these followup pages must be completed before the user is actually signed up, then the redirect will happen after. If the signup is complete, the forceRedirectUrl should work correctly.

Is there have documentation reference? My understanding is that if I manually configure it here does it not jump to the account settings page again? Also I think one thing about the account settings page is confusing for the user: because this page doesn't have any jump buttons. If the account settings page is unavoidable, is it possible to give a button to jump to the page? And can I configure this page via i18n? Also I tried an account that I have already signed up for, and when I sign up again via social connect, it still jumps to the account settings page.

jescalan commented

in Chrome sign in/up is the account portal, but in Safari it's a popup

This doesn't make sense to me and should not be the case. Do you have a URL that I can reproduce this with so we can look into it?

My understanding is that if I manually configure it here does it not jump to the account settings page again?

I'm sorry, I'm kind of lost at this point. I don't know what you're referring to manually configuring, and I also don't know what you mean by "account settings page". It may be easier for us to get on the same page if you have some screen recordings of the behavior you're talking about or even better a minimal reproduction

linkscope commented

@jescalan Hey I've just tried to reproduce this and realized that for some reason I'm now not getting the account settings page no matter what I do, I'm not sure but I think that's exactly right, the account settings page I'm experiencing is the account settings in the <UserProfile> component, except that it's displaying it as a whole page. But now I think it should be work fine for now. I'll close this issue and thanks again for the reply!

  • 👍1