fix(i18n): bring Hebrew (he) locale to full key parity with English#670
fix(i18n): bring Hebrew (he) locale to full key parity with English#670yosef-chai wants to merge 1 commit into
Conversation
The he locale drifted behind the English source after fathah#530: 77 keys added to en were missing in Hebrew, so those strings fell back to English. - Translate the 77 missing keys, matching the existing he terminology and second-person-plural register: chat clarify dialog + queued-message counters, model registry browser, profile appearance / danger zone, AIML API & AtlasCloud providers, and the auxiliary-task model config. - Fix a stale brand string: common.appName "Hermes Agent" -> "Hermes One" (every other locale already uses "Hermes One"). - Add a regression test asserting he stays at full key parity with en, so future drift is caught in CI. he is now at 1261/1261 keys. Placeholders and inline markup preserved; brand/technical identifiers kept in Latin. typecheck, lint and tests pass.
Greptile SummaryThis PR brings the Hebrew (
Confidence Score: 4/5Translation-only change with no runtime code touched; safe to merge. All 77 added Hebrew strings have correct key names, preserved interpolation placeholders, and consistent RTL treatment. The one minor gap is that the new parity test only checks English→Hebrew completeness and will not catch stale Hebrew keys that no longer have an English counterpart. index.test.ts — the parity assertion is one-directional; worth considering adding the reverse check to catch future stale keys. Important Files Changed
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| it("keeps the he locale at full key parity with en", () => { | ||
| const enKeys = flattenKeys( | ||
| resources.en.translation as Record<string, unknown>, | ||
| ); | ||
| const heKeys = new Set( | ||
| flattenKeys(resources.he.translation as Record<string, unknown>), | ||
| ); | ||
| expect(enKeys.filter((key) => !heKeys.has(key))).toEqual([]); | ||
| }); |
There was a problem hiding this comment.
The test only asserts that every en key exists in he, but it does not check the reverse — so stale he-only keys (translations added to Hebrew but later removed from English, or mistakenly named keys) will accumulate silently without being caught. Over time this can lead to dead entries in the Hebrew locale with no CI signal. Adding a reverse check, heKeys.filter(k => !enKeys.has(k)), would catch this class of drift before it compounds.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
1 participant
Summary
Follow-up to #530 (which added the Hebrew locale). Since that PR merged, the English source gained new strings that were never added to Hebrew, so the
helocale had drifted to 1184/1261 keys — 77 missing. Those keys silently fell back to English for Hebrew users. This PR restores full key parity (1261/1261) and adds a guard so it can't regress.What changed
1. Translate the 77 missing keys (matching the existing
heterminology and second-person-plural register, with placeholders/markup preserved and brand/technical identifiers kept in Latin):chatclarify.*),searchModels, queued-message counters (queuedCount/Attachment/Cancel)constantsauxiliary*)agentseditAppearance,dangerZone,deleteProfile*, …)modelsregistry*,browseRegistry,allProviders)navigationshowRecentSessions/hideRecentSessionscommondone,editsetup/sessions/gatewaylocalPresets.atlascloud,closeTab,setupFirst2. Fix a stale brand string —
common.appNamewas still"Hermes Agent"; every other locale already uses"Hermes One". Updated to match.(Note:
gateway.subtitleandinstall.installingHermesintentionally keep "Hermes Agent" because the English source still uses it there.)3. Add a regression test —
index.test.tsnow asserts thehelocale is at full key parity withen, so future English-side additions that miss Hebrew are caught in CI.Verification
npm run typecheck— passesnpm test— passes (incl. the new parity test)npm run lint— 0 errorsNotes
{{interpolation}}placeholders and inline markup are preserved; RTL marks added where a string begins with a Latin token or{{name}}, consistent with existinghestrings.