How to use AI to translate an extension

Replace bracketed values before sending the prompt. Give the assistant the relevant public files from the exact target release; use synthetic examples and keep credentials, private campaigns and proprietary material out of its context.

What you will build

Translate the interface of your own package while preserving identifiers, authored campaign content and exact legal notices.

Context to give the assistant

• The package’s existing keys/catalogs and its i18n registration and lookup calls.

• docs/en/modules.md: private catalogs, context.i18n and document-type labelKey.

• A glossary of game terms you are authorized to translate and screenshots of long/empty states.

Step by step

1. Inventory interface strings without changing identifiers or player-authored text.

2. Keep English as the fallback and preserve explicit language choices.

3. Ask for matching key sets in en, pt-BR and es using the official package mechanism.

4. Inspect long text, placeholders, pluralization, missing keys and narrow layouts in the real interface.

Copy and adapt this prompt

Repository: [local checkout or public repository]
Target host release: [installed/requested version; preserve it]
Task scope and authorization: [what may be changed/published]

Translate the interface strings of [package] using its supported i18n mechanism.
Inspect the existing catalogs and context.i18n registration/lookups. Keep catalogs inside the owning package and preserve English fallback and explicit user language choice.
Produce en, pt-BR and es with identical keys. Preserve interpolation variables, identifiers, command names and document data. Do not translate user-authored names or exact license notices.
Use the glossary [original terms]. Mark ambiguity for review instead of inventing rules or copying proprietary book passages.
Register translated type labels through documented labelKey behavior where applicable. Do not change core language globally as a shortcut.
Validate missing keys, long text, empty states, focus and layout at narrow widths, with interface text at least 12px.

Inspect the actual files and supported APIs before proposing code. Do not invent commands, fields, endpoints or package capabilities.
Use disposable test data and installation-local tools/caches. Explain any unsupported requirement and validate the result with the project’s real tools.
Deliver concrete files or editor steps, the checks performed and any unresolved limits.

How to validate

• Compare key sets and placeholder names across all three catalogs.

• Switch languages in the actual package; check fallback without translating campaign content.

• Inspect the longest labels and empty/error states on a small viewport.

Ready when

The package uses its official catalogs with matching keys, readable layouts and preserved authored/legal content.

Continue with the module reference, public API and testing guide.