Localization prompts: gate release on catalog and rendered retests

Last updated: 4 Oct 202611 min read

tutorial

A localization release packet needs the source and target catalog versions, changed-key list, placeholder and plural checks, language-review status, rendered-state evidence, open defects, and named approval. The prompt may summarize that packet, but it must not convert missing checks into a pass. Count distinct failed keys, not screenshots or repeated observations, and preserve each finding's owner and retest path. A fix to a shared renderer can close several failures only after every affected state is checked against the same release build.

Operational case

Harbor's H-47 packet has 47 keys. Forty-two pass, while HP-07, HP-12, HP-18, HP-29, and HP-41 each fail a different gate. A reviewer assigns the first two to message owners, mixed direction and clipping to component owners, and date ambiguity to the formatter owner. After repairs, the packet records the new catalog and build versions plus retest evidence for all five. Until then, the localized release remains blocked regardless of a polished summary.

H-47: 47 keys = 42 pass + 5 failed distinct keys
Open: HP-07, HP-12, HP-18, HP-29, HP-41
Required: owner, fixed build, rendered retest, language review
Decision now: do not release the locale

Performance and review cost

Set comparison between source and target catalogs is O(N) expected time for N keys; retesting F failed keys adds at least O(F) targeted checks. A release ledger saves time by narrowing inspection to changed and affected states, but shared-component changes still warrant broader regression samples. No prompt wording can replace missing runtime or language evidence.

Common Mistakes

Do not count five screenshots of one defect as five distinct failed keys.
Do not approve a locale with an untested required action.
Do not omit the catalog and build versions from a retest receipt.

Connected lessons

prompt engineering

localization quality