Repository navigation
Conversation
… names
Twelve entries in en.json sat at the root under a name that spells out
the whole path ("settings.agents.save") instead of inside the nested
settings object. Eleven of them, the host agent-settings strings from
stablyai#26479, were flat in es, fr, ja, ko and zh as well. The twelfth
duplicated the nested settings.appearance.chat.title.
Built-in locales rendered them anyway, because i18next falls back to a
flat key when the nested path is missing. A language pack cannot use
that shape: the pack parser rejects any key that contains a dot, and
one rejected key rejects the whole catalog.
The eleven strings now live in settings.agents in all six catalogs and
the duplicate is gone. Every path and value is unchanged, so no call
site moves. The catalog verifier now fails on a key with a dot in its
name, in en.json and in the target catalogs.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Priority: ➖ Normal Severity of issue fixed: Medium Merge Risk: ⚪ Minimal · up to No outstanding issue is established by the supplied changes; the PR is mergeable after normal checks. Pre-merge checks |
  |
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Linked Issues check |  |
Issue #28017 requires the twelve entries to move to nested objects while preserving their paths and values. The verifier and test implement the dotted-key requirement, and the catalogs move the entrie… |
Revert the five Chinese value changes to the pre-PR values, while retaining the nested catalog structure, duplicate removal, verifier check, and test. |
| Out of Scope Changes check | |
The five Chinese terminology changes in zh.json are not needed to prevent dotted catalog keys or to add the verifier check. They change user-visible translations and are separate from the linked iss… |
Remove the unrelated 代理 to 智能体 translation changes from this pull request, or link a separate coding requirement that authorizes that translation update. |
| Docstring Coverage | |
Docstring coverage is 20.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 5 functions across 2 files. (1 skipped: 1… | Write docstrings for the functions missing them to satisfy the coverage threshold. |
✅ Passed checks (2 passed)
-
Check name Status Explanation Title check The title clearly identifies the primary change: nesting localization catalog keys that were incorrectly stored with dots in their names. Description check The description is complete and structured according to the repository template. It explains the change, reason, linked issue, testing, AI usage, review notes, scope, and checklist status. It also exp…
Full details: Linked Issues check
-
Explanation
Issue
#28017requires the twelve entries to move to nested objects while preserving their paths and values. The verifier and test implement the dotted-key requirement, and the catalogs move the entries correctly. However,zh.jsonchanges five values from代理to智能体forloadingHost,updateHost,readFailed,saveFailed, andhostDefaults. This does not preserve all values requested by#28017.
Full details: Out of Scope Changes check
-
Explanation
The five Chinese terminology changes in
zh.jsonare not needed to prevent dotted catalog keys or to add the verifier check. They change user-visible translations and are separate from the linked issue's requested data-shape correction. The remaining catalog, verifier, and test changes support#28017.
Full details: Docstring Coverage
-
Explanation
Docstring coverage is 20.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 5 functions across 2 files. (1 skipped: 1 unsupported.)
- Fix all pre-merge checks with AI
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
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 help to get the list of available commands.
![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
ℹ️ Review info
⚙️ Run configuration
- Configuration used: Repository UI
- Review profile: CHILL
- Plan: Advanced
- Run ID:
d80c46ac-1315-42c8-a0e8-aacae93ae161
📒 Files selected for processing (8)
config/scripts/verify-localization-catalog.mjsconfig/scripts/verify-localization-catalog.test.mjssrc/renderer/src/i18n/locales/en.jsonsrc/renderer/src/i18n/locales/es.jsonsrc/renderer/src/i18n/locales/fr.jsonsrc/renderer/src/i18n/locales/ja.jsonsrc/renderer/src/i18n/locales/ko.jsonsrc/renderer/src/i18n/locales/zh.json
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.
…tings strings Five of the eleven strings this branch nests said 代理 for "agent" in zh.json. The rest of the Chinese catalog calls an agent 智能体 and keeps 代理 for proxy and user-agent copy, so 代理设置 read as "proxy settings". The new wording is what the catalog's own repair policy (locale-phrase-fixes.mjs) produces for these five strings. Raised by CodeRabbit in review. Only zh.json changes, and only these five values.
|
Superseded by #28251, which landed the same change. |
1 participant
ELI5
Orca keeps its interface text in a tree:
settings, thenagents, thensave. Twelve entries were filed at the top of that tree under one long name,settings.agents.save, instead of in their place. Orca itself still finds them. A community language pack is not allowed to use names like that, so it cannot translate those strings the way the catalog writes them. This PR files the twelve where they belong and adds a check so it does not happen again.What Changed
settings.agents.*strings from Edit agent launch settings on the workspace host #26479 move from the root of the catalog into the existing nestedsettings.agentsobject, inen,es,fr,ja,koandzh.settings.appearance.chat.titleentry inen.json(from Add chat appearance settings: text size, code size, width #25657) is deleted. The nested entry with the same text was already there.verify-localization-catalog.mjsnow fails when a key inen.jsonor in a target catalog has a dot in its name, and lists the offending paths.zh.jsonnow call an agent 智能体, the word the rest of the Chinese catalog uses, instead of 代理, which reads as "proxy" (loadingHost,updateHost,readFailed,saveFailed,hostDefaults).Nothing a user sees changes in English, Spanish, French, Japanese or Korean: the flattened path → value map of those five catalogs is identical on both sides, and
en.jsonhas 15,813 paths either way. In Chinese every path is the same and five values differ, the ones named above. No call site is touched.Why
The built-in locales never noticed the flat entries. i18next falls back to a flat key when the nested path is missing, and the verifier flattens both shapes to the same dotted path.
Language packs do notice.
parsePluginLanguagePackArtifactrejects any catalog key that contains a dot (hasUnsafeCatalogKeyCharacter), and one rejected key rejects the whole pack:A pack that mirrors
en.jsonalready fails to load on v1.4.223 and v1.4.224 because of the duplicatechat.titleentry, and a pack that drops such keys would leave the eleven host agent-settings strings in English once #26479 ships. The eleven are not in a release yet, so nesting them now means no pack author has to special-case them.Two alternatives I did not take:
--fixrewrite dotted keys.sync:localization-catalogalready writes nested keys (setCatalogEntrysplits on the dot), so these twelve did not come from it. A failing check that lists the paths is enough.Linked Issue
Fixes #28017
First raised in #10592 (details, confirmation from the Traditional Chinese pack).
Visual Proof
N/A. No layout or interaction change: the catalogs hold the same paths, only stored nested, and i18next returns the same text for all twelve keys in five locales. In Chinese, five of them now read 智能体 where they read 代理.
Testing
I did not launch the app: there is no behavior to observe. The catalogs are compared as data instead.
main(cef4d29096), exits 1 and lists the twelve paths foren.json. On this branch it exits 0.rejects a key that carries its path in a dotted namecoversen.json, a target catalog, and that--fixleaves the file alone.en,es,fr,jaandko; inzh, the five reworded values and nothing else.pnpm lintandpnpm typecheckpass, and so do the fiveverify:localization-*scripts.vitest rununder Node overconfig/scripts,src/renderer/src/i18nandsrc/shared/plugins: 378 files. Two fail,ensure-native-runtimeandpatched-dependencies-frozen-install, and both fail the same way on a clean checkout ofmainon this machine.pnpm testandpnpm buildwere not run. Thepnpm testwrapper runs Vitest on Bun, and this machine has Bun 1.3.14 rather than the pinned 1.4.2.Run on macOS. The change is JSON and a Node script; nothing in it is platform-specific.
AI Disclosure
Claude Opus 5.5 in Claude Code made the change and ran the checks listed above. I directed the work and approved publishing it.
Review
Self-review, by risk:
zhdiffers only in the five values reworded in review, so nothing was dropped or renamed.locale-phrase-fixes.mjsrewrites 代理 to 智能体 when the English says "agent", andrepairCatalogrun overzh.jsonproduces exactly these five values.--fixdoes anything and never rewrites a file.mainand with fix(i18n): select whole count sentences at twelve more call sites #27974 and chore(i18n): retire unreferenced catalog keys and gate the scan #19801, which also touch the catalogs.Agent skill upstream boundary
Notes
Catalog data and a lint-time check only. No runtime code, no platform, SSH or mobile impact. Existing installs are unaffected: the keys the code asks for resolve to the same text, and the five reworded Chinese strings are not in a release yet.
Checklist
N/Awith reasonpnpm lint,pnpm typecheck,pnpm test, andpnpm buildpass (or CI will cover; local preferred) — lint and typecheck pass locally; test and build left to CI, see Testing