# General Translation Knowledge Base: How do I give AI translation enough context for software strings?
URL: https://generaltranslation.com/en-GB/kb/ai-translation-context.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: Translate complete messages with meaning notes, placeholder roles, length limits, and shared terminology. General Translation's CLI extracts marked JSX as a structured block and carries context notes into generation. For existing JSON and YAML catalogues, keyed metadata supplies per-string instructions. Context Groups apply your Glossary and Custom Prompts across assigned projects, and reviewers correct the output in the Dashboard.
Category: Translation
Last updated: 2026-11-13
Authors: Jackie Chen
Published: 2026-11-13

A short interface string can have several correct translations. Take &quot;Free&quot;: on a pricing badge it means &quot;costs nothing&quot; (German *kostenlos*), and on a seat map it means &quot;available&quot; (German *frei*). The word alone doesn&#39;t identify which meaning you intend. Send the information a human translator would ask for: what the text describes and what the user can do next.

## What context does a translation model need?

| Context                              | What it tells the model                                                  | Example                                                                        | How to supply it                          |
| ------------------------------------ | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------ | ----------------------------------------- |
| The surrounding sentence or UI block | How the words fit together, including links and formatting               | &quot;Read our **terms** before you continue&quot;, translated as one sentence | Translate whole blocks, not fragments     |
| A meaning note                       | Which sense of an ambiguous word you mean                                | &quot;Free&quot; means available                                               | A description, comment, or `context` note |
| UI role and length limit             | Whether it&#39;s a button, heading, or tooltip, and how much room it has | A tab label that must fit 12 characters                                        | A role note and a maximum length          |
| Variables and placeholders           | What a value holds and that it stays untranslated                        | `{name}` is a person&#39;s first name                                          | Placeholder syntax and a note             |
| Terminology                          | Product names and terms with one approved translation                    | &quot;Workspace&quot; is never translated as &quot;office&quot;                | A glossary                                |
| Tone and formality                   | How the product talks                                                    | Formal *Sie* in German                                                         | Style rules                               |
| Where it appears                     | What the screen looks like around the string                             | A screenshot of the checkout page                                              | Screenshots attached in a TMS             |

Terminology and style rules apply to every string, so set them once. The [glossary guide](/kb/ai-translation-glossary) covers keeping terms consistent. The rest is per-string context, and it&#39;s where workflows differ most.

## How do catalogue-based workflows supply context?

When strings live in key-value catalogues, context travels in fields next to each key:

