Saturday, December 12, 2009

Design and Technology for the Software Product Manager

While different technologies are available to implement the next level of multilingual support in software applications, we examine one design approach based on .NET's technology elements.

Satellite assemblies can be used to provide multilingual support for menus since they contain localized resources. Microsoft Developer Network defines a satellite assembly as follows:

A .Net framework assembly containing resources specific to a given language. Using satellite assemblies, [the developer] can place the resources for different languages in different assemblies, and the correct assembly is loaded into memory when the user opts to use that specific language.

Using satellite assemblies, designers can place resources for different languages in different assemblies. Depending upon the language selected by the user, the corresponding assembly will get automatically loaded into memory. The application will need to incorporate individual satellite assemblies for each specific culture (the combination of a particular language with a particular country). For example, the culture "fr-FR" refers to the French language as used in France, whereas "fr-CA" refers to the French language used in Canada. These satellite assemblies can be placed in a specific location and loaded by the parent framework based on the culture setting of the software.

Support for multilingual messages can be provided by storing the culture-specific user messages in separate culture-specific message files (one file per culture). Message files appropriate to the specific culture setting of the software will be used to retrieve and display messages to the user.

By leveraging the locales facility, developers can build support for different date formats and decimal separators. Microsoft Developer Network defines a locale as follows:

A collection of rules and data specific to a language and a geographic area. Locales include information on sorting rules, date and time formatting, numeric and monetary conventions, and character classification.

While the user-selected default locale would be applied by default to all information presented to the user, the user can also select any other locale from a list of pre-defined locales to view the same information in another format.

Multilingual support for special characters in queries can be incorporated by maintaining separate culture-specific mapping files (one file for each culture). A mapping file maps a character in the chosen culture to the special accent characters in the other cultures supported by the software. The application would scan the mapping file corresponding to the language setting (culture) of the software and construct additional search phrases for all other mapped cultures.

By consciously designing the application so that it enables the user to select the language culture at the time of installation, one can prevent a "forced install" in the local language culture derived from the PC's regional settings. By designing the application to install and load all—and not just the user-selected culture files, designers bestow it with the capability of being re-started in another culture.

By leveraging the facility available to set the user interface (UI) culture property in report controls, reports generated in the native locale can be toggled into another locale. As a result, the application will be able to support recasting of data, reports and charts generated in one language into another.

In this manner, product managers and designers can combine sophisticated features available in the .NET technology stack with an innovative design approach in order to deliver the next level of multilingual support in a software product, with the overall goal of improving usability and boosting productivity.

No comments:

Post a Comment