ASP.NET MVC I18n – Teil 2: Browser-Einstellungen auswerten

Home » Dev » ASP.NET MVC I18n – Teil 2: Browser-Einstellungen auswerten

ASP.NET MVC I18n – Teil 2: Browser-Einstellungen auswerten

8. Januar 2014

Will man dem Anwender eine lokalisierte Anwendung präsentieren, dann sollte man zunächst wissen, welche Region er gerne hätte. Man könnte zwar einfach mit einer Standardregion beginnen und ihn wechseln lassen, aber er teilt uns ja mit, was er gerne hätte, also sollten wir uns danach richten.

Hinweis: Dieser Beitrag ist Teil einer Serie, die Übersicht findet sich hier.

Seine bevorzugte Sprache stellt der Anwender in den Browser-Settings ein…

Diese Information wird mit jedem Request in Form des accept-language http header mitgeschickt. Die Einträge oben führen etwa beim Internet Explorer zu folgendem Eintrag:

   1: Accept-Language: de-DE,de;q=0.8,en-US;q=0.5,en;q=0.3

Das ist sehr grundlegende Information und ich gehe darauf nur im Detail ein, weil ich oft genug Code gesehen habe, der den Wert behandelt, als würde er nur eine Sprache beinhalten, keine Liste, oder der die Gewichte ignoriert.

Der einfache Ansatz…

Alles, was wir tun müssen, ist, die gewünschte Sprache aus dem Header zu extrahieren und .NET mitzuteilen, und zwar für jeden Request:

public class MvcApplication : System.Web.HttpApplication 
{ 
    protected void Application_OnBeginRequest() 
    { 
        CultureHelper.ApplyUserCulture(this.Request); 
    } 
}

Die Klasse CultureHelper enthält die eigentliche Implementierung:

public static void ApplyUserCulture(this HttpRequest request) 
{ 
    ApplyUserCulture(request.Headers); 
}
 
static void ApplyUserCulture(NameValueCollection headers) 
{ 
    var culture = GetUserCulture(headers) ?? CultureInfo.GetCultureInfo(“en-US”); 
 
    var t = Thread.CurrentThread; 
    t.CurrentCulture = culture; 
    t.CurrentUICulture = culture; 
    Debug.WriteLine("Culture: " + culture.Name); 
}

Die eigentliche Bestimmung des Anwenderwunsches ist einfach:

static CultureInfo GetUserCulture(NameValueCollection headers) 
{ 
    // Accept-Language: de, en-US;q=0.8 
    string acceptLanguages = headers["Accept-Language"]; 
    if (string.IsNullOrEmpty(acceptLanguages)) 
        return null; 
    // split languages _and_ weights 
    var cultureName = acceptLanguages.Split(',', ';')[0]; 
    return GetCultureInfo(cultureName); 
}
 
private static CultureInfo GetCultureInfo(string language) 
{ 
    try 
    { 
        return CultureInfo.GetCultureInfo(language); 
    } 
    catch (CultureNotFoundException) 
    { 
        return null; 
    } 
}

Man beachte das Exception-Handling: Dies ist notwendig um die unterschiedlichen Vorstellungen von “Sprache” zwischen Client und Server abzufedern (vgl. der letzte Beitrag). In der Regel wird man kaum mal in die Situation kommen, dass der Anwender nach “klingonisch” fragt, aber es mag Ausnahmen geben. Weniger exotisch ist vielleicht (leider) die Möglichkeit von Angriffsszenarien…

Den Header-Wert auf diese Art auszulesen und .NET mitzuteilen ist etwas, das man in jedem Blog-Beitrag und Tutorial zum Thema findet. Tatsächlich müsste man sich nicht mal die Arbeit machen, denn ASP.NET tut das gerne automatisch (ebenfalls Scott’s Beitrag).

Leider greift das zu kurz!

Abstimmung des Anwenderwunsches und der unterstützten Regionen…

Ich möchte die erste Sprache, die der Anwender sich wünscht, gar nicht in jedem Fall verwenden…

Mein Anwendung wird englisch und deutsch unterstützen. Wenn ich die Region für meinen französischen Kollegen (der besser Deutsch kann als Englisch) auf fr-FR setzten würde, hätte das unerwünschte Konsequenzen:

Er würde englische Texte zu Gesicht bekommen, weil ich seine zweite Wahl deutsch ignoriere.

