Problem

PONS should be usable as a normal MT language resource for pre-translating translate5 segments, like DeepL. This is the first part of the PONS integration and provides a usable solution without waiting for the new translate5 context infrastructure (terminology and TM injection) - that context support and the TQE/automated post-editing support are separate follow-up tickets.

This first MT implementation must not depend on local translate5 terminology or t5memory matches.

Solution

PONS plugin foundation

Implement a new plugin PrivatePlugins/Pons/ following the modern namespaced service layout (analog OpenAI/TildeMT): Init.php, Service/Pons.php (authenticated service), LanguageResource/ResourceConfig.php, LanguageResource/Type.php, LanguageResource/Connector.php, Api/PonsApi.php (Guzzle via ClientFactory, centralised exception mapping to plugin error codes analog DeepL), error-codes.yaml, migrations, locales and the frontend service registration for the add-resource dropdown.

Authentication: Bearer-token/API-key, configured analog DeepL (runtimeOptions.plugins.Pons.server + runtimeOptions.plugins.Pons.apiKey).

MT pre-translation

Extend the connector with the PONS translation endpoint (v2/translate) and register PONS as a regular MT resource (analysable, assignable to tasks, usable in InstantTranslate).

Implement:

• Batch translation with parallel requests: multiple segments per request (segments[], configurable batch size) and several chunk requests in flight in parallel via the parallel batch infrastructure from TRANSLATE-5226 (BatchQueryCapableInterface + ParallelRequestExecutor, analog the OpenAI connector - PONS becomes its second implementer). Parallelism is configurable and defaults conservatively (2) until PONS rate limits are clarified
• Source and target language mapping (translate5 langcodes ↔ PONS codes)
• Segment-order preservation: each response entry is mapped to the correct input segment; segment boundaries are always preserved
• Inline tag handling via the tag dialect system with the paired-tags dialect as default (xml_paired_tags, analog DeepL after TRANSLATE-5360); damaged tag output goes through the existing automatic repair pipeline
• Response-to-match mapping with a configurable default matchrate (penalty value, analog runtimeOptions.plugins.DeepL.matchrate)
• Error handling: authentication errors, 4xx, 5xx and malformed responses generate understandable, user-visible errors; empty translations for non-empty segments never produce an empty match

Proposed request parameters: segments[], source_lang, target_lang, split_sentences=true, handle_xml=true, alternatives=false, doc_level=false. The final doc_level and cross-segment-context settings must be verified against the current PONS API before implementation, because earlier discussions referred to doc_level=true while the latest concept uses doc_level=false. The chosen behaviour is documented.

Language management

PONS does not expose a supported-languages endpoint. Start with the unrestricted default (all languages offered, analog TildeMT/OpenAI); clarify the supported language pairs with PONS and, if a list becomes available, restrict analog DeepL (hasSourceLang()/hasTargetLang() on the resource plus languages() on the connector).