Free Translation Prompt Generator (Tone-Preserving)

TL;DR: A translation prompt generator is a fill-in-the-blanks template with seven fields: source language, target language and locale, register, audience, content type, a do-not-translate list, and output format. Fill them in before you paste your text and the model preserves tone and intent instead of swapping words.

What is a translation prompt generator?

It is a prompt template that turns the seven decisions a professional translator makes before typing anything into blanks you fill in. Nothing installs. You copy the block, replace the brackets, paste your text.

The reason it beats "translate this into Spanish" is not that the model becomes smarter. It is that "translate this into Spanish" leaves seven decisions to a coin flip: which Spanish, spoken to whom, at what level of politeness, in what kind of document, with which of your product names left alone.

Here is the whole thing. Copy it, replace everything in square brackets, delete the options you do not want.

Translate the text below.

SOURCE LANGUAGE: [English / auto-detect and tell me what you detected]
TARGET LANGUAGE + LOCALE: [Spanish (es-MX) / German (de-CH) / Japanese (ja-JP)]
REGISTER: [name the exact form, not "formal" — see the table below]
  e.g. Spanish: use "tú" throughout, never "usted"
  e.g. German: use "du" throughout, never "Sie"
  e.g. Japanese: teineigo (です/ます). No sonkeigo, no kenjougo, no plain form.
AUDIENCE: [existing paying customers, 25-40, already know the product]
CONTENT TYPE: [in-app error / landing page / support email / UI button label /
  legal summary / social post]
TONE: [warm, direct, slightly apologetic. Short sentences.]
INTENT: [what the reader should do or feel after reading — they retry the
  action, they do not feel blamed]
DO NOT TRANSLATE (reproduce exactly, including case and punctuation):
  [Prompt Architects, Enhance, Refine, Pro, Advanced, {user_name}, %s, <b>, </b>]
LENGTH CONSTRAINT: [must fit a 24-character button / within ±15% of the source /
  no constraint]
OUTPUT FORMAT: [translation only, nothing else / table: source | translation |
  note]

RULES:
- Translate meaning and intent, not words. Reword freely if a literal rendering
  would sound translated.
- Hold the register identical in every sentence. Do not drift formal mid-text.
- Where the source is ambiguous, choose the reading that fits AUDIENCE and
  CONTENT TYPE, then flag it under NOTES.
- Do not add, remove or soften any claim, number, date, name or obligation.
- Idioms: replace with a native idiom of equal force, never a literal calque.
  List every swap under NOTES.
- If a DO NOT TRANSLATE term has an established local form, leave the source
  form and say so under NOTES. Do not decide that on your own.
- End with NOTES: at most 5 bullets. Ambiguities, register calls, idiom swaps.

TEXT:
[paste here]

That is the generator. The rest of this page is about filling it in without wasting a field.

Which fields change the translation most?

Register and locale do most of the work, and they are the two fields people leave blank. Content type is a close third, because it silently sets sentence length, punctuation and how much the model is allowed to editorialise.

The field almost everyone skips is intent, and it changes more than tone does. "Warm and apologetic" gets you softer adjectives. "The goal is that they retry the action and do not feel blamed" gets you a restructured sentence where the system takes responsibility, which is a different translation, not a nicer one.

The length constraint is the field that saves you a round trip. German runs longer than English for the same content, Japanese often runs shorter in characters, and a button that fits in English will break in German. If the string lands in a fixed-width UI element, say so in the prompt rather than discovering it in a screenshot.

Why does "formal" mean something different in every language?

Because the mechanism that carries formality is different in each one. In German it is a pronoun. In Japanese it is a verb system with several layers. In English it is nothing grammatical at all, just word choice and sentence length. Telling a model to "be formal" hands it a word that does not map onto one thing.

Most European languages have a T–V distinction: two second-person forms, one familiar and one deferential, where choosing wrong is not a style error but a social one. Japanese and Korean go further and encode the relationship in the verb itself. Chinese carries most of its register lexically rather than through a full pronoun system. English has no equivalent system, which is exactly why English speakers under-specify this field.

Two lines in that table deserve extra attention.

Japanese is not a two-way switch. Asking for "formal Japanese" tends to produce a mix of polite verb endings and honorific vocabulary, which reads as either overwrought or subtly wrong depending on where it lands. Teineigo is the neutral polite layer most product copy wants. Sonkeigo elevates the person you are addressing and kenjōgo lowers yourself, and both are relationship claims, not politeness dials. If you do not know which one your text needs, say teineigo only and get a native speaker to tell you whether that was right.

Thai politeness particles are keyed to the speaker, not the reader. ครับ and ค่ะ mark the gender of whoever is talking. For product copy that means you are choosing a voice for your brand, so the answer needs to be a deliberate decision rather than whatever the model assumed.

