This documentation is archived and is not being maintained.

String-Related Issues

Visual Studio .NET 2003

String resources include the text that appears in an application's user interface. This refers to, but is not limited to, menus, dialog boxes, and messages (informational, alert, and error messages).

When you are developing a world-ready application, you must consider differences among languages, especially as those differences relate to strings. During the localizability process, you should verify which strings require localization, ensure your application makes it possible for strings to grow, and ensure your application does not rely on string concatenation.

String Concatenation

String Growth

String Sorting and Comparison

Strings and Resource Files

String Concatenation

When you try to reduce the size of a string, one possible approach developers try to use is string concatenation. However, this method will significantly limit the localizability of your application and you should not use this method. In this section, you will see several reasons why string concatenation is a hazard to localizability and why you should avoid this practice.

Gender Issues

English French
String1: one after the other String1: un après l'autre
String2: The controls will be deleted String2: Les contrôles seront supprimés
String3: The forms will be deleted String3: Les feuilles seront supprimées

Taken separately, String1, String2, and String3 are easily localizable. If your code concatenates String2 and String1 or String3 and String1, the resulting English string looks fine. The localized strings, however, are likely to be wrong. In the French column, for instance, String3 + String1 would be wrong, because in French grammar, forms (feuilles) is a feminine word. Thus, String1 should be "une après l'autre" and not "un après l'autre." The same situation will be true in many other languages.

You can easily fix this problem by avoiding string concatenation and using complete strings in a resource file.

Word-Order Issues

In the preceding example, the order of the words that make up the sentence is the same in English as it is in French. However, the word order is generally not the same from one language to another. (For example, in both German and Japanese the verb generally appears at the end of the sentence.) The following example illustrates this:

English French
String1: DLL String1: DLL
String2: Missing Data Access String2: Accès aux données manquante
String3: Missing OLE String3: OLE manquante

If your code concatenates String2 + String1 and String3 + String1, localized versions are incorrect because the order of the two strings produces a message that does not make sense.

You can easily fix this problem by avoiding string concatenation and using complete strings in a resource file.

Translation issues

Finally, it is also important to know that identical words or sentences in English may require translation into different words or sentences when localized. Consider the following example:

English French
String1: Setup program String1: Programme d'installation
String2: 'String1' did not complete successfully. String2: String1 a échoué.

In the English version, String1 is the setup program's banner string. It is also used as part of an error message in String2. In the French version, String1 works perfectly as the stand-alone banner string. However, it needs to become "Le programme d'installation" when used with String2.

You can easily fix this problem by avoiding string concatenation and using complete strings in a resource file.

String Growth

In most cases, translated strings are usually longer, such as when you translate strings from English to German.

The following table shows the additional average growth for strings beyond initial length. This data is from past Visual Basic localization projects and describes an average growth rate:

English length (in characters) Additional growth for localized strings
1 to 4 100%
5 to 10 80%
11 to 20 60%
21 to 30 40%
31 to 50 20%
Over 50 10%

String Sorting and Comparison

Although we may think that sorting criteria are universal, users of world-ready applications might disagree when sorting in another language. Not only does alphabetical order vary among languages, but conventions for sequencing items in dictionaries and phone books can also be quite different.

In Swedish, some vowels with diacritics sort after Z. However, in other European languages, the same diacritic vowel sorts right after the non-diacritic vowel. Languages that include characters outside the Latin script have special sorting rules. For example, the Icelandic character ð sorts between D and E. Asian DBCS languages have several different sorting orders depending on phonetics, radical order, number of pen strokes, and so on.

String sorting and casing are language specific. Even within Latin script based languages, there are different composition and sorting rules. In only a few languages (including English) does the sort order match the code point (A [65] comes before B [66]). However, that only works if you normalize text to either uppercase or lowercase before sorting. So, do not rely on code points to do proper sorting and string comparisons.

Strings and Resource Files

Designing your application with localization in mind and separating string resources from code from the beginning of your project is more efficient than revising your finished application to meet the requirements of an international audience later in the development process.

Although it might be more work for the person writing the application, no user-interface elements should be present in the application's code. Instead, the string resources should be in a separate file from which the application will load them at run time. This file, called a resource file (.resx in managed code and .rc in Visual C++), contains all the localized strings, bitmaps, and icons.

The teams working on localizing the application should work exclusively on the resource file to develop all the different language versions of the application. This approach has the following advantages:

  • Efficiency Developing a new international version of the application only involves creating a new international resource file because each version has the same code block. This streamlines the creation of multiple language versions of your application.
  • Greater security Whether you decide to localize your application in-house or to use an external company, you will not need to access source code to develop international versions of your application.
  • Less testing This approach dramatically reduces the amount of testing required to ensure the quality of your application's international version.
  • Better localization By placing all relevant string resources in one file, you ensure a more efficient localization process and reduce the chance of leaving some strings un-localized.

One resource you should consider using is the glossary for all Microsoft localized products. Individual glossaries for 31 languages are available for download from the glossary directory on (

When building resource files that contain localizable strings, the data block should only include strings that require localization. Conversely, it is also fundamental to make sure all the resources that need to be localized are actually present in these resource files. The code block consists of hard-coded items not requiring localization.

See Also

Globalization and Localization Issues