Wednesday, April 6, 2011

WP7 Localization Explained

I believe you are going to create a new Windows Phone Application to follow me in this article.
I’ll assume you understand that everything that applies for a language, also applies for the language-Culture.
I.e. you can use “en” for English or “en-UK” for English and United Kingdom culture.
The language will affect the translation and what’s written in the resource files will be used for that sake, and the culture will affect the formats of date, currency…etc.

Step 1 – Add Resource Files:
Anyone who has brief experience with localization in .net, will guess the first step.
You have to add a Resource file for each language you need to use in your application.
You should have a file for the default language and others for each other language used, having the same name as the default language file but with a small extension using each language abbreviation.
Let’s say I’m going to support English (default) and Italian. Then I should end up having something like:


If it’s your first time to use a resource file, this is added from: Project (right click) => Add => New Item => (pick Resource File).
- Needless to say, when you fill the resource files, the Name of each resource should match, and only the value should reflect the translation.
- So say I’m going to have (Hello/Hello) & (Hello/Ciao) as the English & Italian (Name/Value)s.

Step 2 – Declare the Languages you support:
We should tell the application which languages we are supporting. Guess it’s not smart enough to figure this out by itself.
And for this you we’ll have to close the project/solution. Then open the project file in notepad, and add the supported languages (except the default one) in the supported cultures tag, using semi-colon as a separator, as follows:
<SupportedCultures>it;</SupportedCultures>You’ll also need to define the default language in case the user is using a language you don’t support, and thus the default language should be used then.
For that you need to go to the Project Properties => Application (Tab) => Assembly Information (button) => Set the (Neutral Language).

Step 3 – Use Resource-File in code behind:
Let’s see if this is going to work.
In the MainPage.xaml.cs, I’ll write the following in the CTor of the page.
PageTitle.Text = MyResources.Hello;
Step 4 – Test:
Now you can test this on a device, and it should display the “Ciao” if you went to the phone settings and set “Italiano” as the display language.
But the Emulator won’t let you change the “Display Language”, so if you want to test this in the Emulator, you will have to set the language-culture in code. (Just for testing).
So go the App.xaml.cs and write the following in CTor or in the Launching event handler.
Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("it");You may also add the following if you are testing the culture (format of dates, currencies…etc.)
Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("it");** Don’t forget to remove these when you finish testing.
Now you should see the localization working. I hate to say it but that’s not the end of it.

Now you can change the display language in the emulator, all you have to do is to click on the: "tap here to accept changes and restart your phone." link, which appears when you select a different Display Language.
Still this might be consume more time than applying the change in code.

Step 5 – Access the Resource Files in XAML:
To use the resource files in XAML, you need to map them to a Static Resource, to able to bind to them.
Say you have a TextBlock as follows.
<TextBlock Name="textBlock1" Text="Hello">And instead of hardcoding the Text, we want to use the resource files. In other words we want to bind the Text property of the TextBlock to the appropriate key/property of the resource files.
We will go and define the generated Resource class as a static resource in the App.xaml, as follows:
<local:MyResources xmlns:local ="clr-namespace:MyNamespace" x:Key="AnyGivenKey" />
Please make sure you replace MyNamespace with the namespace under which MyResources is defined.
If you try to run the application now the following exception will blow right in your face:
AG_E_PARSER_UNKNOWN_TYPE [Line: 10 Position: 65]
Of type: System.Windows.Markup.XamlParseException
This issue has been reported here:

That’s because the class generated for the resource file was marked internal, and to access it from the XAML we need it to be public.
If you open each of the resx files, you will find an option in the toolbar to change the access modifier.
This should change the access modifier of the classes, but we still need to change the access modifier of the CTor. So you will have to open the default language resx.cs file, and look for the CTor and change the internal to public.

Now the application can run safely without weird exceptions.
And now it’s safe to go back to the TextBlock and change it to the following to use the Static Resource we just defined in the App.xaml:
<TextBlock Name="textBlock1" Text="{Binding Path=Hello, Source={StaticResource AnyGivenKey}}"/>That’s all? You wish…
The problem now is: whenever you add extra resources to the resource files, the resx.cs class is re-generated and the modifier of the CTor gets set back to internal. So if you are happy with manually changing it each time you add a new resource and build your application, then you are done.
If it’s cumbersome tedious thing to manage, then we need to find another solution.

Step 5.2 – Access the Resource Files in XAML:
To overcome this internal access modifier thing, we will create a class that wraps the generated resources class, and use that as our static resource in the App.xaml, as follows:
public class MyResourcesWrapper
public MyResourcesWrapper()

private static MyResources _myWrappedResources = new MyResources();

public MyResources MyWrappedResources { get { return _myWrappedResources; } }
And then our TextBlock should be changed to:
<TextBlock Name="textBlock1" Text="{Binding Path=MyWrappedResources.Hello, Source={StaticResource AnyGivenKey}}"/>You will need to modify the Resource definition in the App.xaml into the following:
<local:MyResourcesWrapper xmlns:local ="clr-namespace:MyNamespace" x:Key="AnyGivenKey" />

One extra step to go (if you need to localize the application bar).

Step 6 – Localizing the ApplicationBar:
The application bar is not growing out of the Silverlight, it’s a shell system tray.
So using the binding method in the xaml file won’t work.
We will have to add items to the application bar in the code behind and set the required localized text as we’ve done earlier in step 3.
<shell:ApplicationBar IsVisible="True" IsMenuEnabled="True">

ApplicationBar = new ApplicationBar();

var appBarButton = new ApplicationBarIconButton(new Uri("/Images/appbar_button1.png", UriKind.Relative));
appBarButton.Text = MyResources.Hello;

var appBarMenuItem = new ApplicationBarMenuItem(MyResources.Hello);


How to: Build a Localized Application for Windows Phone:
CultureInfo Class:
Extra link for the WP7 toolkit controls:


Anonymous said...

Hi - I am really delighted to find this. Good job!

Emanuel Mendez said...

Hello. Good article! I was wondering if you can give me some advice regarding the following situation:

I am developing a WP7 app that has a radio button group to change the language app from English to Spanish and viceversa. On the Radio Button Group event, I set the Thread culture depending of the option chose. My problem is that even though I change the main thread culture, the changes are not reflected until I load again the page. Furthermore, every page on the "Back" stack does not reflect the chances, since they are already loaded.

Thanks in advance.

Walaa M Atef said...

Hi Emanuel,

Apps should be localized according to the culture of the device.

Second best is to let the user select the language on the first page of the application.

Otherwise you'd better store his choice and ask him to close the app and restart it again.

Other than that, I can only imagine a dirty hack of loading resources dynamically on each page which happens after checking the current culture stored some where globally, and having this called on the OnNavigatedTo() of each page.
Still not sure if this would work.

So better to stay away of it. And keep it as simple as possible.