@@ -38,6 +38,7 @@ tooling over novelty or abstraction.
3838- ** Runtime:** Node.js (Docker)
3939- ** Linting:** ESLint (flat config)
4040- ** Formatting:** Prettier (project-defined config)
41+ - ** i18n:** i18next (required)
4142
4243Do not:
4344
@@ -49,6 +50,70 @@ Do not:
4950
5051---
5152
53+ ## Internationalisation (i18n) requirements (mandatory)
54+
55+ This project ** must** use an established i18n library, not a custom implementation.
56+
57+ ### Library
58+
59+ - Use ** i18next** with a Svelte-compatible integration (do not build our own
60+ i18n layer).
61+ - Keep translations in JSON resource files.
62+ - Prefer ** literal Unicode characters** in i18n JSON (e.g. ` … ` , ` £ ` , ` → ` )
63+ over HTML entities (e.g. ` … ` ) or escaped codepoints (e.g. ` \u2026 ` )
64+ unless a tool forces escaping.
65+
66+ ### Supported locales (for now)
67+
68+ - ` en ` (English, International) — default
69+ - ` en-GB ` (English, British)
70+
71+ ### Locale selection priority (authoritative)
72+
73+ 1 . User-selected locale in the UI (persisted)
74+ 2 . Browser language headers (e.g. ` navigator.languages ` )
75+ 3 . Fallback to ` en `
76+
77+ ### Fallback behaviour
78+
79+ - ` en-GB ` ** must** fall back to ` en ` for missing keys so British English only
80+ needs to override deltas.
81+ - Do not duplicate ` en ` strings into ` en-GB ` unless the wording/spelling
82+ genuinely differs.
83+
84+ ### Hard rule: no new plain text in the UI
85+
86+ - ** Do not introduce new user-visible strings inline** in Svelte components,
87+ stores, routes, or helpers.
88+ - Any new user-visible text ** must** be added as an i18n string key and rendered
89+ via ` t(...) ` .
90+ - This includes:
91+ - Button labels, headings, breadcrumbs, empty states
92+ - Toasts, alerts, errors shown to users
93+ - Inspector labels and field names
94+ - Modal titles and helper text
95+
96+ Allowed exceptions (narrow):
97+
98+ - User data (workflow names, task names, branch labels, etc.)
99+ - Debug-only ` console.* ` output (must not be user-facing)
100+
101+ ### Key naming + structure guidance
102+
103+ - Use a predictable, boring hierarchy (e.g. ` editor.* ` , ` sidebar.* ` , ` inspector.* ` ,
104+ ` errors.* ` , ` actions.* ` ).
105+ - Prefer stable keys over copy-based keys (do not bake full sentences into key
106+ names).
107+ - Keep strings short and composable where it helps reuse, but do not over-abstract.
108+
109+ ### Testing expectation
110+
111+ - Any feature work that introduces UI text must include the corresponding ` en ` key.
112+ - If a string is British-specific, add it to ` en-GB ` ; otherwise only ` en ` is
113+ required.
114+
115+ ---
116+
52117## Runtime & deployment assumptions
53118
54119- The app runs as a ** Node server** , not a static site
@@ -210,6 +275,8 @@ Validation errors must be:
210275- Inspector panels edit ** node config** , not graph topology
211276- UI must reflect validation state clearly
212277- Avoid auto-magic graph rewrites
278+ - All user-visible UI strings must come from i18n resources via ` t(...) ` (no
279+ inline copy).
213280
214281---
215282
@@ -454,3 +521,5 @@ When asked to “build” something:
454521
455522- Start with the smallest viable, end-to-end slice
456523- Prefer scaffolding that can grow over finished-looking systems
524+ - Add or extend tests to lock in behaviour
525+ - All new user-visible UI text must use i18n (i18next), not inline strings
0 commit comments