Events

The bundle dispatches two kinds of events: job events, which let you react to the lifecycle of a translation job, and Studio pre-response events, which let you extend the payloads Studio receives.

Job Events

Use these to hook into translation processing, for example to notify an external system when a job comes back or to post-process a translated element. All constants are defined in Pimcore\TranslationsProviderInterfaceBundle\Event\JobEvents and each one dispatches a Symfony GenericEvent.

Constant	Event name	Dispatched when	Subject and arguments
TRANSLATION_ITEM_PROCESSED	translations-provider-interface-bundle.job.translationItemProcessed	After a single translated item has been written back to its element	Subject: the translated element. Argument: attributeSet
JOB_SUBMITTED	translations-provider-interface-bundle.job.submitted	After a job has been submitted	Subject: the job. Argument: restarted
JOB_RECEIVED	translations-provider-interface-bundle.job.received	After the provider's result data has been stored on the job	Subject: the job
NO_EXPORT_DATA	translations-provider-interface-bundle.job.no-export-data	When a job produced nothing to export	Subject: the job. Argument: result
CLI_START_PROCESSING_OPEN_JOB	translations-interface-provider-bundle.cli.job.open.start-processing	Before the CLI command starts processing open jobs	Subject: the command instance
CLI_STOP_PROCESSING_OPEN_JOB	translations-interface-provider-bundle.cli.job.open.stop-processing	After the CLI command has finished processing open jobs	Subject: the command instance

warning

The two CLI event names use the prefix translations-interface-provider-bundle, with "interface" and "provider" transposed relative to every other event, which uses translations-provider-interface-bundle. Subscribe using the constant, or copy the exact string above, rather than assuming a consistent prefix.

TRANSLATION_ITEM_PROCESSED is dispatched by both shipped providers, DeepL and Translations.com. The other job events are dispatched by the DeepL provider and the CLI command only.

JobEvents also declares TRANSLATION_ITEM_ALREADY_PROCESSED, JOB_NOT_SUBMITTED, JOB_IN_PROGRESS and FINISHED_JOB. These constants exist but are never dispatched, so a listener registered on them never runs. They are deliberately left out of the table above.

Example

<?php

namespace App\EventListener;

use Pimcore\TranslationsProviderInterfaceBundle\Event\JobEvents;
use Symfony\Component\EventDispatcher\Attribute\AsEventListener;
use Symfony\Component\EventDispatcher\GenericEvent;

#[AsEventListener(event: JobEvents::JOB_RECEIVED)]
final class JobReceivedListener
{
    public function __invoke(GenericEvent $event): void
    {
        $job = $event->getSubject();
        // notify an external system that translations came back for $job
    }
}

Studio Pre-Response Events

The bundle builds its Studio responses through the Pimcore Studio Backend Bundle. Before a response is returned, it dispatches a pre-response event carrying the response object, so you can attach your own data without replacing the controller behind it. See Additional and Custom Attributes for how additional attributes reach the Studio frontend.

Event classes live in Pimcore\TranslationsProviderInterfaceBundle\Event\Studio\PreResponse\.

Event name	Payload	Dispatched when	Use it to
pre_response.translations_provider_interface.configuration_detail	Schema\ConfigurationDetail	When Studio requests the bundle configuration, carrying the provider types and available providers	Add your own fields to the configuration payload
pre_response.translations_provider_interface.configuration_ui_settings_detail	Schema\ConfigurationUiSettingsDetail	When Studio requests the UI capability flags	Extend the UI settings response
pre_response.translations_provider_interface.translation_item_count	Schema\TranslationItemCountResponse	When the number of items a translation request would affect is previewed	Add data to the item count response
pre_response.translations_provider_interface.translation_request	Schema\TranslationRequestResponse	When a translation request has been handled	Add data to the acknowledgement response

Each event exposes its payload through a dedicated getter: getConfigurationDetail(), getConfigurationUiSettingsDetail(), getTranslationItemCountResponse() and getTranslationRequestResponse().

note

configuration_ui_settings_detail, translation_item_count and translation_request are dispatched on the failure path as well, with a payload built in a degraded state: ConfigurationUiSettingsDetail is constructed with its enabled flag set to false when no provider resolves, and TranslationItemCountResponse / TranslationRequestResponse carry success = false plus an error message. A listener must not assume the operation succeeded.

warning

The Studio endpoints these events belong to are internal. They are marked @internal, change without deprecation, and must not be called directly. The events are the supported extension point. The generated reference for the endpoints is served by Studio Backend at /pimcore-studio/api/docs.