Add language detection for password-protected link page#3515
Add language detection for password-protected link page#3515ctafsiras wants to merge 1 commit intodubinc:mainfrom
Conversation
|
@ctafsiras is attempting to deploy a commit to the Dub Team on Vercel. A member of the Team first needs to authorize it. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review infoConfiguration used: defaults Review profile: CHILL Plan: Pro 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds internationalization to the password-protected link flow: a new translations module with language detection from Accept-Language, page-level language selection, and PasswordForm updated to accept a language prop and render localized strings. Changes
Sequence Diagram(s)mermaid Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/web/app/password/`[linkId]/translations.ts:
- Around line 53-66: The getLanguage logic currently ignores q-weights and uses
"in" to check translations, causing incorrect picks; update getLanguage to parse
acceptLanguage into language;q pairs (extract base code from each entry), sort
entries by descending q (default q=1), then iterate sorted entries and use an
own-key check (e.g., Object.prototype.hasOwnProperty.call(translations, lang))
to find the first supported language, returning it as Language; if none match,
fall back to the existing default. Ensure you reference the variables/functions
getLanguage, acceptLanguage, and translations when making the change.
ℹ️ Review info
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
apps/web/app/password/[linkId]/form.tsxapps/web/app/password/[linkId]/page.tsxapps/web/app/password/[linkId]/translations.ts
| const languages = acceptLanguage | ||
| .toLowerCase() | ||
| .split(",") | ||
| .map((lang) => { | ||
| const [code] = lang.trim().split(";"); | ||
| return code.split("-")[0]; // Extract base language code (e.g., "en" from "en-US") | ||
| }); | ||
|
|
||
| // Check for supported languages in order of preference | ||
| for (const lang of languages) { | ||
| if (lang in translations) { | ||
| return lang as Language; | ||
| } | ||
| } |
There was a problem hiding this comment.
getLanguage does not compute the actual best match from Accept-Language.
Current logic uses list order only and ignores q weights, so headers like fr;q=0.8,en;q=0.9 can resolve incorrectly. Also, prefer own-key matching over in for user-derived keys.
💡 Suggested fix
export function getLanguage(acceptLanguage?: string | null): Language {
if (!acceptLanguage) return "en";
- const languages = acceptLanguage
+ const languages = acceptLanguage
.toLowerCase()
.split(",")
- .map((lang) => {
- const [code] = lang.trim().split(";");
- return code.split("-")[0]; // Extract base language code (e.g., "en" from "en-US")
- });
+ .map((entry, index) => {
+ const [rawCode, ...params] = entry.trim().split(";");
+ const baseCode = rawCode.split("-")[0];
+ const qParam = params.find((p) => p.trim().startsWith("q="));
+ const q = qParam ? Number.parseFloat(qParam.split("=")[1]) : 1;
+ return {
+ baseCode,
+ q: Number.isFinite(q) ? q : 0,
+ index,
+ };
+ })
+ .sort((a, b) => b.q - a.q || a.index - b.index);
// Check for supported languages in order of preference
- for (const lang of languages) {
- if (lang in translations) {
- return lang as Language;
+ for (const { baseCode } of languages) {
+ if (Object.hasOwn(translations, baseCode)) {
+ return baseCode as Language;
}
}
// Default to English if no match found
return "en";
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const languages = acceptLanguage | |
| .toLowerCase() | |
| .split(",") | |
| .map((lang) => { | |
| const [code] = lang.trim().split(";"); | |
| return code.split("-")[0]; // Extract base language code (e.g., "en" from "en-US") | |
| }); | |
| // Check for supported languages in order of preference | |
| for (const lang of languages) { | |
| if (lang in translations) { | |
| return lang as Language; | |
| } | |
| } | |
| const languages = acceptLanguage | |
| .toLowerCase() | |
| .split(",") | |
| .map((entry, index) => { | |
| const [rawCode, ...params] = entry.trim().split(";"); | |
| const baseCode = rawCode.split("-")[0]; | |
| const qParam = params.find((p) => p.trim().startsWith("q=")); | |
| const q = qParam ? Number.parseFloat(qParam.split("=")[1]) : 1; | |
| return { | |
| baseCode, | |
| q: Number.isFinite(q) ? q : 0, | |
| index, | |
| }; | |
| }) | |
| .sort((a, b) => b.q - a.q || a.index - b.index); | |
| // Check for supported languages in order of preference | |
| for (const { baseCode } of languages) { | |
| if (Object.hasOwn(translations, baseCode)) { | |
| return baseCode as Language; | |
| } | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/web/app/password/`[linkId]/translations.ts around lines 53 - 66, The
getLanguage logic currently ignores q-weights and uses "in" to check
translations, causing incorrect picks; update getLanguage to parse
acceptLanguage into language;q pairs (extract base code from each entry), sort
entries by descending q (default q=1), then iterate sorted entries and use an
own-key check (e.g., Object.prototype.hasOwnProperty.call(translations, lang))
to find the first supported language, returning it as Language; if none match,
fall back to the existing default. Ensure you reference the variables/functions
getLanguage, acceptLanguage, and translations when making the change.
There was a problem hiding this comment.
Thanks for the thorough review! This is a valid observation about q-weight parsing.
However, this getLanguage() implementation intentionally mirrors the existing pattern in the deeplink page (apps/web/app/app.dub.co/(deeplink)/deeplink/[domain]/[[...key]]/translations.ts), which was merged by the maintainer in PR #3362. Keeping both implementations consistent felt more appropriate than diverging.
In practice, most browsers send Accept-Language headers with the preferred language listed first (the order already reflects priority), so the current approach works correctly for the vast majority of real-world cases.
Happy to improve q-weight handling across both locations in a follow-up PR if the maintainers would like that.
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify the existing pattern in the deeplink translations file
cat "apps/web/app/app.dub.co/(deeplink)/deeplink/[domain]/[[...key]]/translations.ts" 2>/dev/null | grep -A 20 "function getLanguage"
Length of output: 567
@ctafsiras, thank you for the clarification! I've verified that the implementation indeed matches the existing pattern in the deeplink page, and your reasoning about maintaining consistency makes sense—especially since that approach was already reviewed and merged by the maintainers.
You're right that browser behavior typically handles this well in practice, as the preferred language usually appears first in the Accept-Language header.
If you'd like to track the potential q-weight improvement for both locations, feel free to open an issue for future consideration. Either way, maintaining consistency with the existing codebase is a reasonable choice here. 👍
✏️ Learnings added
Learnt from: ctafsiras
Repo: dubinc/dub PR: 3515
File: apps/web/app/password/[linkId]/translations.ts:53-66
Timestamp: 2026-02-27T20:55:21.761Z
Learning: In the Dub codebase, when implementing language detection from Accept-Language headers, the existing pattern (seen in apps/web/app/app.dub.co/(deeplink)/deeplink/[domain]/[[...key]]/translations.ts) intentionally does not parse q-weights and instead relies on the order of languages in the header. This simple approach works for most browser implementations. Maintaining consistency with this established pattern is preferred over introducing divergent implementations.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: devkiran
Repo: dubinc/dub PR: 3346
File: apps/web/lib/api/bounties/approve-bounty-submission.ts:165-165
Timestamp: 2026-01-13T12:06:42.476Z
Learning: Use 'noreply' as a sentinel for the replyTo email field: if replyTo === 'noreply', omit the replyTo property by spreading an empty object. Call sites can use replyTo: someEmail || 'noreply' to conditionally set replyTo without null/undefined. This pattern is broadly applicable across the TypeScript codebase; ensure this behavior is documented and that readability is preserved, using explicit conditional logic if the intent may be unclear.
Learnt from: devkiran
Repo: dubinc/dub PR: 3358
File: apps/web/app/(ee)/api/cron/partners/deactivate/route.ts:7-7
Timestamp: 2026-02-03T14:14:47.579Z
Learning: In all TypeScript files under apps/web, import zod using a namespace import: import * as z from 'zod/v4' and avoid using named import: import { z } from 'zod'. This ensures consistent API access and version specificity. During reviews, look for and replace any occurrences of import { z } from 'zod' with import * as z from 'zod/v4', and verify all zod usage continues to compile.
ctafsiras
force-pushed
the
feat/password-language-detection-360
branch
from
edd5324 to
a801a03
Compare
1 participant
Summary
Adds automatic language detection to the password-protected link page (
/password/[linkId]) based on the browser'sAccept-Languageheader. This addresses the feature request in #360 where users with non-English-speaking audiences see a fully English password prompt.Supported languages: English, Chinese, Spanish, French, Turkish — matching the same set already used in the deeplink preview page.
Changes
apps/web/app/password/[linkId]/translations.ts(new) — Translation strings for 5 languages withgetLanguage()andgetTranslations()utilities, following the same pattern as the deeplink translationsapps/web/app/password/[linkId]/page.tsx— ReadsAccept-Languageheader server-side, resolves the best matching language, and passes it to the form component. All 3 user-facing strings are now translated (heading, description, footer link)apps/web/app/password/[linkId]/form.tsx— Acceptslanguageprop and translates the input label, error message, and submit button textDesign decisions
Accept-Languageheaders, so translating metatags would have no practical benefitheaders()fromnext/headersworks on edge runtime (the page usesruntime = "edge")Closes #360
Summary by CodeRabbit
New Features
Bug Fixes / UX