-
Notifications
You must be signed in to change notification settings - Fork 7
Why this exists
Issue #558 is the primary implementation context for language and internationalization quality. Issue #557 provides the accessibility context. This Discussion explores what native-quality writing across languages and RTL scripts requires beyond translating interface strings.
Product decision space
Consider manuscript, scene, world, and character terminology; tone and formality; RTL layout and mixed-direction content; punctuation, numbers, provider and model names; editor caret and selection; IME/input methods; locale-specific typography; date and number formats; shortcuts; security and privacy language; AI/provider terminology; and export typography.
A project language and UI language may be independent: an author may write a project in one language while using the interface in another. Mixed-direction text, quoted material, code-like identifiers, URLs, names, and provider/model terminology need deliberate boundaries rather than blanket direction changes.
Localization quality includes editing behavior, accessibility, import/export, error messages, security explanations, and AI/provider semantics. Translation should preserve meaning, tone, and user control without changing an implementation or privacy guarantee.
Role perspectives
Role-perspective note: The viewpoints below are maintainer-curated, AI-assisted design lenses. They are not separate community members, votes, user testimony, or evidence of consensus.
- 🌍 Multilingual author: write, search, organize, and export naturally across multiple project languages.
↔️ RTL author: mixed direction, caret, selection, punctuation, numbers, and layout should remain predictable.- ✍️ Translator/editor: terminology, tone, formality, typography, and project-specific language choices need control.
- ♿ Accessibility/i18n: screen readers, keyboard navigation, IME behavior, focus, zoom, and direction must work together.
- 🧭 Localization maintainer: keep keys, terminology, fallbacks, formats, and provider/security wording consistent and maintainable.
Questions
- Should project language and UI language be independent by default?
- Which terminology must be project-configurable rather than globally translated?
- What mixed-direction cases currently cause the most editing friction?
- Which typography, date/number, shortcut, and export behaviors are essential?
- How should AI/provider names and privacy/security explanations be localized without ambiguity?
- Which language quality checks should block an export or release?
Relationship to implementation
This Discussion is language, writing UX, accessibility, and localization design. #558 remains the implementation and acceptance authority; #557 remains the accessibility context. This Discussion does not change their priority, roadmap admission, acceptance criteria, or execution sequencing.