| Comments

One of the announcements that happened during the MIX10 conference was the availability of the V2 of the Microsoft Translator API.  This is the engine that powers the translation behind http://www.bing.com/translate and some other Bing-related properties as well.  A lot of research has gone into the engine from Microsoft Research and others.  Language translation isn’t an easy task especially taking into consideration cultural significance of words, etc.  I have heard that the most challenging in machine translation is to Asian languages.  I will admit to not speaking any of them, so I don’t know how well we are performing here – you’ll have to let that team know if they are doing well.

After reading the announcement and working on my translate plugin for the new Seesmic Desktop Platform, I noticed that there was a Speak API.  After reading I saw this literally translates text to a WAV file for platback.  Pretty cool I thought.  I wanted to play around with this in Silverlight so created a simple application to do so:

Microsoft Translator in Silverlight

The Speak translation isn’t available for all the Translator languages (currently 30 languages for text language translation) but does support seven (7) languages: English, German, Spanish, French, Italian, Portuguese, and Russian.  So how is Silverlight talking back to you?

The Translator API comes in 3 flavors: SOAP, HTTP and Ajax.  Now I could have used the SOAP version and used Add Service Reference but I felt for what I was doing this was overkill.  The SOAP API doesn’t return me back super-strongly typed objects, so I saw little value in doing that over the REST-based HTTP methods which I decided to use.  The code is relatively simple.  I first want to translate the text input into the selected language, then pass the translated text to the Speak API and play the results in a MediaElement.

First, we use the Translate method and a WebClient call to accomplish this:

   1: private void TranslateTextToAudio(object sender, RoutedEventArgs e)
   2: {
   3:     if (Languages.SelectedIndex < 0)
   4:     {
   5:         MessageBox.Show("Please select a language first...");
   6:         return;
   7:     }
   8:     WebClient client = new WebClient();
   9:     client.OpenReadCompleted += ((s, args) =>
  10:         {
  11:             if (args.Error == null)
  12:             {
  13:                 DataContractSerializer des = new DataContractSerializer(typeof(string));
  14:                 string responseText = des.ReadObject(args.Result) as string;
  15:                 SpeakIt(responseText);
  16:             }
  17:         });
  18:     client.OpenReadAsync(new Uri(string.Format(TRANSLATE_URI, _appId, HttpUtility.UrlEncode(TextToTranslate.Text), Languages.SelectedValue.ToString(), _currentLang)));
  19: }

Notice the DataContractSerializer use here.  The HTTP API returns serialized objects, so you’ll want to use this method here to deserialize to make it easier.

After we have the translated text, we pass that to the Speak API (notice the call to SpeakIt above) which returns a Stream that is an audio/wav format.   We know that Silverlight’s MediaElement cannot directly play lossless WAV format.  But luckily there is a MediaStreamSource API that enables us to essentially write our own decoders for audio/video.  One of the Silverlight team members, Gilles, created a WAV MediaStreamSource for us to use.  After having that and not worrying about decoding, I could create a new WaveMediaStreamSource with my result Stream and set that as the Source for the MediaElement – here is the resulting SpeakIt() method (TranslatedPlayback is the name of my MediaElement in the application):

   1: private void SpeakIt(string responseText)
   2: {
   3:     WebClient client = new WebClient();
   4:     client.OpenReadCompleted += ((s, args) =>
   5:     {
   6:         if (args.Error == null)
   7:         {
   8:             WaveMediaStreamSource mss = new WaveMediaStreamSource(args.Result);
   9:             TranslatedPlayback.SetSource(mss);
  10:         }
  11:     });
  12:     client.OpenReadAsync(new Uri(string.Format(SPEAK_URI, _appId, responseText, Languages.SelectedValue)));
  13: }

That’s it!  It’s pretty cool (bonus points to you in identifying the obvious pre-filled text being used in my sample).

I’ve almost completed my Seesmic plugin and using the Translator API has made it easier.  I’ve found that a simple wrapper to the HTTP-based methods is going to make things easier for people to use, so I’ve created a Translator Client for Silverlight that I’ll be releasing once I can complete the plugin (waiting on a few things).  This will make it easier for Silverlight developers to quickly consume the API for text and Speech translation.

