Translate with AI into Indian Languages: A Quality Checklist

If you ask a model to translate your product page into Hindi and the result reads fine to you, that tells you almost nothing, because you can't see what a native reader sees. The way to get a trustworthy translation is not a cleverer prompt. It is a short pipeline: fix the terms before translating, translate with the right constraints, run mechanical checks, back-translate to find dropped meaning, and have a native reader sign off on a sample.

This post is that pipeline: a checklist, three prompt templates (untested on a live model, so adapt them), a small script I wrote and ran, and a clear rule for when to hire a human. It covers translation to and from Indian languages such as Hindi, Tamil, Bengali, Telugu and Marathi.

What do you decide before you translate?

Most bad translations are decided before the first token is generated. Answer these first:

1. Who reads it, and where? A government notice, a WhatsApp reply and a landing page each need a different register. Write it down in one sentence.
2. Politeness level. Pick one (for example "aap" form in Hindi) and state it.
3. Script and digits. Devanagari or Roman? ASCII digits or native digits? Date format?
4. Term policy. For each domain term, decide: translate it, transliterate it, or keep it in English. Many Indian users say "refund" or "password" in English even in a Hindi sentence.
5. Names, brands, placeholders. Which strings must never change?
6. Stakes. If a mistake could hurt someone, plan for a human reviewer now (see the last section).

How do you build a glossary the model will actually follow?

A glossary in the prompt works better than "use correct terminology", and it is checkable afterwards. A table is enough:

The Hindi forms in this table are illustrative examples I wrote; no native speaker has reviewed them, so don't copy them into production. Get the target forms from a native speaker or from your existing published copy, not from the model. If the model proposes terms, treat them as suggestions for a reviewer to accept. Keep the glossary in the same file as your prompts and version it, as you would with any other prompt asset.

What prompt should you use to translate?

Untested template for the translation step:

Translate the text between the markers from [SOURCE_LANGUAGE] to [TARGET_LANGUAGE].

Audience and register: [AUDIENCE, e.g. retail customers on mobile, polite "aap" form, plain spoken style].
Script: [e.g. Devanagari]. Numbers: ASCII digits 0-9. Dates: DD-MM-YYYY.

Glossary (use these exact target forms; do not translate rows marked "never change"):
[GLOSSARY TABLE]

Rules:
- Keep every placeholder such as [ORDER_ID] exactly as written.
- Do not add, remove or summarise sentences. One source sentence becomes one target sentence.
- If a phrase is ambiguous or idiomatic, translate the meaning, not the words, and list it under NOTES.
- Do not explain the translation inside the text.

Output format:
TRANSLATION:
[translated text]
NOTES:
[bullet list of ambiguities or choices, or "none"]

TEXT:
"""
[TEXT]
"""

The "one source sentence becomes one target sentence" rule exists so a mechanical check can align sentences and catch dropped ones. The NOTES section gives your reviewer a shortlist of risky choices, but a model that says "none" has not proven there are none.

How do you run mechanical checks (with a script)?

Before anyone reads the translation, a script can catch the cheap errors: changed numbers, damaged placeholders, glossary terms missing, and suspicious length. I wrote this and ran it on 2026-10-08 with Python 3 (standard library only):

import re, unicodedata

DIGIT_ZEROS = [0x0966, 0x09E6, 0x0BE6, 0x0C66]  # Devanagari, Bengali, Tamil, Telugu

def to_ascii_digits(s):
    out = []
    for ch in s:
        cp = ord(ch)
        for z in DIGIT_ZEROS:
            if z <= cp <= z + 9:
                ch = str(cp - z)
                break
        out.append(ch)
    return "".join(out)

def check(source, target, glossary, placeholders=r"\[[A-Z_]+\]"):
    problems = []
    if sorted(re.findall(placeholders, source)) != sorted(re.findall(placeholders, target)):
        problems.append("placeholders differ")
    if sorted(re.findall(r"\d+", to_ascii_digits(source))) != sorted(re.findall(r"\d+", to_ascii_digits(target))):
        problems.append("numbers differ")
    t = unicodedata.normalize("NFC", target)
    for term, required in glossary.items():
        if term.lower() in source.lower() and unicodedata.normalize("NFC", required) not in t:
            problems.append("glossary: '%s' should appear as '%s'" % (term, required))
    ratio = len(target) / max(1, len(source))
    if ratio < 0.5 or ratio > 2.0:
        problems.append("length ratio %.2f outside 0.5-2.0" % ratio)
    return problems

I ran it on one translation I wrote, and on two deliberately broken ones (labelled illustrative, I wrote the errors by hand). Real output:

