Strings and String.Format

One of the most basic rules of localization is to avoid concatenating bits of text to form a sentence or phrase. For example:

 statusBar1.Text = "Processing file " +     fileNumber.ToString() + " of " + totalFiles.ToString() + "..."; 

This code builds up a string using English sentence rules. The result is something like this:

 Processing invoice 3 of 15... 

Different languages form sentences according to different rules. The same phrase in Japanese is:

 15  ... 

Notice that the 15 comes before the 3, not after it, as it does in English. Also be aware that this is a translator's nightmare. The translator will be presented with three strings: "Processing file", "of", and "...". There is no guarantee that the translator will be presented with these strings sequentially or that the translator will be aware that the three strings form a single phrase. Good translators translate meaning and not words, so this approach prevents them from providing a meaningful translation. The solution is to use String.Format and to use placeholders to mark the positions of the substituted text; a nonlocalized better version is:

 statusBar1.Text = String.Format(     "Processing file {0} of {1}...", fileNumber, totalFiles); 

The phrase is represented by a string that has numbered placeholders ({0} and {1}). When the string is extracted from the code, moved to a resource, and sent to the translator, the translator will understand the context of the words and the relationship between them, and be able to translate the string accurately. The translated Japanese string now becomes:

 {1}  ... 

Notice that the placeholders are in a different order, but because they are numbered, the correct information is substituted for the correct placeholder. In the "Reintegrating Resources" section of Chapter 14, "The Translator," I show how you can ensure that translated strings have the same number and same type of placeholders as their original strings.

Text Ending with Colons

Some developers prefer to terminate strings used in labels with a full colon, whereas others prefer to leave out the colon. For the most part, localization does not play a part in your decision-making process as to which approach you should pursue. Most machine-translation facilities understand that text might be terminated with a colon and can perform their translation without the colon affecting the success of the translation. In addition, the .NET Framework's mirroring functionality (see Chapter 7, "Middle East and East Asian Cultures") in both Windows Forms and ASP.NET accounts for the colon and moves the colon from the right side of a text string to the left side of a text string.

If you are looking to create a company standard for Windows Forms user interfaces, you should take a look at Microsoft's "Official Guidelines for User Interface Developers and Designers" (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/welcome.asp), which includes advice on using colons in labels (open the section on Windows Interface Components, then Menus, Controls and Toolbars, and then Controls, and search on "colon").