The code (C#) for the above sample is here: MSTranslatorSilverlightSample.zip.  You will need a Translator Application ID key to run it yourself (put it in the App.xaml resources).  If you just want to see it running really quick, you can view it here: Speak Translator for Silverlight.  You will need Silverlight 4 RC to run the sample.

NOTE: The Translator API actually doesn’t need Silverlight 4, but I just created the app using that base.

Hope this helps!

| Comments

While I was at the Silverlight Atlanta Firestarter event I had a chance to meet some great people.  One of them was Sergey Barskiy.  Sergey was doing a session on deployment and while in the speaker area we were chatting about overall feedback on Silverlight.  One of the things he mentioned was what he thought was a bug in Visual Studio Tools for Silverlight.  It was around RESX files and the modifier setting (Internal, Public, etc.).  More on that later.  Sergey was using RESX files for localization.  While investigating the bug for him, I realized how many people might not know how to do some simple string localization/binding in their Silverlight applications.  It’s relatively simple and I thought I’d outline the steps.  I must admit that I’ve never had to develop a full-fledged internationalized application before, and I applaud those who have and have tackled both the obvious of the language localization challenges as well as cultural and display challenges with various technologies.

The Sample Application

For this experiement we’ll keep it simple and we’re talking about String localization.  We are going to work with a Silverlight 3 application in simple form which will have a TextBlock and a Button control which will have their respective Text and Content settings.  Here’s the English-US (en-US) version of the app:

Sample application image

If we were like most applications we’d be done…but this post will try not to be so US-centric :-).

Step 1: Adding default String resources

As a best practice for String resource localization, in your Silverlight application structure, organize your resource files accordingly.  We’re going to use the RESX file approach and let the framework do most of the work for us.  To that regard in my application I have created a folder called Resources and will be placing my RESX files there.  I’ll first add the default set of data, adding a new RESX file named Strings.resx.

When you add this you’ll notice you get a Strings.resx and a designer (cs or vb) file.  By default the Resource Designer will open and we’ll add two values: WelcomeMessage and ButtonMessage.  Our surface looks like this:

Visual Studio resource designer

Notice the Access Modifier section in the designer.  We need to set this to Public in order to use it in binding we will do later, so set it now.  We save this and step one is done.  Let’s test it out and use it.

Step 2: Binding our RESX files to our XAML

Now that we have a Strings.resx file (which is marked as Embedded Resource by default) in our Resources folder, we can use it as a resource in our XAML.  We need to do a few things to enable this.  First, we need to add an XML namespace to our XAML page.  I’ve chosen local for mine, but choose whatever.  We will have this namespace point to our Resources namespace in our application.  Mine looks something like this:

   1: xmlns:local="clr-namespace:StringLocalization.Resources"

Now I can use that assembly classes in my XAML.  I’ll add the Strings class to my UserControl’s Resources section giving it a key of LocStrings like this:

   1: <UserControl.Resources>
   2:     <local:Strings x:Key="LocStrings" />
   3: </UserControl.Resources>

And now I have a XAML resource I can bind to.  Let’s do that.

Step 3: Binding to the resx file data

My XAML has a TextBlock and a Button I want to bind to the string values.  Because I have a XAML resource this is simple and I just create a binding using the the XAML binding syntax to that resource.  here’s what my TextBlock and Button look like (relevant portions):

   1: <TextBlock Text="{Binding Source={StaticResource LocStrings}, Path=WelcomeMessage}" />
   2: <Button Content="{Binding Source={StaticResource LocStrings}, Path=ButtonMessage}" />

Notice that I’m using a Path that points to the String name in the RESX file.  Let’s run the application now and we should see what we’re looking for right?

WRONG.  Here’s the bug that Sergey was talking about.  It turns out that there does seem to be a bug in Visual Studio with regard to the modifier, and more specifically the PublicResXFileCodeGenerator custom tool that is used to generate the code.  It turns everything in the resource to public except the constructor.  Not having the constructor public (it is still marked internal) is what is causing our problem. 

NOTE: This is not a bug in Silverlight or in the Silverlight tools, but more widely in Visual Studio.  The same thing reproduces on any VS project type.  It’s been noted and is being tracked to address.  See this topic:

What we have to do as a workaround is to go into the Strings.designer.cs file manually and change the constructor from internal to public.  I will note that each time you open up the designer for that main resource file that it may get reset to internal, so remember that. 

