LearnNowOnline

Blog

Working with String Resources

Excerpt by Ken Getz | July 05, 2013

Although lots of developers do it, it's never a good idea to embed string resources directly into your application's source code. Sure, it makes it easy to get the application written quickly, but extracting all the text of your application into a shared resource file makes it far easier to maintain the text over time, and hard-coding text in the application makes it nearly impossible to translate the application for multiple cultures. The more experienced developer will, instead of hard-coding text in an application, extract the strings into a resource file, creating a single resource corresponding to each piece of translatable text in the application. Using string resources allows you to replace text with culturally-sensitive content, so that Windows can load text specific to the current or selected locale.

Therein lies the beauty of working with resources: Windows itself takes care of loading the appropriate resource information at runtime, assuming that the content is labeled correctly. As you'll see as you work through the examples in this chapter, it's up to you to appropriately label the resources, so that Windows can load the correct language resources at runtime. It's also up to you to designate a default language (specified in the Package.appxmanifest file) so that Windows can have a "fallback" language, in case you haven't supplied resources for the current user language. In .NET Framework apps (as opposed to Windows Store apps), developers generally store resources using a "hub and spoke" topology. That is, the main application contains the default, "fallback" language info, and satellite assemblies contain only resources, with one language per codeless assembly. Windows Store applications use a single resource file, called a Package Resource Index (or PRI) file. This PRI file stores the resources for all languages, cultures, and scaling factors (including images that need to be scaled for different screen resolutions, another use for resources). What if the Windows Runtime can't find a particular resource for a particular language in the PRI file? In this case, Windows provides fallback rules that determine which resource to load that best fits the requirements.

Creating Resources

The techniques for creating and naming resources have changed between .NET Framework applications and Windows Store applications. In a desktop application, created using the .NET Framework, you place resources in either text or XML (.resx) files. You use the Resgen.exe application to compile the resources into binary format, and the .NET compiler embeds resources from the default/neutral culture into the main assembly. You use the Assembly Linker (AL.exe) to embed other resources into satellite assemblies.

At runtime, you retrieve resources using the ResourceManager class. In Windows Store applications, you create .resw files that contain the resources. These files are identical in format to the old .resx files, except that they contain only strings and file paths. You can create as many of these files as you need, for various languages that your application supports. At compile time, the compiler packs all the .resw files into a single PRI file using the MakePRI utility, and the PRI file is included with your app's deployment package. At runtime, you can use either of two classes to work with your resources programmatically (examples later in this chapter use both of these classes):

• For more complex activities, use the Windows.ApplicationModel. Resources.Core.ResourceManager class.

You'll find it easiest to use Visual Studio 2012's resource editor to create resources. This editor provides two advantages:

• There's no need to create the resource file manually, and to ensure that it contains valid XML content.
• The resource editor handles the process of calling the MakePRI utility to compile the resource file, pack it into a PRI file, and include it in the deployment package.

In other words, use the editor. You'll be glad you did.

Naming Resources

Windows supports a broad range of naming techniques for resources, to ensure that it can load the appropriate resources at runtime. In this chapter, you'll investigate a few of the naming standards that work with Windows, although the support is actually broader than you'll see here. Selecting the appropriate resource at runtime is all about setting an appropriate file name at design time. Although a complete discussion of language and locale support is far beyond the scope of this chapter and its intended coverage of resource usage, it is important to understand how Windows handles language and locale naming. Microsoft provides a complete list of standard names for languages, and you'll find that list here: http://go.appdev.com/?id=8AFG (see Figure 1).

If you study the list carefully, you'll see that for every language, the list provides a two-letter code representing that language (ar for Arabic, bg for Bulgarian, zh for Chinese, and so on, including en for English). In addition, each language possibly supports multiple specific locales, represented by a two-letter code after a dash (you can probably use your own memory of social studies to guess at the exact meaning of some of the codes-for example, ar-sa would seem to support Arabic as spoken in Saudi Arabia, while ar-eg would seem to support Arabic as spoken in Egypt.) Figure above. The list of supported languages. When specifying a language, you can either select the two-letter name, or a full name as listed on this page. When creating resources, start by creating a folder in your project named Strings. Inside that folder, create a folder for each language's resources, using the language name retrieved from the Microsoft list. For example, in the US, the default language is generally en-us, so your application could contain a folder named Strings and a subfolder named en-us. Then, when it's time to describe the particular set of resources you want to use, you can specify the resource using the culture name followed by the resource name and file extension, as in en-usResources.resw. You also have the option of using the culture or locale as part of the file name (as opposed to the folder name). This allows you to place multiple locale's resources in the same folder. You'll see examples of this technique later in the chapter.

This post is an excerpt from the online courseware for ourWindows 8 Using XAML: Views, Resources, and Toastscourse written by expert Ken Getz.

Thousands of developers worldwide use LearnNowOnline to gain the technical skills they need to succeed on the job and advance their career.