Translate Add Locale

translate-add-locale

A thin orchestrator for adding one interface language to a codebase. The mechanical scaffolding is delegated to the general-purpose Agent; this skill resolves the locale metadata, sanity-checks it isn't a country code, hands off a clean brief, then points at /translate for the real work.

"Scaffolded" ≠ "done." The scaffold makes the build go green and the UI render in the new locale, but every string is still a source-language placeholder. The locale is not done until /translate --full --to <locale> fills it and the completeness gate confirms zero leftovers. The scaffold step reports 🟡 SCAFFOLDED — NOT DONE until then.

What this skill does NOT do

• Translate. It clones the source language into the new locale's files as placeholders. Real translation + terminology audit is /translate's job, run right after (Step 4 hand-off). Do not hand-translate here and do not spawn the translator panel inline.
• Add a data/content entity (a new product, country, article). A new language is not a new entity.
• Change source facts, numbers, or references.
• Commit or push. Stop on the working branch and let the human commit.

Language code vs country code (read first)

The argument is the language/locale code, never a country code. They diverge often: Greek is el (not gr), Czech cs (not cz), Ukrainian uk (not ua). Regional variants use BCP-47 / WP form as the project already uses them (pt-BR / pt_BR, zh-Hans, en-GB). If the user says "add GR", confirm they mean the Greek language (el), not a Greece entity. RTL check: if the language is right-to-left (ar, he, fa, ur), flag it — the scaffold does not handle dir="rtl", mirrored layout, or font subsetting; those need design work before the locale ships.

Invocation

/translate-add-locale <locale>            # e.g. /translate-add-locale el   or   /translate-add-locale pt-BR

If no locale arg, ask once (AskUserQuestion) for the code and the language's native name.

Step 1 — Resolve the locale metadata

Gather once (from a standard locale table; use AskUserQuestion only if you can't determine them):

Step 2 — Detect the wiring and brief the worker

First discover how this project registers a locale (don't assume a layout) — Glob/Grep for the locale list, the message-catalog naming, the routes/build config, and the language switcher. Then hand a general-purpose Agent a brief listing every surface to touch:

• Add the locale to the type union / locale registry (locale list, HTML-lang map, OG-locale map).
• Clone the message catalog to the new <locale> file (JS/TS/JSON) — or, for WordPress, copy languages/<textdomain>.pot to languages/<textdomain>-<locale>.po and set its Language: + Plural-Forms: header (leave every msgstr empty for /translate to fill).
• Mirror per-context copy files and content-tree pages (MDX/HTML/.po) as source-language placeholders so routes resolve and the build is green.
• Add metadata (native name, flag, number-format fields) wherever the project keeps it.
• Add routes / build config (locales array, sitemap, hreflang) and the language switcher entry.
• Run the project's type/build gate; report red/green.
• Quantify the placeholder backlog (how many strings/files still read source-language) so /translate knows the size of the job.

The worker returns: status 🟡 SCAFFOLDED — NOT DONE (<N> placeholders owed), the files created/edited, the gate result, and the backlog count.

Step 3 — Relay the worker's summary

Print it as-is — status, backlog, files, gate result. Don't editorialize.

Step 4 — Hand off to /translate

Tell the user (and, if they confirm, invoke it): the locale is scaffolded but every string is a placeholder. Run:

/translate --full --to <locale> --domain <the project's specialization>

to fill it. The completeness gate in /translate confirms the locale adds zero leftovers before it's considered done.

Reference

• Translation half: /translate skill (drives the Lead → Senior/Junior panel).
• Coverage check (after filling): /translate-audit — confirms the new locale has no missing keys.
• Panel agents: .claude/agents/translate-lead.md, translate-senior.md, translate-junior.md.
• Config: translation.config.json (the project's source/target langs + specialization).