1.) Modify the Silverlight project file (I prefer to do this in a simple editor). Modify the SupportedCultures element by adding the language-culture information as shown:
1 <SilverlightApplication>true</SilverlightApplication>
2 <SupportedCultures>en-US;en-CA;fr-FR;hi</SupportedCultures>
3 <XapOutputs>true</XapOutputs>
In this example, we are going to support (in addition to the base language) en-US (US English), en-CA (Canadian English using Region instead of State and Postal Code instead of Zip Code), fr-FR (the french language in France) and finally, Hindi which is a Unicode font making our sample more illustrative of the challenges of globalization that can happen. Notice too that it's not necessary to include the culture. We need the culture information for en-US and en-CA since they both use English; however, we can simply use hi for Hindi (हिन्दी) support (across all countries) without the IN country code.
2.) Add a single resource file - do not follow the temptation to add the additional language resource files. Its FAR easier to copy the base language file when you are ready to implement multi-languages and rename it as needed (i.e. localization.en-US.resx).
3.) Localize your app. This means removing all hard-coded string references (i.e. ... = "Address") to localized equivalents. This can be simply something like ... = localization.CON_Address where localization is the namespace representing my base localization.resx file and CON_Address is a property defined therein. I generally prefer to support runtime M-V-VM approaches to large Silverlight projects, so I usually create a Model representing my language resource. Since I am also VERY lazy when it comes to repetitive labor, I have created a spreadsheet in Excel where I simply copy everything from the Visual Studio resource editor of the localization.resx file into my spreadsheet which creates the properties and declarations that I can then use for binding (I use a three letter category designator, a single underscore and then a meaningful name - you can modify as you need). I have included it here [CreateDeclarationsAndProperties.xls (434.00 kb] if you like this approach, it is certainly NOT required. But this approach means you can then use XAML binding instead of the hard-coded approach, i.e. ...="{Binding Address}" where the DataContext is the localization model.
NOTE: As a best practice, I generally prefer when writing applications that I know will be localized to add a lower case z in front of all user-facing text, i.e. zAddress. This forces me to remember to localize such text before general release.
4.) Get translations. Now if you are like me, you know that machine translations are a poor substitute and that you cannot release your application into the wild using such translations. However, since true translations can take time, and you might like to get a sense of how the application appears in the language as you are designing it, using machine translation can make this very easy. I thus wrote a quick utility to call Google translate to do the hard work for me. Although it is NOT required, it can quickly illustrate how your application will appear in the specified language.
Subscribe