The MVCControlsToolkit.Owin.Globalization Owin Globalization Module is the Owin/Katana counterpart of the standard Asp.net globalization module. Owin modules may be used also without IIS in custom hosts, and have the advantage of more frequent release deliveries, since Owin/Katana packages are deployed indipendently of the Asp.net stack as Nuget packages. Moreover MVCControlsToolkit.Owin.Globalization extends Asp.net Globalization in several ways.
The MVCControlsToolkit.Owin.Globalization Owin Globalization Module is available as a Nuget package in the official public Nuget feed, so the module may be installed by using the Visual Studio Nuget package installer.
Sources are available on https://owinglobalization.codeplex.com/
If possible it is adviced to select both cookie and and Url path culture storing (the default), because the cookie is useful to remember the selected language in future visits, while including the culture in the path improves SEO and furnishes an easy way to change the selected culture (it is enough to add links with all supported cultures in their path to the page).
Install the MVCControlsToolkit.Owin.Globalization Nuget package in your Mvc 5 project, then open the Startup.cs file located in the Web Site root, and add the Owin Globalization module as follows:
If culture stroring in the Url is enabled you need also to add the {language}/ segment to all routing rules. Thus for instance:
becomes:
The UseGlobalization extension accepts an OwinGlobalizatioOptions object containing all globalization options as its sole argument. In turn, the OwinGlobalizatioOptions constructor accepts the default culture as its first obligatory argument, and a second optional boolean that specifies if the UI culture must use only the language part of the default culture. Further options may be added with a fluent interface:
.Add(string culture, bool uIIsNeutral = false)
Adds a new supported culture. If uIIsNeutral is true only the language part of the provided culture is used to set the UICulture.
.DisablePaths(path1, path2, ..., pathn)
Globalization module is not applied to the declared paths. Useful, to exclude from globalization, CSS and JavaScript resources created with the minification/bundling module.
As a default the selected culture is stored both in the first segment of the Url path and in a cookie whose name is "preferred_culture". The methods below change these default options:
.DisableCultureInPath()
Disables storing the selected culture in the Url.
.DisableRedirect()
If culture storing in the Url is enabled it disables the automatic redirect to an Url containing the selected culture as first segment of the path when an Url containing no culture in the path is received.
.DisableCookie()
Disables storing the selected culture in a cookie
.CustomCookieName(string name)
If storing the selected culture in a cookie is enabled it changes the globalization cookie default name.
.AddCustomSeeker(ICultureSeeker x)
It adds a custom culture provider, that is able to select a culture by analyzing the current IOwinContext. A culture provider is a class that implements the ICultureSeeker interface:
The Get method must return the selected culture as a string or null if it was not able to find the needed information. If PriorityOnUrlCulture returns true the culture returned by the Get method is preferred also on the culture extracted by the URL, otherwise it is preferred just on the culture extracted by the culture cookie. The providers inserted first have higher priority, and all providers with PriorityOnUrlCulture true have higher priority.
The tool comes with the CultureFromPreferences implementation of ICultureSeeker interface that extracts culture information from the logged user preferences. See the Culture from Logged User Preferences section for more information.
The CultureManager static class contains some helpers methods:
The tool supports also storing of culture preferences in the Users database and in the authentication cookie. To enable this feature follows the step belows:
Step1. Add a new property to the ApplicationUser:
Step2. Add the preferred culture as a claim in the authorization cookie by adding the highlighted code lines to the SignInAsync method of the AccountController:
Step 3. Add the needed User Interface for selecting the value of the PreferredCulture of the ApplicationUser in the "Registration" and "Modify Preferences" Views. Each time a modification is done the SignInAsync method must be called to create an updated authentication cookie.
Step4. Add the CultureFromPreferences culture provider: