Localisation of Silverlight projects after completion (Part 1 of 3)

So, you’ve created a Silverlight app for you client… It was so well received they now want to take it global!

Before you start shouting hooray, the question you need to ask yourself is “did you take localisation into account when you created the application?”

If your project had a typical short time-frame and small budget, then the answer is “probably not”. At this point you might be starting to sweat a little as you just know they are going to ask you “how long will it take to add new languages?“.

Options:

  1. Create multiple version of the application (so many downsides how dare you even consider it?).
  2. Use language specific resource files for different assets (one per page, per locale).
  3. Fetch and replace the strings using code-behind (and lots of code).
  4. Some combination of 2 and 3, usually involving very (very) long binding expressions to fetch values.
  5. Using simpler bindings and using the application resource dictionaries for storage.
  6. Something new

After looking at the available options in Silverlight, against the requirements of localisation for our project (which I am betting are similar for most Silverlight projects), I came to the conclusion that most publicised methods for Silverlight localisation were too weighty.

Option 5 (simpler bindings) was initially the preferred option and it worked something like this:

  • Use a binding like Text={Binding L_MainMenuTitle}.
  • Insert a dictionary item, of type System.String, under the key L_MainMenuTitle.
  • Manage language changes by simply deleting and replacing name/key entries in the application resource dictionary.

I should point out that the above solution does work, and it works well, but it has some deficiencies:

  • The developer is required to insert [generally] unreadable keys into binding expressions.
  • The developer must manage the adding of new strings to the language database/files.
  • It is intrinsically difficult to track usage of any given key value throughout a large project.

Our final solution (something completely new)

The requirements for localisation of your Silverlight project may run something like this:

  • You want the translated strings to be stored in a centralised location for easy of translation and maintenance.
  • You only need one language at a time to be visible.
  • You only want to download to the client the selected language.
  • You probably would not want to change the current language while in the middle of a critical operation (like form entry).
  • You want to make it easy for the developer to add new strings without worrying about maintaining a database.
  • You want to make it easy for localisation testers to edit and view changes inside the running application.

- “Centralised” and selectable, in a Silverlight application, straight away says server database and RIA services to me.

- Not requiring an instantaneous update negates the huge overhead of every string being a bindable INotifyPropertyChange property.

- Making it easy for the developer implies some form of automation, or integration, with the pages and project is required.

So how does it work? What magic did we perform to meet all the requirements above (and then some)? Stay tuned for part 2 coming soon.

Microsoft Prism 4 hits second Beta

Things are heating up… The second Beta (drop 10) of Prism was released today. We are just awaiting to final release of Prism V4 in the next month or so.

The basic premise of Prism is one of divide and conquer. The divide is cleverly performed by using loose coupling of modules (in English that means that modules know little if anything about each other).

Prism includes a practice referred to as Unity. The Unity container is responsible for providing interfaces to modules and objects on request and acts as the central port of call that modules use to communicate with other modules.

There is a very good set of videos giving examples of Prism on the Channel 9 site here.

The latest version combines a second practice known as MEF (Managed Extensibility Framework). This is another Microsoft produced open source project. MEF uses clever techniques to identify requirements in projects, at runtime, by analysing “import” and “export” directives that exist only in the Metadata of the project. MEF is designed to allow for a plug-in style environment, like the Visual Studio IDE.

We are now using Prism and MEF on a medium to large scale project that is expected to have a lifespan of many years.

We will post updates on techniques as we progress on the project. I must say it’s good to be back on hard-core Silverlight development after a spell of APS.Net development.

Thanks, Dave

Deep Deep Zoom – Let’s take the red pill and see…

Below is a first experiment using DeepZoom with Silverlight 4 to see what setting are needed to host one in a WordPress Silverlight app.

Install Microsoft Silverlight

The key was to set the InitiParams to “path=DeepZoom/GeneratedImages/dzc_output.xml” so the full plugin setting for this one is (in square brackets):

silverlight: DeepZoom/DeepZoomProject.xap, 480, 300, path=DeepZoom/GeneratedImages/dzc_output.xml

If you follow the right eye of Koala (his right, your left), then the eye of the left Penguin (your left) you can see how deep the rabbit hole goes.

Easing into Silverlight animation – Announcing www.easing.co

After asking a specific question about easing functions on StackOverflow.com I received a comment from user AnthonyWJones. It occurred to me that a lot of people must have the same problem. That is: How to choose an appropriate Easing Function for a given visual effect.

The range of Easing Functions is currently only 33, but most have properties to allow variations on that theme resulting in a huge number of permutations.

The idea is that we build a Silverlight application that will show working examples of each easing type and common useful settings. Further, it would allow  users of the application (i.e. you, the public) to supply keywords for any given Easing configuration. This will allow a search, based on English descriptions of the desired effect, to show appropriate sample settings and active demo.

The end result of the idea is that a few hours ago, and only 20 minutes after the idea formed,we created www.Easing.co to contain the proposed Easing project.

The site will hold a place-holder blog initially, describing the Silverlight development, but later it will house the final application.

It should be an interesting project. If you would like to contribute, contact us through this form on Easing.co.

Thanks, Dave

WordPress Themes