* **Message descriptions.** [react-intl message descriptors](https://formatjs.github.io/docs/react-intl/api#message-descriptor) take a `description` that extraction can retain. gettext PO files have extracted comments (`#.`) for translators and [`msgctxt`](https://www.gnu.org/software/gettext/manual/html_node/Contexts.html) to separate identical strings with different meanings.
* **Platform comments.** Android XML and Apple `.strings` files support comments; Apple String Catalogs and .NET `.resx` entries have comment fields. Your export and translation integration must carry those notes through.
* **Key names.** A key such as `pricing.badge.free` hints at meaning, though a model can&#39;t rely on it. The [key naming guide](/kb/i18n-key-naming) covers naming keys by meaning.
* **TMS fields.** Translation management systems add descriptions, screenshots, and character limits per key. [SimpleLocalize](/kb/general-translation-vs-simplelocalize), for example, keeps a developer-written code description and a translator description for each key. [SimpleLocalize AI](https://simplelocalize.io/docs/general/auto-translation/#simplelocalize-ai) uses those descriptions, screenshots, and comments during translation.

Keep each sentence together, including its placeholders and markup. A catalogue can do that under one key; splitting it into separately translated fragments makes reordering harder. Then check that the notes reach the translation step. A description in an editor or source file helps only when the integration passes it along.

## How does General Translation send context from your code?

General Translation starts from the component. [`<T>`](/docs/react/reference/components/t) marks a block of JSX, and the CLI extracts its text, element structure, variable placeholders, and note for the translation service. The SDK renders the result with your runtime values:

```tsx title="src/SeatStatus.tsx"
import { T, Var } from 'gt-react';

export function SeatStatus({ seat }: { seat: string }) {
  return (
    <T context="Seat map. Free means the seat is available, not that it costs nothing.">
      <p>
        Seat <Var>{seat}</Var> is free. <a href="/checkout">Book it now</a>
      </p>
    </T>
  );
}
```

* **The block is the unit.** The sentence, the seat placeholder, and the link text travel together, so the service can translate and reorder them while preserving the elements. The seat&#39;s runtime value stays in the app. The [conditional JSX guide](/kb/translate-conditional-jsx) shows how this works for sentences with branches.
* **Notes and limits sit next to the copy.** The `context` prop resolves ambiguity, and the `maxChars` prop requests a best-effort length limit, for example `<T maxChars={12}>` on a tab label. Strings outside JSX take the same options in [`gt()`](/docs/react/reference/hooks/use-gt) as `$context` and `$maxChars`.
* **Source code as context.** Under `files.gt.parsingFlags` in `gt.config.json`, set `includeSourceCodeContext` to `true` to send surrounding source lines as additional context. This is opt-in and supplements the extracted block. (See [inline content parsing](/docs/cli/reference/formats/gt-jsx-files#parsing).)
* **Values that stay untranslated.** Wrap names, emails, and other dynamic values in [`<Var>`](/docs/react/reference/components/var); their contents aren&#39;t sent for translation, and the translation keeps the placeholder in place.
* **Context for existing catalogues.** For JSON and YAML files, a companion [keyed metadata](/docs/cli/reference/keyed-metadata) file adds a `context` note and `maxChars` limit per key. Comments in [Android `strings.xml`](/docs/cli/reference/formats/android-strings-files), [Apple `.strings`](/docs/cli/reference/formats/dot-strings-files), and [`.resx`](/docs/cli/reference/formats/resx-files) files are passed to translation as context.
* **Shared terms and tone.** [Context Groups](/docs/platform/dashboard/guides/defining-context-for-translations) hold a Glossary and Custom Prompts and apply them to every project you assign them to. Create one from a project with **Autogenerate from project files** to draft terms and prompts from your existing copy, and a coding agent can update them through General Translation&#39;s [MCP server](/docs/overview/for-coding-agents#mcp).

For a keyed catalogue, the same seat-map instruction belongs beside the source file. These two files let you keep the existing key and library:

```json title="locales/en.json"
{
  "seatStatus": "Free"
}
```

```json title="locales/en.metadata.json"
{
  "seatStatus": {
    "context": "Seat map. Free means the seat is available, not that it costs nothing.",
    "maxChars": 12
  }
}
```

## How do I know the context is enough?

Collect one-word buttons, words with several meanings, sentences with variables, and plurals. Translate them into your launch languages and have someone who reads each language check them in the [Dashboard](/kb/review-translations). Correct the current wording there, then add the missing information where it belongs: a `context` note for that string, or a Glossary term or Custom Prompt if the problem would repeat. Updated instructions guide subsequent generation; they don&#39;t rewrite saved translations by themselves. The [AI translation accuracy guide](/kb/is-ai-translation-accurate) covers building a fuller evaluation.

## Key takeaways

* Keep a message and its placeholders together, whether you author it in JSX or under a catalogue key.
* General Translation carries marked structure and explicit notes into generation; opt-in source lines and shared Context Groups add meaning beyond the message itself.
* Correct existing output and improve the instructions for future translations. Check meaning and layout separately.

## Related questions

- [How do I keep terminology consistent in AI translation?](https://generaltranslation.com/en-GB/kb/ai-translation-glossary.mdx): Keep one glossary of approved terms, including names that stay untranslated, apply it to every translation request, keep variables and code out of translation, and review the result. General Translation does this with Context Groups, whose Glossary and Custom Prompts apply to every project you assign them to, plus the Var component for values that are never translated.
- [Is AI translation accurate enough for a production app?](https://generaltranslation.com/en-GB/kb/is-ai-translation-accurate.mdx): Often, for widely spoken languages, but only after it passes evaluation on your own languages, UI strings, and higher-risk content. In WMT25, Gemini 2.5 Pro matched or beat human reference translations in 10 of 16 language pairs, yet a document benchmark doesn't show whether short interface strings are ready to ship.
- [How do I translate conditional text in JSX?](https://generaltranslation.com/en-GB/kb/translate-conditional-jsx.mdx): Keep the sentence whole and translate every version of it, because a ternary splits it into fragments that lose their meaning and their place in each language's word order. General Translation does this with `<Branch>` inside `<T>`, which translates the sentence as one unit.
- [Can you localise software without translators or a localisation team?](https://generaltranslation.com/en-GB/kb/localize-without-translators.mdx): Yes, you can localise without a dedicated translation team. General Translation generates new and changed copy in your build using code context and shared terminology, while Locadex can mark new React and Next.js text. Bilingual teammates or freelance reviewers correct wording in the Dashboard without seat fees. Set review requirements by language and the cost of a mistake.
- [How should I name i18n translation keys?](https://generaltranslation.com/en-GB/kb/i18n-key-naming.mdx): Name keys by where text appears and what it means, such as checkout.summary.title, not by its English wording. Give each distinct use its own key, even when the English matches: German translates the button Open as Öffnen and the status Open as Offen.

## Previous and next questions

- Previous question: [General Translation vs. SimpleLocalize: which should you use?](https://generaltranslation.com/en-GB/kb/general-translation-vs-simplelocalize.mdx)

## Sitemap

See the [Knowledge Base sitemap](https://generaltranslation.com/en-GB/kb/sitemap.md) for every article.
