Okapi omegat4/12/2023 Select the command New from the File menu (or press Ctrl+N). The pre-processing is done as follows: Input Files We can use the Okapi Text Extraction and Text Merging utilities to pre-and post-process the file, and work, between the two processes, in an OmegaT project. We want to translate the file using OmegaT. The recommended file structure organization is listed below: The client has provided us with the full set of XML-related config files, e.g. In this document, we have one sample XML file (100001000014322_421_6.0_frc.xml) to translate into 6 target languages: Thai, Indonesian, Malay, Vietnamese, Lao, and Khmer. The following is the Unicode font required for the three rare languages, e.g. You must have Unicode font installed for the languages you are going to translate.You must have OmegaT installed on your machine.You must have Okapi tool installed on your machine.Read Also: General Style Guide for Translations Requirements OmegaT® is a free and open-source multiplatform CAT tool with fuzzy matching, translation memory, keyword search, glossaries, and translation leveraging into updated projects. The open-source Okapi Framework is a set of interface specifications, format definitions, components, and applications that provide an environment to build interoperable tools for the different steps of the translation and localization process. This document provides a step-by-step guide on how to use the Text Extraction and the Text Merging utilities from the open-source Okapi tool to pre-and post-process files to be translated using OmegaT, one of the free translations tools available in the open-source community.Ĥ. This document is prepared for the Project Manager who manages multilingual translation projects and requires pre-and post-process files to be translated into multiple languages.ģ. The process has been tested on the translators’ end to be feasible, but whether it is supported on client’s DTP machine needs to be further tested.Ģ. The multilingual translation process with the combination of Okapi and OmegaT was brought to attention by the need of localizing the client’s XML content generated from their Content Manage System, where Unicode support for some rare languages such as Khmer and Lao is a must on the one hand, and taking advantage of Computer Assisted Translation (CAT) tool to maximally attain quality and consistency is necessary on the other hand. on OmegaT's side, keep OmegaT from having a file be handled by an Okapi filter if it is already handled by an OmegaT native filter, but that won't fix the issue either.1. That won't fix the issue but it will make OmegaT useable when the 2 filters are used.ģ. having the OmegaT plugin filter just *log* the error so as not to keep OmegaT from reloading. excluding OpenXML temporary files (basically those that start with ~$), but Okapi does not seem to have the ignore list that OmegaT does (it looks like it works based on mime type mapping: /okapi/core/src/main/java/net/sf/okapi/common/MimeTypeMapper.java and I have no idea how to tweak that)Ģ. I've tried to find how to fix that in the Okapi code but it seems beyond what I can do.ġ. > Would it be possible to have something similar on the Okapi side ? > The OmegaT filter has fixed that by adding **/~$* to the excluded files list: > 13459: Erreur: net.sf.: Error opening zipped input > For some reason, even though the file should be handled my the OmegaT MSO filter, it is eventually passed to the Okapi filter that chokes on it, and OmegaT refuses to (re)open the project. the translator has to close the file, manually reselect the project and reload it OmegaT refuses to reload because the Okapi filter cannot handle/ignore the temporary file the translator modifies and saves the file, but does not close it (- the application creates that temporary file) she opens the file in the dedicated MS application The translator notices something in the source file in the OmegaT interface OpenXML files are handled by the native filter OmegaT has both the native filters and the Okapi filters installed To be more specific, those ~$.(doc)x files are just temporary files that MSO creates when a file is open. It is related to the fact the MSO creates a temporary file when opening an OpenXML file, with a ~$ prefix and a standard ".x" extension, that OmegaT tries to unzip, and fails. > There is a bug in the handling of MSO files. On Nov 16, 2021, at 0:31, Jean-Christophe HELARY wrote:
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |