XLIFF, or XML Localization Interchange File Format, is an XML-based format that was developed specifically for use in translation projects. As its name and origin suggest, XLIFF was designed to facilitate the exchange of information across different systems during document localization. In general, source text is converted into XLIFF by a filter that depends on the source structure. This filter extracts the translatable content as plain, unformatted text, allowing the translator to concentrate on the meaning of the text to be translated, regardless of the original source file format, structure, or appearance. Such additional information about the source is still preserved in the XLIFF file in the form of tags, which are used to apply the appropriate processing to the translated text so that the original structure and formatting are reproduced upon conversion of the translated text back to the original format.
It is assumed that, if you choose to localize your Developer content using XLIFF, you are already familiar with basic XLIFF concepts and are working with an XLIFF tool or sending your content to a localization vendor who does. For further information on XLIFF in general, see the web site of the OASIS Technical Committee on XLIFF at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff.
Developer XLIFF Processing
When you execute the Export Localization command, the Developer applies a filter to the selected content, extracting all translatable text and rendering it in a form that complies with XLIFF specifications. The text extracted depends on the type of document selected. Within the XLIFF file, the text is organized by document and then by translation unit within each document. Therefore, as you process the XLIFF file, you proceed sequentially through each of the exported documents.
Warning! During the Localization export process, the Developer applies a unique ID to each translation unit that includes information regarding the document ID, document type, and text type (if the document can have multiple translation units; see below). Therefore, you should neither merge nor split translation units during processing in XLIFF, as this could lead to problems upon import. Specifically, if the file selected for import contains translation units with invalid IDs or other problems, the Developer skips such translation units, thus not importing the corresponding text.
Web Pages
Each web page document is exported as at least two translation units, one for the document name and multiple for the body of the web page, regardless of the amount of text it contains. Web pages can include such elements as formatted text, images, and hyperlinks. Although such information is not relevant to the translation of the text itself, it is important for ensuring that the translated document has the same structure and appearance as the source document. Therefore, the XLIFF generated by the Developer includes such information within web page translation units using the standard XLIFF processing tags <bpt> (begin paired tag) and <ept> (end paired tag). These tags surround appropriate pieces of text in the source translation unit and contain XHTML code (generated by the Web Page Editor) corresponding to the formatting and processing needed.
Topics
Topics can consist of a large number of translation units, and the translation units corresponding to bubble text can include both formatting and markup for play modes and outputs.
Custom bubble text can also include markup for play mode (visible in See It/Try It!, Do It!, and Know It? modes) and output (visible in Player and print outputs). If all of the custom bubble text in a topic frame is marked for the same play modes and outputs, it is exported as a single translation unit. However, if the same bubble contains custom text marked for different modes and outputs, multiple translation units are generated, one for each unique set of play modes and outputs. Despite the obvious overlap in content, these translation units should be translated and maintained as separate units because they represent different combinations of mode and output markup. Although this approach leads to some duplicate translation and repetition in the bubble of text appearing in different markup combinations, it ensures that the play mode and output markup of the source text is accurately reproduced in the translated bubble text, so that the translated topic publishes correctly. In addition, this approach simplifies the translation process. That is, translators are frequently comfortable with formatting attributes such as bold or font name, but might find it more difficult to interpret and appropriately process the mode and output markup, which are specific to the Developer. Moreover, use of a translation memory can minimize the impact of any duplication.
Images and Hyperlinks
For images (<img> tag) in web pages, the processing tags always include the image source attribute (src) and might also include attributes representing the properties that can be set using the Image Properties dialog box. Some of the attributes are alternative text (alt), size (style), border (border), and alignment (align). Likewise, for hyperlinks (<a>, or anchor, tag) in web pages, the processing tags always include the hyperlink target attribute (href) and might also include an attribute representing the tooltip (title). In general, image and hyperlink processing tags should also be copied from the source text to the corresponding portion of the translated text. However, you might want to translate the alternative text for an image or the tooltip for a hyperlink. You can do so by directly editing the corresponding <bpt> processing tag to include the appropriate translation in the alt or title attribute, respectively.
Note that, except for URL images or URL hyperlinks, you should not need to edit the image source (img src) or hyperlink target (a href) attributes in web page translation units. Rather, these values are updated when you create a duplicate of your content (including related documents) before exporting it for localization. If you need to change these attributes further, you should edit the image properties or edit the hyperlink properties from the Web Page Editor after importing the translated web page.
Note: Hyperlinks are included in translation units only for manually created links, not for glossary links. Rather, you should update glossary links from the Developer after importing the translated content and glossary (or glossaries).
See Export Content for Localization for a list of the text that is exported for each document type.
Summary
In summary, the translation of custom Developer text using XLIFF is relatively straightforward, with most translation units consisting simply of unformatted text. The exceptions are web page text and custom bubble text, which can include formatting and processing information in the form of <bpt>/<ept> processing tags. For the most part, these tags should be copied directly from the source text to the linguistically equivalent portion of the translated text.
In addition, in cases where the mode and output markup of the text within a bubble differs, multiple translation units are created for a single bubble. Because the IDs of the resulting translation units contain information on markup, these translation units should always be processed individually, even if they contain similar text. This preserves the appropriate bubble text markup upon import of the translated content. A translation memory should prove helpful in automating translation in such cases.