-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
fix(nextjs): Inconsistent transaction naming for i18n routing #17927
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
fix(nextjs): Inconsistent transaction naming for i18n routing #17927
Conversation
size-limit report 📦
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sweet! Could we add a e2e test for this e.g. in next-15-basebath
?
7e23ca1
to
68b20a8
Compare
I might've overdid it but testing the setup with other tests in place is tricky, so I set up another nextjs project with the actual intl-next package. |
68343f8
to
21c72bc
Compare
21c72bc
to
89b04f7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding the test! Since they all run in parallel and this is a fast one I'd not expect this to be a problem.
Great work!
Problem
When using Next.js 15 App Router with
next-intl
andlocalePrefix: "as-needed"
, Web Vitals and transaction names were inconsistent across locales:/foo
(default locale, no prefix) → Transaction:/:locale
❌/ar/foo
(non-default locale, with prefix) → Transaction:/:locale/foo
✅This caused all default locale pages to collapse into a single
/:locale
transaction, making Web Vitals data unusable for apps with i18n routing.After investigation it seems like the route parameterization logic couldn't match
/foo
(1 segment) to the/:locale/foo
pattern (expects 2 segments) because the locale prefix is omitted in default locale URLs.Solution
Implemented enhanced route matching with automatic i18n prefix detection:
hasOptionalPrefix
flag to route info to identify routes with common i18n parameter names (locale
,lang
,language
)hasOptionalPrefix
/foo
→ tries matching as/PLACEHOLDER/foo
→ matches/:locale/foo
✓/:locale/foo
(2 segments) now beats/:locale
(1 segment)Result
After fix:
All routes now consistently use the same parameterized transaction name regardless of locale, making Web Vitals properly grouped and usable.
Backwards Compatibility
locale
/lang
/language
Fixes #17775
Maybe we should make certain aspects of this configurable, like the
['locale', 'lang', 'language']
collection