i18n-expert

Other Community

Repo stars 0
Author updated Aug 24, 2026, 03:33 PM
Author repo claude-code-skills

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: This skill should be used when setting up, auditing, or enforcing internationalization/localization in UI codebases (React/TS, i…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “Overview”, “Core Capabilities”, “Scope Inputs (ask if unclear)”, “Workflow (Audit -> Fix -> Validate)”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name i18n-expert directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “Overview / Core Capabilities / Scope Inputs (ask if unclear)” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / write; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

I18n Expert

Overview

Deliver a complete i18n setup + audit pass: configure the i18n framework, replace user-facing strings with keys, ensure locale parity, and validate pluralization/formatting for en-US and zh-CN.

Core Capabilities

Library selection and setup (React, Next.js, Vue).
Key architecture and locale file organization.
Translation generation and quality strategy (AI, professional, manual).
Routing and language detection/switching.
SEO and metadata localization (when applicable).
RTL support (only if RTL locales are in scope).

Scope Inputs (ask if unclear)

Framework and routing style.
Existing i18n state (none, partial, legacy).
Target locales (default: en-US + zh-CN).
Translation quality needs (AI vs professional vs manual).
Locale formats in use (JSON, YAML, PO, XLIFF).
Formality/cultural requirements (if any).

Workflow (Audit -> Fix -> Validate)

Confirm scope and locale targets

Identify the i18n framework and locale locations.
Confirm locales; default to en-US + zh-CN when specified.

Setup i18n baseline (if missing)

Choose a framework-appropriate library (e.g., React: react-i18next; Next.js: next-intl; Vue: vue-i18n).
Install packages and create the i18n entry/config file.
Wire the provider at the app root and load locale resources.
Add a language switcher and persistence (route/param/localStorage) as appropriate.
Establish locale file layout and key namespaces.
If routing is locale-aware, define the locale segment strategy early (subpath, subdomain, query param).
If metadata is user-facing, include translation for titles/descriptions.

Audit key usage and locale parity

Run:

python scripts/i18n_audit.py --src <src-root> --locale <path/to/en-US.json> --locale <path/to/zh-CN.json>

Treat missing keys/parity gaps as blockers.
Manually verify dynamic keys (t(var)).

Find raw user-facing strings

Search:

rg -n --glob '<src>/**/*.{ts,tsx,js,jsx}' "<[^>]+>[^<{]*[A-Za-z][^<{]*<"
rg -n --glob '<src>/**/*.{ts,tsx,js,jsx}' "aria-label=\"[^\"]+\"|title=\"[^\"]+\"|placeholder=\"[^\"]+\""

Localize accessibility labels.

Replace strings with keys

Use t('namespace.key') for UI text.
For plurals use t('key', { count }) + _one/_other keys.
Use Intl/app formatters for time/date/number.

Localize error handling (critical)

Map error codes to localized keys; show localized UI only.
Log raw error details only.
Provide localized fallback for unknown codes.

Update locale files

Add missing keys in both locales.
Keep placeholders consistent; avoid renames unless requested.
Generate translations using the agreed method; preserve placeholders and plural rules.

Validate

Re-run the audit until missing/parity issues are zero.
Validate JSON (e.g., python -m json.tool <file>).
Update tests asserting visible text.

Guardrails

Never expose raw error.message to UI; show localized strings only.
Do not add extra locales unless explicitly requested.
Prefer structured namespaces (e.g., errors.*, buttons.*, workspace.*).
Keep translations concise and consistent.
Some technical/brand terms should remain untranslated (e.g., product name, API, MCP, Bash).

Deliverables (expected outputs)

i18n config/provider wiring.
Locale files for each target language.
Replaced UI strings with stable keys.
Language switcher and persistence (if applicable).
Updated tests for visible text.

Architecture Guidance (keep concise)

Key structure: prefer nested namespaces by area (e.g., common.buttons.save, pricing.tier.pro).
File layout: one file per locale or per-locale namespaces; keep keys in sync across locales.
Placeholders: preserve {name}/{{name}} exactly; validate plurals by locale rules.
Formatting: use Intl/app helpers for date, time, number, and list formatting.
SEO/metadata: localize titles and descriptions if the app exposes them.
RTL: only needed for RTL locales; use logical CSS properties and test layout.
Non-web surfaces (Electron main-process dialogs, CLI prompts, native menus) need localization too.

Performance Notes (short)

Lazy-load locale bundles when the app supports it.
Split large locale files by namespace.

Failure Modes (watchlist)

Missing translations: fall back to default locale and log warnings.
RTL layout issues: verify logical CSS and test pages.
SEO missing: ensure alternates and metadata are localized when applicable.

Validation Checklist (short)

No missing keys and no raw UI strings.
Locale switching works and persists.
Plurals and formatting verified in both locales.
Fallback locale configured.

Resources

scripts/

scripts/i18n_audit.py: Extracts t('key') usage and compares against locale JSON files.

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: Other
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 88 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @daymade · no license declared
Fluxly token estimate: Lean
Fluxly setup estimate: Plug-and-play
External API key: No requirement detected
Detected OS requirements: Unspecified
Runtime requirements: Python
Detected file/system behavior: Read-only
Write / modify
Detected network behavior: Local-only
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview i18n-expert.preview

# Deliverables (expected outputs)

- i18n config/provider wiring.
- Locale files for each target language.
- Replaced UI strings with stable keys.
- Language switcher and persistence (if applicable).
- Updated tests for visible text.

SKILL.md SKILL.md

# I18n Expert

## Overview

Deliver a complete i18n setup + audit pass: configure the i18n framework, replace user-facing strings with keys, ensure locale parity, and validate pluralization/formatting for en-US and zh-CN.

## Core Capabilities

- Library selection and setup (React, Next.js, Vue).
- Key architecture and locale file organization.
- Translation generation and quality strategy (AI, professional, manual).
- Routing and language detection/switching.
- SEO and metadata localization (when applicable).
- RTL support (only if RTL locales are in scope).

## Scope Inputs (ask if unclear)

- Framework and routing style.
- Existing i18n state (none, partial, legacy).
- Target locales (default: en-US + zh-CN).
- Translation quality needs (AI vs professional vs manual).
- Locale formats in use (JSON, YAML, PO, XLIFF).
- Formality/cultural requirements (if any).

## Workflow (Audit -> Fix -> Validate)

1) Confirm scope and locale targets
- Identify the i18n framework and locale locations.
- Confirm locales; default to en-US + zh-CN when specified.

