Prompts for Translation and Localization

How to Use This Lesson Lesson 21 explained the foundations of translation with language models: register, formality, do-not-translate terms, placeholders in interface strings, transliteration, code-mixed text, and the difference between translation and localization. This lesson is a practical collection of translation and localization prompts for real projects, together with the code checks that make the results safe to publish.

Two principles run through every recipe:

1. The model translates language. Code handles exact formats (numbers, dates, prices, placeholders).
2. Every translation that users will see is checked automatically, and important ones by a fluent speaker. Recipe Purpose
3. Glossary-controlled translation Consistent terminology across a product
4. Short interface text with length limits Buttons, labels, notifications
5. Building a glossary from source text Finding the terms that need fixed translations
6. Marketing transcreation Adapting persuasive content, not translating it literally
7. Locale formats in code Numbers, currency, and dates for a region
8. Avoiding sentence fragments Translating complete messages instead of pieces
9. Consistency with earlier translations Reusing approved translations
10. Translation review A structured quality check
11. Back-translation check A quick meaning check for important text Recipe 1: Glossary-Controlled Translation Use it when: translating many texts for one product, where key terms must always be translated the same way.

Prompt Translate the text in from English into {target_language} for {audience}.

Glossary — always use these translations: {glossary}

Do not translate these terms; keep them exactly in English: {do_not_translate}

Keep placeholders in curly braces, such as {name}, exactly unchanged. Return only the translation.

{text} Example Settings Glossary — always use these translations:

• course → கோர்ஸ்
• certificate → சான்றிதழ்

Do not translate these terms: GOCOURSE, Django, OTP Checking Terms in Code The glossary is an instruction; code confirms it was followed.

GLOSSARY = {"course": "கோர்ஸ்", "certificate": "சான்றிதழ்"} DO_NOT_TRANSLATE = ["GOCOURSE", "Django", "OTP"]

def check_terms(source: str, translation: str) -> list[str]: issues = [] for term in DO_NOT_TRANSLATE: if term in source and term not in translation: issues.append(f"'{term}' should stay in English") for english, required in GLOSSARY.items(): if english in source.lower() and required not in translation: issues.append(f"'{english}' should be translated as '{required}'") return issues

source = "Your GOCOURSE certificate for the Django course is ready." print(check_terms(source, "உங்கள் GOCOURSE Django கோர்ஸ் சான்றிதழ் தயாராக உள்ளது.")) print(check_terms(source, "உங்கள் ஜாங்கோ படிப்பு சான்றிதழ் தயாராக உள்ளது.")) Output:

[] ["'GOCOURSE' should stay in English", "'Django' should stay in English", "'course' should be translated as 'கோர்ஸ்'"] Code Explanation For every do-not-translate term in the source, the translation must contain it unchanged. For every glossary term in the source, the translation must contain the required translation. The second translation transliterated "Django" into Tamil script, dropped "GOCOURSE", and used a different word for "course". All three problems are reported, so the string can be retranslated with the issues as feedback (Lesson 73). This check is intentionally simple: it does not handle grammatical changes in word endings, which are common in languages such as Tamil and Hindi. Treat its warnings as prompts for review, not automatic rejection, when your glossary includes words that change form.

Recipe 2: Short Interface Text With Length Limits Use it when: translating buttons, menu items, labels, and notifications, where space is limited.

Prompt Translate each interface string in from English into {target_language}.

Rules:

• Each translation must fit in at most the character limit given for that string.
• Buttons and menu items: use a short verb or noun phrase, as is natural for app interfaces in {target_language}.
• Keep placeholders unchanged.
• Return only JSON mapping each key to its translation.

{"button_enroll": {"text": "Enroll now", "max_chars": 15}, "menu_my_courses": {"text": "My courses", "max_chars": 18}, "toast_saved": {"text": "Your progress has been saved", "max_chars": 40}} Why It Works Per-string limits reflect real layout constraints: a button that is too wide breaks the screen. Interface conventions differ by language; asking for what is "natural for app interfaces" avoids overly literal or formal phrasing. Check in Code Compare len(translation) with each max_chars. Translated text is often longer than English, so plan layouts with extra space.

Recipe 3: Building a Glossary From Source Text Use it when: starting localization for a product and you do not yet know which terms need fixed translations.

Prompt List the terms in that should have a fixed, consistent translation across a product's interface and documentation.

