Istnieje kilka podejść do kwestii wyboru wersji językowej aplikacji stworzonej w ASP.NET MVC.
Między innymi można odczytywać jaki język preferuje przeglądarka użytkownika, tutaj powstaje jednak problem, gdy chcemy uruchomić wersję językową inną niż przeglądarka (bo trzeba się bawić w przechowywanie tego w sesji lub ciasteczkach).

Osobiście jestem „fanem” subdomen językowych – czyli dla jednej aplikacji tworzymy bindingi dla hostów w stylu „pl.luktom.net”, „en.luktom.net”, „de.luktom.net”.
Rozwiązanie to jest szybkie w implementacji – ot, wpis w DNSie i ustawienie bindingów – góra kilka minut.
Poza tym daje nam elastyczność związaną z możliwością rozbicia obsługi poszczególnych wersji językowych aplikacji na kilka serwerów – dzięki czemu np. użytkownicy z Japonii zostaną już na poziomie DNS skierowani do serwera w Japonii, a użytkownicy z Niemiec mogą zostać przekierowani do serwera w Europie (ale to jest osobny temat, na inny artykuł).

W dalszej części prezentuję kod wybierający kulturę w zależności od nazwy hosta z subdomeną językową.

Implementacja wybierania kultury aplikacji jest bardzo prosta i sprowadza się do dodania metody Application_AcquireRequestState do klasy MvcApplication w Global.asax (nie zapomnijcie o using System.Globalization!):

protected void Application_AcquireRequestState(object sender, EventArgs e)
{
    CultureInfo ci = new CultureInfo(Request.Url.Host.Substring(0, 2))

    System.Threading.Thread.CurrentThread.CurrentUICulture = ci;
    System.Threading.Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(ci.Name);
}

Powyższy kod, na postawie pierwszych dwu liter domeny hosta tworzy odpowiedni obiekt CultureInfo, a następnie bieżącemu wątkowi, w którym wykonywana jest aplikacja ASP.NET MVC przypisuje tę kulturę, dzięki czemu automatyczne użyte zostaną odpowiednie pliki zasobów dla danej kultury.

Zobacz także

• Jak utworzyć kanał RSS w ASP.NET MVC?
• C# i uruchamianie procesu z uprawnieniami administratora
• WCF Data Services i DataGridView – wyświetlanie relacji