Internationalization and its dimensions in Product space
Following are some of the aspects from a Product internationalization perspective:
1. Platform Independence: An internationalized software product should be able to operate in any locale on any operating system (Windows, Linux, Solaris etc) and should deliver consistent results. Also, the product should be able to work in a locale which is different from the Operating system locale. For instance, a product should be able to work in a Japanese locale on a Windows English OS, or on a Linux English OS.
2. Multiple Locales on same installation: An internationalized product should be able to support multiple locales in a single installation. Moreover, the user should have the choice to select the locale of his choice and the product should adapt to the new locale seamlessly at runtime. For example websites like www.hp.com, www.google.com, provide options to the user to switch to a different locale (country + language combination) at runtime.
3. Different timezones: An internationalized product should be able to deal with different timezones in a consistent manner. It should be able to store and retrieve the time in multiple timezones and display the correct time as per the selected locale. For instance an application might have a feature to send alerts about an event to various users located across the globe. The user might be able to view the time of the event's occurrence in their respective time-zones. The application should be able to smartly handle this. Microsoft Outlook is a live example for this feature, where meeting requests, mail etc all display the time to different recipients in their respective time-zones.
4. Help and Documentation: The product should be able to display the Help documentation as per the language in the selected user locale.
Lets consider a situation where a product has been released in a new market, with additional locale support. As the time to market was important, the entire help documentation might not get translated at the time of release. For such cases the product should be designed in manner that if some documentation or help files are not available in the user locale then the product should seamlessly shift to the default locale. In such a situation displaying help pages in default language would be a better option then showing broken links or error pages. Just like resource bundles, for resources like help documentation also product should shift to default locale if locale specific resource is missing.
5. Images/Audios/Videos: Some products may make use of images, audios clips, or video clips which may contain information (visible text or audible data). For instance, a website may use images to display different buttons, links, or use video files which contain text in a specific language (English for instance). For such a product to be internationalized and operate successfully in a different locale (in the Japanese locale for instance), the images with English text should change to display images with same text in Japanese, videos with English text should change to videos displaying the same message in Japanese. The product should be capable enough to pick the correct image/audio/video clips based on the user locale. Also as discussed for help files, product should shift to the default locale seamlessly if locale specific image/audio/video resource is missing.
6. Installers: Deployments of enterprise applications are generally limited, and are done in a planned manner by skilled people. However, products are expected to support multiple deployments and a varied set of environmental conditions. Hence, products generally come packaged in an installer. As a result, it is sensible that these installers are also internationalized. I18n support to installers would again have different dimensions:
a. Internationalized Installer: Installer application should be internationalized as any other software. Installer should display user interface as per user locale and should support core I18n requirements like resource bundle, encoding support, data formatting etc.
b. Ability for Locale specific installations/configurations: Another aspect is that the installer should be able to install the internationalized product with specific localized features. For example, consider a product being developed for the international market. It is possible that the product may have been well internationalized and built to support a large number of locales. In a case where an end user wants to be selective in installing components corresponding to only those locales that he is going to work on, the installer should be able to provide the user the ability to select the locales of his choice and customize features as per the selected locale. As an example, if the user selects German and French locales, the installer should extract only those resource bundles/documentation/images corresponding to the German and French languages.
7. Bi-directional Support: Product should also support bi-directional languages. Most of the languages across the globe are written left to right (LTR), while there are some scripts which are written from right to left (RTL) (Urdu, Arabic, Hebrew for example). These scripts can also have sections of LTR scripts (like some English words) or numbers embedded. The product should be able to handle such languages. Such languages impact the layout of the UI, the direction of cursor movement, the order of labels and inputs fields etc. An internationalized product in deployment should be able to handle language bi-directionality without needing any engineering changes.
8. Regional Business Rules & Regulations: Different countries have different rules and regulations. Differing rules could be around the storage/retrieval of information, tax laws, financial transactions etc. The product should be able to adapt to such rules based on locale changes. This is complex as the magnitude of such variations in business rules could be huge. An Internationalized product should provide a framework such that new rules can be added, or existing rules can be changed easily for different locales without impacting the design of the product. Based on the product design, the rules could be even be configurable in files, databases etc. .Sometimes, it becomes necessary to write custom code for a particular locale as part of Localization. Such custom code should be easily pluggable in an internationalized product.
9. Encoding Support: Unicode (UTF-8, UTF-16 or UTF-32) encoding supports almost all the scripts that are used across the globe. In addition, there are a number of native language encoding schemes that have been in existence from times before Unicode. For instance, SHIFT-JIS, EUC are two different encodings used for Japanese text. Not every operating system supports these native encodings and that brings in the implementation challenges. The product should be able to adapt to such encoding changes based on the underlying platform support, without impacting the functionality.
10. Ease of adding new Language: Product design should be such that support for any new language can be added without any code/design changes and recompilation.
Many of us consider 'Internationalization' to be as simple as displaying text in different languages - but as indicated in the points above there are different dimensions that need to be evaluated before starting the I18n work for any product. Not all the dimensions discussed above are mandatory for every software application/product. The applicability of each dimension depends upon the type of application, its usage, deployment landscape and the target market requirement. Businesses should select features to be implemented based on the cost of implementation and the ROI that can be achieved in target markets.