Include: product and feature names, technical terms, and domain words that appear repeatedly. For each term, say whether it should usually stay in English for {audience} or be translated, and why in a few words.

Return only JSON: [{"term": "...", "keep_english": true or false, "reason": "..."}]

{text} Why It Works The model proposes candidates; a team member who knows the audience makes the final decisions. The approved list becomes the glossary for Recipe 1.

Recipe 4: Marketing Transcreation Transcreation means recreating a message for another language and culture so that it has the same effect, rather than translating the words literally. It is used for slogans, advertisements, and campaign messages, where a literal translation often sounds unnatural or loses its appeal.

Use it when: adapting persuasive content, not instructions or policies.

Prompt Adapt the marketing message in for {audience} in {target_language}.

Goal: the adapted message should create the same impression as the original: {intended_impression}

• You may change wording, idioms, and examples to sound natural to the audience.
• Keep these facts exactly: {facts}
• Do not add claims, discounts, or promises not in the original.

Return 3 alternatives, each with a short back-translation into English.

{text} Why It Works The intended impression tells the model what to preserve when the words change. Fixed facts ensure prices, dates, and offers remain correct. Back-translations let English-speaking reviewers understand each alternative before choosing. Note: Transcreated marketing should always be reviewed by a fluent speaker familiar with the audience. Cultural fit is exactly where automated output is least reliable.

Recipe 5: Locale Formats in Code Numbers, currencies, and dates follow regional conventions. India, for example, groups large numbers in lakhs and crores: ₹12,34,567 rather than ₹1,234,567.

These formats follow exact rules, so they belong in code, not in a prompt. Translate the text with a placeholder, then insert the formatted value.

def format_inr(amount: int) -> str: """Format an integer amount with Indian digit grouping, e.g. 1234567 -> ₹12,34,567.""" sign = "-" if amount < 0 else "" digits = str(abs(amount)) if len(digits) <= 3: grouped = digits else: last_three, rest = digits[-3:], digits[:-3] pairs = [] while len(rest) > 2: pairs.insert(0, rest[-2:]) rest = rest[:-2] if rest: pairs.insert(0, rest) grouped = ",".join(pairs + [last_three]) return f"{sign}₹{grouped}"

for amount in [999, 4999, 123456, 1234567, 10000000, -25000]: print(amount, format_inr(amount)) Output:

999 ₹999 4999 ₹4,999 123456 ₹1,23,456 1234567 ₹12,34,567 10000000 ₹1,00,00,000 -25000 -₹25,000 Code Explanation The last three digits form one group. The remaining digits are grouped in pairs from the right, which produces the lakh and crore pattern. Negative numbers keep their sign in front of the rupee symbol. Using It With Translations Translation template from the model: "{student} பணம் செலுத்த வேண்டிய தொகை: {amount}" Filled in code: amount = format_inr(4999) For many locales, libraries such as Babel provide number, currency, and date formatting rules, which is safer than writing your own formatter for each region.

Recipe 6: Avoiding Sentence Fragments Use it when: an application builds messages by joining pieces of text, which is a common source of broken translations.

The Problem Code like this works in English:

message = "You have " + str(count) + " " + ("lesson" if count == 1 else "lessons") + " left" But translating "You have", "lesson", and "left" separately fails in languages with different word order or grammar. The translator, human or model, never sees the full sentence.

The Fix: Translate Complete Messages Store and translate complete messages with placeholders, including separate versions for singular and plural where needed:

lessons_left_one: "You have {count} lesson left." lessons_left_other: "You have {count} lessons left." Prompt Translate each complete message in into {target_language}. Messages ending in _one are for a count of 1; messages ending in _other are for all other counts. Translate each as a natural, complete sentence for its count. Keep {count} and other placeholders unchanged. Return only JSON.

{messages_json} Why It Works Complete messages give the model the whole sentence, so it can use correct word order and grammar. Note that plural rules differ between languages: some have more than two forms. Internationalization libraries define these rules per language; follow their conventions when your application supports many languages.

Recipe 7: Consistency With Earlier Translations Use it when: updating a product that already has approved translations, so that new strings match the existing style and wording.

Prompt Translate the new strings in into {target_language}.

Approved earlier translations are in . Match their terminology, tone, and level of formality. If a new string is identical or almost identical to an approved one, reuse the approved translation.

Return only JSON mapping each key to its translation.

{approved_pairs}