This is the specific thing an automated engine cannot do for you. DeepL, for instance, exposes a formality parameter, and its own API reference says the feature "is only available for certain target languages" and that setting it on an unsupported target fails unless you use one of the prefer_ options (developers.deepl.com, accessed August 2026). That is a binary switch on a subset of languages. It cannot select a keigo layer, and it cannot be told that this one email is to a customer you already have a first-name relationship with.

How do you pick the right locale, not just the right language?

Name the locale code, not the language. "Spanish" is roughly twenty markets with real vocabulary divergence. "es-MX" is one of them, and the model behaves differently the moment you write it.

Locale also controls the things that are not words. Date order, decimal separators, thousands separators, currency placement, address shape, and how a phone number is grouped are all locale-bound, and a model will happily leave your 03/04/2026 ambiguous unless you tell it what to do. Add a line: Reformat dates, numbers and currency for the target locale. Show dates in the locale's standard written form, not numerically.

What belongs on your do-not-translate list?

Three categories: names you own, interface strings that have to match your existing UI, and anything that is code rather than language. Localisation platforms call this a DNT list and keep it inside the project glossary, where it "tells translators, CAT tools, and machine translation engines which content to pass through untouched" (localazy.com, accessed August 2026). In a prompt it is one block you paste above the text.

DO NOT TRANSLATE — reproduce these exactly, character for character:

Brand and product names:
  Prompt Architects, Enhance, Refine, Shorten, Pro, Advanced, Team

Interface strings that must match the shipped UI:
  Settings, Prompt Library, Global Variables

