Go to page: 1 2  Printer Friendly Version

(Editor's note: To download this project, click here (ZIP file.)

Living in the United States I sometimes forget that most of the world doesn't speak English. Sure I occasionally run into someone who speaks Spanish, Japanese, or Mandarin Chinese as a primary language but that's more of a rarity than an every day occurrence. As a result if you ask me the number of times that I've needed to build localized versions of my software the answer would be --- not very often. However, just because it's not something I run into every day doesn't mean that I shouldn't be more cognizant and aware of the right practices to support localized software.

In this article, I'll round up the scattered pieces of information about localization in SharePoint, provide some tips and tricks and leave you with a working approach to localization. However, before we work on meeting the challenge, we should understand it.

The Low Down on Localization

Software localization is the process of making software works for people who live in a different culture than the software was originally developed in. Localization breaks down into two broad areas: language and formatting. We'll be focusing on the language aspects of the localization challenge in this article. The other area of localization, formatting is handled relatively well by Windows, the .NET framework, and SharePoint. The formatting of dates, currencies, etc., all tend to appear the way that they should appear with little or no developer intervention. Language is, however, more challenging as it's not a matter of moving around periods and commas. It's a matter of selecting the right word, having different abbreviations, and generally making the right words work.

More From Intranet Journal

Chin Music: Put a Cork in Software Zimbra Beats SharePoint for Collaboration Award MediaWiki Voted Best Wiki Tool If you want to comment on these or any other articles you see on Intranet Journal, we'd like to hear from you in our IT Management Forum. Thanks for reading. - Tom Dunlap, Managing Editor. FREE IT Management Newsletters bITa Planet CIO Update Intranet Journal Update Datamation IT Management Careers Datamation IT Management Update Grid Computing Planet HTML E-Security Planet Text E-Security Planet HTML DRM Watch HTML

Most of the time, we barely recognize that the software has language embedded in it. Labels are prime candidate for needing to be converted as are error messages. Anything that you might display in the body of the web part qualifies as text that may need to be localized. Similarly in a SharePoint world, there are properties of the web part which need to be made language specific. The property's friendly name, category, and description are all candidates for localization. The challenge is that much of this text is hardcoded into controls through attributes and constants. The localization technique must make it easy to take working code and convert the strings which are already hard coded into a language specific string.

.NET and the web part infrastructure does provide facilities which make localization easier. In fact all of the fundamentals are provided, it's up to you to string them together and make them work. One of the fundamental components necessary to localize software is the Locale Id (lcid). This is an internationally standardized ID to indicate the language used by a particular location. The beauty of this is that you can read from code the lcid from the running thread very easily (System.Threading.Thread.CurrentThread.CurrentUICulture.LCID).

Once you know what language you're working with you can apply a technique for loading the appropriate text string for the locale the software is being used in by taking in a key and fetching the locale. In the SharePoint web part class there is a virtual method called LoadResource which takes in a string-based key and returns a string value. By overriding this method you can control how SharePoint loads the localized strings for the application.

Typically, .NET leverages resource DLLs which are simply compiled versions of resources. The resources in this case are strings. Because we're most frequently concerned with strings while localizing, it's possible to take a different approach than resource files to get our localization information. We can load and use XML files directly. Before we get to the code to do this, we need to figure out how to get these files.

Creating the non-Resource File

Sometimes the simplest solutions are best. While resource files are more compact and offer more flexibility, in a simple application like a web part - particularly one where you want to encourage others to write language files - an XML file is a good place to start.

Bil Simser proposed a very simple XML file format which I like quite a bit, it looks like this:

SomeValue

The simplicity of this file format allows you to quickly add new entries without worrying about XML namespaces or extra processing. A suggested naming the files with the language ID and an extension of .XML makes it easy to find the files after they've been deployed. Naming the language files with their locale id with a .XML extension is exactly what the code shown below will expect. The Locale ID for US English is 1033. So a US English resource file would be 1033.xml.

Deploying Resources

When you deploy a web part with the STSADM tool you create a web part CAB file. In that CAB file you include a manifest.xml which tells SharePoint what to do with the files that are contained inside it. Basically you end up with an Assemblies section and a DwpFiles section. In the Assemblies section you describe the assemblies that must be installed and the supporting files that those assemblies need.

The tag contains one or more tags which are the assemblies (DLLs) to be installed. Within that tag you can specify class resources in a tag in addition to the SafeControls entries that you want to add. Class Resources, each in its own tag require only a FileName. When the tags are provided these files are copied out of the CAB file and into a special resources folder on the web server during the installation of the web part. The specific location of the resources folder will vary slightly based on the installation so there's no one, easy way to know precisely where the files will be placed.

The good news is that you can find the path that the class resources are deployed in by looking at the Web Parts' ClassResourcePath property. It will point you to where the class resources were copied. That makes the process of actually finding the files once they're deployed very easy.

Go to page: 1 2 

Printer Friendly Version