Er würde Datums-Werte sehen, die er womöglich falsch interpretiert. Dass “01/06/2013” (in einem englisch gehaltenen UI!) für den ersten Juni steht (Interpretation als TT/MM/JJJJ) ist alles andere als offensichtlich. Viel wahrscheinlicher ist die (falsche) Interpretation als Dreikönigstag (MM/TT/JJJJ).

Ergo ist es besser, ihm ein konsistentes UI (in diesem Fall en-US) darzustellen, als eine unglückliche Mixtur.

Was ich also möchte ist, dem Anwender das beste Angebot aus der Liste von mir unterstützten Sprachen zu machen, unter Berücksichtigung aller seiner Präferenzen, nicht nur der ersten.

Tatsächlich habe ich das noch selten adressiert und nirgendwo sauber umgesetzt gesehen. Immerhin hat z.B. Nadeem den Bedarf erkannt.

Um’s für die Implementierung deutlich zu machen die verschiedenen Fälle etwas im Detail. Dabei wird unterstellt, dass meine Anwendung en-US und de-DE unterstützt, mit en-US als Standard.

Vollständige Übereinstimmung:

Wenn der Anwenderwunsch "de-DE, en-US;q=0.8" ist,dann ist de-DE natürlich die beste Übereinstimmung. Analog ist bei "fr-FR, en-US;q=0.8", en-US die beste Wahl – nicht die erste Wahl des Anwenders, aber einer seiner Wünsche – der leider von vielen Beispiel-Implementierungen ignoriert wird.
Ein ebenfalls oft unterschlagener Fall: Wenn der Anwender nach "de, en-US;q=0.8" fragt, dann ist de-DE – obwohl es in der Liste gar nicht auftaucht – eine perfekte Übereinstimmung, denn zuallererst fragt der Anwender nach irgendeiner deutschsprachigen Darstellung.
Sollte er hingegen nach "de-AT, en-US;q=0.8" fragen, dann ist en-US die besser Wahl. Das mag diskussionswürdig sein, aber so kann der Anwender immerhin durch die Browsersettings Einfluss nehmen, was im umgekehrten Falle nicht möglich wäre.

Teilweise Übereinstimmung:

Sollte es keine vollständige Übereinstimmung geben, kann man dem Anwender immer noch mit teilweiser Übereinstimmung entgegen kommen: Bei der Anfrage nach "de-AT, fr-FR;q=0.8" macht es durchaus Sinn, ihm de-DE anzubieten, anstatt auf den (für ihn vielleicht unverständliche) Standard en-US zurückzufallen.

Keine Übereinstimmung:

Der Vollständigkeit halber: Wenn gar nichts passt, etwa "es-ES, fr-FR;q=0.8", dann kommt natürlich der Standard en-US zum Zug.

Es dürfte klar sein, dass dafür etwas mehr Code notwendig ist…

Analyse des Headers…

Der Accept-Language Header enthält eine Liste von gewichteten Einträgen. Zwar sind diese üblicherweise nach dem Gewicht sortiert, aber verlassen würde ich mich darauf nicht. Die Liste zu Parsen ist kein unlösbare Aufgabe, es erfordert nur etwas Arbeit:

public static CultureInfo[] GetUserCultures(string acceptLanguage)
{
    // Accept-Language: fr-FR , en;q=0.8 , en-us;q=0.5 , de;q=0.3
    if (string.IsNullOrWhiteSpace(acceptLanguage))
        return new CultureInfo[] { };
 
    var cultures = acceptLanguage
        .Split(',')
        .Select(s => WeightedLanguage.Parse(s))
        .OrderByDescending(w => w.Weight)
        .Select(w => GetCultureInfo(w.Language))
        .Where(ci => ci != null)
        .ToArray();
    return cultures;
}

Dazu die Hilfsklasse WeightedLanguage:

class WeightedLanguage
{
    public string Language { get; set; }
    public double Weight { get; set; }
 
    public static WeightedLanguage Parse(string weightedLanguageString)
    {
        // de
        // en;q=0.8
        var parts = weightedLanguageString.Split(';');
        var result = new WeightedLanguage { Language = parts[0].Trim(), Weight = 1.0 };
        if (parts.Length > 1)
        {
            parts[1] = parts[1].Replace("q=", "").Trim();
            double d;
            if (double.TryParse(parts[1], NumberStyles.AllowDecimalPoint, CultureInfo.InvariantCulture, out d))
                result.Weight = d;
        }
        return result;
    }
}