After changing to public you can run the application and get the desired output.  There is actually a way to still use the resources and keep the constructor internal, but it involves using another class you have to create and instantiate…more on that later.

Step 4: Adding additional localized resources

Now that we have our base working, we simply need to provide the localized resources for our application.  I’m choosing to localize in Spanish (es-es), French (fr-FR), German (de-DE) and Japanese (ja-JP). 

I solicited some help on Twitter to get some “human” translation to double-check my translated text with Windows Live Translator.  To my surprise, Windows Live Translator actually did a great job.  I think with short sentences it is fine, but longer conversational text may lose context.

Thanks to: Ken Azuma, Othmane Rahmouni, Talya, Misael Ntirushwa, Hannes Preishuber, and others who jumped in to offer help for my little sample.

To do this we simply add more resource files into our project following a specific naming scheme.  Since we have Strings.resx when we add additional languages we’ll add them as Strings.<locale>.resx.  So adding German would be Strings.de-DE.resx and so forth.  It really is best to use the xx-xx locale settings versus just the two character (i.e., de) ones.  Note when you add these files to the project that your modifier section in the resource designer should say No Code Generation automatically.  If it doesn’t, choose that option.  We only need the code for our default language choice.  When I’m done my structure looks like this:

Project structure with localized string resx files

Obviously the contents of the file contains the localized string information.  Note that the string parameter names still have to match.  So even though I’m localizing the contents of WelcomeMessage, in the German resource the parameter is WelcomeMessage and not Wilkommen or something like that.

UPDATE: Forgot one critical step – oops.  You have to manually edit your **proj (csproj/vbproj) file for your Silverlight project to add the locales in the SupportedCultures node of the proj file.  This is a manual step (and sucks), but don’t forget it or nothing will work as you suspect.

Step 5: Testing it out.

Because we used our declarative binding in Steps 2-3, we don’t have to change our code.  We should test it out to make sure it works though.  There are two good ways I have found to test this out.  First, the Silverlight plugin supports forcing a UICulture and we could do it that way.  Let’s test German.  In our plugin instantiation on our hosting page we’ll add these two parameters to the <object> tag (relevant portions):

   1: <object ...>
   2:     ...
   3:     <param name="culture" value="de-de" />
   4:     <param name="uiculture" value="de-de" />
   5:     ...
   6: </object>

That tells the plugin to load with those cultures set.  You can change them without recompiling your application and the language will change.

A second option would be to actually change the display language of your Windows environment.  For some this may be a little frightening as your screen suddenly may change to a language you don’t understand natively.  I recommend if you go this route to keep a translation dictionary handy find your way back (you have to logoff/logon to change a display language)!

Either way when you run the application using either of these methods you should get what you expect.  Here’s my German output:

German localized sample application

Obviously it is easier to test using the <param> approach (changing display languages in Windows requires a logoff), but ultimately I recommend doing actual OS display language for verification.  If a user is on a language culture that you have not localized, it will use the default values provided in our initial Strings.resx file.

Another option for testing is that you can actually change the culture and UICulture values using the Thread namespace APIs in Silverlight.  Keep in mind though changing these values on the CurrentThread does *not* reload the default resource, so you’d have to do some additional code to get the resource to load using that new culture setting.

Caveats and cultural differences

One thing to note is that while your application may now have an easy ability to display localized string data with simple bindings, it may not always be appropriate.  Take for instance Japanese language translation (I’ll assume it is roughly translated correctly, but for the sake of this discussion this serves a purpose) of “Click here” for the button.  In English it fits fine in our lovely world of fixed width button sizes.  But look at the Japanese translation of the text:


And here’s how it looks in the button:

Japanese localized sample output

Notice that we don’t see all of the characters?!  These are things that you’ll have to understand when things seem simple enough.  Sometimes translated strings will be longer/shorter than your intended design.  Designing around a localized approach will have to consider these in advance.  In fact, for some languages you may have an alternate placement of controls even to accommodate the culture.

As I noted that I used machine translation for my sample here, but I do want to stress that I think respecting cultural differences is important in customer facing applications.  Using something like Windows Live Translator seems simple enough and might work in simple instances, but I would recommend hiring true localization resources/people to help you differentiate the subtle differences in languages.

Public modifier workaround and dynamically setting the culture

