How the Translation Prompt Works

Editing the prompt is available in LATW AI Translation for Polylang PRO.

The prompt is the instruction sent to a language model with every translation: what it is
translating, into what, and how it should behave. The free plugin ships one prompt and prints it in
full under AI Translation → Settings → Translation → Translation Prompt — so you always know
exactly what is being sent, even where there is nothing to change.

With PRO that text becomes an editable field, with a Reset to Default button next to it. Your
wording is stored by PRO, so it is still there if a licence lapses and comes back; while the
licence is inactive, translations use the prompt the free plugin ships.

#What the AI actually receives

A page does not reach the AI as a page. The plugin splits it into separate fields — the title,
the excerpt, each piece of text in the block content, each Elementor text field, every translated
custom field — and sends those fields as one JSON object:

{
  "post_title": "Aeropress filters compared",
  "content_1": "Paper, metal or cloth?",
  "content_2": "The paper filter keeps roughly half the sediment out of the glass."
}

JSON rather than plain text, for three reasons: the answer can be mapped back to the exact place in
the post it came from, HTML and shortcodes survive untouched inside the values, and a broken answer
is detectable instead of being silently saved.

Around that JSON the plugin assembles the prompt. Every translation is sent in this shape:

1. Translation prompt        the template from Settings, with its placeholders filled in
2. Website context           your Website Description, via {{website_context}}
3. Glossary                  the pairs for this language pair, via {{glossary}}
4. Payload note              added by the plugin — what this payload is
5. REFERENCE                 added by the plugin — the rest of the page (one mode only)
6. INPUT JSON                the fields to translate

Parts 1–3 are yours to edit. Parts 4–6 are assembled per job and cannot be edited, because they
describe the job rather than your preferences.

#Part 1 — the template and its placeholders

The template ships with a default that tells the model to behave as a translation engine (no
questions, no commentary, no splitting the answer into parts) and to return JSON with the same keys
as the input.

Four placeholders are filled in when the prompt is built:

Placeholder	Filled with
{{source_language}}	The language name of the original, e.g. “Polish”
{{destination_language}}	The language name being translated into, e.g. “German”
{{website_context}}	Your Website Description from Settings → General, prefixed with “Website context:”, if you wrote one
{{glossary}}	Your glossary entries for this language pair (PRO)

A placeholder that is not in the template is not sent. This matters most for the glossary: if
you edit the prompt and remove {{glossary}}, translations continue perfectly happily with no
glossary at all, and nothing in the result would say so. The settings screen therefore warns about
every missing placeholder — as you type, and again after saving — and says what each one costs you:
without {{destination_language}}, for instance, the model is not told which language to translate
into at all.

{{glossary}} resolves to nothing without the PRO add-on, so a prompt that mentions it still works
in the free version — the line simply disappears.

Keep the placeholders. A prompt with {{destination_language}} removed leaves the model guessing
which language you wanted. Reset to Default restores the shipped template.

#Part 4 — the payload note

The JSON above is ambiguous in a way that matters: three separate values could be three fragments
of one article, or three unrelated interface strings. A model that guesses wrong translates each
value in isolation, and the result reads as if written by several people.

So the plugin appends a short note saying what the payload is. It is a fact about the job, not a
preference, so it is added to your custom prompt as well as to the default one. There are three
versions:

Payload	What the note says
A post or page	The values are fields of a single web page and belong together: keep terminology consistent across all of them, and translate the title in the register a page title would use.
A taxonomy term	The values are term names and descriptions: translate them as short labels, not as prose, as brief as the original.
Interface strings	The values are unrelated interface strings — buttons, menu items, notices: each is independent, keep it close to the original in length, and keep placeholder tokens such as %s exactly as they are.

#Part 5 — the REFERENCE block

PRO. This appears only in the Translate only changed strings, with the whole page as context
mode (Updating Outdated Translations). The job translates the changed fields alone, and the
untouched rest of the page travels with it as reference:

[
  {
    "field": "post_title",
    "source": "Aeropress filters compared",
    "published_translation": "Aeropress-Filter im Vergleich"
  }
]

The note above it tells the model that this material is approved — it may contain corrections a
human made by hand — so it must reuse that terminology and tone rather than improve on it, and must
not translate or return any of it. Only the fields in INPUT JSON are asked for, and a field from
REFERENCE that comes back anyway is not written: the published translation stays.

#What comes back

The model returns a JSON object with the same keys. The plugin then:

1. Parses it, tolerating a model that wraps the JSON in a markdown fence.
2. Passes the result to the latwaitp_translated_strings filter, where your site can correct or
   reject it — see Checking Translations Before They Are Saved.
3. Rebuilds the translated post from the structure of the original, putting each translated value
   back where its field came from, and saves it in Polylang.

A reply that is not valid JSON fails the job instead of saving half a page.

#The other settings that shape the request

• Website Description (Settings → General) — if all you want is for the model to understand what
  kind of site it is translating, you do not need an editable prompt at all. It is sent with every
  translation in the free version too, and for most sites it is the difference that matters.
• Reasoning Effort (Settings → General) is sent alongside the prompt on models that support it.
  Higher effort means slower and more expensive, with more attention paid to instructions like the
  glossary.
• Processing (Settings → General) changes how the request is delivered, never what it contains.
• Google Translate, DeepL and MyMemory ignore this page entirely. They are machine-translation
  engines: they translate text and cannot follow instructions, so the prompt, the website
  description, the payload note and the REFERENCE block do not apply. The glossary still reaches
  DeepL, through its own glossary feature — see Translation Engine – AI Providers.

#Seeing what was actually sent

AI Translation → History has a Request column. For OpenAI in background or batch processing,
and for Claude in batch processing, View shows the exact prompt that was sent, with the
placeholders filled in and the payload note and REFERENCE block included. For synchronous jobs it
shows the fields that were sent.

This is the fastest way to settle questions like “was my glossary in there?” — it either appears in
the stored prompt or it does not.

#Editing the prompt safely

Worth adding:

• Tone and register — formal or informal address, which matters a great deal in German, Polish or
  French.
• Vocabulary specific to your industry — “this is a medical site, prefer clinical terms over
  colloquial ones”.
• Things that should stay in the original language — product names, legal terms, code samples.

Worth keeping:

• The JSON output rules. They are what makes the answer mappable back to the post; a prompt that
  invites prose instead of JSON fails every job. Rewriting that section will not make translations
  better.
• The four placeholders, even if you rewrite everything around them.
• The instruction not to split the answer into parts.

Not worth relying on:

• The prompt alone for terminology a model keeps getting wrong. Instructions raise the odds; they
  do not enforce anything. Enforcement belongs in the filter described in Checking Translations
  Before They Are Saved.

#What happens if the licence lapses

The site goes back to translating with the prompt the free plugin ships. Your own wording is not
deleted — it is stored and comes back if the licence does — but it is not used while the prompt is
locked. This is deliberate: a prompt nobody can see or edit should not keep steering translations.