Traditionally, multilingual software applications and Web sites allowed users to select a language from a list containing multiple languages at the set-up and log-in stage. The language was then installed and displayed on all screens, menus, and help text. That sufficed when the application's use was confined to a single language at a time.
With the increasing globalization of the twenty-first century, co-workers who are spread across many countries in multinational corporations need to work cohesively as one unit. The traditional level of multilingual support no longer suffices. Multinational corporations need the next level of multilingual functionality from their software applications to boost productivity and, in some cases, even meet compliance with local regulations.
Product managers in product companies and solution architects of custom-developed applications can enhance the marketability of their software applications by creating a roadmap for incorporating the sophisticated multilingual requirements that such multinational corporations need.
Multilingual Support in Software Products
Let's take the case of an analysis and research application for European asset management companies (AMCs) spread across France, Germany, Italy, Spain, the United Kingdom (UK), and other European countries.
It would be typical for a branch of one such AMC in one country to have employees belonging to another (e.g., the Paris office would have a few German employees). As a result, not only would the product be expected to support multiple languages (e.g., French and German), but it would need the capability to permit an employee to choose the language (e.g., German) instead of installing the French-language version by default.
In many AMCs, investment recommendations for funds traded in one country would need the approval of the chief investment officer (CIO), located at the headquarters in another country, before they could be presented to customers. This means that after logging into the application in the German language, the asset manager in the AMC's Frankfurt office might need to switch over to the English language later while reviewing the data with his UK-based CIO prior to obtaining his or her approval. Once the approval is obtained, it might be necessary to recast all data, reports, and charts into the French language before presenting them to a prospective customer in Paris as part of an investment recommendation. Therefore, the application should not restrict users to the language chosen at the time of logging in, but let them toggle between multiple languages "on the fly."
Apart from the multilingual screens, menus, and help features, the application will have to cater to data entry, querying, and reporting needs in the different supported languages. This means support for various accents such as the German umlaut, French grave, acute, cedilla, circumflex, and the Spanish tilde. In addition, sensitivity to different date formats such as 15 June 2006 in the UK versus 15. Juni 2006 in Germany; and decimal separators such as a comma in the UK versus a period in Continental Europe (e.g., 1,000 versus 1.000) are respectively prevalent in different European languages.
Now, when a London-based asset manager queries for all French funds containing a certain letter in their name, he or she would expect the application to return funds containing not just that letter by itself but its various applicable accents like acute (e.g., "ć"), grave (e.g., à), cedilla (e.g., ç), and circumflex (e.g., ĉ). This means that the application will need to support multilingual query literals, characters, and messages.
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.
Multilingual Support in Custom-developed Applications
Apart from usability and productivity, compliance considerations will increasingly raise the bar on the level of multilingual support demanded from software applications. This trend has already been noticed during implementations of the Single Euro Payments Area (SEPA) regulation among banks and corporations operating in different countries in Europe.
With the increasing globalization of the twenty-first century, co-workers who are spread across many countries in multinational corporations need to work cohesively as one unit. The traditional level of multilingual support no longer suffices. Multinational corporations need the next level of multilingual functionality from their software applications to boost productivity and, in some cases, even meet compliance with local regulations.
Product managers in product companies and solution architects of custom-developed applications can enhance the marketability of their software applications by creating a roadmap for incorporating the sophisticated multilingual requirements that such multinational corporations need.
Multilingual Support in Software Products
Let's take the case of an analysis and research application for European asset management companies (AMCs) spread across France, Germany, Italy, Spain, the United Kingdom (UK), and other European countries.
It would be typical for a branch of one such AMC in one country to have employees belonging to another (e.g., the Paris office would have a few German employees). As a result, not only would the product be expected to support multiple languages (e.g., French and German), but it would need the capability to permit an employee to choose the language (e.g., German) instead of installing the French-language version by default.
In many AMCs, investment recommendations for funds traded in one country would need the approval of the chief investment officer (CIO), located at the headquarters in another country, before they could be presented to customers. This means that after logging into the application in the German language, the asset manager in the AMC's Frankfurt office might need to switch over to the English language later while reviewing the data with his UK-based CIO prior to obtaining his or her approval. Once the approval is obtained, it might be necessary to recast all data, reports, and charts into the French language before presenting them to a prospective customer in Paris as part of an investment recommendation. Therefore, the application should not restrict users to the language chosen at the time of logging in, but let them toggle between multiple languages "on the fly."
Apart from the multilingual screens, menus, and help features, the application will have to cater to data entry, querying, and reporting needs in the different supported languages. This means support for various accents such as the German umlaut, French grave, acute, cedilla, circumflex, and the Spanish tilde. In addition, sensitivity to different date formats such as 15 June 2006 in the UK versus 15. Juni 2006 in Germany; and decimal separators such as a comma in the UK versus a period in Continental Europe (e.g., 1,000 versus 1.000) are respectively prevalent in different European languages.
Now, when a London-based asset manager queries for all French funds containing a certain letter in their name, he or she would expect the application to return funds containing not just that letter by itself but its various applicable accents like acute (e.g., "ć"), grave (e.g., à), cedilla (e.g., ç), and circumflex (e.g., ĉ). This means that the application will need to support multilingual query literals, characters, and messages.
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.
Multilingual Support in Custom-developed Applications
Apart from usability and productivity, compliance considerations will increasingly raise the bar on the level of multilingual support demanded from software applications. This trend has already been noticed during implementations of the Single Euro Payments Area (SEPA) regulation among banks and corporations operating in different countries in Europe.
No comments:
Post a Comment