Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 5 additions & 9 deletions api-reference/translate.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ public: true

The text-translation API currently consists of a single endpoint, `translate`, which is described below.

For highest translation quality, we recommend using our next-gen models. For details, please see [here](/api-reference/translate#about-the-model_type-parameter).
For details on model selection, see the [`model_type` parameter](#about-the-model_type-parameter).

To learn more about context in DeepL API translations, see our [context parameter guide](/docs/learning-how-tos/examples-and-guides/how-to-use-context-parameter).

Expand Down Expand Up @@ -210,16 +210,12 @@ Note that we do not include examples for our client libraries in every single se
Specifies which DeepL model should be used for translation.

Possible values:
- `latency_optimized`: Uses the lowest latency translation models available (usually classic models; default parameter value)
- `quality_optimized`: Uses the highest quality translation models available (currently next-gen models)
- `prefer_quality_optimized`: Same as `quality_optimized`, with fallback to classic models if no next-gen model is present (as of December 2025, all languages have next-gen models)
- `latency_optimized`: Optimizes for the lowest latency (default parameter value)
- `quality_optimized`: Optimizes for the highest translation quality
- `prefer_quality_optimized`: Same as `quality_optimized`

When the `model_type` parameter is set, the response includes a `model_type_used` field indicating which model was used.

<Warning>
To ensure accurate automatic language detection, the API uses next-gen models for all requests that omit `source_lang`, regardless of `model_type`. If your source language is known, you can specify `source_lang` to allow classic models to be used where available for your language pair. See [supported languages](/docs/getting-started/supported-languages) for language-specific model availability.
</Warning>

See [About the model_type parameter](#about-the-model_type-parameter) for more details.
</ParamField>
<ParamField body="split_sentences" type="string">
Expand All @@ -240,7 +236,7 @@ Note that we do not include examples for our client libraries in every single se

<p>Please note that newlines will split sentences when <code>split_sentences=1</code>. We recommend cleaning files so they don't contain breaking sentences or setting the parameter <code>split_sentences</code> to <code>nonewlines</code>.</p>

<p>Please note that this value will be ignored when using next-gen models (<code>model_type_used=quality_optimized</code>) and a value of:</p>
<p>Please note that this value may be overridden by the translation engine. When overridden, a value of:</p>
<ul>
<li><code>0</code> will be used if <code>tag_handling</code> is not enabled</li>
<li><code>nonewlines</code> will be used if <code>tag_handling</code> is enabled</li>
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -817,11 +817,9 @@ Naturally, the API tries to provide excellent translation quality and low latenc

If you omit the `model_type`, the API normally defaults to `latency_optimized`.

### Special cases
### Notes

* If your request omits the `source_lang`, the API will use next-generation models to ensure the best possible language detection.
* [tag handling v2](/docs/xml-and-html-handling/tag-handling-v2#whats-new-in-v2) uses next-generation models. It is compatible with all `model_type` values.
* For some languages, like Thai, the API uses the same model, regardless of requested `model_type`. This behavior may change as our models evolve.
* All features and language pairs are compatible with all `model_type` values.

## Limits

Expand Down
2 changes: 1 addition & 1 deletion docs/xml-and-html-handling/html.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ The default value for the `split_sentences` parameter for all requests where `ta

The default value `split_sentences` for text translations where `tag_handling` is not set to `html` is `1`, meaning the translation engine splits on punctuation and on newlines.

Please note that for next-gen models, the parameter `split_sentences`passed by the user is ignored and a value of `nonewlines`is used for maximum translation quality.
Please note that when using HTML tag handling, the `split_sentences` parameter defaults to `nonewlines` for maximum translation quality.

### Disable translation of elements

Expand Down
4 changes: 1 addition & 3 deletions docs/xml-and-html-handling/structured-content.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -5,9 +5,7 @@ description: "Learn how to work with structured XML content with the DeepL API."

When enabling `tag_handling` by setting it to `xml`, the DeepL API is able to process structured XML content. This includes whole XML files, as the following example shows.

Please note that for XML structured content in classic models, we set the parameter `split_sentences` to `nonewlines` to make sure that newlines do not alter the results. The response is beautified for better readability.

Please note that for next-gen models, the parameter `split_sentences`passed by the user is ignored and a value of `nonewlines`is used for maximum translation quality.
Please note that for XML structured content, the `split_sentences` parameter is set to `nonewlines` to ensure that newlines do not alter the results. The response is beautified for better readability.

Parameters and corresponding results:

Expand Down
2 changes: 1 addition & 1 deletion docs/xml-and-html-handling/tag-handling-v2.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -175,7 +175,7 @@ A: Yes, simply set `tag_handling_version: v1` in your API requests.

**Q: Does v2 work with all DeepL API features?**

A: Tag handling v2 works with all standard API features including glossaries and formality settings. However, it currently only supports the `quality_optimized` model type.
A: Tag handling v2 works with all standard API features and `model_type`s.

**Q: Is HTML also strictly parsed?**

Expand Down