feat(i18n): Add Korean language support - #3321
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughAdds Korean documentation and Korean locale support: introduces Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 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 Tip CodeRabbit can use your project's `golangci-lint` configuration to improve the quality of Go code reviews.Add a configuration file to your project to customize how CodeRabbit runs |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
web/src/helpers/utils.jsx (1)
125-151:⚠️ Potential issue | 🟠 MajorGuard
error.responsewith optional chaining before accessingstatus.Line 127 directly dereferences
error.response.statuswithout checking ifresponseexists. For network errors (CORS failures, timeouts, connection refused), AxiosError has noresponseproperty, causing a TypeError that breaks error handling and prevents proper error toasts.Proposed fix
export function showError(error) { console.error(error); if (error.message) { if (error.name === 'AxiosError') { - switch (error.response.status) { + const status = error.response?.status; + switch (status) { case 401: // 清除用户状态 localStorage.removeItem('user'); // toast.error('错误：未登录或登录已过期，请重新登录！', showErrorOptions); window.location.href = '/login?expired=true'; break; case 429: Toast.error(i18n.t('错误：请求次数过多，请稍后再试！')); break; case 500: Toast.error(i18n.t('错误：服务器内部错误，请联系管理员！')); break; case 405: Toast.info(i18n.t('本站仅作演示之用，无服务端！')); break; default: Toast.error(i18n.t('错误：') + error.message); } return; } Toast.error(i18n.t('错误：') + error.message); } else { Toast.error(i18n.t('错误：') + error); } }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@web/src/helpers/utils.jsx` around lines 125 - 151, The switch on error.response.status can throw when error.response is undefined (network/CORS/timeouts); update the AxiosError branch in the error handler to first check for error.response (e.g., if (!error.response) { Toast.error(i18n.t('错误：') + (error.message || error)); return; }) or use optional chaining before accessing status, then only run the switch when response exists; keep existing cases (401/429/500/405/default) and the redirect to /login intact for the 401 path.
🧹 Nitpick comments (1)
web/src/i18n/i18n.js (1)
26-26: Consider using ISO 639-1 locale code 'ko' instead of 'kr' for Korean.The standard ISO 639-1 code for Korean is
ko, notkr. Whilekris the country code for South Korea, usingkowould align with language detection libraries likei18next-browser-languagedetectorand browser language settings (e.g.,ko-KR). However, if the project intentionally useskrfor consistency with other non-standard codes, this is acceptable.Also applies to: 45-45
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@web/src/i18n/i18n.js` at line 26, The import and locale key use 'kr' (krTranslation and ./locales/kr.json) should be changed to the ISO 639-1 language code 'ko': rename the file ./locales/kr.json to ./locales/ko.json, update the import to koTranslation, and replace any resource key or registration that uses 'kr' (e.g., the i18n resources map where 'kr' is referenced) to 'ko' so language detection and browser locales (like ko-KR) work correctly; ensure you update all occurrences (including the other mentioned usage around the resource registration) so nothing still references 'kr'.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@README.kr.md`:
- Line 51: The anchor link href currently uses "#-도움말 및-지원" which contains a
space and may not match the generated heading ID; update the href to the
hyphenated ID that matches the heading (e.g., "#-도움말-및-지원") or confirm the
actual generated ID for the heading "## 💬 도움말 및 지원" and adjust the link
accordingly so the anchor navigation works.
In `@web/src/components/auth/TwoFAVerification.jsx`:
- Line 58: The component calls t('登录成功') but never imports or invokes the i18n
hook; import useTranslation from react-i18next at the top and call
useTranslation() inside the TwoFAVerification component to get the t function,
then replace the undefined t usage (e.g., in the showSuccess(t('登录成功')) call)
with the t returned from the hook so the translation function is defined.
In `@web/src/components/layout/headerbar/LanguageSelector.jsx`:
- Around line 61-66: supportedLanguages is missing the Korean code and
normalizeLanguage() doesn't map browser outputs ('ko' / 'ko-KR') to the app's
internal code, so Korean browsers fall back incorrectly; fix by either (A)
adding 'kr' to the supportedLanguages array and extending normalizeLanguage() to
map 'ko' and /^ko(-|$)/ to 'kr' (so detectors produce the app's 'kr'), or (B)
switch all Korean identifiers to the ISO code 'ko' (update supportedLanguages,
i18n resources, normalizeLanguage mappings, and any UI bits like
LanguageSelector's onLanguageChange/currentLang usage) so detection and
resources align; choose one approach and apply the change consistently across
supportedLanguages, normalizeLanguage, i18n resources, and the language selector
logic.
---
Outside diff comments:
In `@web/src/helpers/utils.jsx`:
- Around line 125-151: The switch on error.response.status can throw when
error.response is undefined (network/CORS/timeouts); update the AxiosError
branch in the error handler to first check for error.response (e.g., if
(!error.response) { Toast.error(i18n.t('错误：') + (error.message || error));
return; }) or use optional chaining before accessing status, then only run the
switch when response exists; keep existing cases (401/429/500/405/default) and
the redirect to /login intact for the 401 path.
---
Nitpick comments:
In `@web/src/i18n/i18n.js`:
- Line 26: The import and locale key use 'kr' (krTranslation and
./locales/kr.json) should be changed to the ISO 639-1 language code 'ko': rename
the file ./locales/kr.json to ./locales/ko.json, update the import to
koTranslation, and replace any resource key or registration that uses 'kr'
(e.g., the i18n resources map where 'kr' is referenced) to 'ko' so language
detection and browser locales (like ko-KR) work correctly; ensure you update all
occurrences (including the other mentioned usage around the resource
registration) so nothing still references 'kr'.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 81a9b11d-d69e-4a23-b193-2cc3b7fa2d74
📒 Files selected for processing (14)
README.kr.mdweb/src/components/auth/LoginForm.jsxweb/src/components/auth/RegisterForm.jsxweb/src/components/auth/TwoFAVerification.jsxweb/src/components/layout/headerbar/LanguageSelector.jsxweb/src/components/settings/OtherSetting.jsxweb/src/components/settings/SystemSetting.jsxweb/src/components/table/channels/modals/EditTagModal.jsxweb/src/helpers/api.jsweb/src/helpers/utils.jsxweb/src/hooks/channels/useChannelsData.jsxweb/src/i18n/i18n.jsweb/src/i18n/locales/kr.jsonweb/src/pages/Setting/Operation/SettingsChannelAffinity.jsx
2d1fa39 to
9df1489
Compare
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
web/src/components/auth/LoginForm.jsx (2)
250-255:⚠️ Potential issue | 🟡 MinorRemaining hardcoded Chinese text causes partial localization gaps.
Line 253, Line 254, Line 433, and Line 461 still use raw Chinese strings instead of
t(...). Inkrlocale these remain untranslated.🌐 Suggested patch
if (username === 'root' && password === '123456') { Modal.error({ - title: '您正在使用默认密码！', - content: '请立刻修改默认密码！', + title: t('您正在使用默认密码！'), + content: t('请立刻修改默认密码！'), centered: true, }); } @@ if (!success) { - showError(message || '无法发起 Passkey 登录'); + showError(message || t('无法发起 Passkey 登录')); return; } @@ if (finish.success) { @@ } else { - showError(finish.message || 'Passkey 登录失败，请重试'); + showError(finish.message || t('Passkey 登录失败，请重试')); }As per coding guidelines: Frontend i18n must use
useTranslation()and callt('中文key')in components.Also applies to: 433-434, 458-462
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@web/src/components/auth/LoginForm.jsx` around lines 250 - 255, LoginForm currently contains hardcoded Chinese UI strings (e.g., the success message passed to showSuccess and the Modal.error title/content) which break i18n; import and call useTranslation() in the LoginForm component and replace raw strings with t('...') keys (e.g., t('login.success'), t('login.defaultPasswordTitle'), t('login.defaultPasswordContent')), ensure all other occurrences referenced in the review (the other modal/messages in the same component) are similarly replaced, and keep the original showSuccess and Modal.error calls but pass translated strings returned by t; add or update locale keys in your locales files accordingly.
187-208:⚠️ Potential issue | 🔴 CriticalAdd all 41 missing translation keys to
web/src/i18n/locales/kr.json.All keys referenced in LoginForm.jsx are missing from the Korean locale file. This affects the entire login form and will cause Korean users to see Chinese text. The missing keys include UI strings ("登 录", "登录成功！"), error messages ("登录失败，请重试", "Passkey 验证失败，请重试"), authentication method labels ("使用 Discord 继续", "使用 微信 继续"), and API endpoints ("/api/user/passkey/login/begin", "/api/user/passkey/login/finish"), among others (41 total).
List of missing keys (all 41)
- /api/user/passkey/login/begin
- /api/user/passkey/login/finish
- Passkey 登录失败，请重试
- Passkey 验证失败，请重试
- aff
- expired
- 使用 Discord 继续
- 使用 LinuxDO 继续
- 使用 OIDC 继续
- 使用 Passkey 登录
- 使用 {{name}} 继续
- 使用 微信 继续
- 使用 邮箱或用户名 登录
- 其他登录选项
- 和
- 密码
- 已取消 Passkey 登录
- 当前浏览器不支持 Passkey
- 当前环境无法使用 Passkey 登录
- 微信扫码关注公众号，输入「验证码」获取验证码（三分钟内有效）
- 微信扫码登录
- 忘记密码？
- 我已阅读并同意
- 或
- 未登录或登录已过期，请重新登录
- 没有账户？
- 注册
- 用户协议
- 用户名或邮箱
- 登 录
- 登录
- 登录失败，请重试
- 登录成功！
- 继续
- 请先阅读并同意用户协议和隐私政策
- 请稍后几秒重试，Turnstile 正在检查用户环境！
- 请输入您的密码
- 请输入您的用户名或邮箱地址
- 请输入用户名和密码！
- 隐私政策
- 验证码
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@web/src/components/auth/LoginForm.jsx` around lines 187 - 208, The Korean locale is missing 41 translation keys used in LoginForm.jsx (strings passed to t(...) and messages shown via showSuccess/showError like "登录成功！", "登录失败，请重试", Turnstile message, UI labels such as "登 录", "使用 微信 继续", API key names like "/api/user/passkey/login/begin", etc.), so add all listed keys into web/src/i18n/locales/kr.json with appropriate Korean translations; ensure the keys exactly match the Chinese keys used in LoginForm.jsx (so t('登录成功！'), t('请稍后几秒重试，Turnstile 正在检查用户环境！'), etc.) and update any pluralization/placeholders (e.g., "使用 {{name}} 继续") to preserve interpolation syntax used in the component.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@web/src/components/auth/LoginForm.jsx`:
- Around line 250-255: LoginForm currently contains hardcoded Chinese UI strings
(e.g., the success message passed to showSuccess and the Modal.error
title/content) which break i18n; import and call useTranslation() in the
LoginForm component and replace raw strings with t('...') keys (e.g.,
t('login.success'), t('login.defaultPasswordTitle'),
t('login.defaultPasswordContent')), ensure all other occurrences referenced in
the review (the other modal/messages in the same component) are similarly
replaced, and keep the original showSuccess and Modal.error calls but pass
translated strings returned by t; add or update locale keys in your locales
files accordingly.
- Around line 187-208: The Korean locale is missing 41 translation keys used in
LoginForm.jsx (strings passed to t(...) and messages shown via
showSuccess/showError like "登录成功！", "登录失败，请重试", Turnstile message, UI labels
such as "登 录", "使用 微信 继续", API key names like "/api/user/passkey/login/begin",
etc.), so add all listed keys into web/src/i18n/locales/kr.json with appropriate
Korean translations; ensure the keys exactly match the Chinese keys used in
LoginForm.jsx (so t('登录成功！'), t('请稍后几秒重试，Turnstile 正在检查用户环境！'), etc.) and update
any pluralization/placeholders (e.g., "使用 {{name}} 继续") to preserve
interpolation syntax used in the component.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 1a911359-b178-4c5a-b235-6086bbb51c59
📒 Files selected for processing (14)
README.kr.mdweb/src/components/auth/LoginForm.jsxweb/src/components/auth/RegisterForm.jsxweb/src/components/auth/TwoFAVerification.jsxweb/src/components/layout/headerbar/LanguageSelector.jsxweb/src/components/settings/OtherSetting.jsxweb/src/components/settings/SystemSetting.jsxweb/src/components/table/channels/modals/EditTagModal.jsxweb/src/helpers/api.jsweb/src/helpers/utils.jsxweb/src/hooks/channels/useChannelsData.jsxweb/src/i18n/i18n.jsweb/src/i18n/locales/kr.jsonweb/src/pages/Setting/Operation/SettingsChannelAffinity.jsx
🚧 Files skipped from review as they are similar to previous changes (11)
- web/src/components/table/channels/modals/EditTagModal.jsx
- web/src/components/auth/RegisterForm.jsx
- web/src/components/auth/TwoFAVerification.jsx
- web/src/components/settings/OtherSetting.jsx
- web/src/helpers/utils.jsx
- web/src/pages/Setting/Operation/SettingsChannelAffinity.jsx
- web/src/helpers/api.js
- web/src/i18n/i18n.js
- web/src/hooks/channels/useChannelsData.jsx
- web/src/components/layout/headerbar/LanguageSelector.jsx
- README.kr.md
- Add README.kr.md (Korean translation) - Add web/src/i18n/locales/kr.json (Korean translation file) - Add Korean language link to all README files - Add Korean language support to i18n settings (keys.go, i18n.js, language.js) - Add Korean option to LanguageSelector component - Add Korean support to index.jsx
- Fix error.response optional chaining in utils.jsx - Add useTranslation hook import in TwoFAVerification.jsx
dceaaa3 to
93c4475
Compare
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
web/src/components/auth/LoginForm.jsx (1)
430-462:⚠️ Potential issue | 🟡 MinorWrap the Passkey fallback error messages with
t()for i18n consistency.Lines 433 and 461 contain hardcoded Chinese fallback strings that bypass i18n, causing non-English locales to display Chinese text when backend messages are empty. Line 467 already demonstrates the correct pattern.
Suggested patch
- showError(message || '无法发起 Passkey 登录'); + showError(message || t('无法发起 Passkey 登录')); @@ - showError(finish.message || 'Passkey 登录失败，请重试'); + showError(finish.message || t('Passkey 登录失败，请重试'));🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@web/src/components/auth/LoginForm.jsx` around lines 430 - 462, The two hardcoded Chinese fallback messages passed to showError in the Passkey login flow should be wrapped with the i18n translator t(): replace the literal strings used after prepareCredentialRequestOptions/buildAssertionResult failure and after the finish.failure branch with t('...') so they use localization; update the showError calls around the buildAssertionResult check (where it currently shows 'Passkey 验证失败，请重试') and the finish.error branch (where it shows 'Passkey 登录失败，请重试') to call t(...) instead, leaving API.post('/api/user/passkey/login/begin') and API.post('/api/user/passkey/login/finish') logic unchanged.
🧹 Nitpick comments (1)
web/src/helpers/api.js (1)
333-333: Inconsistent navigation behavior compared to OIDC.
onOIDCClickedhas anopenInNewTabparameter with explicit control (window.open(..., '_blank')vswindow.location.href), butonCustomOAuthClickedalways useswindow.open()without a target, which typically opens a new tab but behavior varies by browser.Consider adding the same
openInNewTabparameter for consistency, or document this as intentional.♻️ Suggested change for consistency
-export async function onCustomOAuthClicked(provider, options = {}) { +export async function onCustomOAuthClicked(provider, openInNewTab = false, options = {}) { const state = await prepareOAuthState(options); if (!state) return; try { // ... existing code ... - window.open(authUrl.toString()); + if (openInNewTab) { + window.open(authUrl.toString(), '_blank'); + } else { + window.location.href = authUrl.toString(); + } } catch (error) {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@web/src/helpers/api.js` at line 333, The navigation in onCustomOAuthClicked is inconsistent with onOIDCClicked because it always calls window.open(authUrl.toString()) with no target; update onCustomOAuthClicked to accept the same openInNewTab boolean parameter used by onOIDCClicked and use it to decide between window.open(authUrl.toString(), '_blank') when openInNewTab is true and window.location.href = authUrl.toString() when false (mirroring onOIDCClicked's behavior), ensuring both functions expose the same navigation control.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@web/src/components/auth/LoginForm.jsx`:
- Around line 430-462: The two hardcoded Chinese fallback messages passed to
showError in the Passkey login flow should be wrapped with the i18n translator
t(): replace the literal strings used after
prepareCredentialRequestOptions/buildAssertionResult failure and after the
finish.failure branch with t('...') so they use localization; update the
showError calls around the buildAssertionResult check (where it currently shows
'Passkey 验证失败，请重试') and the finish.error branch (where it shows 'Passkey
登录失败，请重试') to call t(...) instead, leaving
API.post('/api/user/passkey/login/begin') and
API.post('/api/user/passkey/login/finish') logic unchanged.
---
Nitpick comments:
In `@web/src/helpers/api.js`:
- Line 333: The navigation in onCustomOAuthClicked is inconsistent with
onOIDCClicked because it always calls window.open(authUrl.toString()) with no
target; update onCustomOAuthClicked to accept the same openInNewTab boolean
parameter used by onOIDCClicked and use it to decide between
window.open(authUrl.toString(), '_blank') when openInNewTab is true and
window.location.href = authUrl.toString() when false (mirroring onOIDCClicked's
behavior), ensuring both functions expose the same navigation control.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: d46892f0-5c6e-4ce2-8a84-fad72c27c6db
📒 Files selected for processing (14)
README.kr.mdweb/src/components/auth/LoginForm.jsxweb/src/components/auth/RegisterForm.jsxweb/src/components/auth/TwoFAVerification.jsxweb/src/components/layout/headerbar/LanguageSelector.jsxweb/src/components/settings/OtherSetting.jsxweb/src/components/settings/SystemSetting.jsxweb/src/components/table/channels/modals/EditTagModal.jsxweb/src/helpers/api.jsweb/src/helpers/utils.jsxweb/src/hooks/channels/useChannelsData.jsxweb/src/i18n/i18n.jsweb/src/i18n/locales/kr.jsonweb/src/pages/Setting/Operation/SettingsChannelAffinity.jsx
✅ Files skipped from review due to trivial changes (5)
- web/src/components/auth/TwoFAVerification.jsx
- web/src/i18n/i18n.js
- web/src/components/auth/RegisterForm.jsx
- web/src/components/settings/SystemSetting.jsx
- README.kr.md
🚧 Files skipped from review as they are similar to previous changes (5)
- web/src/components/table/channels/modals/EditTagModal.jsx
- web/src/components/settings/OtherSetting.jsx
- web/src/pages/Setting/Operation/SettingsChannelAffinity.jsx
- web/src/hooks/channels/useChannelsData.jsx
- web/src/helpers/utils.jsx
…omponent - Wrap all hardcoded Chinese strings in t() function for proper i18n - Add missing Korean translation keys to kr.json - Update language.js with Korean language support
c08c2a5 to
3e70ca1
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
web/src/i18n/language.js (2)
57-57: Minor: Redundant explicit check.The condition
lower === 'ko'is already covered by the regex/^ko(-|$)/(which matches'ko'via the end-of-string anchor$). Simplifying to just the regex would be slightly cleaner.💡 Optional simplification
- if (lower === 'ko' || /^ko(-|$)/.test(lower)) { + if (/^ko(-|$)/.test(lower)) { return 'kr'; }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@web/src/i18n/language.js` at line 57, The if condition checking language uses a redundant explicit equality check; replace the compound condition "if (lower === 'ko' || /^ko(-|$)/.test(lower))" with just the regex-based test to simplify logic—locate the if statement referencing the variable "lower" in web/src/i18n/language.js and remove the "lower === 'ko' ||" part so the condition is solely "/^ko(-|$)/.test(lower)".
27-27: Consider standardizing to'ko'for consistency with language codes across the projectThe codebase intentionally uses
'kr'(ISO 3166-1 country code for South Korea) instead of the standard ISO 639-1 language code'ko'. While this is internally consistent—evidenced by the dedicatednormalizeLanguage()function that maps'ko'to'kr'and the correspondingkr.jsontranslation file—it diverges from the convention used by other languages in the array ('en','fr','ru','ja','vi').The implementation works correctly, with browser language detection properly normalized. However, using the standard
'ko'throughout would improve consistency with language naming conventions and reduce potential confusion for developers and integrations with tools expecting ISO 639-1 codes.If
'kr'is intentional for project-specific reasons, consider adding a comment explaining the choice for future maintainers.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@web/src/i18n/language.js` at line 27, Replace the nonstandard 'kr' language code with the ISO 639-1 'ko' across the project: update the languages array entry (replace 'kr' with 'ko'), rename the translation file kr.json → ko.json, and adjust normalizeLanguage() so it maps browser 'ko' to the internal key (or remove any mapping from 'ko'→'kr'); also update any code that references 'kr' to use 'ko' (or add a short comment in language.js explaining why 'kr' is intentionally used if you choose to keep it).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@web/src/i18n/language.js`:
- Around line 57-60: The LanguageDetector runs before normalizeLanguage is
applied, causing 'ko'/'ko-KR' to not match supportedLngs ('kr'); add a custom
detector object (e.g., normalizedDetector with type: 'custom', async: false,
init: ()=>{}, detect: ()=>normalizeLanguage(LanguageDetector.detect())) and plug
it into i18n via i18n.use(normalizedDetector) before the rest of initialization
so detected values are normalized to 'kr' before i18next checks supportedLngs;
optionally simplify the normalizeLanguage Korean branch by removing the
redundant lower === 'ko' check since /^ko(-|$)/ already covers it.
---
Nitpick comments:
In `@web/src/i18n/language.js`:
- Line 57: The if condition checking language uses a redundant explicit equality
check; replace the compound condition "if (lower === 'ko' ||
/^ko(-|$)/.test(lower))" with just the regex-based test to simplify logic—locate
the if statement referencing the variable "lower" in web/src/i18n/language.js
and remove the "lower === 'ko' ||" part so the condition is solely
"/^ko(-|$)/.test(lower)".
- Line 27: Replace the nonstandard 'kr' language code with the ISO 639-1 'ko'
across the project: update the languages array entry (replace 'kr' with 'ko'),
rename the translation file kr.json → ko.json, and adjust normalizeLanguage() so
it maps browser 'ko' to the internal key (or remove any mapping from 'ko'→'kr');
also update any code that references 'kr' to use 'ko' (or add a short comment in
language.js explaining why 'kr' is intentionally used if you choose to keep it).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f29a8fff-9872-49c0-9995-cbb7f707e868
📒 Files selected for processing (3)
web/src/components/auth/TwoFAVerification.jsxweb/src/i18n/language.jsweb/src/i18n/locales/kr.json
✅ Files skipped from review due to trivial changes (1)
- web/src/components/auth/TwoFAVerification.jsx
…dLngs - Wrap LanguageDetector.detect() to normalize 'ko'/'ko-KR' to 'kr' - Simplify Korean regex in normalizeLanguage (remove redundant 'ko' check)
- supportedLanguages 배열에서 'kr' → 'ko' 변경 - language.js에서 한국어 변환 로직 정리 - i18n.js에서 import 및 resources 키 변경 - PreferencesSettings.jsx와 LanguageSelector.jsx의 언어 옵션 업데이트 - kr.json을 ko.json으로 파일명 변경
|
Translation Bugs (ko.json)
"页脚内容更新失败": "푰터 내용 업데이트에 실패했습니다"
"每个备用码只能使用一次": "백업 코드는 한 번만 사용할 수 있습니다 있습니다"
"备用码必须是8位": "백업 코드는 자리여야 합니다"
"kr": "한국어" File Naming In particular, the changes in web/src/helpers/api.js appear to modify OAuth redirect behavior (window.open vs window.location.href), which is a functional change beyond i18n scope. Please fix the 4 translation bugs and the filename, and I'll take another look. Thanks for the effort! |
|
I will proceed smoothly in the new pull request. |
2 participants
Summary by CodeRabbit
Documentation
New Features
Localization