Problem

PONS is already integrated as a regular MT language resource for pre-translation. In addition, the PONS API provides, for each segment pair of source and existing target, both an MQM-style quality assessment and a post-edited translation - so one PONS request can serve translation quality estimation (TQE) and automated post-editing (TRANSLATE-5280) at the same time.

PONS must therefore also be usable as a TQE resource and as an automated post-editing resource. This part must not depend on terminology or TM integration.

One structural gap in translate5 currently prevents this: the TQE machinery is hardcoded to the AI serviceNames - the resource listing (QualityResourcesRepository.php:182 filters serviceName IN (translate5AI, AzureOpenAI, OpenAI)), the estimator instantiation (QualityEstimateService.php:171 calls editor_Plugins_OpenAI_Init::createService()) and the frontend flag (TmWindowViewModel.js:99 isTqeResource with a literal serviceName array). A different plugin cannot provide quality estimation for its own resources.

Solution

PONS as TQE and post-editing resource

Extend the existing PONS plugin with the quality-estimation endpoint: send for each segment the source text, the current target text, source and target language and a stable segment identifier where supported. Batch requests preserve segment association and order (same rules as the MT batch path).

Map the PONS response to translate5 as agreed in the ServiceDesk discussion (existing TQE fields, no additional editor columns):

• quality_estimation_score → existing TQE score (LEK_segments.qualityScore)
• error type and description → existing TQE reasoning
• post_edited_translation → handed to the generic automated post-editing workflow from TRANSLATE-5280
• source_error_phrase, target_error_phrase, corrected_phrase → not stored separately

The PONS connector itself must not implement separate replacement, threshold or loop logic - thresholds and repetitions are handled by the generic workflow. Since every PONS response carries score, errors and post-edited target together, PONS is inherently a combined TQE and post-editing provider: the generic loop can use the returned score directly without a separate TQE call per iteration.

Make TQE and post-editing provider-pluggable

• Extract a quality-estimator contract from the existing OpenAI TQE runtime (interface around checkSegmentsQuality() as used by QualityEvaluationRunner) and resolve the implementation per language resource through a provider registry instead of the hardcoded OpenAI factory call. The existing OpenAI implementation registers itself; PONS registers its own estimator.
• Replace the hardcoded serviceName lists (QualityResourcesRepository, TQE and post-editing candidate queries, isTqeResource frontend formula) with registry/flag-based lookups, so PONS resources are offered in the TQE tab and the post-editing tab.
• The same registry approach applies to the automated post-editing provider of TRANSLATE-5280, so PONS can return post_edited_translation (and score + reasoning + target in one response) through the same result processor.

Error handling

Authentication errors, 4xx, 5xx and malformed responses generate understandable, user-visible errors (existing PONS plugin error codes, extended where needed). Missing or invalid results for a segment must never replace a target with empty content - such segments are reported as "no usable result" to the generic workflow.