Globalization

Mvc Controls Toolkit extends the predefined client side validation of MVC to allow globalization of input formats. Moreover, all validation attributes defined in the MVC Controls Toolkit supports globalization. Finally, some toolkit controls support localized display formats also when values are changed on the client side. Display formats are taken from data annotations.

Client side globalization support is supplied through the  Globalize library. More specifically, the toolkit detects the server side culture and passes the same culture on the client side to the Globalize library.

Server side globalization support relies on the standared Asp.net globalization module. However, multi-cultural may benefit of the advanced features offered by the MVCControlsToolkit.Owin.Globalization Owin module. 

Starting from the 3.0.0 release the toolkit Nuget package provides a js and css bundles definitions and two Layout pages one for server controls and the other one for client controls, that define all needed javascript and css files. Anyway, for a better understanding below the headers required to add manually  globalization, and validation, based on the Globalize library:

 

<script type='text/javascript' src="~/Scripts/jquery-x.x.x.min.js"></script>
<script type='text/javascript' src="~/Scripts/jquery.validate-x.x.x.min.js"></script>
<script type='text/javascript' src="~/Scripts/jquery.validate.unobtrusive.min.js"></script>
<script type='text/javascript' src="~/Scripts/jquery.unobtrusive-ajax.min.js"></script>
<script type='text/javascript' src="~/Scripts/globalize.min.js"></script>
    
    @Html.GlobalizationScript("~/Scripts/globalize/cultures/")

 

The above assumes that the "cultures" folder containing all js files with the culture specific information is located in the "Scripts/globalize/" folder of the web site. As a matter of fact it is exactly where these files are installed by the Globalize Nuget package.

The definition of the Html.GlobalizationScript function is:

public static MvcHtmlString GlobalizationScript(this HtmlHelper htmlHelper, string globalizationFolder)

All Mvc Controls toolkit Date controls supports: JQuery UI DatePicker, Bootstrap Datepicker, and jQuery mobile Datebox. While the jQuery UI DatePicker comes with the standard jQuery UI installation, the other DatePickers doesnt come with the Bootstrap and jQuery Mobile installations and must be installed separately through specific Nuget packages. 

The javascript files of all datepickers must be located before the MVCControlToolkit.Controls.Core library so they may be autodetected, and all Date controls may configure themselves to use them automatically. The bundles definition file that is installed with the toolkit Nuget package contains comments that show where to place all files references.

All DatePickers have their globalization files. The right one may be chosen with some Razor ifs on the current server culture.

The jQuery UI globalization Nuget package installs an unique javascript file with all cultures. If you use it instead of separate files you may configure the DatePicker Culture with a javascript snippet  contained (commented out) in all Layout pages installed by the toolkit Nuget package.

If all DatePickers globalization files are kept separate and if you support too many cultures to handle the gloabalization files with some ifs, you may use the Html.JQueryDatePickerGlobalizationScrip() for the jQuery UI DatePicker. The above call uses the localization files contained in  “~/Scripts/cultures/datepicker/". If do you want to copy the in a local folder, please use this different overloads, that allows the specification of the folder path:

 

public static MvcHtmlString JQueryDatePickerGlobalizationScript(
    this HtmlHelper htmlHelper, string cultureName = null,
    string globalizationFolder = "~/Scripts/cultures/datepicker/",
    Func<string, bool> useCountry = null,
    Func<string, bool> isSupported = null)
 
If the culture parameter is set to null the current thread culture is used (this is the adviced usage).
 
If the optional function useCountry is supplied, it is passed the string representing the current Culture (such as en-US)  and it must return true, if we want to use a globalization file that is specific for both language and Country, otherwise a file specific for just the language is used (in the previous example (en). The default is the x => false function that never use the Country information. The reason to use just the language might be that there is no globalization file for the current language-Country pair. A smart implementation of useCountry might be based on an array containing all supported languages and language-Country pair.
 
Anagously, if the isSupported function return false no globalization script is inserted.

In order to use all the above methods one is required to include the namespace:MVCControlsToolkit.Controls.Validation: If the Mvc Controls Toolkit is installed through Nuget this namespace is included among the default ones, so you don't need to include it in all pages.

The MVCControlsToolkit.Controls.Validation namespace contains also an helper to support a generic globalization script, that you may use for Bootstrap and jQuery Mobile DatePickers:

 

public static MvcHtmlString LocalizableResourceScript(
    this HtmlHelper htmlHelper,
    string sourceFormat ,
    Func<string, bool> useCountry = null,
    Func<string, bool> isSupported = null)

 

Where sourceFormat is a format string with an unique “hole” {0} where to put either the two letter language code or the 5 letters language-Country code, according to the value returned by useCountry function.

There is also another more complex overload where the format string is returned by a function that receives as input the 5 letters language-Country code of the current culture:

public static MvcHtmlString LocalizableResourceScript(
    this HtmlHelper htmlHelper,
    Func<string, string> sourceFormatCreate,
    Func<string, bool> useCountry = null,
    Func<string, bool> isSupported = null)

  

 

Last edited Jun 22, 2014 at 11:31 AM by frankabbruzzese, version 24

Comments

No comments yet.