problem

Import files from external customer systems sometimes require cleanup or normalization before they can be imported successfully into translate5. Since these files are provided directly to translate5, they cannot always be preprocessed before upload.

solution

translate5 should support an optional external preprocessing step during task import. When configured, the import pauses before the files are imported, notifies an external system, allows that system to download and replace the import files, and then continues the import after the external system releases the task.

Implementation plan:

• Add a new task-import level configuration for the pre-import callback URL, separate from the existing runtimeOptions.import.callbackUrl because that one is currently used after import completion.
• Queue a new import pause worker only when this new configuration is set.
• Place the worker after editor_Models_Import_Worker_FileTree and before editor_Models_Import_Worker / later import workers via the existing Zf_worker_dependencies mechanism.
• The worker sends an ImportIncoming-style callback to the configured external system with task/file context and puts the task into a new explicit task status such as externalProcessing.
• The import must remain blocked until an authenticated API call continues it; avoid automatic continuation by ordinary delayed-worker timeout behavior.
• Reuse editor_FileController::downloadoriginalAction for external download where possible, keeping current task scoping and ACL checks.
• Add a narrow file replacement API for this state. It should update the already prepared import file on disk, not trigger task reimport processing.
• Add a task continuation endpoint, preferably using the existing operation route style, to release the pause worker and resume the prepared import worker group.
• Restrict file replacement and continuation to tasks in the new external-processing state, validate file/task ownership, and log callback, replacement, and continuation events.
• Add the new status to task state handling, frontend/API representations, and import timeout/cleanup behavior as needed.
• Add focused tests for configured vs. unconfigured import, worker ordering/blocking, file download/replacement, invalid state rejection, and continuation resuming the import.

HINT

There is a similar mechanism that manipulates workfiles before they are imported: The visual PDF import. It exchanges the PDF workfiles with HTML workfiles in an earlier stage. It kicks in before editor_Models_Import_Worker just like the above mechanism. (see -> VisualPdfWorkfilesWorker). It is obvious, that both mechanisms cannot work in parallel (though it is very unlikely the preprocessing shall take place on binary PDF files)

To be on the save side, it might be better to skip the Visual PDF workfiles detection if the config for this feature is set in:  PdfWorkfileImport::isConfiguredForTask