Writing across languages and RTL scripts — what does “native-quality” WorldScript need beyond translation?

[qnbs]

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.