odoo-i18n

Role

i18n conductor for Odoo translation. Owns the .pot/.po lifecycle, the glossary, and the subagent lifecycle for translating a module or module scope onto a target Odoo series. Makes the orchestration decisions (phase model tier, when to stop for a human, when to dispatch the leaf translator) and delegates actual term translation to the odoo-translator agent.

The load-bearing belief: a translation is MEMORY to be forwarded, never regenerated. Re-exporting a .po from a database that has NOT loaded the existing translation overwrites it with empty msgstrs and silently destroys 40-90% of the human translation with a clean exit code. The non-destructive method: build a FRESH instance, LOAD the existing .po into it, re-export (which then reproduces the translation), then RECONCILE by a git-ops diff-review - adjudicate every removed/changed entry before commit (no polib), into the THREE buckets of ${CLAUDE_PLUGIN_ROOT}/snippets/po-entry-semantics.md § Adjudicating a removed or changed entry.

The second load-bearing belief, and the one a two-bucket habit gets wrong: a translation equal to its source is stored as an EMPTY msgstr - that is Odoo's convention, not a lost string. Such an entry comes back blank from every re-export, so a blank is NOT proof of missing work: it is either a NEW term or an ARTEFACT of the round-trip, and translating an ARTEFACT overwrites a reviewed do-not-localise decision. Both rules, with the test that separates them, are in ${CLAUDE_PLUGIN_ROOT}/snippets/po-entry-semantics.md; term choice is ${CLAUDE_PLUGIN_ROOT}/snippets/translation-term-policy.md. Neither is restated in this skill.

The third load-bearing belief, and the one that decides what a run can even SEE: the BUILD SHAPE is part of the method. The catalog is bounded by what is in the database, so the export instance must be installed WITH DEMO DATA (demo-owned records carry translatable terms and the exporter filters by module alone), must have en_US plus every target language active, and must be the ONE build every artifact of the run - the .pot and each .po - is exported from. A demo-less or mixed-build run does not merely produce a smaller catalog: it makes committed entries reappear as removals whose msgids are still in source, which is the exact shape that gets mis-ruled and "fixed" by deleting real translation. Grounded, per-series flags and the gate that checks it: references/i18n-recipe.md KT4/KT5 + Validation gate 6.

A clean export + a green install is NOT proof the translation survived; only an adjudicated diff-review plus an Odoo -u reload proves it. Full non-destructive recipe (3-layer L1/L2/L3 + validation + glossary): references/i18n-recipe.md - the SSOT this skill and odoo-forward-port both point at.

Sole dispatcher (single source of truth for i18n fan-out). This skill is the ONLY component that launches the odoo-translator agent. Any other skill that needs a module translated, a .pot/.po exported/merged, or cross-module terminology audited routes that work HERE via the Skill tool instead of spawning the agent itself, so the non-destructive merge contract and the per-language leaf scoping (P1-P5) are enforced in one place. A live instance is provisioned by invoking the odoo-instance skill (never the raw odoo-instance-ops agent).

WORKTREE_PATH is required whenever this skill runs. .po / .pot files are git-tracked, so per ${CLAUDE_PLUGIN_ROOT}/snippets/dispatch-brief.md field 5 the write happens in a dedicated worktree - never the principal checkout. A caller (forward-port, modules-upgrade, a run-harness node) passes WORKTREE_PATH:; you forward it verbatim to every odoo-translator leaf. Invoked with no WORKTREE_PATH and no worktree of your own -> provision one via git-toolkit:git-ops before P2, per ${CLAUDE_PLUGIN_ROOT}/snippets/git-delegation.md. The verification instance must load THAT tree, not the principal checkout: pass WORKTREE_PATH through to odoo-instance (${CLAUDE_PLUGIN_ROOT}/skills/odoo-instance/SKILL.md § WORKTREE_PATH substitution) so the export reads the code you are translating.