OK translation -> PASS
Illustrative broken: number, placeholder, glossary -> FAIL
   - placeholders differ: ['[ORDER_ID]'] vs []
   - numbers differ: ['1500'] vs ['1050']
   - glossary: 'invoice' should appear as 'इनवॉइस'
Illustrative broken: dropped sentence -> FAIL
   - numbers differ: ['2'] vs []
   - length ratio 0.31 outside 0.5-2.0

Look at the last case. The dropped sentence was caught only because it happened to contain the number 2, and because the length ratio fell to 0.31. A dropped sentence with no number and a smaller loss would pass. That is the limit of mechanical checks: they find damage to things you can count. Meaning needs the next step. The length bounds (0.5 to 2.0) are my arbitrary starting values; tune them per language pair on your own data.

How does back-translation help, and where does it fail?

Back-translation means translating the output back to English with a fresh prompt, then comparing against the original. It is good at finding dropped content, flipped negations ("do not" becoming "do"), and wrong entities.

Untested template for the back-translation step. Use a fresh conversation so the model can't see the original:

Translate the following [TARGET_LANGUAGE] text into English. Translate literally, including awkward phrasing. Do not fix errors or improve the text. Mark any word you are unsure about with [?].

TEXT:
"""
[TRANSLATION]
"""

Then compare the two English texts with a second prompt or by eye:

Compare ORIGINAL and BACK_TRANSLATION. List only differences in meaning: added claims, missing claims, changed numbers or names, changed negation, changed tone. Quote the exact words from each side. If there are no differences, say "none found".

Where this fails: a model may repair a clumsy phrase while translating back, so natural-sounding English can hide an unnatural Tamil sentence. It also shares blind spots with the first model. And it says nothing about register, politeness level or whether a phrase sounds like a textbook. Treat it as a way to prioritise what the human reviewer reads, never as sign-off. For the broader check-your-facts habit, see how to fact-check AI answers.

What should the native reviewer check?

Give the reviewer a short rubric, a sample (every sentence for short texts, at least 20 percent for long ones, always including the highest-stakes parts), and the NOTES from the translation step. Ask them to mark each issue by type so you can fix the prompt, not just the text.

Record every correction. After a few batches you will see patterns, such as a consistently wrong honorific, and those patterns become new lines in the prompt or entries in the glossary. If you want a more systematic setup for scoring, see building evaluation datasets.

What about translating into English from Indian languages?

The risks differ. The model usually produces fluent English, which makes errors harder to spot. Ask for a literal pass first, with uncertain words marked, as in the back-translation template, then a polished pass. Keep the original text next to the translation for whoever uses it. For names of people and places, ask the model to list how it transliterated them, because spellings vary and a wrong one can break search or matching.

If your source text is mixed-language (Hinglish with English words), tell the model so, since otherwise it may treat the English words as errors to fix. More on mixed-language prompts in prompting in Hindi and Indian languages.

When should you hire a human translator instead?

Use a human, either as the translator or as a paid final reviewer, when:

• A wrong word has consequences: contracts, consent forms, medical instructions, drug or safety labels, tax and regulatory notices, official filings. Whether certified translation is required for your purpose is a question for a qualified professional in your jurisdiction; I haven't verified it for any specific authority here.
• It is public and permanent under your brand: a launch page, a TV or print slogan, app-store copy. Slogans and humour rarely survive literal translation.
• Nobody in your team reads the language, and the stakes are above "a customer will be mildly confused". Machine checks cannot replace a reader.
• Your review samples keep finding the same problem after two prompt revisions. At that point you are paying more in review than you would pay a translator.

AI is a good first draft for a human to correct, and often a good enough final for low-stakes, high-volume, easily corrected text such as internal notes or draft support replies. Decide by the cost of a mistake, not by how fluent the output sounds.

Cost and context for long documents

Indic scripts use more tokens than English, so a long document costs more to translate, and the output limit matters: a limit set for English can truncate a Tamil translation. I measured the multipliers in tokenizer cost for Hindi, Tamil and Bengali; on one tokenizer Tamil needed about 2x the English tokens and on an older one over 7x. Translate in chunks along sentence or paragraph boundaries, keep the glossary in every chunk, and check each chunk with the script above.

The checklist

1. Audience, register, script, digits, dates written down.
2. Glossary with exact target forms, versioned.
3. Translation prompt with placeholder and sentence rules, plus NOTES.
4. Mechanical checks run (numbers, placeholders, glossary, length).
5. Back-translation in a fresh conversation, differences listed.
6. Native reviewer on a sample, issues tagged by type.
7. Fixes fed back into prompt and glossary.
8. High-stakes content routed to a human translator or qualified professional.