ASP.NET MVC I18n – Part 9: 3rd Party Controls

Localization quite regularly involves localizing additional 3rd party controls. This is something that your control has – obviously – to support. Fortunately many controls – certainly the commercial ones, such as Telerik do. Unfortunately (but not unexpectedly) each and every one has its own approach to localization.

Note: This post is part of a series…

To get a better feeling for the demands, let’s take a look at the jQuery UI date picker – the canonical example for additional controls.

Using the date picker is relatively simple: It typically is already included in an MVC project, the respective bundles for script and CSS files are readily defined and only need to be included in the _layout.cshtml. That done, a little initialization script (datepicker.initialize.js) will turn a textbox into a date picker:

$(document).ready(function () {
    var lang = $("html").attr("lang");
    $("input[type=’date’]").datepicker();
});

This script needs to be included in our views which can be achieved with minimal impact by including it in the existing UI bundle:

var bundle = bundles.GetBundleFor("~/bundles/jqueryui");
bundle.Include("~/Scripts/datepicker.initialize.js");

And the result works as expected…

… using American localization.

 

Localization

In order to localize the date picker, you need respective localization files. You can either grab them all (quite simple using the nuget package jQuery.UI.i18n), or you can grab the ones you actually need from github. Using these files, again, causes minimal impact if you simple include them in the bundle as above:

var bundle = bundles.GetBundleFor("~/bundles/jqueryui");
bundle.Include(
    "~/Scripts/jquery-ui-i18n.js", // option 1: from nuget package
    //"~/Scripts/jquery.ui.datepicker-*", // option 2: single localization files
    "~/Scripts/datepicker.initialize.js");

Including the localization scripts will not only register the necessary information, it will actually switch the default language for the date picker. So, if you grabbed the file using nuget, you will end up with Chinese (zh-TW) as date picker region…

With single files, you might include just the one that is actually needed, and avoid that issue. Only you can’t use the nuget package in this cases, as it contains one single script file with all localizations. In any case you could provide your own initialization, that comes after those scripts and sets the date picker region to the correct one, by adjusting the initialization script above:

var lang = $(„html“).attr(„lang“);
$.datepicker.setDefaults($.datepicker.regional[lang]);

We have all the information handy and did the same thing for globalize, right?

Wrong actually. Date picker localizations generally exist for the neutral culture (e.g. de) and only those specific cultures that differ form the default one. E.g. there is a localized version for en-GB, but not en-US, or de-DE respectively, as en and de are sufficient. On top of that the date picker does not support a proper fallback strategy, i.e. setting the region to de-DE will end up using the last included region, again zh-TW if you included all regions, not de.

This is an issue that is rarely mentioned and sometimes missed completely.

The solution is a mapping from our application‘s supported regions to regions supported by the date picker. You could do this on the server and provide a second attribute (e.g. langDatePicker) beside lang on the html tag. If you grabbed single localization files for the date picker, you could automate this by just scanning the available .js files. Or – for just two regions probably the more sensible approach – just do it in the initialization script:

$(document).ready(function () {
    var lang = $("html").attr("lang");
    
    if (lang == "de-DE")
        $.datepicker.setDefaults($.datepicker.regional["de"]);
    else
        $.datepicker.setDefaults($.datepicker.regional[""]); // en-US is default
    
    $("input[type=’date’]").datepicker();
});

And now the date picker changes formats, appearance (e.g. first day of the week), etc.:

 

Verdict

Localizing the date picker control can e done completely in all aspects. But there are also some inconsistencies compared to localizing the validation:

• The globalize nuget package comes with single files, the date picker nuget package provides one consolidated file. This makes it harder to include just the one localization needed. (Performance is hardly an argument, as this is addressed by the bundle logic anyway.)
• With Globalize you need to set a region explicitly, the date picker does it implicitly with referencing the localization file.
• Globalize supports a fallback to the neutral culture if the specific region is not available. Date picker does nothing of the kind and simply ignores the call.

And these are the subtle differences in two packages from the jQuery universe. That might be a good indicator as to what to expect with 3rd party libraries from another source. Bring together a couple of controls, and you’ll have a mighty mishmash.

 

That’s all for now folks,
AJ.NET

Advertisement