Problem

Before translate5 can send its own terminology and TM matches, PONS MT should already be able to use glossaries and translation memories that are maintained on the PONS side. This is the fallback solution requested as the first context-aware MT implementation: the customer maintains glossaries/TMs directly in PONS, and translate5 automatically picks the right ones per task.

Currently the PONS connector sends plain translation requests without any glossary or TM reference. There is no precedent in translate5 for selecting remote resources by customer and language combination - the closest existing mechanism, the DeepL glossary support, stores one fixed glossary id per language resource / customer assoc (DeepL/Glossary/GlossaryService.php:211-222) and does no matching.

Solution

Implement a PONS resource-discovery and matching service in the PONS plugin.

For each task (and analog for InstantTranslate requests, where the customer is also known):

1. Retrieve available PONS glossaries via the API
2. Retrieve available PONS translation memories via the API
3. Match them against the translate5 client of the task and the source/target language combination
4. Add matching ids to the PONS translation request as glossary_ids and translation_memory_ids
5. If no matching resource exists, send a normal translation request without these fields

When this runs: the discovery is triggered when a PONS resource is assigned to a task and the result is persisted per task and resource in a plugin table (LEK_pons_task_resources: matched glossary ids, TM ids, match trace, detection timestamp). Covered assignment paths: manual assignment and import wizard (taskassoc controller events) and default assignment on import (via the import event, analog the TQE queueing - LEK_languageresources_taskassoc has no event of its own for defaults). Unassigning deletes the stored row. Translation then only reads the stored ids - no discovery latency at translation time, and the decision is deterministic and inspectable.

Safety nets: if no stored row exists at translation time (edge paths), discovery runs lazily once and stores the result. If PONS rejects a stored id as unknown (resource renamed/deleted on the PONS side after detection), the connector re-runs discovery, updates the stored row and retries once; if it still fails, the request is sent without context ids. A failing discovery call never fails the assignment or the translation - it degrades to a normal MT request. InstantTranslate has no task and no assignment moment, so it resolves lazily at request time with a short TTL cache (default 300 s).

Matching fields: PONS glossary display_name and description, PONS TM collection_name and name.
The naming convention is: the identifying fields of a PONS resource must contain the translate5 client identifier (original proposal: a client such as Demo-Kunde uses only PONS resources whose identifying fields contain that client name; recommendation: match on the stable customer number instead of the name - to be confirmed, see concept).
The language combination must also match; how languages are exposed by the PONS list endpoints must be verified against the API (metadata fields vs. encoding in the naming convention).

Multiple suitable glossaries are sent when the API supports it; all matching TM ids are sent.

The matching decision (which resources were found, which matched and why, or that none matched) is written to the diagnostic logs - for task-based requests into the task log, so administrators can see it in the task events and understand which naming convention is required. The convention is also documented for administrators.