菜单
Internationalization and localization patterns. Detecting hardcoded strings, managing translations, locale files, RTL support.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Senior agent organizer with expertise in assembling and coordinating multi-agent teams. Your focus spans task analysis, agent capability mapping, workflow design, and team optimization.
AI agent design principles. Agent loops, tool calling, memory architectures, multi-agent coordination, human-in-the-loop gates, and guardrails. Use when building AI agents, autonomous workflows, or any system where an LLM plans and executes multi-step tasks.
API design principles and decision-making. REST vs GraphQL vs tRPC selection, response formats, versioning, pagination.
Main application building orchestrator. Creates full-stack applications from natural language requests. Determines project type, selects tech stack, coordinates agents.
Architectural decision-making framework. Requirements analysis, trade-off evaluation, ADR documentation. Use when making architecture decisions or analyzing system design.
Bash/Linux terminal patterns. Critical commands, piping, error handling, scripting. Use when working on macOS or Linux systems.
| name | i18n-localization |
| description | Internationalization and localization patterns. Detecting hardcoded strings, managing translations, locale files, RTL support. |
| allowed-tools | Read, Write, Edit, Glob, Grep |
| version | 1.0.0 |
| last-updated | "2026-03-12T00:00:00.000Z" |
| applies-to-model | gemini-2.5-pro, claude-3-7-sonnet |
Internationalization (i18n) is preparing code to support multiple languages. Localization (l10n) is the work of adapting to a specific locale. Do i18n once, properly. Do l10n for each market.
Every user-visible string in the source code is a localization problem waiting to happen.
// ❌ Hardcoded — untranslatable
<button>Save Changes</button>
<p>You have {count} messages</p>
<p>Error: Invalid email address</p>
// ✅ Key-referenced — translatable
<button>{t('common.save')}</button>
<p>{t('inbox.messageCount', { count })}</p>
<p>{t('errors.invalidEmail')}</p>
Organize translation keys hierarchically — flat files become unmaintainable past ~50 keys:
// en.json
{
"common": {
"save": "Save Changes",
"cancel": "Cancel",
"loading": "Loading…",
"error": "Something went wrong"
},
"auth": {
"login": "Sign In",
"logout": "Sign Out",
"register": "Create Account",
"errors": {
"invalidEmail": "Enter a valid email address",
"passwordTooShort": "Password must be at least {{min}} characters"
}
},
"inbox": {
"messageCount_one": "{{count}} message",
"messageCount_other": "{{count}} messages"
}
}
Key naming conventions:
feature.element or feature.element.state.errors"Save Changes": "Save Changes")Pluralization rules differ per language. Use your i18n library's plural system — never manual if count > 1:
// ❌ Only works for English
const label = count === 1 ? 'message' : 'messages';
// ✅ i18next handles per-language plural rules
t('inbox.messageCount', { count })
// Translation files handle the variants:
// English: { "messageCount_one": "{{count}} message", "messageCount_other": "{{count}} messages" }
// Arabic: 6 plural forms (zero, one, two, few, many, other)
// Russian: 3 plural forms with complex rules
Never format these manually. Use the browser's Intl API:
// Date
const date = new Date();
new Intl.DateTimeFormat('en-US').format(date); // "2/20/2026"
new Intl.DateTimeFormat('de-DE').format(date); // "20.2.2026"
// Number
new Intl.NumberFormat('en-US').format(1234567.89); // "1,234,567.89"
new Intl.NumberFormat('de-DE').format(1234567.89); // "1.234.567,89"
// Currency
new Intl.NumberFormat('en-US', { style: 'currency', currency: 'USD' }).format(99.99);
// "$99.99"
new Intl.NumberFormat('de-DE', { style: 'currency', currency: 'EUR' }).format(99.99);
// "99,99 €"
Arabic, Hebrew, Persian, Urdu are RTL languages. Supporting them requires more than flipping direction.
<!-- Set direction on html element based on locale -->
<html lang="ar" dir="rtl">
<!-- Or dynamically -->
<html lang={locale} dir={isRTL(locale) ? 'rtl' : 'ltr'}>
/* Use logical properties — they flip automatically with direction */
/* ❌ Physical: only works for LTR */
padding-left: 1rem;
margin-right: 2rem;
border-left: 2px solid;
/* ✅ Logical: works for both LTR and RTL */
padding-inline-start: 1rem;
margin-inline-end: 2rem;
border-inline-start: 2px solid;
Look for:
<p>some text</p> (not <p>{t(...)}</p>)`Welcome, ${name}!`toast.success('Saved!')new Error('Invalid input') shown to usersplaceholder, aria-label, title attributes hardcoded| Script | Purpose | Run With |
|---|---|---|
scripts/i18n_checker.py | Scans codebase for hardcoded strings | python scripts/i18n_checker.py <project_path> |
When this skill produces a recommendation or design decision, structure your output as:
━━━ I18N Localization Recommendation ━━━━━━━━━━━━━━━━
Decision: [what was chosen / proposed]
Rationale: [why — one concise line]
Trade-offs: [what is consciously accepted]
Next action: [concrete next step for the user]
─────────────────────────────────────────────────
Pre-Flight: ✅ All checks passed
or ❌ [blocking item that must be resolved first]
AI coding assistants often fall into specific bad habits when dealing with this domain. These are strictly forbidden:
// VERIFY or check package.json / requirements.txt.Slash command: /review or /tribunal-full
Active reviewers: logic-reviewer · security-auditor
// VERIFY: [reason].Review these questions before confirming output:
✅ Did I rely ONLY on real, verified tools and methods?
✅ Is this solution appropriately scoped to the user's constraints?
✅ Did I handle potential failure modes and edge cases?
✅ Have I avoided generic boilerplate that doesn't add value?
CRITICAL: You must follow a strict "evidence-based closeout" state machine.