This file provides guidance to agents when working with translations in this repository.
For the translation workflow, use the /add-missing-translations command or see .kilocode/workflows/add-missing-translations.md.
1. SUPPORTED LANGUAGES AND LOCATION
- Localize all strings into the following locale files: ar, ca, cs, de, en, es, fr, hi, id, it, ja, ko, nl, pl, pt-BR, ru, sk, th, tr, uk, vi, zh-CN, zh-TW
- The VSCode extension has two main areas that require localization:
- Core Extension: src/i18n/locales/, src/package.nls.json, src/package.nls..json (extension backend)
- WebView UI: webview-ui/src/i18n/locales/ (user interface)
- Always use informal speech (e.g., "du" instead of "Sie" in German) for all translations
- Maintain a direct and concise style that mirrors the tone of the original text
- Carefully account for colloquialisms and idiomatic expressions in both source and target languages
- Aim for culturally relevant and meaningful translations rather than literal translations
- Preserve the personality and voice of the original content
- Use natural-sounding language that feels native to speakers of the target language
- Don't translate the word "token" as it means something specific in English that all languages will understand
- Don't translate domain-specific words (especially technical terms like "Prompt") that are commonly used in English in the target language
- Located in src/i18n/locales/
- NOT ALL strings in core source need internationalization - only user-facing messages
- Internal error messages, debugging logs, and developer-facing messages should remain in English
- The t() function is used with namespaces like 'core:errors.missingToolParameter'
- Be careful when modifying interpolation variables; they must remain consistent across all translations
- Some strings in formatResponse.ts are intentionally not internationalized since they're internal
- When updating strings in core.json, maintain all existing interpolation variables
- Check string usages in the codebase before making changes to ensure you're not breaking functionality
- Located in webview-ui/src/i18n/locales/
- Uses standard React i18next patterns with the useTranslation hook
- All user interface strings should be internationalized
- Always use the Trans component with named components for text with embedded components
example:
"changeSettings": "You can always change this at the bottom of the <settingsLink>settings</settingsLink>",
<Trans
i18nKey="welcome:telemetry.changeSettings"
components={{
settingsLink: <VSCodeLink href="#" onClick={handleOpenSettings} />
}}
/>
5. TECHNICAL IMPLEMENTATION
- Use namespaces to organize translations logically
- Handle pluralization using i18next's built-in capabilities
- Implement proper interpolation for variables using {{variable}} syntax
- Don't include defaultValue. The
entranslations are the fallback - Always use apply_diff instead of write_to_file when editing existing translation files (much faster and more reliable)
- When using apply_diff, carefully identify the exact JSON structure to edit to avoid syntax errors
- Placeholders (like {{variable}}) must remain exactly identical to the English source to maintain code integration and prevent syntax errors
- First add or modify English strings, then ask for confirmation before translating to all other languages
- Use this process for each localization task:
- Identify where the string appears in the UI/codebase
- Understand the context and purpose of the string
- Update English translation first
- Use the
<search_files>tool to find JSON keys that are near new keys in English translations but do not yet exist in the other language files for<apply_diff>SEARCH context - Create appropriate translations for all other supported languages utilizing the
search_filesresult using<apply_diff>without reading every file. - Do not output the translated text into the chat, just modify the files.
- Validate your changes with the missing translations script
- Flag or comment if an English source string is incomplete ("please see this...") to avoid truncated or unclear translations
- For UI elements, distinguish between:
- Button labels: Use short imperative commands ("Save", "Cancel")
- Tooltip text: Can be slightly more descriptive
- Preserve the original perspective: If text is a user command directed at the software, ensure the translation maintains this direction, avoiding language that makes it sound like an instruction from the system to the user
- Switching between formal and informal addressing styles - always stay informal ("du" not "Sie")
- Translating or altering technical terms and brand names that should remain in English
- Modifying or removing placeholders like {{variable}} - these must remain identical
- Translating domain-specific terms that are commonly used in English in the target language
- Changing the meaning or nuance of instructions or error messages
- Forgetting to maintain consistent terminology throughout the translation
- Maintain consistent terminology across all translations
- Respect the JSON structure of translation files
- Watch for placeholders and preserve them in translations
- Be mindful of text length in UI elements when translating to languages that might require more characters
- Use context-aware translations when the same string has different meanings
- Always validate your translation work by running the missing translations script:
node scripts/find-missing-translations.js - Address any missing translations identified by the script to ensure complete coverage across all locales
- ✓ Used informal tone consistently ("du" not "Sie")
- ✓ Preserved all placeholders exactly as in the English source
- ✓ Maintained consistent terminology with existing translations
- ✓ Kept technical terms and brand names unchanged where appropriate
- ✓ Preserved the original perspective (user→system vs system→user)
- ✓ Adapted the text appropriately for UI context (buttons vs tooltips)
Language-Specific Guidelines
German (de) Translation Guidelines
Key Rule: Always use informal speech ("du" form) in all German translations without exception.
Quick Reference
| Category | Formal (Avoid) | Informal (Use) | Example |
|---|---|---|---|
| Pronouns | Sie | du | you |
| Possessives | Ihr/Ihre/Ihrem | dein/deine/deinem | your |
| Verbs | können Sie, müssen Sie | kannst du, musst du | you can, you must |
| Imperatives | Geben Sie ein, Wählen Sie | Gib ein, Wähle | Enter, Choose |
Technical terms like "API", "token", "prompt" should not be translated.
Simplified Chinese (zh-CN) Translation Guidelines
Key Terminology
| English Term | Preferred (zh-CN) | Avoid | Context/Notes |
|---|---|---|---|
| API Cost | API Fee | API Cost | Finance-related terminology |
| Tokens | Token | Tokens | Keep abstract terminology |
| Token Usage | Token Usage | Token usage | Technical unit of measurement |
| Cache | Cache | Cache | Conciseness first |
| Context | Context | Keep abstract terminology | |
| Context Menu | Right-click menu | Context menu | Technical terminology accuracy |
| Context Window | Context window | Technical terminology accuracy | |
| Proceed While Running | Force continue | Runtime continue | Operation command |
| Enhance Prompt | Enhanced prompt | Optimize prompt | AI-related feature |
| Auto-approve | Auto-approve | Always approve | Permission-related terminology |
| Checkpoint | Save point | Checkpoint/snapshot | Unified technical concept |
| MCP Server | MCP Service | MCP Server | Technical component |
| Human Relay | Human-assisted mode | Human relay | Clear feature description |
| Network Timeout | Request timeout | Network timeout | More accurate description |
| Terminal | Terminal | Command line | Unified technical terminology |
| diff | Diff update | Diff/patch | Code change |
| prompt caching | Prompt cache | Prompt cache | AI feature |
| computer use | Computer interaction | Computer use | Technical capability |
| rate limit | API request rate limit | Rate limit | API control |
| Browser Session | Browser session | Browser process | Technical concept |
| Run Command | Run command | Execute command | Action verb |
| power steering mode | Enhanced steering mode | Power steering mode | Avoid literal translation |
| Boomerang Tasks | Task breakdown | Boomerang task | Avoid literal translation |
Formatting Rules
-
Mixed Chinese and English
- Add spaces: add spaces between Chinese and English/numbers, such as "API 费用" (not "API费用")
- Unit format: time units are standardized as "15秒", "1分钟" (not "15 seconds", "1 minute")
- Number range: "已使用: {{used}} / {{total}}"
- Technical symbols remain as-is: "{{amount}} tokens"→"{{amount}}"
-
Punctuation
- Use Chinese full-width punctuation
- Use Chinese enumeration comma for list items: "创建、编辑文件"
-
UI text optimization
- Button text: use concise verbs, such as "展开" is better than "查看更多"
- Operation instructions: use step-by-step instructions (1. 2. 3.) instead of long paragraphs
- Error prompt: use "确认删除?此操作不可逆" instead of "Are you sure...?"
- Keep operation instructions concise: "Shift+drag files" is better than a long description
- Keep button text to 2-4 Chinese characters: "展开" is better than "查看更多"
-
Technical descriptions
- Keep English abbreviations: e.g., do not translate "MCP"
- Unify terminology: use the same translation for the same concept throughout the system
- Split long sentences into short sentences
- Convert passive voice to active voice
- Unify feature names: "计算机交互" is better than "计算机使用"
- Parameter description: "差异更新" is better than "差分/补丁"
-
Variable placeholders
- Keep the original format:
{{variable}} - Place Chinese descriptions outside the variable: "Token 使用量: {{used}}"
- Keep the original format:
UI Element Translation Standards
-
Buttons
- Confirmation type: OK/Cancel/Apply/Save
- Action type: Add/Delete/Edit/Export
- State type: Enable/Disable/Expand/Collapse
- Length limit: 2-4 Chinese characters
-
Menus
- Main menu: File/Edit/View/Help
- Submenu: use ">" to connect, e.g., "文件>打开"
- Shortcuts: keep English, e.g., "Ctrl+S"
-
Labels
- Setting items: describe the function, e.g., "自动保存间隔"
- Status prompts: concise and clear, e.g., "正在处理..."
- Unit descriptions: place in parentheses, e.g., "超时时间(秒)"
-
Tooltips
- Feature description: concise description, e.g., "复制选中内容"
- Operation guidance: clear steps, e.g., "双击编辑单元格"
- Length limit: no more than 50 Chinese characters
-
Dialogs
- Title: explain the purpose of the dialog
- Body: explain in paragraphs
- Buttons: use verbs, e.g., "确认删除"
Contextual Translation Principles
-
Adjust according to UI position
- Button text: concise verb (e.g., "展开", "收起")
- Setting items: descriptive (e.g., "自动批准写入操作")
- Help text: complete explanation (e.g., "开启后自动创建任务存档点,方便回溯修改")
-
Technical documentation style
- Use active voice: e.g., "自动创建和编辑文件"
- Avoid colloquial expressions
- Use bullet points for complex features
- Explain the operation result: e.g., "无需二次确认"
- Clear parameter descriptions: e.g., "延迟一段时间再自动批准写入"
-
Brand/Product names
- Keep English brand names
- Keep technical terminology consistent
- Keep English proper nouns: e.g., "Amazon Bedrock ARN"
-
User operations
- Unify action verbs:
- "Click" → "点击"
- "Type" → "输入"
- "Scroll" → "滚动"
- Button states:
- "Enabled" → "已启用"
- "Disabled" → "已禁用"
- Unify action verbs:
Technical Documentation Guidelines
-
Technical terminology
- Use "Token" consistently instead of "令牌"
- Keep English proper nouns: e.g., "Model Context Protocol"
- Unified feature naming: e.g., "computer function calling" is better than "computer use"
-
API Documentation
- Endpoint: keep the original path
- Parameter descriptions: present in table form
- Examples: keep the code format
- Parameter labels:
- Clear units: e.g., "maximum output Token count"
- Complete range description: e.g., "the total number of Tokens the model can process"
-
Code-related translation
- Code comments:
- Keep technical terms: e.g., "// Initialize MCP client"
- Brief description: e.g., "check whether the file exists"
- Error messages:
- Include error codes: e.g., "Error 404: file not found"
- Provide solutions: e.g., "please check file permissions"
- Command line:
- Keep native commands: e.g., "git commit -m 'message'"
- Parameter descriptions: e.g., "-v: show detailed output"
- Code comments:
-
Configuration Guide
- Setting item naming: e.g., "Enable prompt caching" → "Enable prompt caching"
- Price description:
- Unified units: e.g., "cost per million Tokens"
- Explain the impact: e.g., "this affects the cost of generated content and completions"
- Operation instructions:
- Use numbered steps: e.g., "1. Register a Google Cloud account"
- Consistent step verbs: e.g., "install and configure the Google Cloud CLI tool"
Common Patterns
| Original | Avoid | Preferred |
|---|---|---|
"dragFiles" |
"按住shift拖动文件" |
"Shift+拖拽文件" |
"description" |
"启用后,Kilo Code 将能够与 MCP 服务器交互以获取高级功能。" |
"启用后 Kilo Code 可与 MCP 服务交互获取高级功能。" |
"cannotUndo" |
"此操作无法撤消。" |
"此操作不可逆。" |
"hold shift to drag in files" |
"按住shift拖动文件" |
"Shift+拖拽文件" |
"Double click to edit" |
"双击进行编辑" |
"双击编辑" |
Common Pitfalls
-
Avoid overly literal translations that sound stiff
- ✗ "Do more with Boomerang Tasks" → "Use boomerang tasks to get more work done"
- ✓ "Do more with Boomerang Tasks" → "Allow task splitting"
-
Keep feature descriptions accurate
- ✗ "Enhance prompt with additional context" → "Use additional context to enhance the prompt"
- ✓ "Enhance prompt with additional context" → "Enhance prompt"
-
Clear operation guidance
- ✗ "hold shift to drag in files" → "Hold shift to drag files"
- ✓ "hold shift to drag in files" → "Shift+drag files"
-
Ensure terminology consistency
- ✗ Mixing "Token"/"token"/"coin" in the same document
- ✓ Consistently use "Token" as the technical term
-
Pay attention to cultural adaptability
- ✗ "Kill the process" → "Kill the process" (too violent)
- ✓ "Kill the process" → "Terminate the process"
-
Special handling for technical documentation
- Comments in code examples: ✗ Translation breaks the code structure ✓ Keep code comments as-is or translate only the explanatory part
- Command-line parameters: ✗ Translating parameter names makes them unusable ✓ Keep parameter names in English and translate only the descriptions
Best Practices
-
Translation workflow
- Read the full text to understand the context
- Mark and unify technical terms
- Translate in sections and check consistency
- Final overall review
-
Quality check points
- Terminology consistency
- Accuracy of feature descriptions
- UI element length adaptability
- Cultural Adaptability
-
Tool Usage Recommendations
- Establish a project terminology base
- Use translation memory tools
- Maintain a style guide
- Regularly update translation resources
-
Review Process
- Initial translation → Technical review → Language polishing → Final confirmation
- Focus on technical accuracy, language fluency, and UI display effects
Quality Checklist
- Are terms consistent throughout the text?
- Does it conform to Chinese technical documentation conventions?
- Is the UI control text concise and clear?
- Have long sentences been reasonably split?
- Are variable placeholders kept in their original format?
- Is the technical description accurate and error-free?
- Is the cultural expression appropriate?
- Has the precise meaning of the original text been preserved?
- Are special formats (such as variables and code) correctly preserved?
Traditional Chinese (zh-TW) Translation Guidelines
Key Terminology
| English Term | Use (zh-TW) | Avoid (Mainland) |
|---|---|---|
| file | 檔案 | 文件 |
| task | 工作 | 任務 |
| project | 專案 | 項目 |
| configuration | 設定 | 配置 |
| server | 伺服器 | 服務器 |
| import/export | 匯入/匯出 | 導入/導出 |
Formatting Rules
- Add spaces between Chinese and English/numbers: "AI 驅動" (not "AI驅動")
- Use Traditional Chinese quotation marks: 「範例文字」(not "範例文字")
- Use Taiwanese computing conventions rather than mainland terminology