Context
ROADMAP.md explicitly lists a human native review for the 14 Beta/RTL locales as v2.0 Foundation work. The repository already enforces structural i18n properties such as key/placeholder parity and has focused security-language work in #382, but automated parity cannot establish naturalness, idiom, tone, grammatical quality or culturally correct UX copy.
There is currently no durable issue that owns this human-language acceptance pass.
Goal
Perform a native-speaker quality review of every locale currently classified by repository policy as Beta/RTL/non-primary, while preserving the existing source/generated-bundle workflow and keeping security-sensitive truth synchronized with implementation.
The authoritative locale classification must be taken from the live repository registry/policy at execution time. If the set changes from 14 before work begins, update this issue's matrix from that authority rather than hard-coding a stale list.
What automated checks already prove — and what they do not
Automated checks should continue to prove:
- key parity;
- placeholder/interpolation parity;
- JSON/build validity;
- deterministic generated bundles;
- required fallback availability.
Human review must additionally prove:
- natural native phrasing;
- grammar and inflection;
- consistent product terminology;
- appropriate formal/informal register;
- punctuation/capitalization conventions;
- avoidance of literal/awkward machine translation;
- correct plural/context meaning where the source semantics require it;
- understandable error/recovery/security language;
- culturally sensible date/number/keyboard wording where applicable.
Review categories
Audit at least:
CORE NAVIGATION / SETTINGS
WELCOME / ONBOARDING
PROJECT / MANUSCRIPT / BINDER TERMINOLOGY
AI PROVIDERS / LOCAL AI / VOICE
IMPORT / EXPORT / BACKUP
OFFLINE / STORAGE / RECOVERY
SECURITY / PRIVACY / ENCRYPTION
COLLABORATION / LOCAL-FIRST
UPDATES / INSTALL / PWA
ACCESSIBILITY COPY
ERRORS / VALIDATION / EMPTY STATES
Prioritize high-risk and high-frequency copy before long-tail descriptive text.
Security/privacy wording
Coordinate with #382 and #549.
Security-sensitive strings must be reviewed against current implementation truth, not merely translated literally. In particular do not conflate:
- API-key protection;
- project/manuscript at-rest encryption;
- collaboration transport encryption;
- local device execution;
- local-network Ollama;
- direct cloud provider routing;
- WorldScript proxy routing.
A fluent translation of a false English claim is still a defect.
RTL-specific acceptance
For RTL locales, human review must include actual UI use rather than string files alone:
- bidi ordering around mixed Latin/provider/model names;
- punctuation/numbers/paths/shortcuts;
- icons with directional meaning;
- input/caret/selection behavior;
- mirrored vs non-mirrored controls;
- dialogs/toasts/menus;
- code/file/path snippets that should remain LTR.
Coordinate UI/accessibility defects with #557 rather than hiding them as translation edits.
Workflow / provenance
- Edit locale source files only according to repository policy.
- Do not hand-edit generated runtime bundles.
- Regenerate bundles with the canonical repository command.
- Record reviewer language/locale competence without collecting unnecessary personal information.
- Prefer review in bounded batches so corrections remain reviewable.
- Do not mechanically promote a locale to “production/stable” solely because all keys have native text.
Acceptance matrix
For each live Beta/RTL locale record:
native reviewer completed
high-risk security/recovery copy reviewed
core writing workflow reviewed
AI/provider terminology reviewed
placeholder/plural checks green
RTL interactive pass if applicable
remaining known limitations
release classification recommendation
Acceptance criteria
Non-goals
Context
ROADMAP.mdexplicitly lists a human native review for the 14 Beta/RTL locales as v2.0 Foundation work. The repository already enforces structural i18n properties such as key/placeholder parity and has focused security-language work in #382, but automated parity cannot establish naturalness, idiom, tone, grammatical quality or culturally correct UX copy.There is currently no durable issue that owns this human-language acceptance pass.
Goal
Perform a native-speaker quality review of every locale currently classified by repository policy as Beta/RTL/non-primary, while preserving the existing source/generated-bundle workflow and keeping security-sensitive truth synchronized with implementation.
The authoritative locale classification must be taken from the live repository registry/policy at execution time. If the set changes from 14 before work begins, update this issue's matrix from that authority rather than hard-coding a stale list.
What automated checks already prove — and what they do not
Automated checks should continue to prove:
Human review must additionally prove:
Review categories
Audit at least:
Prioritize high-risk and high-frequency copy before long-tail descriptive text.
Security/privacy wording
Coordinate with #382 and #549.
Security-sensitive strings must be reviewed against current implementation truth, not merely translated literally. In particular do not conflate:
A fluent translation of a false English claim is still a defect.
RTL-specific acceptance
For RTL locales, human review must include actual UI use rather than string files alone:
Coordinate UI/accessibility defects with #557 rather than hiding them as translation edits.
Workflow / provenance
Acceptance matrix
For each live Beta/RTL locale record:
Acceptance criteria
Non-goals