Claude CodeCursor

Source pending

i18n Manager

Name: i18n Manager
Rating: 4.4 (6800 reviews)
Author: l10n-tools

Extract strings, manage translations, and validate i18n completeness

Intermediate30 min

engineering/LocalizationUpdated Jan 16, 2026

Software Engineer

terminal

claude install community/i18n-manager

This install command is a placeholder. The real source repo for this skill is still being verified.

by l10n-tools

About this skill

Internationalization workflow: extract hardcoded strings, generate translation files, validate translation completeness, handle plurals and interpolation, and check RTL support.

Capabilities

file editing
code execution

Use cases

String extraction
Translation management
Locale validation

Skill Definition

This is the actual SKILL.md file that powers this skill. Copy it to install.

SKILL.md

---
name: i18n-manager
description: |
  Trigger when the user asks to add internationalization, translate a UI,
  or manage locales. Phrases: "i18n", "internationalization", "translate",
  "add locale", "translation keys", "multi-language", "localize".
allowed-tools:
  - Read
  - Write
  - Edit
  - Grep
  - Bash(pnpm add *)
---

# i18n Manager

Set up and maintain internationalization without turning every string into
a maintenance burden. Covers key structure, plurals, interpolation,
RTL support, and the "who actually translates this?" question.

## Prerequisites

- Framework chosen: next-intl / react-intl (React), vue-i18n (Vue),
  i18next (framework-agnostic), Paraglide (compile-time)
- Locale list decided (start with 2; adding more is cheap, removing is not)
- Translation workflow picked: Crowdin, Lokalise, Phrase, or plain JSON
  reviewed in PRs

## Steps

1. **Pick a key convention and stick to it.** Two viable styles:
   - **Hierarchical:** `settings.profile.email.label` - searchable, groups
     well, survives refactors when keys move with features
   - **Flat English:** `"Email address"` as the key itself - readable in
     code, no indirection, but breaks when English copy changes

   Hierarchical wins for apps with 500+ strings. Flat wins for small apps
   and marketing sites.

2. **Default locale file is the source of truth.** `en.json` is written
   by product/design. All other locales are derived. Never let
   translators edit `en.json` directly.

3. **Interpolation, not concatenation.** Never build sentences by joining
   fragments; grammar varies across languages.
   ```json
   { "greeting": "Hello, {name}! You have {count} messages." }
   ```

4. **Plurals with ICU MessageFormat:**
   ```json
   {
     "cart.items": "{count, plural, =0 {empty} one {# item} other {# items}}"
   }
   ```
   English has 2 plural forms. Arabic has 6. Russian has 3. Let ICU
   handle it.

5. **Dates, numbers, currency via Intl, not strings.**
   ```ts
   new Intl.DateTimeFormat(locale, { dateStyle: 'medium' }).format(date)
   new Intl.NumberFormat(locale, { style: 'currency', currency: 'EUR' })
   ```

6. **RTL (Arabic, Hebrew, Persian).** Use logical CSS properties
   (`padding-inline-start`, not `padding-left`). Set `dir="rtl"`
   on `<html>` based on locale. Test with pseudo-locale `ar-SA` early.

7. **Extract keys automatically.** Run a linter that fails CI if a
   hardcoded string appears in JSX. `eslint-plugin-i18next` or
   `eslint-plugin-formatjs`.

8. **Translation workflow.**
   - New keys land in `en.json` via normal PRs
   - CI exports new/changed keys to the TMS (Crowdin, Lokalise)
   - Translators work in the TMS; their output syncs back to the repo
   - Missing keys fall back to `en` at runtime with a warning in dev

9. **Lazy-load locale bundles.** Do not ship 40 languages to every user.
   Code-split by locale; load on demand.

## Patterns that work

- Pseudo-locale (`[!!Ëñglïsh!!]`) enabled in dev to spot hardcoded strings
- Type-safe keys via generated TypeScript from the JSON files
- One string, one key - never duplicate to match UI context
- Context notes on keys (`"button.save.description": "CTA on settings page"`)
  so translators get it right the first time

## Anti-patterns

- String concatenation ("Hello " + name + "!")
- Translating placeholder variables
- Storing translations in the database when they should be in static JSON
  (slow, hard to review)
- Keeping stale keys forever (add a "last seen in code" check)

## Output

- `locales/{en,...}.json` with hierarchical keys
- Type-safe translation helper (e.g. `t('settings.save')`)
- RTL-tested layout with logical CSS properties
- CI check that fails on hardcoded JSX strings
- TMS sync workflow documented in README

How to install

Create the skill directory and file

terminal

mkdir -p ~/.claude/skills/i18n-manager

Copy the SKILL.md content above

file path

