Content internationalization (it’s not just for software)
This post is part of a series on the value proposition of localization strategies.
When people think of internationalization (IF they think of it), software labels often come to mind—buttons, menus, and other user interface text. But content development can benefit from it as well.
What is internationalization?Internationalization (commonly abbreviated as “i18n”, meaning “i 18-letters-in-the-middle n”) is the planning and preparation for localization. It’s all of the implementation work that makes the translation and targeted adaptation of content and products easier.
In the software industry, all user interface text is stored separate from the application source code. The source code references the text as necessary. When the software needs to be delivered in a different language, that UI text file is translated instead of trying to translate within the source code itself.
How does this relate to content development?
With regard to localization, content development parallels software development in many ways. There are many components that make up a content development project. To name just a few:
- templates (for controlling layout using desktop publishing tools)
- transforms (for controlling layout if developing content in XML)
These content development components contain translatable pieces. Anything that can be isolated and translated separately is a candidate for internationalization.
Templates and transforms
Templates and XML transforms contain many boilerplate content elements. Admonitions (notes, cautions, warnings, etc.) usually use a standard format where the word “Note” or “Warning” is inserted automatically. Header, footer, and other static text on final layouts (whether for print, HTML, or other) are also stored separately. The boilerplate content can be translated in advance and saved in localized template files.
Internationalized templates and transforms also make it easier to localize design for a specific audience. Right-to-left (RTL) languages such as Arabic and Hebrew may require a mirrored or otherwise modified layout. The placeholders for boilerplate text can be repositioned ahead of time in the layouts based on design needs.
Images are trickier to internationalize, especially if they contain text. If your image contains text, use a separate layer for the text in each language. To change the image’s language, show the layer for the appropriate language and save a copy in the format you need.
Whenever possible, link images in content instead of embedding them. Set up a system for swapping out images by language. On the file system, this means naming your translated output images with the same filename in a different folder, so that you can swap out the entire folder instead of replacing each image individually. This will save you the time of replacing each image individually.
Tip of the proverbial iceberg
This post only touches on a few aspects of content internationalization. There are many other ways to internationalize your content, and concerns beyond boilerplate content and images (currency conversions, units of measure, and more). Begin looking at the many facets of your content infrastructure for internationalization candidates—or things that could be if handled differently.
Internationalization depends on consistency and conformity in how content is created and published. The more your content conforms to established templates, structure, and conventions, the easier it will be to internationalize your content infrastructure and streamline the production of your translated content.
Image format is also important. SVG files can be handled as any other XML file by many TMS systems.
Very true. I didn’t want to dig into specific output formats but SVG definitely helps with images containing text.