---
name: translation
description:
Translate site copy to Brazilian Portuguese in a register and vocabulary that
match the existing translated collections. Use when adding a new localized
field, auditing a chapter for missing or identical en/pt pairs, or proposing
translation candidates for review. Always pair with
[`../../rules/content-i18n.md`](../../rules/content-i18n.md).
---
# Translation
This site is bilingual EN/PT-BR. The English is editorial; the Portuguese has to
read like a native technical writer, not like a machine. The glossary
([`references/glossary.md`](references/glossary.md)) and tone notes
([`references/tone.md`](references/tone.md)) pin the conventions so any agent —
me, a different LLM, a future you — produces Portuguese that matches what is
already there.
## Before anything
Read [`../../rules/content-i18n.md`](../../rules/content-i18n.md) and
[`../../context/content-i18n.md`](../../context/content-i18n.md). Both are
binding. In particular:
- Both `en` and `pt` are required on every `localized` field. A missing `pt`
must fail the build.
- These are hand-written translations with deliberate tone. **Copy, do not
retype.** Retyping introduces drift.
- The site's bilingual contract is client-side: both languages ship in the
payload, the toggle swaps visibility. Do not propose `/en/` `/pt/` routing
without a separate decision.
## Audit before you propose
Run the audit script first. It walks `src/content/**` and reports every
`localized` field where `en === pt`:
```bash
node .agents/scripts/audit-translations.mjs
```
The script exits non-zero on any identical pair. That is the list you work from
— chapter, file, field. Touch only what's flagged, and only after a human has
reviewed your proposal for the first chapter (the tone is contagious: if the
first chapter is right, the rest fall into the same voice).
## Propose, do not commit
This skill is **review-first**. The workflow is:
1. Pick the smallest chapter (today: `landing.json`, 30 fields). Read the
English, read the existing translations in the other collections to absorb
the voice, then write candidates.
2. Show the diff to a human reviewer. They sign off on tone, terminology, and
register before you proceed to the next chapter.
3. Only after the reviewer agrees, write the JSON. Re-run the audit; it must
pass.
4. Repeat for the next chapter.
Auto-committing a translation in bulk is the same failure mode as a content
migration that "passes" by deleting assertions: silent monolingualism. The
review step is the whole point.
## What stays in English
Some terms are kept in English by deliberate convention. Do not translate:
- Code identifiers, file paths, command names, product names (`SKILL.md`,
`AGENTS.md`, `.agents/skills/`, `git`, `pnpm`, `claude`, `opus`, `sonnet`,
`haiku`, `gpt-5.6`, `sol`, `terra`, `luna`)
- Product surface nouns that the team has decided to keep: `skill`, `worktree`,
`worker`, `branch`, `merge`, `commit`, `diff`, `brief`, `gate`, `pipeline`,
`recall`, `prompt`
- The `` and `` glyphs that ship in copy — they are decorative and
the stylesheet depends on them
- Arrows used as connectors (`→`, `↗`) — keep them, the spacing is intentional
The full list is in the glossary.
## What to translate
Everything else, including:
- Section titles, ledes, eyebrows
- Card titles, body copy, call-to-action labels
- Stage / phase labels in prose ("PLAN", "BUILD", "REVIEW" stay uppercase
English because they are acronyms in the design system; the prose around them
translates)
- Inline `` emphasis and `
` line breaks — the structure is shared, the
words differ
## Verification
After writing, before committing:
```bash
pnpm run build # schema check (both locales present)
node .agents/scripts/audit-translations.mjs # en !== pt everywhere
pnpm run verify # full gate, includes rendered snapshots
```
A rendered snapshot diff in `verify.mjs` catching a new Portuguese string is
expected. Update `.agents/snapshots/*.txt` if the prose really did change and
the snapshot was a stale capture. Do not delete assertions to make it pass.
## What this skill does NOT do
- Migrate content out of legacy `app.js` (that's `content-migration`)
- Wire `lang` state into chapter pages (that's tasks 12 / 13 / 15)
- Edit `src/content/config.ts` (the schema is `verification-engineer`'s scope)
- Touch components, layouts, styles, or the legacy tree
- Translate code, comments inside code blocks, command output, or paths
The chapter's review-desk body (`src/content/reviews/*.md`) is intentionally not
localized — the review desk is an English-only editor by design.