Different solutions exist for different needs based on all the preceding questions. Here are some good general approaches to use when internationalizing.
Design the system around a locale. Each locale is a pairing of a country with a language to create a unique identifier. This may provide duplication of language data, but it offers the maximum amount of flexibility and avoids needing to change the code later. For example, Canada would have two locales: Canadian-English and Canadian-French. The US would have one locale: US-English.
Design the entire translation process in advance and write it up. The process should describe how to export, import, and translate the data. Consider the costs and turnaround time for the translators. This will help determine the future delivery schedule for your product. When engineering completes the code for a release, it can sometimes take weeks more to translate, verify, and repair. Translation mistakes and text changes are common, so assume time for iteration.
Plan a strategy for how QA will verify languages other than US English. A QA strategy will require that someone review the website or program and point out problems.
Design the data format and database interface up front. Take the following elements into consideration when designing database changes and data exchange formats.
Select a data format for storing language information. Avoid choosing multiple formats based on history. Ideally, use a coding of UTF-8 or UTF-16 if a Kanji language is a possibility. However, in some situations, no single encoding will work for all of the countries being considered.
Use unique keywords in the program to identify different text elements. A switch in the code will select the language, which the keyword will reference from a table in the database.
Design the data import and export system in advance. Store and export not only the keywords and their English values, but also context phrases that clarify the intent for the translator. Example: Go could mean press the button or exit.
If the translator will not support your ideal format, design a method of automatically converting it to the preferred format. For example, suppose the customer chooses the translator, but the translator supports only Microsoft Word and Excel files. Creating special interfaces or practices for these firms may be necessary, as translation is not a one-time task.
One potential solution for the translator who wants to use only Excel is to customize the program. Excel 2003 and later versions support XML import/export if the proper template is built in advance. You can set up a template such that XML import/export is easy to perform. The process would then be as follows:
Your program can export an XML format.
The translator can read the XML into an Excel program using a standard XML template you set up.
The translator makes changes to specific boxes in the Excel program and returns it to you.
You export the XML from Excel and read it back into your program.
A convenient way to lay out a translation table in Excel is illustrated in Table B-1, showing an English-to-Wingdings (
) translation template. The Context column provides the translator with context if the English phrase is ambiguous.
Plan your layout of screens and pages with flexibility to allow larger-sized text as well as photo and graphics changes. A graphics team cannot just think about the US office and English layout considerations.
Consider graphics and photos as part of the locale swapping code. Store multiple images and allow references from different locales to the desired images. Multiple locales can point to the same image.
Finally, be sure to include error messages in your translation strategy. Development staff often overlook error messages because they are not always visible.