Showing posts with label Localization. Show all posts
Showing posts with label Localization. Show all posts

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:

MyResources.resx
MyResources.it.resx

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.

(UPDATE)
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:
<Application.Resources>
<local:MyResources xmlns:local ="clr-namespace:MyNamespace" x:Key="AnyGivenKey" />
</Application.Resources>
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: http://connect.microsoft.com/VisualStudio/feedback/details/628281/silverlight-wp7-resource-files-and-binding

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:
<Application.Resources>
<local:MyResourcesWrapper xmlns:local ="clr-namespace:MyNamespace" x:Key="AnyGivenKey" />
</Application.Resources>

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.
e.g.
MainPage.xaml
<phone:PhoneApplicationPage.ApplicationBar>
<shell:ApplicationBar IsVisible="True" IsMenuEnabled="True">
</shell:ApplicationBar>
</phone:PhoneApplicationPage.ApplicationBar>
MainPage.xaml.cs

ApplicationBar = new ApplicationBar();

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

var appBarMenuItem = new ApplicationBarMenuItem(MyResources.Hello);
ApplicationBar.MenuItems.Add(appBarMenuItem);

References:

How to: Build a Localized Application for Windows Phone:
http://msdn.microsoft.com/en-us/library/ff637520%28v=VS.92%29.aspx
CultureInfo Class:
http://msdn.microsoft.com/en-us/library/system.globalization.cultureinfo(VS.95).aspx
Extra link for the WP7 toolkit controls:
http://blogs.msdn.com/b/delay/archive/2010/12/20/quot-and-she-d-say-can-you-see-what-i-m-saying-quot-how-to-localize-a-windows-phone-7-application-that-uses-the-windows-phone-toolkit-into-different-languages.aspx

Sunday, July 5, 2009

Localization with MasterPages - The Final Cut

I'll try to be short and to the point. You may skip all the following text description and go ahead to the code example.

Intro:
Assuming you want your ASP.NET website/web application to have a multi-lingual interface. You'll find multiple resources on the internet on how to use LocalResources files or GlobalResources files to store specific language's data.
Nice Video Tour for Localization.
A specific language resource would be loaded according to the user's browser language preferences.
But most probably you'll need to give the user the option to switch between languages on the fly without going to the browser's preferences....makes sense.

Questions:

1- Where to store user language preference?
Some suggest using a Session variable to store the language preference across the pages. But shouldn't you be storing this for future uses?
Some suggest using a Cookie, but this will be browser specific and/or a machine specific.
IMHO, it would be perfect if the site can remember a user preference regardless of the browser or machine he uses to sign in. That's why storing it in the database might sound like the best option, and I use ASP.NET Profile for that.

Btw, Profile usage is not as easy to use in a Web-Application project as it is in a WebSite project, as no custom class gets created to hold your profile properties defined in the web.config. Please check the code below to know how to manage Profile properties in a Web-Application.

2- How to switch it on the fly?
Simply by setting 2 properties: CurrentThread.CurrentUICulture & CurrentThread.CurrentCulture

3- But where to set them?
Basic answer is to override the InitializeCulture() method on each and every page in your application....not the smartest thing to do.
Another suggestion is to let all your pages inherit from a BasePage class which in turn inherits from the Page class, and there you override the InitializeCulture() method.
The problem is that InitializeCulture() method is never called on cached pages. Ref: InitializeCulture and caching don't mix

I'm using a MasterPage, can I do this in the code behind of the MasterPage.... The answer is a striking NO. The MasterPage doesn't inherit from the Page class, and it has no idea what InitializeCulture() is.

If we want a global location to set the culture, then why not using the Global.asax class to set the culture in one of the events declared there.
That's why many people who don't like to use the BasePage approach sugests using the
Application_BeginRequest() as a good location for this code.
Good point, only that the Profile won't be read at this point, yet... so what's now.
The answer is: Application_PreRequestHandlerExecute(). It's not there by default, you should add it yourself.

Code example (might have a room for refactoring):
Here I use a couple of buttons on the master page for switching the language on the fly, you may use whatever approach you want to use.

public partial class Main : System.Web.UI.MasterPage
{
protected void English_Click(object sender, EventArgs e)
{
SwitchCulture("en-Us");
}
protected void Arabic_Click(object sender, EventArgs e)
{
SwitchCulture("ar-Eg");
}
private void SwitchCulture(string culture)
{
CultureHelper.SaveCulture(culture);
Response.Redirect(Request.Url.AbsolutePath);
}
}

As said before thie event is not there by default when you add the Global class to your application.

public class Global : System.Web.HttpApplication
{
protected void Application_PreRequestHandlerExecute(Object sender, EventArgs e)
{
CultureHelper.SetCulture();
}
}

I created a class to encapsulate the culture manipulation.

public class CultureHelper
{
public static void SaveCulture(string culture)
{
HttpContext.Current.Profile.SetPropertyValue("Culture", culture);
}
public static void SetCulture()
{
var culture = GetCulture();
if(string.IsNullOrEmpty(culture))
return;
var cultureInfo = new CultureInfo(culture);
Thread.CurrentThread.CurrentUICulture = cultureInfo;
Thread.CurrentThread.CurrentCulture = cultureInfo;
}
private static string GetCulture()
{
var culture = string.Empty;
if (HttpContext.Current.Profile != null)
{
culture = (string) HttpContext.Current.Profile.GetPropertyValue("Culture");
}
return culture;
}

And don't forget the Profile property definition in the web.config

[system.web]
[anonymousIdentification enabled="true"/]
[profile]
[properties]
[add name="Culture" allowAnonymous="true" defaultValue="Auto" type="string"/]
[/properties]
[/profile]
...
[/system.web]