Localization Improvements for YLAD

Over the last weeks, some users of my project "YLAD" brought some additional localization scenarios to my attention. This resulted in both some improvements to the project itself (which I've just released as a new version on CodePlex and NuGet), and the need to talk about some obstacles you might come across.

App Title Localization

Windows Phone supports native localization of your App title and Tile strings. The process of implementing this is described on MSDN. Before I talk about the conflict that arises with YLAD when you use this feature, let me emphasize that I disagree with this article in that what is described there is far from being "a simple method" to do this. The process in that document requires an excessive amount of manual steps, and it literally encourages you to throw away your work after each finished step. Luckily, there are some alternatives out there; for example, Patrick Getzmann has created a small app that lets you enter all data in one single form and create all the DLLs/MUI files in one go with a single mouse button click. It even goes out to the Bing translation service to get you started with your localized strings quickly. So instead of creating C++ libraries, fiddling with linker settings and manually copying files around one by one in explorer, you should take a look at this much simpler method.

Either way, once you're done creating your MUI files, you need to change the WMAppManifest.xml entries to a resource lookup string, namely this for the application title:

Title="@AppResLib.dll,-100"

In turn, this will result in some nice localized app list entries, dependent on the device settings:

The problem with this is that this is a native feature of the underlying OS – something the involved process of creating a native C++ dll should already hint you at. This means that the method used by a variety of projects, including YLAD, to extract the application title, doesn't work anymore. This method simply loads and extracts the title from the WMAppManifest.xml at runtime. With application title localization, this manifest entry contains the cryptic resource pointer shown above, which cannot be resolved from managed code. As a consequence, your YLAD dialog will show something nasty like:

To fix this, you can use an already existing feature of YLAD: the possibility to override the App title in your YLAD configuration file. This file contains a node for the App data, and you can use the "Title" attribute to specify a different App title than what is contained in the WMAppManifest.xml file. By doing this, you work around this issue and still can provide nicely localized strings. For example:

<!-- In the invariant Data.xml -->
<App Title="My Sample App"
     Author="Joe Doe"
     Publisher="Some Publisher"       
     AdditionalNotes="" />

<!-- In the localized German Data.de.xml -->
<App Title="Meine Beispiel-App"
     Author="Joe Doe"
     Publisher="Irgendein Publisher"       
     AdditionalNotes="" />

Which results in the correct display:

Localization Based on Country/Region

Version 1.3. of YLAD introduces an improved fallback mechanism for the search of localized resources that lets you specify both language-based configurations as well as country/region-based ones. This means that you can not only use "Data.de.xml" as demonstrated above to support the German language. You can also use a more specific culture name of e.g. "Data.de-AT.xml" to provide values that are only used if the current culture is set to Austrian. You can mix both variants, which then means the "de-AT" version is used for an Austrian culture setting, whereas the "de" version is used for all other German cultures (like de-DE, de-CH etc.). The logic in YLAD is:

• Look for the most specific possible resource: "Data.[culture name].xml"
• If that is not found, look for a language resource: "Data.[two-letter ISO language code].xml"
• If that is not found, use the invariant resource: "Data.xml"

In the just discussed example setup, when a device is set to a current culture of "de-DE", this means:

• First a resource for "de-DE" is searched and not found, we only have a country resource "de-AT"
• Then a resource for "de" is searched, which is found. The search is stopped and the "de" resource is used to create the YLAD dialog.

When the device is set to a current culture of "en-US", this means:

• First a resource of "en-US" is searched and not found, we only have a country resource "de-AT"
• Then a resource for "en" is searched and also not found, we only have a language resource "de"
• The invariant resource "Data.xml" is used to create the YLAD dialog.

You may ask yourself whether this really is required. Usually there's only few differences between e.g. de-DE and de-AT that are not important for something like an about dialog. However, this becomes very relevant for e.g. Asian languages, where we have huge differences based on the country (or region) code. I got multiple requests regarding the possibility to differentiate between Chinese cultures in the last weeks (one here, for example). I hope this change satisfies all these requirements and makes it easier for all of you to create your custom localizations.

Have fun!