{new_strings_json} Why It Works Approved translations act as examples of the desired style (Lesson 26) and as a translation memory: a store of previously approved source–translation pairs. Select only the most relevant approved pairs, such as those sharing words with the new strings, to keep the prompt short (Lesson 28).

Recipe 8: Translation Review Use it when: checking a translation before publishing, either with a model or as a checklist for a human reviewer.

Prompt Review the translation in of the source in .

Check each item and report problems only:

1. Meaning: anything added, missing, or changed
2. Numbers, dates, names, and placeholders: all present and unchanged
3. Terminology: glossary terms used correctly ({glossary})
4. Register: appropriate formality for {audience}
5. Naturalness: phrases that sound translated rather than natural

Return only JSON: {"problems": [{"type": "...", "text": "...", "suggestion": "..."}]} Return {"problems": []} if there are none. Why It Works A structured checklist focuses the review on the error types that matter most. A model review is a useful first pass, but it can miss subtle problems in languages where it is less strong, so final approval for important content should come from a fluent speaker.

Recipe 9: Back-Translation Check Use it when: you need a quick check that an important translation kept its meaning, and no reviewer is immediately available.

Prompt Translate the text in back into English as literally as possible. Do not improve, correct, or summarize it. Compare the back-translation with the original. Differences in meaning suggest a translation problem. As noted in Lesson 21, a good back-translation does not prove that the translation sounds natural; it only checks meaning.

A Localization Workflow

1. Extract complete messages with placeholders from the application
2. Build or update the glossary (Recipe 3) and get it approved
3. Translate with the glossary and approved translations (Recipes 1, 2, 7)
4. Check in code: placeholders, glossary terms, length limits (Lesson 21, Recipe 1)
5. Review: model checklist (Recipe 8), then a fluent speaker for important content
6. Insert locale-formatted values in code at runtime (Recipe 5)
7. Store approved translations for reuse Common Mistakes Mistake 1: Translating Fragments What it is: Translating pieces of sentences that code joins together.

Why it happens: The application was built for one language first.

What it causes: Wrong word order and grammar in other languages.

How to fix it: Translate complete messages with placeholders.

Mistake 2: Formatting Numbers and Dates in the Prompt What it is: Asking the model to write amounts and dates in local formats.

Why it happens: It seems part of translation.

What it causes: Inconsistent and sometimes incorrect formatting.

How to fix it: Format values in code and insert them into translated templates.

Mistake 3: No Glossary What it is: Translating each string independently.

Why it happens: Glossaries seem like extra work.

What it causes: The same term translated differently across screens.

How to fix it: Build and enforce a glossary, and check it in code.

Mistake 4: Literal Translation of Marketing What it is: Translating slogans word for word.

Why it happens: Translation and transcreation are treated as the same task.

What it causes: Messages that sound awkward and lose their effect.

How to fix it: Use transcreation with a stated intended impression and fixed facts, plus native review.

Mistake 5: Publishing Without Native Review What it is: Releasing translations that only a model has checked.

Why it happens: Translations look fluent.

What it causes: Subtle errors in tone or meaning that damage trust.

How to fix it: Use automated checks for structure and native speakers for meaning and naturalness.

Best Practices Translate complete messages. Never fragments.

Control terminology with a glossary and check it. Consistency builds trust.

Respect length limits for interface text. Check them in code.

Format numbers, currency, and dates in code. Use locale-aware libraries.

Reuse approved translations. Keep style and terminology stable.

Use transcreation for marketing. Preserve the effect and the facts, not the words.

Combine automated checks with native review. Each catches different problems.

Try It Yourself Exercise 1: Glossary Enforcement Create a glossary of five terms for your platform and a list of three do-not-translate terms. Translate ten interface messages into Tamil or Hindi with Recipe 1, check each with check_terms(), and retranslate any string with issues using the issues as feedback.

Exercise 2: Fix Fragmented Messages Find three places in an application, real or imagined, where messages are built from fragments, such as counts of lessons or days remaining. Rewrite them as complete messages with _one and _other variants, translate them with Recipe 6, and test with counts of 1 and 5.

Exercise 3: Locale Formatting Extend format_inr() to accept amounts with paise, such as 1234567.5, and format them as ₹12,34,567.50. Then write a function that formats dates as day, month name, and year, such as 15 November 2026, and use both functions to fill a translated payment reminder template.