Full spec: 00-product-spec.md . Related: 13-inference-and-dependencies.md .
YZOS’s typical user scenario is Chinese IM (WeChat/Lark) + English code/docs + mixed OCR . The language strategy principle is: do not translate the user’s raw content; retrieval and reasoning stay bilingual (zh/en); UI and MCP output language are configurable .
flowchart TD
subgraph L1["L1 user content (source of truth)"]
A["OKF / entity names / chat excerpts (never auto-translated)"]
end
subgraph L2["L2 processing (auto-detect, multilingual)"]
direction LR
OCR["OCR"] --> ASR["ASR"] --> EMB["Embedding"] --> PII["PII"] --> FTS["FTS"] --> TRI["LLM triage"]
end
subgraph L3["L3 presentation (configurable)"]
UI["Tauri UI"]
MCP["MCP summaries"]
ROLL["Rollup exports"]
CLI["CLI output"]
end
L1 --> L2 --> L3
Layer
Strategy
L1 source of truth
WeChat Chinese is stored as Chinese, GitHub English is stored as English; whole-document translation before ingestion is forbidden
L2 processing
Components support zh + en by default; auto-detection is a fallback, not a forced single language
L3 presentation
The user’s locale decides the UI and generated-summary language; retrieval is not restricted by it
Item
Default
Notes
Target user’s primary language
zh-CN
Docs and Tauri UI are Chinese-first at launch
Secondary working language
en
Code, technical docs, some IM
OKF / Memory writing
user’s native language
Mixed zh/en text is allowed
MCP JSON field names
en
kind, status, entity_id are a stable contract
MCP / summary body text
locale config
Defaults to zh
activity_summaries.language
zh
See 06-data-model.md
The full modality-level model table (OCR / VLM / video frame extraction / speaker diarization) is in 15-modality-models.md .
Item
Selection
Engine
Vision.framework (macOS)
Recognition
zh-Hans + en-US auto; an optional per-window locale hint
Strategy
Chinese IM windows prefer zh-Hans; IDE/browser windows are not forced
Not in scope for launch
Dedicated Japanese/Korean models (add after usage data justifies it)
Item
Selection
Engine
sherpa-onnx SenseVoice int8
Language
auto (zh/en/ja/ko/yue); YZOS defaults to auto
Speaker
3D-Speaker embedding, optimized for Chinese
Output
Transcript keeps the original language; not translated
Item
Selection
Model
multilingual-e5-small (384d)
Prefix
passage: / query: (mandatory)
Fallback
bge-small-en-v1.5, only when the user sets languages: [en] (English-only config)
Principle
Mixed zh/en paragraphs are not split ; embedded as a whole
Phase
Approach
P0
jieba-rs pre-tokenization + to_tsvector('simple', ...)
P1
pg_jieba + yzos_zh config (ascii -> english_stem, word -> jieba)
English code
english_stem covers ASCII tokens
Hybrid query
A search like “DNS troubleshooting” runs vector + FTS in parallel; no single tokenizer is relied on
Item
Selection
Model
Qwen3.5-4B-Instruct GGUF (llama-server, all platforms; thinking: false)
Rationale
Balanced zh/en quality (C-Eval 85+); one stack also covers lightweight vision; structured JSON triage via grammar POC
System prompt
Defaults to Chinese instructions; switches to English when locale: en
Input
OCR/chat text goes in raw , never pre-translated
Output
Follows locale; JSON key names are always English
Grammar schema
Field names are fixed English; the language of content fields such as summary follows locale
ui : zh-CN # Tauri interface
generated : zh # LLM summaries, rollup, MCP narrative text
# generated: en | auto (auto = detect the session's dominant language)
Tier
Language coverage
L0 rules_cn
Chinese national ID, mainland phone numbers, UnionPay cards, Chinese address heuristics
L0 rules_en
SSN, US phone, email, JWT, API key patterns
L1 NER
multilang-pii-ner (mostly Latin-script languages)
Principle
Chinese IM relies primarily on L0 ; NER supplements the rules, it does not replace them
No dedicated language-identification model is introduced. session.lang is inferred by priority:
flowchart TD
START["Infer session.lang"] --> Q1{"Chat locale or window title script ratio?"}
Q1 -->|"available"| R1["Use platform locale (CJK vs Latin)"]
Q1 -->|"none"| Q2{"OCR available?"}
Q2 -->|"CJK ratio > 30%"| ZH["zh"]
Q2 -->|"otherwise"| EN["en or mixed"]
Q2 -->|"none"| MIX["Default: mixed"]
Used for:
Writing activity_summaries.language
Choosing the summary language when locale.generated: auto
Not used to discard content that does not match the detected language
Phase
Scope
P0
UI copy hardcoded in zh-CN
P1
i18n skeleton (zh-CN + en); locale.ui setting in Settings
Out of scope
Auto-translating OKF content for display
Entity display_name and chat excerpts: shown as-is , never translated to match the UI language.
Output type
Language
Structured fields
English enums (in_progress, person)
summary, journal, narrative text
locale.generated
Raw OKF paths / references
Not translated
Error messages
Follows locale.ui
An upstream AI asking in English while querying Chinese knowledge is allowed - the retrieval layer is multilingual and does not require the query language to match the document language.
Not doing
Reason
Full-text translation before ingestion
Fidelity loss, secondary privacy exposure, pollutes the source of truth
Defaulting to a single English embedding model
Poor recall on Chinese IM content
Making UI language force the summary language
A user may run an English UI while working in Chinese
A separate LLM per language
Memory and cold-start cost; Qwen3.5-4B already covers zh/en
Auto-translating WeChat content to English for MCP
Violates the L1 source-of-truth principle
generated : auto # zh | en | auto
languages : [ zh-Hans , en-US ]
asr_language : auto # auto | zh | en
embed_model : multilingual-e5-small-q
model : qwen3-4b-instruct-q4_k_m.gguf
system_locale : zh # system prompt language; linked to locale.generated