Rainbow TKit - Generic XLIFF
The Generic XLIFF package is one of the types of translation packages you can create with the Rainbow Translation Kit Creation Step. Such package can be post-processed using the Rainbow Translation Kit Merging Step.
In this package the input documents are extracted into corresponding standard XLIFF 1.2 documents.
- Existing and leveraged translation are output into different TMX files. They can also, optionally, be included directly in the XLIFF documents as
- Segmented text units are represented using the standard XLIFF 1.2 representation.
- Inline codes are represented using either the placeholder notation (
<g>/<x/>/<bx>/<ex>) or the encapsulation notation (
The XLIFF documents generated in this package can be translated using any XLIFF-capable translation tool. Several of these tools (free and commercial) are described in the "How to Translate XLIFF Documents" page.
Include non-translatable text units — Set this options to include the text units marked as non-translatable in the translation package. They will be marked also as non-translatable (
translate='no') there. Providing non-translatable text is sometimes useful for context.
Set approved entries as non-translatable — Set this option to mark any entry that is approved in the original file as a non-translatable entry in the XLIFF output. This option is available only if the option Include non-translatable text units is set.
Use <g></g> and <x/> notation — Set this option to create an XLIFF output where inline codes are coded as place-holders that do not include the original data. Some file formats have inline codes that correspond to large chunk of data that are not useful for the translator: This notation allows you to not include them in the XLIFF output.
If this option is not set, the encapsulation notation (
<bpt>/<ept>/<ph>/<it>) will be used and includes the original data.
For example, given an original text like this:
Text in <span style='123'>bold and italics</span>
With the option set you will get:
Text in <g id="1">bold and italics</g>
Without the option set you will get:
Text in <bpt id="1"><span style='123'></bpt>bold and italics<ept id="1"></span></ept>
Copy source text in target if no target is available — Set this option to fill the
<target> element with the source text if no translation is available. This is useful to generate XLIFF documents that can be translated by tools that are not specifically XLIFF-enabled but can work with XML documents.
Include <alt-trans> elements — Set this option to include
<alt-trans> elements for the entries that have leveraged translation.
Include extended code attributes — Set this option to include
equiv-text attributes in inline codes.
Include ITS markup — Set this option to include ITS markup in inline codes.
The extracted files are stored in the same directory structure as the original files, relative to the root of the file set.
For example if you have two files named
index.html in two different sub-directories, they will be both extracted as
index.html.xlf but each on its corresponding sub-directory.
Inline codes are stored using either the placeholder notation (
<g>/<x/>/<bx>/<ex>) or the (
<bpt>/<ept>/<ph>/<it>) depending on what you have selected in the options.
The placeholder notation is often more user-friendly, especially for some complex document-type formats like Word, InDesign, etc.
Segmented entries use the XLIFF standard representation with
<seg-source> as described in the XLIFF 1.2 specification.
If a translation is present, it follows also the standard representation as well, using
<mrk mtype="seg"> elements in the
<target> elements. Note that some of those segments may be empty if only some segments have been leveraged.
Translatable entries can be pre-translted different ways. In this package, the result of pre-translation is as follows:
- Existing translations marked as approved are put in the
<target>element and the attribute
approvedis set to
yes. These entries are also put in the
- Existing translations without flag are put in the
- Existing translations coming from alternate-translation constructs in the original file (for example the
<alt-trans>elements of an XLIFF document) are put in the
- Translations coming from some leveraging steps are put in the
In addition, if the option is set, alternate-translations and leveraged translations are also put in
<alt-trans> elements for each given
Assuming that your package name is
pack1, your input root ends with
main, the target language is French, you have selected to use the same filenames as the input files for the output files, and you have the following source files:
--- main | +--- index.html +--- myFile.idml +--- subDir | +--- index.html
The layout of this package after creation will be:
--- pack1 | +--- manifest.rkm +--- *.tmx +--- original | | | +--- index.html | +--- myFile.idml | +--- subDir | | | +--- index.html | +--- work | +--- index.html.xlf +--- myFile.idml.xlf +--- subDir | +--- index.html.xlf
originalcontains a copy of the original source documents. You needs those files for post-processing.
workcontains the documents that are to be translated. The translation is expected to be saved into those files.
After post-processing it will be:
--- pack1 | +--- done | | | +--- index.html | +--- myFile.idml | +--- subDir | | | +--- index.html | +... (same as after creation)
donecontains the merged translated documents. This directory is created during post-processing.
- None known