Localization prompts should give an agent the context a translator or interface reviewer would need. A short label may be a button, a status or a noun in a sentence. A count may need language-specific plural forms, and longer wording may change the layout. These prompts focus on application readiness: preserving message structure, checking formatting and testing the interface after text changes.
Provide a message system and product context
Include source messages, key names, supported locales and the message library version. Explain where each message appears and show relevant screenshots or component code. Supply a glossary for product terms and a rule for names that remain untranslated. Use sanitized example values so the agent can understand variables without seeing customer data.
The ICU message-format guide explains selection and plural arguments and the importance of complete message context. Verify the exact syntax your library supports. The prompts below do not assume every application uses the same ICU generation or supports every formatting feature.
Preserve structure while drafting localized messages
Ask for key and variable preservation before requesting fluent wording. A translation that changes a placeholder name can fail at runtime even when the sentence reads well. Have the agent flag ambiguity instead of deciding whether an isolated word is a verb or noun. Keep machine-checkable syntax review separate from language approval.
Draft localization for {{message_file}} into {{target_locale}}.
Context: {{screens_and_glossary}}. Message system: {{library_version}}.
Preserve keys, placeholder identifiers and supported formatting syntax.
Explain ambiguous source messages before choosing wording. Return a draft
and a list for qualified language review. Validate message parsing with
our existing tooling; do not present a syntax pass as language approval.
Review plural and formatting behavior
Give representative values rather than testing only one and two. Ask how the locale handles counts, dates, times and currencies in the actual product context. A currency symbol alone does not identify the intended currency. Timezone and rounding choices are product decisions that need an explicit rule before the agent formats values.
Review localized formatting in {{component_paths}} for {{locales}}.
Use {{message_library}} and these product rules: {{formatting_rules}}.
Check count branches, zero, representative larger values, dates, timezone
and currency. Identify string concatenation that loses sentence context.
Propose targeted fixtures and assertions. Mark missing product rules
instead of guessing a timezone, currency or rounding policy.
Test expansion and direction in the interface
A locale-ready component needs room for longer labels and a plan for bidirectional content where applicable. Ask the agent to inspect truncation, wrapping, focus order and icons with directional meaning. Pseudolocalized text is useful for finding layout assumptions, but it does not prove the real translation is correct or natural.
Plan UI localization checks for {{screens}}.
Cover text expansion, wrapping, narrow viewports and {{direction_requirements}}.
Inspect layout assumptions, directional icons and mixed text/numbers.
Use pseudolocalization if our tooling supports it, then list checks with
real localized content. Keep keyboard and reading order meaningful.
Report browser observations separately from proposed code changes.
Keep language and interface review connected
After wording is approved, load it in the real interface and inspect the states users actually encounter. Error messages and empty states are easy to miss in a default screenshot. Record locale, viewport and example values beside any issue. Keep an unresolved-language list so a technically valid resource file is not mistaken for a finished localization.
Save the approved localization prompt in Kipt with variables for locale, glossary and message system. Use the design system prompts to document recurring layout and component rules discovered during the review.