background

As the conception showed, the best way to integrate Okapi is by using Okapi Longhorn REST server. This way it is possible to pass bconf-files generated by Okapi Rainbow along with the import. With bconf-files Okapi can be customized regarding what exactly it does when extracting source text from source file formats into xliff. This way e. g. it can be configured for an excel file, if you want to exclude certain columns or text with a certain color.

implementation

• A generic way to integrate different source file converters as plug-ins should be implemented in translate5 core.
• The Okapi Integration is then realized as the first of these Plug-Ins. Communication to Okapi is triggered by events in import / export worker.
• Each file is delivered separetely to Okapi.
• The implementation will be done in a way that makes it easy to integrate other micro-services than Okapi for source file format conversion.

Import

The returned XLF file is placed in the import folder and is processed by normal XLF Import routines.
The Original file is moved into the reference files dir, where it can be reused for export.
The XLF import must be improved so that it can deal with seg-source and <mrk type="seg"> subsegments and all internal tags that xliff 1.2 supports.

Export

After exporting the task, the files processed by Okapi on import time are sent back to Okapi to get back the imported original file.
Packaging the XLF into the export zip should be configurable in Zf_configuration and set to “off” by default. It simply confuses users.
The original import files should be exported then instead of the XLF files.

Okapi Installation

Using Longhorn a Java application server is needed. A tomcat testserver was easily setup in ubuntu.
The final way must be well documented in Confluence. We will evaluate, if it will be possible to integrate the Okapi Longhorn installation into translate5 Windows installer.