- Localization using XLIFF
- Localization using XLIFF
- "8888173d-73da-40c0-8c26-8dc5ae9e4c1e
- 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
- Warning!
- 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
- hyperlink properties
- Note:
- See
- Export Content for Localization
- 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.