| name | design-localization |
| description | Design multi-language and multi-culture support for the target OS — localized modes, culture-specific vocabulary, and language detection. |
/design-localization - Localization Framework Design
When to Use
- When the OS serves users in multiple languages or cultural contexts
- When the domain has culture-specific terminology (legal terms, business norms, compensation structures)
- When
domain-input/domain-workflow.md mentions international users or markets
- Skip if the OS is single-language only
Inputs
- Auto-loaded:
domain-input/domain-workflow.md (target markets/regions)
- Auto-loaded:
domain-input/quality-contract.md (tone and vocabulary standards)
- Auto-loaded:
output/designs/skill-designs.md (which skills need localization)
Process
Step 1: Identify Languages and Cultures
Ask the designer:
- What languages do users work in? (list all, mark primary)
- Are there culture-specific differences beyond language? (legal terms, business norms, compensation structures, social conventions)
- Does the user's input language differ from the output language? (e.g., user writes in English, system generates German output for DACH market)
Step 2: Determine Localization Scope
What needs localization?
| Component | Needs Localization? | Why |
|---|
| Skill mode files | [yes/no] | Instructions reference culture-specific terms |
| Output templates | [yes/no] | Generated content must match target language |
| Scoring rubrics | [yes/no] | Evaluation criteria differ by market |
| Insider data | [yes/no] | Reference data is market-specific |
| System messages | [yes/no] | Error messages, prompts in user's language |
Step 3: Design Mode File Structure
For each language/culture:
modes/
├── [lang]/ # e.g., de/, fr/, ja/
│ ├── [mode-1].md # Localized version of each mode
│ ├── [mode-2].md
│ └── ...
Each localized mode file contains:
- Same structure as the default mode
- Culture-specific vocabulary (e.g., DACH: "13. Monatsgehalt," "Probezeit," "AGG")
- Culture-specific evaluation criteria (e.g., France: CDI vs CDD, RTT, mutuelle)
- Adapted tone (e.g., Japanese: formal register with appropriate honorifics)
Step 4: Design Language Detection
How does the OS detect which language to use?
- User-configured:
config/overrides.md has language: [code] and modes_dir: modes/[lang]
- Auto-detected: OS detects input language and suggests switching
- Per-item: Each item may be in a different language (e.g., JDs in German, user works in English)
Step 5: Culture-Specific Vocabulary
For each language, document terms that an AI might get wrong:
| Language | Term | Correct Usage | Common AI Mistake |
|---|
| [e.g., German] | Probezeit | 6-month probation period, standard in German employment | Translating literally without legal context |
| [e.g., French] | CDI/CDD | Permanent vs fixed-term contract — CDI is the norm | Not distinguishing between contract types |
| [e.g., Japanese] | 正社員 | Full-time permanent employee (seishain) | Using katakana for a term that should be kanji |
Output
Write localization design to output/designs/localization-designs.md.
Tell the designer:
Localization designed:
- Languages: [list]
- Localized components: [list]
- Detection method: [user-configured / auto-detected / per-item]
- Culture-specific terms: [N] terms documented across [N] languages
Key decision: [e.g., "Default language is English; modes_dir switches to localized modes"]
Next: Run /generate-os to assemble everything.
Quality Checks
Good localization:
- Culture-specific vocabulary is documented with correct usage
- Mode files preserve structure while adapting content
- Language detection has a clear mechanism
- Output language matches the user's configuration
Bad localization:
- Direct translation without cultural adaptation
- No culture-specific vocabulary list
- Language detection is ambiguous
- Localized modes have different structure than default modes