Code, placeholders and markup:
  {user_name}   {count}   %s   %1$s   {{first_name}}   <b>   </b>   \n   &nbsp;
  ICU blocks such as: {count, plural, one {# file} other {# files}}

Terms that stay in the source language for regulatory reasons:
  GDPR, DPA, SOC 2

RULES:
- A listed string keeps its exact form even mid-sentence. Inflect the grammar
  around it, never inside it.
- Never translate, reorder, renumber or reformat a placeholder.
- Positional placeholders: if the target word order needs a different argument
  order, convert %s to indexed form (%1$s, %2$s) and flag it under NOTES.
  Do not silently swap two %s tokens.
- If moving a placeholder is unavoidable, move the whole token unchanged and
  say which one you moved.
- If you are unsure whether something is a placeholder, leave it alone and ask.

That positional-placeholder rule is the one that saves you a production bug. Bare %s tokens are filled in the order they appear, so a model that quietly reorders them to fit target-language syntax has swapped your two arguments and broken the string in a way no test catches until a user reads "Alice was added by the Marketing team" as "Marketing team was added by Alice". Indexed placeholders exist precisely for this, and the model will use them if you tell it to.

Plurals are the second trap. Unicode CLDR defines six plural categories — zero, one, two, few, many, other — and languages use different subsets of them, with other as the only required one (cldr.unicode.org, accessed August 2026). English uses two. Polish and Arabic use more. So a string translated with English's singular-plural pair baked in is structurally wrong in those languages, no matter how good the wording is. Handle it explicitly:

This string uses ICU MessageFormat. Source (en-US):
{count, plural, one {# file} other {# files}}

TARGET: [Polish (pl-PL)]
Return the same ICU structure using the plural categories CLDR defines for the
target language, not the English ones. Do not drop a category the language
needs. Do not add one it does not use. Keep # and the variable name exactly.
Return only the ICU string, nothing else.

If your output feeds a file rather than a human, ask for structured output with the key and the translation as separate fields, so nothing downstream has to parse prose. Showing the model the schema works better than describing it, which is the pattern covered in JSON prompts explained.

How do you check a translation in a language you cannot read?

Back-translation, then a separate register check. Neither one is sufficient alone, and the order matters.

Back-translation is the standard verification step in cross-cultural instrument design, where the sequence runs forward translation, expert panel, independent back-translation, then pre-testing. The point is not to produce a matching English text. It is to surface the places where meaning moved.

You are translating into [English]. You have not seen any original.
Translate the [Spanish] text below into [English] as literally as English
grammar allows. Do not smooth it. Do not correct anything that reads oddly.
Where a word could go two ways, give both, separated by a slash.

TEXT:
[paste the translation]

Run this in a fresh session. If the original English is still in the context window, the model reconstructs the source from memory rather than reading the translation, and you get a clean bill of health you did not earn. This is the most common way people fool themselves with back-translation, and it produces a false negative every single time.

Back-translation reliably catches dropped clauses, flipped negations, wrong numbers, wrong names, and quiet meaning drift. It does not catch register, and this is the part worth internalising: when you back-translate into English, the tú-versus-usted distinction disappears, because English has no grammatical formal second person to carry it back. A translation that addressed your enterprise customer as a close friend back-translates into perfectly acceptable English. Run a second pass for that:

Do not translate anything. Analyse the [Spanish (es-MX)] text below and answer
in English, in exactly this order:
1. Which second-person form does each sentence use? List any sentence that
   differs from the others.
2. Overall register, 1-5, where 1 is street casual and 5 is notarial.
3. Any sentence that would read as machine-translated to a native speaker,
   and the specific reason.
4. Any term that is correct in Spain but wrong in Mexico.
5. Anything a Mexican reader would find odd, awkward or unintentionally rude.

That second pass is the model grading its own homework, so treat it as a smoke test rather than sign-off. It catches gross drift, inconsistent pronouns, and obvious regional slips. It will not tell you that a phrase is technically fine but nobody says it that way. Only a native speaker does that, and for anything customer-facing, one native speaker reading it once is worth more than any amount of prompt engineering.

Which language pairs can you actually trust?

Trust drops as you move away from high-resource pairs, and the model gives you no signal when it happens. This is the honest limit of the whole approach.

Machine translation benchmarks have been deliberately getting harder because the easy ones stopped telling anyone anything. The most recent WMT general translation task was published under the title "Findings of the WMT25 General Machine Translation Shared Task: Time to Stop Evaluating on Easy Test Sets", covering 30 language pairs, evaluating 60 systems including LLMs and commercial providers, and using a difficulty-sampling technique with professional annotators to build harder test sets (aclanthology.org, accessed August 2026). When the field's own shared task frames its year around test sets being too easy, that is a good reason to check your pair rather than assume it.

The practical version:

The dangerous property is that fluency is not evidence of accuracy. A model optimises for plausible target-language text, so a bad translation reads beautifully. There is no equivalent of a compiler error. A hallucination in a translation looks exactly like a correct sentence, which is why the verification pass is not optional and why "it looks fine to me" is not a check when you do not speak the language.

Isolated UI strings deserve their own warning. "Open" with no context can be a verb or an adjective, and the two translate differently in most languages. If you are translating a strings file, add a comment field with what the string does and where it appears, and pass that into the prompt. A few-shot example of two already-approved strings from your own product helps more than another paragraph of instructions.

When is a human translator not optional?

Anywhere the translation is the legally operative text, and anywhere a wrong word causes physical harm. That is a short list and it is not negotiable.

Filings and immigration. US immigration is explicit about this. Under 8 CFR 103.2(b)(3), "Any document containing foreign language submitted to USCIS shall be accompanied by a full English language translation which the translator has certified as complete and accurate, and by the translator's certification that he or she is competent to translate from the foreign language into English" (law.cornell.edu, accessed August 2026). A model cannot certify its own competence, and no output of one satisfies that requirement.

Contracts. If the translated version is the version a counterparty signs, a softened obligation or a mistranslated deadline is now the deal. Get it translated by someone whose professional indemnity covers the mistake.

Medical and safety-critical text. Dosing, contraindications, allergen statements, machinery warnings. The failure mode is not embarrassment.

Anything with a quality standard attached. ISO 17100, the translation services standard, requires revision by a second qualified person who is not the translator who produced the text. That structural check is the thing AI translation does not have, and bolting a second model onto the end does not reproduce it, because both models share the same blind spots.

For high-volume software localisation, the right tool is a translation management platform with glossary, translation memory and DNT support — Smartling, Lokalise, Crowdin and Phrase all operate in that space — with AI as a first pass inside that workflow rather than a replacement for it. That is not our product and we are not going to pretend otherwise.

How do you reuse this without rebuilding it every time?

Retyping a forty-line block is how good prompt discipline dies in week two. Three ways to avoid it, in increasing order of setup effort.

Keep it as a saved template with the blanks visible. Any snippet tool works. The requirement is that the seven fields stay on screen as empty brackets, so you fill them in rather than shipping a prompt still pointed at last quarter's locale.

Turn the stable fields into variables. Target locale, register line, and the do-not-translate list change per project but not per string, so they belong in a variable rather than retyped into the body every time. That is the difference between a template you edit and a template you fill, and it is the same pattern described in reusable prompt variables for dev teams. If your brand has a defined voice, the tone and intent fields are better held in a reusable context than pasted per translation — building a brand-voice context covers how to write one that survives contact with a model.

Store it where your team can find it. Prompt Architects keeps prompts in a personal or shared library, with global variables for the fields that repeat and a Tone Selector for adjusting register on the output side. There is a free plan with a daily enhancement limit, and paid plans start at $4.99/month at the time of writing — current pricing lives on the pricing page. Built-in AI is included, so there is no separate API key to wire up. To be clear about what that is and is not: we build the prompt layer, not a translation engine. The translation still happens in whichever model you point the prompt at.

One thing to settle before you standardise: the language you write your instructions in and the language you want out are two separate choices, and whether routing through English helps depends on the specific language rather than being a universal rule. Non-English prompting works through that properly with sources. Test both directions on your own pair before you commit the template.

If any of this is your first structured prompt, what prompt engineering actually is is the shorter grounding. Otherwise: take the block at the top, fill in the register line for your target language from the table, and run it on the last thing you translated badly. The register field is usually the one that was missing.