2) Setup i18n baseline (if missing)
- Choose a framework-appropriate library (e.g., React: react-i18next; Next.js: next-intl; Vue: vue-i18n).
- Install packages and create the i18n entry/config file.
- Wire the provider at the app root and load locale resources.
- Add a language switcher and persistence (route/param/localStorage) as appropriate.
- Establish locale file layout and key namespaces.
- If routing is locale-aware, define the locale segment strategy early (subpath, subdomain, query param).
 - If metadata is user-facing, include translation for titles/descriptions.

3) Audit key usage and locale parity
- Run:
  ```bash

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> Overview → Core Capabilities → Scope Inputs (ask if unclear) → Workflow (Audit -> Fix -> Validate) → Guardrails → Deliverables (expected outputs)
terms    -> - Library selection and setup (React, Next.js, Vue). · - Framework and routing style. · 1) Confirm scope and locale targets - Identify the i18n framework and locale locations. · 2) Setup i18n baseline (if missing) - Choose a framework-appropriate library (e.g., React: react-i18next; Next.js: next-intl; Vue: vue-i18n). · 5) Replace strings with keys - Use t('namespace.key') for UI text. · 6) Localize error handling (critical) - Map error codes to localized keys; show localized UI only. · 7) Update locale files - Add missing keys in both locales. · 8) Validate - Re-run the audit until missing/parity issues are zero.
files/cmd -> t(var) · t('namespace.key') · t('key', { count }) · one/other · python -m json.tool <file> · error.message · errors. · buttons.
body sha256 -> c2c54157aabd