Introduction
This article discusses about issues of application globalization and globalization best practices.
Most applications are developed with one language in mind, but as the application evolves and opportunities in other cultures increases, there comes a need for the application to be deployed or used by different locales.
Making an application world class ready can be costly when that application has never been planned for globalization; this cost normally comes in terms of the work required for localization and testing.
So, it is important that the application is designed and developed in such a way that it would make it much easier to localize the application when the need arises.
Of course, globalizing an application would mean lots of planning and decision making, but it would not make much of a difference if we can blend some practices that are done when localizing an application with an application development that was never thought of being localized; these practices would result in much lesser effort when the application is planned and implemented for actual localization.
Basic localization
The following section describes some of the basic localization practices that should be adhered to from day one of an application development.
Texts that are displayed to the user should be externalized into a separate resource file, thus separating messages from the actual code. The text would be read from the resource file when the program needs it.
Avoid concatenating strings to form messages; given a set of words, a sentence can be formed in different ways in different languages. If you need to concatenate different strings to form a phrase or sentence, move the whole string into a resource file with place holders that can be dynamically replaced with the correct strings. This gives translators the freedom to interchange place holders to form the correct string in different languages.
It’s also important to note that any string that is found in the code that is not displayed to the user is moved into constant fields; this makes it much clear to the programmer in the future that it is not something that should be translated.
Date, time, and numbers should be displayed in the format for the current locale; to do this, data, time, and numbers should be formatted taking the current locale into account. If any of these types are (date, time, or numbers) stored in a text file or database for future use, these should be stored in an invariant form. The most common way to do this is, when any of these types is entered by the user, the type is converted into the default culture (en-US) and stored in the data store (text file, database etc.). Of course, these types should be used in their invariant form when doing calculations on them. When these types stored in their invariant form are needed for display, they are retrieved and converted into the current user’s format using the current locale.
It’s also interesting to note that a text can be used to mean differently in different contexts; therefore, it is important that multiple copies of the same text are made when using in different contexts in the program.
Avoid using images and icons that contain text in your application. They are expensive to localize as separate images need to be created for each and every language. If images are needed to be used, symbolize them, and show a tooltip (which would be localized) when hovered over the image.
It is a good idea to base all the text that appears to the user on the client locale; do not display messages that are directly sent from the service (in the case of a Web Service etc.); design your service so that it tells you what message to show. However, it is OK to show messages from the service if the service takes into account the current client locale, but the previous approach should be chosen over this as much as possible.
Unhandled exception messages or messages written to the log should not be localized; this gives the developer the flexibility to troubleshoot issues in the application without needing to know the language of the current locale the application is running on.
When third party UI components are used in the application, make a note to check if the component supports localization, and if so, if it supports the languages you are localizing the application to.
Post localization
One of the problems that many GUI development projects face is when the application is run, the actual translated language disfigures the UI.
One of the main issues comes when the text for a certain control runs out of width. A workaround for this is to make the controls, especially the labels and the checkboxes, to automatically grow with the text. In some languages, phrases can require 50-75 percent more space than they need in other languages.
Avoid positioning text fields and labels horizontally; this would pose problems when in one language the text grows beyond the width of the text field or label and you need to increase the size of the text field or label. If these controls are horizontally placed, you might need to put up a scrollbar to fit the entire set of horizontally placed controls. This might not give the exact same looks to the UI. Thus, it’s better to design your UI layout so that controls are positioned vertically instead of horizontally.
One main phase of an application globalization cycle would be translation verification testing. In this phase, testers would verify translated text in the UI, as the UI layout can change for each and every language. Generally, it would be cost effective if the UI layout is adjusted to best fit most of the languages. If this is not done, then the UI layout has to be adjusted for each and every language.
Therefore, it is a best practice to keep adequate space between controls, so that text could grow. The size of textboxes and labels should also be increased (if auto adjusting of size is not set), so that text in other languages can averagely fit in.
Multilingual support
It is important to note that the application being developed should be fully Unicode enabled.
Implementing Unicode support frees you from having to worry about the language and codepage support of the platform your application runs on. Unicode can support most of the languages around the world, hence a Unicode-enabled application can process and display characters in any of these languages.
Consider implementing a multilingual user interface. If you design the user interface to open in the default UI language and offer the option to change to other languages, users of the same machine who speak different languages reduce down time related to software configuration. This may be a particularly useful strategy in regions such as Belgium with more than one culture/locale and official language.
Many applications persist UI setting of the application. An example for this would be the width of columns in a grid or the state of the application when the initial screen is shown, whether it is minimized or maximized.
If the application is built to support different languages at runtime, i.e., if the user is given the ability to change the locale when the application is started, any value stored in the setting file should be stored in an invariant format (en-US) so that the UI could be gracefully restored with these settings.
Pseudo translation
Pseudo translation is the process of testing the software application for globalization with dummy text.
In this process, text that needs to be externalized are already in resource files; the text in these files are used to generate dummy text for different languages. Next, the application is run on top of these pseudo translated resource files with an appropriate locale.
And so, the testing begins; texts that shows up in the default language are not externalized, i.e., they are not in resource files and they need to be moved into appropriate resource files and pulled into the program. Pseudo translation testing also reveals overlapping text in controls. Note that the text might not overlap when the actual translated application is run, therefore the best judgment is used to space out controls and to increase the width of labels, checkboxes etc.
The application is also tested for its functionality. One of the most common thing that can occur here is, a piece of string is translated where it should not be. This can be hard to notice sometimes, but a through set of test cases would show them off easily.
It would be cost effective in some cases if testers can start testing the UI before the actual UI test is translated, eliminating the lag the testers need to wait until the actual translated application arrives.
Pseudo translation is a worth while effort in judging the feasibility of globalization of an application that was developed with globalization not in mind; possible problems can be identified leading to better estimates.
There are available pseudo translation tools in the market. Some tools tend to translate text using dummy values. In this case, it’s not accurate in terms of overlapping text and controls, but if a tool can translate the text to the target language up to a certain amount of accuracy, this would lead to better outcomes.
Summary
In summary, globalization of an application involves a lot of planning; however, most applications that are developed do not have globalization in mind.
This article described certain issues that come in when an application is actually localized and how this could be overcome by adhering to a few best practices from day one, so when the application if ever is globalized, it could be done with mush less work and with minimum cost.
