Pure Translation Providers
What a pure translation provider is, which ones Read Frog supports, what each one needs, and when to choose one over an LLM provider.
What a pure translation provider is
A pure translation provider does one thing: you send it text, it sends back a translation. There is no model to pick, no prompt to write, and no conversation. Read Frog groups these under Pure translation providers in Options → API Providers → Add Provider.
An LLM provider translates by being asked to translate. That extra step is what makes page context, your own prompt wording and your glossary possible — and it is also why it costs more tokens and usually takes longer.
What they cannot do
Pure translation providers can be assigned to page translation, video subtitles, selection toolbar translation and input translation. They cannot carry anything that depends on a prompt:
- AI Smart Context has no prompt to enrich, so the setting does nothing for these providers.
- Personalized translation prompts are greyed out in the popup when the selected provider is not an LLM.
- Custom AI Actions and note suggestion require an LLM provider and will not accept one of these.
- Subtitle AI segmentation is skipped; subtitles are translated cue by cue as they arrive.
- Glossary terms are ignored. The glossary travels inside the system prompt, so it only reaches LLM translation.
If your glossary suddenly stops taking effect on a page, check which provider that feature is using. Each feature picks its own provider, so page translation can be on DeepL while your selection toolbar is still on an LLM.
The providers in this group
DeepL
The official DeepL API. It needs an API Key and nothing else — there is no Base URL field, because Read Frog picks the Free or Pro endpoint from the shape of your key. See DeepL for the details and its language-code handling.
DeepLX
An unofficial DeepL-compatible API. It needs a Base URL, and an API key only if your instance asks for one, so a free public instance works with the key field left empty. The Base URL may contain an {{apiKey}} placeholder when your provider expects the token somewhere other than the path. See DeepLX.
Google Translate and Microsoft Translator
These belong to the same family but need no setup at all: they ship already added and enabled, have no credentials to fill in, and cannot be removed. You will not find them in the Add Provider dialog for that reason.
Microsoft Translator cannot be paired with Translation Only page mode. Its endpoint does not preserve markup, so Read Frog blocks that combination instead of letting it corrupt the page.
Add and enable one
Click Add Provider and pick a provider from the Pure translation providers group.
Fill in the fields that provider shows — an API key for DeepL, a Base URL (and optionally a key) for DeepLX.
Turn on the Enabled switch, then assign the provider to a feature under Feature providers.
A provider that is added but not enabled will not appear in the feature pickers. Assigning it to a feature from its own editor enables it for you.
Testing the connection
Test Connection is not a ping — it translates the word Hi through your real settings, so a green check means this exact configuration produced a translation.
- A green check means success; an hourglass means it worked but took longer than three seconds.
- A red cross means the request failed. The reason is not shown on the button, so try a translation on a real page to see the error text.
- The button is disabled while the API key field is empty, except for DeepLX, which is allowed to run without a key.
- The result clears after a few seconds, and resets as soon as you edit the provider, the key or the URL — so a stale check never vouches for a configuration you have since changed.
When to pick one of these
Choose a pure translation provider when:
- You translate long pages or full subtitle tracks and want the lowest latency per request.
- You want predictable cost. DeepL bills characters, not tokens, and a free DeepL key or a public DeepLX instance costs nothing.
- Your LLM quota is scarce and you would rather spend it on Custom AI Actions than on bulk page translation.
Stay on an LLM provider when:
- You rely on a glossary, a personalized prompt or AI Smart Context.
- The text needs judgement rather than literal accuracy — idioms, jokes, domain jargon.
- You want one provider to serve both translation and the AI features, instead of maintaining two.
A good middle ground is to run page translation on a pure translation provider and keep the selection toolbar on an LLM, so the fast path is cheap and the careful path is still available on the words you stop to look at.
Troubleshooting
"DeepL API key is not configured"
The API Key field is empty. DeepL has no keyless mode.
"DeepL translation request failed" or "DeepLX translation request failed"
The provider answered with an error status. Read Frog appends the status code and the provider's own error body to this message, which is usually the fastest thing to read. Common causes are an invalid or expired key, a key that does not match the plan, and an exhausted character quota.
"API key is required when using {{apiKey}} placeholder in DeepLX baseURL"
Your Base URL contains the placeholder but the API Key field is empty. Either fill in the key or remove the placeholder from the URL.
"Unexpected response format from DeepLX translation API"
The request succeeded but the body was not what a DeepLX instance returns. Read Frog expects JSON with the translation in a data string field. Public instances that have been repurposed or put behind a login page often fail here.
"Network error during DeepL/DeepLX translation"
The request never reached the server: the instance is offline, the host does not resolve, or its CORS headers reject the extension. Self-hosted instances must be reachable from the browser, not only from your terminal.
Translations are fine but my terms are wrong
That is expected on these providers — see What they cannot do above. Move that feature to an LLM provider if the glossary matters more than the speed.
Related pages
Providers overview · DeepL · DeepLX · Built-in providers · OpenAI-compatible providers
