Skip to content

fix: Updated translation key usage in change password error scenario #8113

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.

Sign up for GitHub

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

Draft
utkershrajvenshi wants to merge 1 commit into
base: preview
Choose a base branch
from
Draft

fix: Updated translation key usage in change password error scenario #8113

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions apps/web/app/(all)/[workspaceSlug]/(settings)/settings/account/security/page.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -99,9 +99,9 @@ function SecurityPage() {

setToast({
type: TOAST_TYPE.ERROR,
title: errorInfo?.title ?? t("auth.common.password.toast.error.title"),
title: errorInfo?.title ?? t("auth.common.password.toast.change_password.error.title"),
message:
typeof errorInfo?.message === "string" ? errorInfo.message : t("auth.common.password.toast.error.message"),
typeof errorInfo?.message === "string" ? errorInfo.message : t("auth.common.password.toast.change_password.error.message"),
Comment on lines +102 to +104
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 13, 2025

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Good alignment with success message pattern, but verify translation keys exist.

The change to use change_password specific error keys is consistent with the success toast pattern (lines 89-90) and is more semantically appropriate than generic password error keys.

However, issue #8082 indicates that translation keys were being displayed as raw text (e.g., "auth.common.password.toast.error.title"), suggesting those keys didn't exist in the translation files. This fix assumes the new keys auth.common.password.toast.change_password.error.title and auth.common.password.toast.change_password.error.message are properly defined. Based on the provided context (lines 222-243 of packages/i18n/src/store/index.ts), if a key is not found, the t() function returns the key itself as a string, which would reproduce the same issue.

Additionally, the PR objective mentions backend error types like INVALID_NEW_PASSWORD and INVALID_PASSWORD from the zxcvbn complexity check. Ensure authErrorHandler (line 97) properly maps these error codes to user-friendly messages.

Run the following script to verify the translation keys exist and check for related password error handling:

🏁 Script executed:

#!/bin/bash
# Verify new translation keys exist in i18n files and check authErrorHandler coverage

echo "=== Searching for new translation keys in i18n/locale files ==="
rg -n "change_password\.error\.(title|message)" --type json --type ts

echo -e "\n=== Checking authErrorHandler implementation ==="
ast-grep --pattern 'export $_ function authErrorHandler($$$) { $$$ }'

echo -e "\n=== Searching for password complexity error codes ==="
rg -n "INVALID_NEW_PASSWORD|INVALID_PASSWORD" --type ts --type py -C 2

Length of output: 22807


</thinking>

Based on the verification, the script output reveals a **critical issue**: The new translation keys `auth.common.password.toast.change_password.error.title` and `auth.common.password.toast.change_password.error.message` do **not exist** in the i18n translation files. The grep search found only references to these keys in the code being reviewed (lines 102, 104), not their definitions in translation files.

Additionally, the `authErrorHandler` function was not found by the ast-grep search, suggesting either it's defined differently or the error handling logic relies entirely on the translation fallback.

**Verify translation keys are added and error handler covers password complexity codes.**

The change aligns error toast keys with the success pattern (consistent with lines 89-90), but verification shows the new keys `auth.common.password.toast.change_password.error.title` and `auth.common.password.toast.change_password.error.message` are not currently defined in i18n translation files. If the key is still not found, i18n will then return the key itself, which would reproduce the exact problem from issue #8082 (raw translation keys displayed).

Additionally, confirm that `authErrorHandler` (line 97) properly handles backend error codes like `INVALID_NEW_PASSWORD` and `INVALID_PASSWORD`. The backend sends these codes from password complexity checks, but the error handler must map them to user-friendly messages before falling back to translation keys.

**Required actions:**
1. Ensure the translation keys are defined in all language translation files (e.g., `packages/i18n/src/locales/en.json`)
2. Verify `authErrorHandler` maps backend error codes (`INVALID_NEW_PASSWORD`, `INVALID_PASSWORD`) to readable messages
3. Test the error handling flow with actual password complexity failures

---

🏁 Script executed:

```shell
#!/bin/bash
# Find authErrorHandler and verify translation key existence more thoroughly

echo "=== Searching for authErrorHandler function definition (any scope) ==="
rg -n "authErrorHandler" --type ts --type tsx -B 2 -A 8

echo -e "\n=== Searching for i18n locale files structure ==="
fd -e json -e ts -path "*i18n*" -path "*locale*" | head -20

echo -e "\n=== Checking if translation keys exist with slightly different format ==="
rg -n "change_password" --type json | grep -i "error\|toast" || echo "No matches found"

echo -e "\n=== Looking at the component to understand error flow ==="
rg -n "authErrorHandler\|errorInfo" apps/web/app/\(all\)/\[workspaceSlug\]/\(settings\)/settings/account/security/page.tsx -A 2 -B 2

Length of output: 590

🏁 Script executed:

#!/bin/bash
# Corrected script with proper syntax

echo "=== Searching for authErrorHandler function definition ==="
rg -n "authErrorHandler" -A 8 --glob "*.ts" --glob "*.tsx" 2>/dev/null || echo "Function not found or search failed"

echo -e "\n=== Finding i18n locale files ==="
find . -path "*/i18n/*" -name "*.json" 2>/dev/null | grep -i locale | head -10

echo -e "\n=== Checking if change_password.error keys exist in JSON files ==="
find . -name "*.json" -path "*/i18n/*" -o -name "*.json" -path "*/locale/*" 2>/dev/null | xargs grep -l "change_password.error" 2>/dev/null || echo "No translation files contain change_password.error keys"

echo -e "\n=== Viewing the security page component error handling ==="
find . -path "*settings/account/security*" -name "page.tsx" 2>/dev/null | head -1 | xargs cat 2>/dev/null | grep -A 15 "catch.*error" | head -30

echo -e "\n=== Finding where translation keys should be defined ==="
find . -name "*.json" -path "*/i18n/*" 2>/dev/null | head -5 | xargs ls -lh

echo -e "\n=== Searching for authErrorHandler in utils or helpers ==="
rg -n "function authErrorHandler|const authErrorHandler|export.*authErrorHandler" 2>/dev/null | head -20

Length of output: 21517

🏁 Script executed:

#!/bin/bash
# Examine authErrorHandler implementation to check password error code coverage

echo "=== Full authErrorHandler implementation ==="
rg -n "export const authErrorHandler" apps/web/helpers/authentication.helper.tsx -A 50 | head -60

echo -e "\n=== Check if INVALID_NEW_PASSWORD or INVALID_PASSWORD return values ==="
rg -n "INVALID_NEW_PASSWORD\|INVALID_PASSWORD" apps/web/helpers/authentication.helper.tsx -B 2 -A 2

echo -e "\n=== Find i18n locale directory structure ==="
find ./packages/i18n -type f | head -20

echo -e "\n=== Check for toast configuration in authErrorHandler ==="
rg -n "toastAlertErrorCodes\|bannerAlertErrorCodes" apps/web/helpers/authentication.helper.tsx -A 20 | head -40

Length of output: 3967

🏁 Script executed:

#!/bin/bash
# Check full authErrorHandler logic and search translation files

echo "=== Full authErrorHandler logic (looking for return statements) ==="
rg -n "export const authErrorHandler" apps/web/helpers/authentication.helper.tsx -A 100 | grep -A 90 "bannerAlertErrorCodes"

echo -e "\n=== Search translation files for change_password.error ==="
find ./packages/i18n/src/locales -name "*.ts" -exec grep -l "change_password" {} \;

echo -e "\n=== Check English translation file for password toast keys ==="
rg -n "auth\.common\.password\.toast" ./packages/i18n/src/locales/en/translations.ts -B 1 -A 1

echo -e "\n=== Full search for password toast keys in all locale files ==="
find ./packages/i18n/src/locales -name "*.ts" -exec grep -H "password.*toast\|toast.*password" {} \;

Length of output: 4572

🏁 Script executed:

#!/bin/bash
# Find errorCodeMessages and verify password error handling

echo "=== Search for errorCodeMessages definition ==="
rg -n "const errorCodeMessages|export.*errorCodeMessages" apps/web/helpers/authentication.helper.tsx -A 5

echo -e "\n=== Find errorCodeMessages entries for password codes ==="
rg -n "\[EAuthenticationErrorCodes.INVALID_NEW_PASSWORD\]|\[EAuthenticationErrorCodes.INVALID_PASSWORD\]" apps/web/helpers/authentication.helper.tsx -B 1 -A 2

echo -e "\n=== Search translation files more broadly for toast keys ==="
rg -n "change_password.*error" ./packages/i18n/src/locales/en/ -A 2 -B 2

echo -e "\n=== Check what keys exist in authentication error messages section ==="
rg -n "auth\.common\.password" ./packages/i18n/src/locales/en/core.ts 2>/dev/null | head -20 || rg -n "auth\.common\.password" ./packages/i18n/src/locales/en/translations.ts 2>/dev/null | head -20

Length of output: 848

Translation keys must be added to all locale files; fallback still risks displaying raw key strings.

The change aligns error fallback keys with the success pattern (change_password.error.* matches change_password.success.*), which is good for consistency. However, critical issues remain:

  1. Missing translation definitions: The new fallback keys auth.common.password.toast.change_password.error.title and message don't exist in any translation files. For INVALID_NEW_PASSWORD and INVALID_PASSWORD specifically, authErrorHandler provides hardcoded English messages (lines 136-138 and 293-295 in apps/web/helpers/authentication.helper.tsx), so those cases work. But any other password error codes not in the bannerAlertErrorCodes list will return undefined, triggering the fallback to non-existent translation keys. The t() function will then return the key string itself, reproducing issue [bug]: Password complexity errors not displayed #8082.

  2. Incomplete error code coverage: authErrorHandler only handles error codes in bannerAlertErrorCodes (which includes INVALID_NEW_PASSWORD and INVALID_PASSWORD). Verify all possible backend password error responses are covered or have translation keys defined.

Required actions:

  • Add auth.common.password.toast.change_password.error.title and auth.common.password.toast.change_password.error.message keys to all locale files in packages/i18n/src/locales/*/
  • Verify authErrorHandler covers all password complexity error codes from the backend or ensure translation fallbacks exist
🤖 Prompt for AI Agents 
In
apps/web/app/(all)/[workspaceSlug]/(settings)/settings/account/security/page.tsx
around lines 102 to 104, the new translation fallback keys used for password
change errors are not defined in locale files and some backend password error
codes may be unhandled; add the keys
auth.common.password.toast.change_password.error.title and
auth.common.password.toast.change_password.error.message to every locale file
under packages/i18n/src/locales/* with appropriate translations, and then audit
authentication.helper.tsx (and bannerAlertErrorCodes) to ensure all backend
password-complexity error codes either map to a handled case that returns a
localized string or have corresponding translation keys/fallbacks so the t()
call never returns a raw key.

});
}
};
Expand Down