ASP. NET Website internationalization policy

1. Question raised

Currently, many website projects require that they support multiple languages at the same time.ProgramTo achieveCodeSmall changes, convenient website deployment, and a wide range of user groups.

 

2. Solution Policy

. NET Framework provides a wide range of support for the development of global applications. This process involves three steps: globalization, localization analysis, and localization.

 

2.1 globalization

The executable code of the application will be compiled in this step. A truly globalized application should be non-specific regional and non-specific language. Therefore, focus on creating applications that support localized user interfaces and regional data for all users. Note that, despite the flexibility of global applications, the globalization process itself does not involve translation of user interfaces. Instead, efforts should be made to make the created application available to users in all regions and regions supported by the application.

 

2.2 localization Analysis

Localization analysis is an intermediate process used to verify whether global applications are ready for localization. If the executable code of the application has been significantly separated from the localization resources of the application, the application can start localization. The ancillary Assembly Resource Model of the Common Language Runtime Library fully supports the separation of such code from resources. Executable code is located in the main assembly of the application, and only resources are located in the resource file of the application.

 

2.3 Localization

Localization is the process of translating application resources into a localized version for each region supported by the application. The localization phase should continue only after the localization analysis step is completed and the localization process can be started for the global application.

Applications that can start localization are divided into two conceptual blocks: one is a block that contains all the user interface elements, and the other is a block that contains executable code. User Interface blocks only contain localized user interface elements in non-specific regions, such as strings, error messages, dialog boxes, menus, and embedded object Resources. The code block only contains the application code used by all supported regions. The Common Language Runtime Library supports a subsidiary Assembly resource model that separates executable code of an application from its resources.

To obtain each localized version of an application, you can add a new affiliated Assembly (including a localized user interface block translated into an appropriate target regional language ). The code blocks of all regions should be the same. The localized version of the user interface block and the combination of the code block generate the localized version of the application.

 

3. Best practices for international applications

 

3.1 globalization Best Practices

1) internally convert the application code into Unicode.

2) use the regional recognition class provided by the system. Globalization namespace to operate and format data.

L sortkey and compareinfo are used for sorting.

L for string comparison, use the compareinfo class.

L use the datetimeformatinfo class to format the date and time.

L use the numberformatinfo class to format numbers.

L for calendars and non-calendars, use the calendar class or a specific calendar.

3) use the regional attribute settings provided by the system. Globalization. cultureinfo class as appropriate. Use the cultureinfo. currentculture attribute to execute a formatting task, such as formatting a date, time, or number. Use the cultureinfo. currentuiculture attribute to retrieve resources. Note that the currentculture and currentuiculture attributes can be set based on each thread.

4) The application can read and write data with various encodings by using the encoding classes in the system. Text namespace. Do not use ASCII data. It is assumed that international characters are provided at any location where the user can enter the text. For example, international characters are accepted in the server name, directory, file name, user name, and URL.

5) when using the utf8encoding class, we recommend that you use the error detection function provided by this class for security reasons. To enable the error detection function, use the constructor with the throwoninvalidbytes parameter to create an instance of this class and set the value of throwoninvalidbytes to true.

6) process the string as long as possible, rather than a series of individual characters. This is especially important when sorting or searching for substrings. This prevents issues related to the analysis of composite characters.

7) use the class provided by the system. Drawing namespace to display text.

8) to maintain consistency between operating systems, do not allow users to set overwrite cultureinfo. Use the cultureinfo constructor that accepts the useuseroverride parameter and set this parameter to false.

9) use international data in international operating system versions to test application functions.

10) if the security decision is based on the result of a string comparison or case-insensitive change operation, explicitly specify the cultureinfo. invariantculture attribute to perform a non-regional operation. This ensures that the results are not affected by the value of cultureinfo. currentculture. For an example of how to generate inconsistent results for a string comparison that does not distinguish between regions, see custom case ing and sorting rules.

 

3.2 Best Practices for localization

1) Move all localized resources to a separate pure resource DLL. Localized resources include user interface elements, such as strings, error messages, dialog boxes, menus, and embedded object Resources.

2) Do not hard encode strings or user interface resources.

3) do not place non-localized resources in pure resource DLL. Otherwise, the translation staff may be confused.

4) do not use a composite string generated from the concatenation phrase at runtime. Composite strings are difficult to localize because they are often syntactically ordered in English, which is not applicable to all languages.

5) Avoid ambiguous structures, such as "empty folder", because these strings may produce different translations according to the syntax rules of the string components. For example, "empty" can be either a verb or an adjective, which may lead to different translations in languages such as Italian or French.

6) Avoid using images and icons containing text in applications. Localization of these images and icons is costly.

7) You can reserve sufficient space for the extension of the string length on the user interface. In some languages, phrases may require an additional space of 50% to 75%.

8) the database is designed to retain the length of other language versions of string fields.

9) use the system. Resources. ResourceManager class to retrieve resources based on the region.

10) arrange for professional localization (translation ).

 

3.3 ASP. NET application globalization Best Practices

1) explicitly set the currentuiculture and currentculture attributes in the application. Do not rely on the default settings.

2) Note that ASP. NET applications are hosted applications, so you can use the same classes as other hosted applications to retrieve, display, and operate information based on the region.

3) You can specify the following three encoding types in ASP. NET:

L requestencoding specifies the encoding received from the client browser.

L responseencoding specifies the encoding to be sent to the client browser. In most cases, this should be the same as requestencoding.

L fileencoding specifies the default encoding used for. aspx,. asmx, And. asax file analysis.

4) Specify the values of the requestencoding, responseencoding, fileencoding, culture, and uiculture attributes in the following three places in the ASP. NET application:

L in the globalization section of the web. config file. This file is an external file of ASP. NET applications. For more information, see the <globalization> element.

L in the page instructions. Note that when the application is on the page, the file has been read. Therefore, it is too late to specify fileencoding and requestencoding. Only uiculture, culture, and responseencoding can be specified in the page instruction.

L is specified programmatically in the application code. This setting may vary with requests. Like page commands, it is too late to specify fileencoding and requestencoding when the application code is opened. Only uiculture, culture, and responseencoding can be specified in application code.

5) Note that uiculture can be set as a browser language.