Connecting client infrastructure with Yamagata Europe machine translation using JSON-based data exchange

Connecting client infrastructure with Yamagata Europe machine translation using JSON-based data exchange Jourik Ciesielski Yamagata Europe Zwijnaardsesteenweg 316 B 9000 Ghent, Belgium jourik.ciesielski@yamagata- europe.com Heidi Van Hiel Yamagata Europe Zwijnaardsesteenweg 316 B 9000 Ghent, Belgium heidi.van.hiel@yamagata- europe.com Abstract This document describes how Yamagata Europe enables organizations to connect seamlessly to its machine translation and translation management system infra- structure using a JSON-based (JavaScript Object Notation) data exchange mecha- nism. 1 JSON protocol Yamagata Europe’s data exchange service is based on the JSON interchange format to transfer data between translation buyers on the one hand and Yamagata Europe on the other. The purpose of the service is to provide an easy-to-implement and extensible alternative for other translation data exchange standards such as COTI (Common Translation Interface) and TIPP (Translation Interoperability Protocol Package). Translatable objects are contained in a ZIP package together with a package description file (hereinafter referred to as manifest). The ZIP packages are compressed programmatically at the client’s end, possibly with support of Yamagata Europe, and subsequently transferred to Yamagata Europe via for example file transfer protocol (FTP) or cloud storage utilities like Amazon S3. Package transfers are monitored and confirmed through a proprietary API (application programming interface). Once at the Yamagata Europe premises, packages are automatically decompressed, analyzed and, in accordance with the prescriptions in the manifest, the required workflow steps (machine translation, machine translation and post-editing, etc.) are organized and executed. When the workflow is completed, © 2022 The authors. This article is licensed under a Crea- tive Commons 3.0 licence, no derivative works, attribution, CCBY-ND. the service creates a response package and sends it back to the native repository at the client’s end. 2 Data flow The manifest in a data package is a JSON file that contains information about:  The required service (e.g., machine trans- lation only, machine translation and post- editing with or without desktop publish-  ing work, etc.). The source and target language(s).  The source file(s) for translation (file name including a unique identifier).  Extra information regarding the source file format. Example of a JSON manifest: Figure 1: JSON manifest file The decompressing of a package entails several checks to verify whether the data meets the conditions to be processed correctly. If zero or more than one JSON files are found, the process will stop and the package will be moved to an “Error” folder, while an error message will be sent to the client through the provided API. The same thing will happen if an unknown service type or an unsupported target language is specified. Furthermore, the source files specified in the manifest must be identical to the files in the payload. The entire payload travels in a single folder without subfolder structures for the translatable objects. If a package is valid, a translation project will be created in Yamagata Europe’s translation management system using a dedicated project template that corresponds to the prescriptions in the manifest. If machine translation is specified as the desired service, the source …

Content truncated to 500 words