Some Thoughts on Initializing Silverlight Culture Properties

  • Article

In his post Introducing xml:lang in XAML Mike Hedley discussed how that property plays an important role in linguistic services on WPF and Silverlight. If there is one take-away, it is that allowing it to default to "en-US" could have unintended consequences, to the point of severely limiting your application’s usefulness for non-English speaking users, especially in East Asia. 

But what about the other culture properties that Silverlight exposes at initialization time? How should these be handled?

Let’s take a moment – or, rather this week’s post -- to examine this question. But first, the basics:

Silverlight’s CurrentUICulture and the uiculture initialization parameter

 A web application may determine how to establish a session’s UI language in a variety of ways – from following the browser accept language, to language selection menus or dialogs, to redirection to language specific sites, etc. However this is determined by the web application, Silverlight provides an <object> parameter uiculture which allows the resolved UI language name to be passed into Silverlight at initialization. This establishes the CurrentUICulture which, consistent with other .NET application environments such as ASP.NET, WPF, etc., informs the Resource Manager to look up localized resources specific to that culture (and if not found to “fallback” to related cultures) at run time.

Silverlight’s CurrentCulture and the culture initialization parameter

In Silverlight, again as in other .NET environments, there is a separate CurrentCulture – the CultureInfo instance associated with the current thread whose properties are used for data formats, calendars, linguistic collation, etc. Consistent with this model, there is a separate parameter culture on the Silverlight <object> tag allowing for initialization on runtime startup.

To default, or not to default….
Consider letting your application’s CurrentCulture property default to client OS settings

 Since Silverlight executes on the client (the Browser’s host Operating System), it is able to take advantage of the current, specific client-side OS locale and its formats -- including user overrides of these, such as user entered format of a DateTime. Silverlight developers should consider allowing this property to default to the client settings such as in the following example:  

 

    <object data="data:application/x-silverlight-2," ... >
...
<!-- \ar\myapp.resources.dll in .xap -->
<param name="uiculture" value="ar"/>

        <!-- OS locale ar-SA, ar-EG, en-NZ,etc. ... -->
<param name="culture" value="auto"/>
...

In this example, we can assume that the web application has made the determination to provide UI in the Arabic language. In response, it has generated a page containing the Silverlight plug-in referencing a .xap (not shown). The referenced .xap contains (the main application assembly, etc. and) a satellite resource assembly containing Arabic resources. By setting the uiculture value to exactly match the delivered satellite assembly culture property, resource loading involves no fallback and is efficient.   

 As an aside, note that specific cultures – those with regional identification -- could alternately have been used in the uiculture parameter:

        <!-- \ar-SA\myapp.resources.dll in .xap -->
<param name="uiculture" value="ar-SA"/>

 For the culture parameter the value "auto" informs the Silverlight runtime to default the CurrentCulture to the OS locale. Likewise, and for the sake of efficiency, the parameter could be removed to the same effect. In either case, the current OS locale will be picked up by the Silverlight runtime which will synthesize a CultureInfo object.
  

 Why does picking up a few end-user properties matter?   

 Well, it should be further noted that defaulting will not only synthesize a CultureInfo object containing over-rides of the formatted properties as mentioned above. But, it will also provide support for completely custom locales installed on the client OS. Although operating systems provide a significant number of out-of-box locales, the number is relatively small compared to the languages and regions in the world. Custom locales provide a solution to address this gap. By defaulting the culture parameter, Silverlight can provide support for cultures whose names are not known at design or web application deployment time, but, nevertheless, will be picked up just-in-time for a given client session. 

But even in the case where it is just one property, there can be good reasons for a given format to be overridden for an out-of-box culture. E.g., consider the case where a format has recently been changed by a government authority, but the OS data update is not yet available. Or, there may be institutional consistency reasons for an administratively effected change to a particular format. In short, developers should take care to respect the OS locale whenever possible.

 On the other hand….
There are some cases where you should consider not defaulting culture

  • In a multilingual Kiosk application, where the OS locale is not a good indicator the end-user’s cultural preference, you may want to derive the appropriate specific culture value from a UI language selection.

 

  • In web applications where Silverlight is presenting culturally formatted data alongside other similarly formatted web content, e.g. culturally formatted dates or numbers. In the interest of application-wide format consistency, you may want to set the culture to be consistent with the non-Silverlight served portions of web application UI. 

 

With these guidelines in mind, may you have further success in your programming for the world.

Happy Coding! 

 ~Team GDX

Post Script:
A general caveat when explicitly setting culture values

If you do choose to explicitly set culture values for culture or uiculture, note that if the culture is not available on the local OS that you may receive a runtime error (code: 2105, category: InitializeError). This may be more likely to occur on Windows XP when East Asian or Complex Script language support is not installed on the system and a culture name from these language families is explicitly passed to Silverlight. (See “Supplemental Language support” in the XP “Regional and Language Options” Control Panel applet). You can choose to handle this in the <object> ’s onError handler when explicitly setting culture or uiculture values.    

An alternative approach to consider is to simply allow Silverlight to default to "auto" for both values, but pass in your intended culture values by using custom initParams. Once Silverlight is running, you can set the current Thread’s CurrentCulture and/or CurrentUICulture via assignment of a new CultureInfo object(s) based on your culture values. This can provide you with an opportunity for handling of the Exception thrown from the CultureInfo’s constructor within your managed code. In any case, should your Silverlight application allow arbitrary culture names to be passed into Silverlight – such as East Asian names when targeting Windows XP -- please be aware of this behavior and remember to code defensively.