Content found in this wiki may not reflect official Church information. See Terms of Use for more information.
Design (Internationalization best practices)
Principle: World-ready product and UI design ensures that the localized product will look and function as expected by global users and simplifies management of the code base.
Start early
Best Practice: Address cultural sensitivity and localizability issues as early as possible.
Internationalization best practices should be implemented intentionally, by design (meaning everybody on the team, not just Designers). Starting early will minimize mistakes and rework. It will minimize the cost of producing a global product. It will improve quality. It will improve the experience of end users. It will improve your translation/localization experience.
Roles, responsibilities, and examples:
- BA/IxD: Find out if the product will ever use international data or if it will every be localized. If so, the product should be be internationalized -- even if the international data or localization won't come along until several product versions later. Find out what languages and counries will ever need to be accommodated. Find out what the Translation division will need. Get a design review from the Translation divison.
- Developer: Ask the Translation division what translatable resource file types they can accept. Send early prototype resource files to the Translation division to validate their ability to accept and process those files. Make sure you know how files will go to Translation and back -- and test it. Understand how you'll do pseudo-translated builds. Research internationalization practices for the specific programming language you're using and document them here so your research will benefit others.
- Tester: Test the product's ability to manage international data. Set up builds to always language versions of the product -- even before you have translation. Set up and test with pseudo translations that validate character handling and text expansion (horizontal and vertical). Create a repository of international data to use in testing.
Links:
Code/feature isolation
Best Practice: Isolate language/culture-sensitive code or features to make code changes more manageable.
Separate the implementation of the language specific functionality and requirements from the main code base by placing them in other modules. By keeping it separate from application logic, it is easier for developers that must maintain the code and add additional languages.
Isolating code intended for multicultural support simplifies design and maintenance. It also aids in ensuring that when work is performed on the multicultural modules that equivalent changes will occur on other related multicultural modules.
Application functionality where this is likely to occur is in searching, sorting, data entry, data storage, and display layout.
Roles, responsibilities, and examples:
- BA/IxD: Ensure that layout logic that is locale specific can be flexible enough to allow for changes due to string content.
- Developer: Separate out multilanguage support from main application logic. For example a section that may search based on lowercasing contents would need to separate out the logic of lower casing since differing locales require different techniques. If this logic is intermixed with the search logic it creates unneeded complexity.
- Tester: Test the multilanguage module separate from the main application to ensure that additions take in account the required supported languages.
Links: IBM
Presentation controls
Best Practice: Consider style sheets or other presentation controls as part of the UI.
<Overview to be written - topics to include: allow swapping the stylesheet by locale, possibly split the stylesheet between colors, font and layout stylesheets>
Roles, responsibilities, and examples:
- BA/IxD: <to be written>
- Developer: <to be written>
- Tester: <to be written>
Links: IBM
Text in graphics
Best Practice: Avoid text in graphics.
The effort required to translate text in a graphic can be significant, not because the act of translation is hard, but replacing the text embedded in a graphic can be difficult and time consuming. Text can be embedded in a graphic in at least two ways: as part of a layer or as part of the image itself.
In the latter case, before a translation can be applied to the graphic, each pixel of the existing text needs to be replaced with a pixel that matches the underlying image before the translated text can be dropped in. In the case of an image where the background is a solid color, this is not a difficult process. But if the underlying image is complex (gradient colors, for example), this can take a great amount of time. When the translated text is applied to the image, re-sizing the graphic may be necessary so it's large enough to accommodate the translated text.
If the text is on a separate layer, replacing the original text with translated text is not difficult. But the challenge of overall image dimensions must still be considered and perhaps reworked if the translated text doesn't properly fit on the graphic.
Compounding the difficulty is that many translators do not own or are not accustomed to using graphics-editing applications. So manipulating the graphic will typically require someone else to do the work, and unfortunately that specific task may not fall into anyone's current job description. Further, the application itself will need to keep track of and use the x number of localized versions of the graphic -- which may require additional coding to ensure the right graphic is used at the right time.
Assume that the average effort to translate embedded text is 15 minutes and that the individuals doing this work are paid $45/hour. Assume there are 50 such images in the application and that the application is being localized into 24 languages. The effort and cost of embedding text in graphics is 300 hours at a cost of $13,500. There's an additional cost to code and test the functionality to store, retrieve and display the correct graphic from 1,200 potential files.
It is almost always worth spending a little extra time up front to ensure that there is no text embedded in graphics.
Roles, responsibilities, and examples:
- BA/IxD: design icons and graphics to not have embedded text.
- Developer: if text needs to be associated with a graphic, ensure it is handled programmatically rather than as part of the graphic file itself.
- Tester: check to see whether text on graphics is embedded.
Links: Microsoft
String buffers
Best Practice: Watch the size of string buffers.
<Overview to be written - this refers to code that allocates its own memory for storing strings, for example if a 4 character single-byte string is expected, and the user types in 3 single-byte characters and a double-byte character, the application has to allow for the differences. >
Roles, responsibilities, and examples:
- BA/IxD: <to be written>
- Developer: <to be written>
- Tester: <to be written>
Links: Microsoft
Text expansion
Best Practice: Design the UI to accommodate the text expansion that results from translation.
Because English is typically more concise than other languages, the result is that translations usually take more space than English. Thus, this concept is usually referred to as "Text Expansion." But compared with English, other languages may grow or shrink in length or height whether text or audio. For example:
- (Arabic) عائلة
- семейство (Bulgarian)
- 家庭 (Chinese)
- family (English)
- οικογένεια (Greek)
- ຄອບຄົວຂອງ (Lao)
- familia (Spanish)
While translators can sometimes find alternative, shorter ways to translate, often they cannot. The following data from IBM indicates average horizontal text expansion to expect and accommodate in UI design:
- 0-10 characters: 100-200%
- 11-20 characters: 80-100%
- 21-30 characters: 60-80%
- 31-50 characters: 40-60%
- 51-70 characters: 30-40%
- 70+ characters: 30%
Ideographic text, like Chinese, Japanese and Korean may require a larger font size in order to be read. Therefore it is important to accommodate this vertical expansion as well.
Roles, responsibilities, and examples:
- BA/IxD: Design applications to accommodate text expansion and contraction in both length and height. This may require a different CSS for some languages. If there is verbal audio component, like a narration, ensure that different durations are anticipated.
- Developer: Code to accommodate not only the visual expansion designed by the IxD, but also recognize that there will be a byte expansion with the use of multi-byte characters.
- Tester: Ensure the translations fit correctly visually and/or audibly. This should be done prior to actual translation by using a pseudo translation. Check text entry fields to ensure proper handling of multi-byte characters.
Links: IBM
Position dependency
Best Practice: Enable functions that depend on UI element location to accommodate changes due to text expansion or mirroring.
<Overview to be written - topics to cover: if elements are located differently due to right-to-left or if buttons are positioned due to priority then they may need to be inverted in alternate locales>
Roles, responsibilities, and examples:
- BA/IxD: <to be written>
- Developer: <to be written>
- Tester: <to be written>
Links: IBM
Colors
Best Practice: Consider the cultural impacts of color.
Color has culture-specific meaning. In a Western culture, we can give a word a 'Christmasy' feel simply by coloring it red and green. But that color combination may have other meanings or no meaning at all in other cultures. As we select the color pallet of our sites and products, we should be aware of how those choices will impact users of other cultures. Colors are so varied in their meanings from culture to culture that we may not be able to please everyone, but we should do our best not to make our message difficult to receive by choosing colors that could literally shade or distort our intent.
Roles, responsibilities, and examples:
- BA/IxD: Understand not only the languages but the cultures of those who will use the product. Then consider cultural meanings of color as you establish your site or product color palette. Refer to the chart at the link below or any other appropriate resource. Examples include:
- Red -- excitement, danger, love, stop (Western); good luck, celebration (China); bad luck, death (Korea); purity (India);
- White -- brides, angels, good guys, doctors, peace (Western); white carnation symbolizes death (Japan); funerals (Eastern)
- Blue -- conservative, corporate (Western); defeat, trouble (Cherokees); color of heaven and spirituality (Iran)
- Yellow -- hope, caution, cowardice (Western); courage (Japan); nourishment (China); mourning (Egypt)
- Developer: Implement colors as indicated by designers.
- Tester: Check site or product colors for cultural mismatches.
Links: Colours in Cultures
Mobile/web resizing
Best Practice: Accommodate mobile/web resizing issues.
<Overview to be written - topics to cover: importance of reaching mobile audience and how developing a mobile version later if the application is not architected correctly that developing a mobile version would be a duplicate version an app. Possibly cover the need for touch integration (hover state not working) >
Roles, responsibilities, and examples:
- BA/IxD: <to be written>
- Developer: <to be written>
- Tester: <to be written>
Links: Microsoft
Translation v. localization
Best Practice: Architect solutions to appropriately use translated or localized content.
<Overview to be written -topics to cover: what does this topic mean? What does 'use translated' mean?>
Roles, responsibilities, and examples:
- BA/IxD: <to be written>
- Developer: <to be written>
- Tester: <to be written>
Links:
UI controls
Best Practice: Design the layout of UI controls for localizability.
<Overview to be written - topics to cover- example: form elements whose labels wrap or overflow layout due to sizing differences >
Roles, responsibilities, and examples:
- BA/IxD: <to be written>
- Developer: <to be written>
- Tester: <to be written>
Links: Microsoft
Icons and clip art
Best Practice: Design icons and clip art for international users or facilitate their localization if necessary.
<Overview to be written - be aware that some icons might mean something in one locale, but not convey the same meaning in another locale>
Roles, responsibilities, and examples:
- BA/IxD: <to be written>
- Developer: <to be written>
- Tester: <to be written>
Links: IBM