This section defines some the main terms used throughout the Okapi components and applications. These definitions are valid within the context of the Okapi Framework.
The common parameters are the options specified from the application calling a utility rather than in the options dialog box of the utility itself. many utilities have the same parameters, for example: an input file, the language of the input, the encoding of the input file, the name of the output file, etc. Instead of having to implement in each utility the UI to select these very often used parameters, the Okapi Framework defines eleven parameters that can be passed to the utilities through their interface (see the Okapi IUtilitySet Interface page for the methods).
These common parameters are the following:
|Files of the first input list||Each file of this list corresponds to the first input file for a given utility. Most utility use only this input list.|
|Root for the first input list||Each file of this list corresponds to a second possible input file for a give utility. For example, a utility that would align two files would need the first input file, and a second input file.|
|Files of the second input list||Each file of this list corresponds to a third possible input file for a give utility. For example, a utility that would update the translation of a new file based on the source text of the old file and its old translation would need three input files.|
|Root for the second input list||This root is a part of path that is common to all files of the first input list.|
|Files of the third input list||This root is a part of path that is common to all files of the second input list.|
|Root for the third input list||This root is a part of path that is common to all files of the third input list.|
|Input language||This is the default language code for the input files.|
|Output language||This is the default language code for the output files.|
|Input default encoding||This is the name of the default encoding for the input files.|
|Output default encoding||This is the name of the default encoding for the output files.|
|Location and names for output files||This is the names of the output files (usually based on the input file names). Some utilities that generate output files may not let you choose their names.|
Not all utility uses all parameters. See the documentation of each utility to know which common parameters you must provide before using the utility.
A filter is a module that implements the Okapi IFilter interface. A filter allows to parse an input in a specific format and retrieve all its localization-related data using a common set of methods. This allows an application (or a module like a utility) to work with input files of any formats that has a filter. The format of the file itself is abstracted for the caller of the filter. New filters can be created or existing one adapted and the calling programs can use them without any changes.
A filter parameters file is a file where the options for a given filter are stored.
When a filter settings string does not have a folder define, the folder is
assumed to be the default Okapi Parameters folder. So, for example, "
.\okf_po@myOptions" are two different parameters files: one
corresponds to the file
okf_po@myOptions.fprm located in the
default Parameters folder, the other to the file
located in the current directory (whatever that directory is).
C:\myProject\okf_xyz#var_abc@myOptions.fprm = Full path C:\myProject\okf_xyz#var_abc@myOptions = Settings string okf_xyz#var_abc@myOptions.fprm = File name okf_xyz = Filter identifier var_abc = Variant identifier myOptions = Parameters identifier
The filter settings string is used to identify which filter to use and its options. The generic syntax is:
<folder> part is not present, and a
is present, the parameters file is assumed to be in the default Okapi parameters
folder. The full path of a parameters file is in the form:
A few examples of valid filter settings: "
.\okf_poLocalParams". See the implementation
documentation of the
IFilter.LoadSettings method for more information.
A segment is a chunk of text used as a unit for translation tools. Most of the time segments are sentences, but some tools may work at the paragraph level or at other wider or narrower levels. The segments are creating using segmentation rules that define how to break down a text. For example: a segment ends with a period followed by one space would be a segmentation rule.
Rules are specific to each tool but the Segmentation Rule eXchange (SRX) format allows the interchange of rules between applications, or to store the rules along a translation memory.
A translation memory (often abbreviated as "TM") is a collection of aligned text segments in two or more languages that is used to leverage existing translation during the localization process.
The mechanism works roughly like this: a new segment is to be translated, the tool query the translation memory to see if there is already an identical segment in the segments in the source language. If so, the segment in the corresponding target language is proposed as possible translation. There are various way to match the new segment with the existing one. The match is often call exact when both are the same, fussy when they have slight differences.
The translation memories are often implemented as databases, but they can also come in various file formats, one of them is TMX, the Translation Memory eXchange format.
A utility is a module that implements a specific function, that usually do something with an input file. For example, a utility could be a module that takes the translatable text of a specified input file and extract it into and XLIFF document. Another could be a module that takes two input files and align them and generates a TM.
Utilities are completely independent from each other. You can see them as "task" that you perform on a give input to produce a given output. Utilities are grouped in utility sets.
A utility set is a component that implements Okapi IUtilitySet interface. It provides access to one or more utilities.