Twelve catalog keys are stored with dots in their names, a shape language packs cannot use #28017

Operating system

All platforms. This is catalog data and a check script, not platform code.

Orca version

main at cef4d29096. One of the twelve keys ships in v1.4.223 and v1.4.224; the other eleven are not in a release yet.

Details

src/renderer/src/i18n/locales/en.json stores twelve strings as root-level entries whose name spells out the whole path, instead of inside the nested settings object:

• "settings.appearance.chat.title" — line 19673, added in Add chat appearance settings: text size, code size, width #25657 and shipped since v1.4.223. The nested settings.appearance.chat.title is there too, with the same text, so this entry is a duplicate.
• eleven "settings.agents.*" entries — lines 19754–19764, added in Edit agent launch settings on the workspace host #26479. They have no nested counterpart, and the same eleven are stored flat in es, fr, ja, ko and zh.

Nothing in the app notices. i18next falls back to a flat key when the nested path is missing, and verify-localization-catalog.mjs flattens both shapes to the same dotted path.

Language packs do notice. parsePluginLanguagePackArtifact rejects any catalog key that contains a dot (hasUnsafeCatalogKeyCharacter), and one rejected key rejects the whole pack:

{"settings.agents.save": "…"}              → catalog key settings.agents.save is not safe
{"settings": {"agents": {"save": "…"}}}    → accepted

So:

• A pack generated by mirroring en.json already fails to load on v1.4.223 and v1.4.224 because of the first key. The Traditional Chinese pack ran into exactly this (comment).
• A pack that drops the keys it may not carry will leave the eleven host agent-settings strings in English once Edit agent launch settings on the workspace host #26479 ships.
• Writing the eleven nested in the pack does work, because i18next finds the nested path first. But every pack author has to find that out separately.

The fix is to store the twelve the way pnpm sync:localization-catalog writes keys: nested. Paths and values stay the same, so no call site changes. A check in the catalog verifier would keep the shape from coming back.

First raised in #10592 (details).

Representative visual evidence

N/A. The app renders the same text before and after. The two parser results above come from parsePluginLanguagePackArtifact on main.

AI disclosure

Claude Opus 5.5 in Claude Code located the keys, traced them to the two PRs and ran the parser on both shapes. I directed the work and approved publishing it.