~/.claude/skills/i18n-manager/SKILL.md

Resulting file structure:

~/.claude/
  skills/
    i18n-manager/
      SKILL.md    <-- skill definition

Skills are loaded automatically by Claude Code when you start a new session. The skill name and description in the frontmatter determine when Claude triggers it.

Learn this in depth

Free courses on AI-assisted development and building agents

Trace your skill's performance

Local observability dashboard for AI tool usage

Build GraphQL schemas with resolvers and type-safe client generation

Both used by Software Engineer

Intermediate

i18n Manager

Extract strings, manage translations, and validate i18n completeness

--- name: i18n-manager description: | Trigger when the user asks to add internationalization, translate a UI, or manage locales. Phrases: "i18n", "internationalization", "translate", "add locale", "translation keys", "multi-language", "localize". allowed-tools: - Read - Write - Edit - Grep - Bash(pnpm add *) --- # i18n Manager Set up and maintain internationalization without turning every string into a maintenance burden. Covers key structure, plurals, interpolation, RTL support, and the "who actually translates this?" question. ## Prerequisites - Framework chosen: next-intl / react-intl (React), vue-i18n (Vue), i18next (framework-agnostic), Paraglide (compile-time) - Locale list decided (start with 2; adding more is cheap, removing is not) - Translation workflow picked: Crowdin, Lokalise, Phrase, or plain JSON reviewed in PRs ## Steps 1. **Pick a key convention and stick to it.** Two viable styles: - **Hierarchical:** `settings.profile.email.label` - searchable, groups well, survives refactors when keys move with features - **Flat English:** `"Email address"` as the key itself - readable in code, no indirection, but breaks when English copy changes Hierarchical wins for apps with 500+ strings. Flat wins for small apps and marketing sites. 2. **Default locale file is the source of truth.** `en.json` is written by product/design. All other locales are derived. Never let translators edit `en.json` directly. 3. **Interpolation, not concatenation.** Never build sentences by joining fragments; grammar varies across languages. ```json { "greeting": "Hello, {name}! You have {count} messages." } ``` 4. **Plurals with ICU MessageFormat:** ```json { "cart.items": "{count, plural, =0 {empty} one {# item} other {# items}}" } ``` English has 2 plural forms. Arabic has 6. Russian has 3. Let ICU handle it. 5. **Dates, numbers, currency via Intl, not strings.** ```ts new Intl.DateTimeFormat(locale, { dateStyle: 'medium' }).format(date) new Intl.NumberFormat(locale, { style: 'currency', currency: 'EUR' }) ``` 6. **RTL (Arabic, Hebrew, Persian).** Use logical CSS properties (`padding-inline-start`, not `padding-left`). Set `dir="rtl"` on `<html>` based on locale. Test with pseudo-locale `ar-SA` early. 7. **Extract keys automatically.** Run a linter that fails CI if a hardcoded string appears in JSX. `eslint-plugin-i18next` or `eslint-plugin-formatjs`. 8. **Translation workflow.** - New keys land in `en.json` via normal PRs - CI exports new/changed keys to the TMS (Crowdin, Lokalise) - Translators work in the TMS; their output syncs back to the repo - Missing keys fall back to `en` at runtime with a warning in dev 9. **Lazy-load locale bundles.** Do not ship 40 languages to every user. Code-split by locale; load on demand. ## Patterns that work - Pseudo-locale (`[!!Ëñglïsh!!]`) enabled in dev to spot hardcoded strings - Type-safe keys via generated TypeScript from the JSON files - One string, one key - never duplicate to match UI context - Context notes on keys (`"button.save.description": "CTA on settings page"`) so translators get it right the first time ## Anti-patterns - String concatenation ("Hello " + name + "!") - Translating placeholder variables - Storing translations in the database when they should be in static JSON (slow, hard to review) - Keeping stale keys forever (add a "last seen in code" check) ## Output - `locales/{en,...}.json` with hierarchical keys - Type-safe translation helper (e.g. `t('settings.save')`) - RTL-tested layout with logical CSS properties - CI check that fails on hardcoded JSX strings - TMS sync workflow documented in README

i18n Manager

About this skill

Capabilities

Use cases

Tags

Skill Definition

How to install

Create the skill directory and file

Copy the SKILL.md content above

Related skills

API Integration Builder

Agentic Stack

Context Engineering Kit

Browser MCP

Error Handler

GraphQL Schema Builder

i18n Manager

About this skill

Capabilities

Use cases

Tags

Skill Definition

How to install

Create the skill directory and file

Copy the SKILL.md content above

Related skills

API Integration Builder

Agentic Stack

Context Engineering Kit

Browser MCP

Error Handler

GraphQL Schema Builder