As I mentioned above there is a workaround to the internal/public modifier bug.  It is easy enough to change of course, but you may want to look at this approach as well…and in some implementations this may fit within your model better.  The idea is to provide your own class implementation access to the Strings resource.  Here’s an example of what my custom class implementation might look like:

   1: public class CustomResources : INotifyPropertyChanged
   2: {
   3:     private static StringLocalization.Resources.Strings _strings = new StringLocalization.Resources.Strings();
   4:     public StringLocalization.Resources.Strings LocalizedStrings
   5:     {
   6:         get { return _strings; }
   7:         set { OnPropertyChanged("LocalizedStrings"); }
   8:     }
  10:     #region INotifyPropertyChanged Members
  12:     public event PropertyChangedEventHandler PropertyChanged;
  14:     private void OnPropertyChanged(string propertyName)
  15:     {
  16:         if (PropertyChanged != null)
  17:         {
  18:             PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
  19:         }
  20:     }
  21:     #endregion
  22: }

And then my resource section would look like this:

   1: <UserControl.Resources>
   2:     <localCustom:CustomResources x:Key="CustomLocStrings" />
   3: </UserControl.Resources>

And my binding would look like:

   1: <TextBlock Text="{Binding Source={StaticResource CustomLocStrings}, Path=LocalizedStrings.WelcomeMessage}" />
   2: <Button Content="{Binding Source={StaticResource CustomLocStrings}, Path=LocalizedStrings.ButtonMessage}" />

Now that I have this in place like this I get around the internal modifier issue because I’m actually binding to an instance of my own class (which has a static instance to the Strings resource class).  Using this method I could dynamically change the culture on the fly as well by resetting the culture settings in the thread and resetting the resource.

   1: ComboBoxItem item = ChangeLog.SelectedItem as ComboBoxItem;
   2: Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo(item.Content.ToString());
   3: Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo(item.Content.ToString());
   4: ((CustomResources)this.Resources["CustomLocStrings"]).LocalizedStrings = new StringLocalization.Resources.Strings();

A bit of a workaround for most scenarios I think.  I think probably remembering to change the modifier may work best for most cases, but this custom instance class might actually fit better into some model implementations.


Hopefully you can see that for simple string resources the technical implementation is fairly simple.  The real challenge is to you, the developer, to ensure the cultural integrity of the message is being displayed appropriately.  Localization is not an overall easy task and I’m simplifying it to simple strings here.  As I stated above, I applaud those who have successfully implemented fully localized applications.  It can be as simple as a button label or as complex as alternate screen layouts for different cultures!

You can download the code for this post here: StringLocalization.zip

Hope this helps!

This work is licensed under a Creative Commons Attribution By license.

| Comments

One thing that I’m just as guilty as probably most of some of my peers is creating US-centric applications.  Forgetting to think globally for your users is something that I think happens too often.  We operate in our US-centric worlds and forget that sometimes even the simplest things can make a difference.

Take for instance, honoring your user’s culture settings (region/locale/whatever you want to call it).  Even if you have a US-based application for a US-company, how do you know that a user might not be of French origin and still perhaps like to view their operating system information in French settings, so they change their culture.

Luckily in some areas this is simple to do, and for Silverlight applications you can let the platform do some of the work for you.  I’ll take a simple example of currency settings.  A colleague of mine was asking about currency formatting in his Silverlight application with regard to data binding.  He sent me a note asking why his formatter didn’t work.  He asked me why:

   1: ConverterParameter={0:$##.00}

As it turns out, it was just something missing in his implementing of a custom converter in his application.  But I let him know that he should really use {0:c} and let the platform do the work.  Let’s look at a simple example of an employee and their salary.  If we data bind this information to a DataGrid using the above formatter here is what we might get:

Makes sense right, looks fine.  Now let’s change the regional settings on my machine to French (France):

Hmm…what happened here.  Well the problem is we forced the format.  Let’s change the format parameter to {0:c} and keep French as our settings and see:

Ah, now that makes sense.  You see we can let our platform do the work and Silverlight is aware of how to use culture settings to honor currency, dates, etc. – here’s the default Calendar with French settings:

Now ideally in our sample with salaries above a literal visual translation probably isn’t accurate (by that I mean USD $1 is not the same as 1 Euro right now in translation.  We could add some custom logic though and get this output based on culture settings:

So be mindful of your applications and look for ways you can reliably and meaningfully add value to your global end users.  Don’t force a format unless you absolutely have to.