design-localization

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:

1. What languages do users work in? (list all, mark primary)
2. Are there culture-specific differences beyond language? (legal terms, business norms, compensation structures, social conventions)
3. 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?

1. User-configured: config/overrides.md has language: [code] and modes_dir: modes/[lang]
2. Auto-detected: OS detects input language and suggests switching
3. 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