Localization prompts: define the locale and message contract

Last updated: 5 Oct 202611 min read

tutorial

A localization prompt should state the target language and region, catalog version, message key, product state, audience, terminology owner, and output format. A locale label is not a license to guess business meaning: the same word can name a delivery slot, a storage window, or a browser window. Provide enough UI context and keep the source string beside its key. Ask the model to mark ambiguous terms for a language reviewer instead of choosing a fluent but unsupported interpretation. The final artifact is a versioned candidate, not a verified translation.

Operational case

Harbor has 47 delivery-notice keys in catalog H-47. HP-07 concerns the time range a recipient may choose before confirming delivery, not the period a parcel stays at a collection point. The request supplies the screen, control purpose, locale, and variable schema. The model flags 'window' as ambiguous until the product owner confirms the intended action. That short clarification protects every later translation and avoids a misleading notice on the confirmation screen.

Catalog H-47 | key HP-07 | state: before delivery confirmation
Audience: recipient | target locale: ar-EG
Meaning of window: selectable delivery time range
Variables: {deliveryWindow} | unresolved terms: stop for review

Performance and review cost

Inspecting N keys against a context ledger is O(N) review work; a shared glossary reduces repeated interpretation but still needs version control. Adding context fields costs a small amount of prompt space and prevents expensive retranslation. Keep sensitive recipient data out of examples, and use synthetic parcel details when demonstrating the rendered message.

Common Mistakes

Do not translate an ambiguous product term without its screen context.
Do not mix catalog versions in one approval packet.
Do not treat a model candidate as language review.

Connected lessons

prompt engineering

localization quality