Die unterstützten Regionen…

Man kann das natürlich konfigurierbar machen, aber im einfachsten Fall wird die Liste der unterstützten Regionen einfach im Code festgeschrieben. Standard-Region ist der erste Eintrag:

public static readonly CultureInfo[] SupportedCultures = new CultureInfo[] 
{ 
    CultureInfo.GetCultureInfo("en-US"),
    CultureInfo.GetCultureInfo("de-DE"),
    //CultureInfo.GetCultureInfo("fr-FR"),
    //CultureInfo.GetCultureInfo("es-ES"),
};

Matching…

Fehlt noch die eigentliche Arbeit, das Matching der vom Anwender angeforderten und der unterstützten Region. Ändern wir also die oben gezeigte Methode entsprechend ab:

public static CultureInfo GetUserCulture(NameValueCollection headers)
{
    var acceptedCultures = GetUserCultures(headers["Accept-Language"]);
    var culture = GetMatchingCulture(acceptedCultures, SupportedCultures);
    return culture;
}

Für das eigentliche Matching brauchen wir zwei Durchläufe, einmal für die vollständige, einmal für die teilweise Übereinstimmung:

public static CultureInfo GetMatchingCulture(CultureInfo[] acceptedCultures, CultureInfo[] supportedCultures)
{
    return
        // first pass: exact matches as well as requested neutral matching supported region
        //      supported: en-US, de-DE
        //      requested: de, en-US;q=0.8  
        //                  => de-DE!  (de has precendence over en-US)
        GetMatch(acceptedCultures, supportedCultures, MatchesCompletely)
        // second pass: look for requested neutral matching supported _neutral_ region
        //      supported: en-US, de-DE
        //      requested: de-AT, en-GB;q=0.8  
        //                  => de-DE! (no exact match, but de-AT has better fit than en-GB)
        ?? GetMatch(acceptedCultures, supportedCultures, MatchesPartly);
}

Die eigentliche Arbeitsmethode ist GetMatch. Sie sucht für alle angeforderten Sprachen oder Regionen eine passende unterstützte Region und liefert den ersten Fund als Ergebnis:

public static CultureInfo GetMatch(
    CultureInfo[] acceptedCultures, 
    CultureInfo[] supportedCultures,
    Func<CultureInfo, CultureInfo, bool> predicate)
{
    foreach (var acceptedCulture in acceptedCultures)
    {
        var match = supportedCultures
            .Where(supportedCulture => predicate(acceptedCulture, supportedCulture))
            .FirstOrDefault();
        if (match != null)
            return match;
    }
    return null;
}

Fehlt nur noch der Abgleich zweier CulturInfos. Für die vollständige Übereinstimmung muss der Fall der angeforderten Sprache (neutral culture) berücksichtigt werden:

static bool MatchesCompletely(CultureInfo acceptedCulture, CultureInfo supportedCulture)
{
    if (supportedCulture.Name == acceptedCulture.Name)
        return true;
    // acceptedCulture could be neutral and supportedCulture specific, but this is still a match (de matches de-DE, de-AT, ...)
    if (acceptedCulture.IsNeutralCulture)
    {
        if (supportedCulture.Parent.Name == acceptedCulture.Name)
            return true;
    }
    return false;
}

Für die teilweise Übereinstimmung werden nur die Sprachen verglichen:

static bool MatchesPartly(CultureInfo acceptedCulture, CultureInfo supportedCulture)
{
    supportedCulture = supportedCulture.Parent;
    if (!acceptedCulture.IsNeutralCulture)
        acceptedCulture = acceptedCulture.Parent;
 
    if (supportedCulture.Name == acceptedCulture.Name)
        return true;
    return false;
}

Fertig.

Halt! Anzeigen sollten wir das wenigstens noch, etwa in der Home/Index View:

   1: Current culture is: @UICulture

Die View-Basisklasse stellt uns den Namen der Region als UICulture schlüsselfertig zur Verfügung.

Aber jetzt: Fertig!

Eine ganze Menge Code, den man eigentlich in der Plattform erwarten würde… Zähnezeigendes Smiley