Summary
DreamCoder defaults to Chinese UI on first launch. Users on non-Chinese systems must navigate Settings — itself in Chinese — to switch to English. This is a textbook onboarding cliff for international users.
Real-world report
"When the app opens it should ask which lang user prefer cause it was all chinese and i dont know chinese so changing lang after finding it in settings is an another hustle."
— @Kafkacodes, #8 (comment)
This is the first feedback we have from an English-speaking contributor, and it's the very first thing they hit before they could do anything else. That's the strongest possible signal.
Why this matters
- We're actively recruiting international contributors (
good first issues in English, README_en.md, CONTRIBUTING_en.md, English Discussions).
- Recruiting English-speaking contributors and then handing them a Chinese-only first-run UI wastes the funnel.
- Locale data is already in the app — we just don't ask the OS.
Proposed UX
Option A — System locale auto-detection (recommended for v1)
On first launch, when no language preference is persisted yet:
- Read OS locale (
navigator.language in WebView, or tauri::api::os::locale() on the Rust side).
- If locale starts with
zh → Chinese.
- Otherwise → English.
- Persist the choice on first user interaction.
Trade-off: silent. Users never see "we picked X for you" — they just get a coherent first experience.
Option B — First-run language picker
Show a tiny modal on the very first launch:
┌─────────────────────────────┐
│ Welcome to DreamCoder │
│ │
│ Language / 语言 │
│ ◯ English │
│ ◯ 简体中文 │
│ │
│ [ Continue ] │
└─────────────────────────────┘
Trade-off: more work, but explicit signal that we care about both audiences.
Recommendation
Ship Option A as the v0.4.x patch (small, safe, instantly fixes @Kafkacodes' complaint). Layer Option B on top later when a proper "first-run welcome" lands.
Files likely to touch
desktop/src/i18n/index.ts (or wherever i18n bootstrap lives)
desktop/src/store/settingsStore.ts (where language preference is persisted)
- Possibly
src-tauri/src/lib.rs if we want OS-level locale detection via Tauri command
Acceptance
Difficulty
⭐⭐ — half a day, mostly i18n bootstrap.
Credit
Reported by @Kafkacodes in #8.
Summary
DreamCoder defaults to Chinese UI on first launch. Users on non-Chinese systems must navigate Settings — itself in Chinese — to switch to English. This is a textbook onboarding cliff for international users.
Real-world report
This is the first feedback we have from an English-speaking contributor, and it's the very first thing they hit before they could do anything else. That's the strongest possible signal.
Why this matters
good first issues in English, README_en.md, CONTRIBUTING_en.md, English Discussions).Proposed UX
Option A — System locale auto-detection (recommended for v1)
On first launch, when no language preference is persisted yet:
navigator.languagein WebView, ortauri::api::os::locale()on the Rust side).zh→ Chinese.Trade-off: silent. Users never see "we picked X for you" — they just get a coherent first experience.
Option B — First-run language picker
Show a tiny modal on the very first launch:
Trade-off: more work, but explicit signal that we care about both audiences.
Recommendation
Ship Option A as the v0.4.x patch (small, safe, instantly fixes @Kafkacodes' complaint). Layer Option B on top later when a proper "first-run welcome" lands.
Files likely to touch
desktop/src/i18n/index.ts(or wherever i18n bootstrap lives)desktop/src/store/settingsStore.ts(where language preference is persisted)src-tauri/src/lib.rsif we want OS-level locale detection via Tauri commandAcceptance
Difficulty
⭐⭐ — half a day, mostly i18n bootstrap.
Credit
Reported by @Kafkacodes in #8.