Migrating from Google, DeepL, or Microsoft Translator

What the compatibility routes cover

Lexel Translate provides compatibility routes for various Google, DeepL, and Microsoft Translator request and response shapes, including:

• Google v2: POST /api/google/translate/v2 (with a GET variant and the /api/google/language/translate/v2 alias), the detect shape at /api/google/translate/v2/detect, and the language list at /api/google/translate/v2/languages.
• Google v3: POST /api/google/v3/projects/{project}:translateText, POST /api/google/v3/projects/{project}:detectLanguage, and GET /api/google/v3/projects/{project}/supportedLanguages. The {project} segment accepts any project identifier string.
• DeepL v2: POST /api/deepl/v2/translate, GET /api/deepl/v2/languages, and GET /api/deepl/v2/usage.
• Microsoft Translator Text v3.0: POST /api/microsoft/translator/text/v3.0/translate, POST /api/microsoft/translator/text/v3.0/detect, POST /api/microsoft/translator/text/v3.0/breaksentence, and GET /api/microsoft/translator/text/v3.0/languages. All routes require api-version=3.0; languages supports only scope=translation. Translate accepts up to 16 text items, up to 10 repeated to targets, optional from, and textType=plain|html.

Just update the route to the equivalent Lexel Translate endpoint and replace the vendor credential with a Lexel Translate API key. The Google wrappers accept the key query parameter and the x-goog-api-key header. The DeepL wrappers accept Authorization: DeepL-Auth-Key ... and the auth_key query or form field. The Microsoft wrappers accept a Lexel API key in Ocp-Apim-Subscription-Key; do not send an Azure subscription key. Native Lexel auth (Authorization: Bearer and x-api-key) works for all compatibility routes. Check the compatibility docs for a complete list of endpoints and examples.

What the compatibility routes do not cover

Compatibility routes act as request and response shape adapters, not full-feature alternatives. Specific limitations include:

• Google v3 custom models, glossaryConfig, and transliterationConfig are unsupported.
• Google translateDocument, batchTranslateText, and long-running operation endpoints are unsupported.
• DeepL document upload, translation memory, style rules, Write, and Voice endpoints are unsupported.
• Microsoft Translator Text transliteration and dictionary (lookup and examples) routes are unsupported and return 501 UnsupportedOperation.
• Google and DeepL glossary API resource shapes are not mirrored. Lexel has its own stored glossaries with immutable versions, but the vendor glossary endpoints are not replicated.

If your integration depends on any of these, factor that into the plan before you start.

The two-phase cutover

Phase one: adopt the compatibility routes and move traffic over while your current provider still handles a share. This answers the question of whether Lexel Translate satisfies your needs.

Phase two: move to the native contract once quality, latency, and cost hold up on your content. The native endpoint is POST /api/v1/translate, documented in the translate docs. New behavior lands on the native contract, so treat it as the end state rather than an optional extra.

If you are starting a new integration rather than migrating, skip the compatibility routes and use the native contract directly.

What to compare during evaluation

Set the evaluation up before you start, and run both providers side by side on your own content as you consider:

• Output quality on your content. Test product strings, documentation, support text, marketing copy, legal text, and chat separately.
• Latency under your normal traffic pattern. Measure the percentile your users experience under load; short batches and large documents behave differently. Measure the percentile your users actually feel under load, because a batch of short strings behaves differently than a single large document.
• Cost at realistic volume. Per-character pricing looks small at 10,000 characters a month and large at 10 million. Compare character counts and workflow costs at your expected volume. Check the usage docs for details on how characters are counted.

What the native contract adds

Compared to the wrappers, the native contract adds a variety of additional features and controls that most integrations will want eventually:

• Structured content handling. Directly translate structured content, such as json-formatted texts, without worry by specifying the content_mmode. No need for any preprocessing or postprocessing.
• Placeholder protection. Enabling preserve_placeholders invokves additional preprocessing to detect placeholder-like values and adds them to protected-term handling. do_not_translate can also be used to explicitly specify protected terms such as brand names.
• Stored glossaries with versioning. glossary_id selects a stored glossary, and glossary_version_id pins an immutable version for reproducible output. Inline glossary.entries work for request-scoped terminology.
• Traceability. request_id can be used as a caller-provided identifier that ties a specific request to a specific response, making debugging a specific request and response pair much simpler.
• Quota visibility. Responses include usage.input_characters and quota state, which simplifies client-side limits and billing enforcement.

The full request and response field list are in the translate docs. You can also test the the native translate route and features without writing code using the playground.

Language tags

The native contract uses canonical language tags, documented in the languages reference. If your integration stores vendor-specific tag strings, plan to normalize them to the canonical set when you move off the wrappers, and verify language mapping as part of your evaluation.

Migration checklist

1. Create a Lexel API key (see the authentication docs).
2. Point one endpoint at the matching compatibility route, keeping your existing auth form.
3. Run both providers side by side on your own content.
4. Compare output quality, latency, and cost.
5. Move the remaining traffic to the wrappers, then to the native contract.
6. Update language tags to the canonical set, and map your glossary and placeholder handling to the native fields.
7. Remove the old provider key once traffic is stable.