Concepts
Real-time and batch modes, translation memory, input formats, language codes and how plans decide which mode a key can use.
Real-time and batch
Every translation request chooses a mode.
real-time | batch | |
|---|---|---|
| Response | The translation, in the same response | A job_id; you poll for the result |
| Best for | Agent tool calls, chat, support, anything a person is waiting on | Content libraries, UI strings, CMS content, product catalogs, newsletters |
| Latency | Fast; repeated content is answered from memory | Background; the result is ready when status is complete |
| Plan | Real-time plan | Batch plan and Real-time plan |
| Reference | Translate | Translate, then Batch results |
A batch request can carry up to 50,000 rows. JSON input is walked, every string is translated on its own, and the structure is put back together for you.
Translation memory
FluentC remembers what it has translated. The memory key is a SHA-256 hash of the target language plus the exact input text. Four consequences follow:
- Repeats are fast and cheap. An identical string returns from memory with no model call. A second pass over a catalog or a UI is faster than the first.
- Matches are exact. There are no fuzzy matches, so a near-miss never stands in for your text. Change one character and it is a new string.
- Batch job IDs are deterministic. Submitting the same text and target language again produces the same
job_id, so resubmitting after a timeout is safe. - It is included. Translation memory is part of every plan.
Consistency across agents
Because the memory is keyed on the target language and the exact text, the translation of a given string is the same for every caller. Ten agents on ten different models that send the same sentence get the same words back, through any integration.
- The first request translates, later requests return it. The result is stored the first time and returned from then on.
- It depends on identical input. If two agents word the English differently, they send different strings and get different translations. Standardise the sentences you care about, such as status messages and policy lines, and send them as written.
- It is a property of the match, not a promise about quality. Review the phrases that matter once, and every agent that sends them sends the reviewed words.
For the longer version, read Ten agents, one translation.
Input formats
input_format tells FluentC how to read input.
| Format | Behaviour |
|---|---|
text | Plain text. Returned as plain text. |
html | Markup is preserved and the text inside it is translated. |
json | Structure is preserved and string values are translated. input can be a JSON object or a string containing JSON. The translation in the response is a JSON-encoded string, so parse it. |
Language detection accepts only text and html.
Language codes
Languages are identified by lowercase ISO 639-1 or 639-2 codes of two or three letters: es, fr, de, ja, zh.
- Region subtags are not accepted.
pt-BRandzh-CNfail with"Invalid or missing target language code."Useptandzh. - Uppercase is accepted and lowercased for you.
- A code that is valid but not enabled for your key fails with
"Target language 'xx' is not enabled for this site."List what you can use with Languages. - FluentC supports 128+ languages in total. Which of them your key can use depends on your account.
Source language
source_language is optional. Leave it out and FluentC works out the source language from the text. Pass it when you already know it: it removes any ambiguity for short strings such as "Pasta" or "Gift". If you pass one, it must be enabled for your key too.
Plans and modes
The plan behind your key decides which modes work.
| Plan | batch | real-time |
|---|---|---|
| Batch | Yes | No |
| Real-time | Yes | Yes |
In the dashboard the Batch plan is called Standard and the Real-time plan is called Pro. A real-time request on a Batch plan key fails with 422 and "Realtime translation is not supported for this agent." See Pricing for what each plan includes.
Polling a batch job
After a batch request, call Batch results with the job_id:
processing: wait forestimated_wait_seconds(use at least 5), then ask again.complete: readtranslation.failed: readerror. The content was recognised but couldn't be translated.
Cap the number of polls. A job_id the API has never seen is reported as processing, so a typo would otherwise poll forever.
Something unclear, or missing? Tell us.