Lokalisierung .NET; Fallback-Sprache bei der Verwendung von ResourceManager

Question

Kürzlich habe ich in Lokalisierung mit .NET vertieft. Im Wesentlichen habe ich gelernt, wie man ein Formular anpasst (mit den Eigenschaften Language und Localizable) und dann die Kultur entsprechend ändert.

Allerdings habe ich festgestellt, dass bei der Migration meiner hartcodierten englischen Zeichenfolgen in die automatisch generierten Ressourcendateien und .GetString ("Key") - naja, sagen wir einfach, es war nicht glücklich: P.

Ich entschied mich, einen separaten Satz von resx-Dateien zu erstellen, die ausschließlich für die fest codierten String-Übersetzungen bestimmt sind. Sie folgten der Konvention/Anforderung von [Name]. [Kultur-Code] .resx. Ich habe davon für jede relevante Sprache gemacht; z.B. appstrings.de.resx (Für Deutsch) und appstrings.resx (als invariante Basislinie).

diese neuen Ressourcen zu nutzen, habe ich eine Instanz von Resourcemanager und Ressourcen Set

Dim resManager As New ResourceManager("LanguageTest.appstrings", Assembly.GetExecutingAssembly) 
Dim resSet As ResourceSet = resManager.GetResourceSet(My.Application.UICulture, True, True) 

Die aktuelle UI Kultur gesetzt wurde (beispielsweise auf Deutsch) mit

My.Application.ChangeUICulture("de") 

---

Originalausgabe

Außer t Er resSet.GetString ("Key") ist explizit in appstrings.de.resx definiert, es wird eine leere Zeichenfolge zurückgegeben. Gibt es da überhaupt noch einen Fallback auf die appstrings.resx (wo "Key" existiert), von dem ich annahm, dass er die Standardbasislinie wäre?

aktualisieren

Rhapsody einen Vorschlag unten gemacht, während die eigentliche Spitze selbst nicht funktioniert, es hat in-fact einen interessanten Punkt entfachen, mit resManager.GetString („Key“) in Bezug auf resSet gegen .GetString ("Schlüssel"). Dies scheint bisher fehlerfrei zu funktionieren. Das heißt, Werte, die in der spezialisierten Sprachdatei vorhanden sind, werden zurückgegeben, während "fehlende" Werte auf die Standardkultur zurückfallen, wenn auf sie durch einen einzelnen Schlüssel zugegriffen wird.

Nachfolgende Ausgabe

Die einzige noch offene Frage, ob die Auswirkungen auf die Leistung der Verwendung von ResourceManger zu einer im Cache gespeicherten ResourceSet im Gegensatz wäre wird diese schädlich sein?

Answer 1

Versuchen

Public Function GetString(ByVal Name As String) As String 
    Return My.Resources.Strings.ResourceManager.GetString(Name) 
End Function 

Wo Strings der Name der resx Dateien in Ihrem Projekt. Dadurch wird automatisch der Grundlinienwert zurückgegeben, wenn er für die aktuelle Kultur nicht verfügbar ist.

Es ist ein einfaches Beispiel, Sie möchten es vielleicht narrensicherer machen.

Answer 2

Ich habe einmal eine Web-Anwendung, die en-US als Ausweichsprache hatte aber haben andere speziellere wie .de, basierend auf den Einstellungen in dem Benutzer Web-Browser

Im Grunde ist es zum Laufen zu bringen hat er die xml im Web.

Config

<globalization uiCulture="auto" culture="auto" requestEncoding="utf-8" responseEncoding="utf-8"/> 

Von dort habe ich die internen statischen Resourcemanager aus der CS-Datei, die mit Ihrer Standardsprache zur Verfügung gestellt, zum Beispiel

Resources.<ResourceFileName>.ItemSearchNoResultsErrorText 

und in ASPX-Dateien:

<%$ Resources:<ResourceFileName>, TimeSelect %> 

Wie ich es verstehe, dann ist es von Bedeutung, wo Ihre CS-Datei, die die Resourcemanager-Klasse Leben enthält, ist es hinter der Datei .de Sprache ist oder die Ausweichsprache? Da es sich um eine separate Satelliten-Baugruppe handelt, hängt es davon ab, wo die .cs-Klasse kompiliert wird und von welcher Satelliten-Baugruppe sie ist.

In der Regel habe ich hatte immer die Resourcemanager-Klasse als Code hinter auf dem en-US Sprache denn das ist die eine, das ich als Ausweichsprache verwenden möchten, wenn die speziellere nicht

gefunden verwenden Dieses Setup habe ich nie einen leeren Wert, es ist immer die Fallback-Sprache, obwohl ich die Satelliten-Assemblies zur Laufzeit austauscht.

Answer 3

können Sie versuchen, wie unten

[assembly: NeutralResourcesLanguageAttribute("en-US", UltimateResourceFallbackLocation.Satellite)] 

Dieser Code eine Standard-Kultur für die Anwendung erklärt erklärt, dass Ihre Standard-Kultur en-US ist. Wenn in Ihrem Beispiel die aktuelle Kultur "de-DE" ist, sucht sie nach einer Ressource in "de-DE", sucht dann nach der übergeordneten "de" -Kultur usw. und geht ultimativ zur Ressourcendatei für die definierte Kultur (en-US) . see MSDN für Fallback-Strategien von ResourceManage. Der obige Code wird normalerweise in der assenblyInfo.cs eingegeben. Der zweite Parameter teilt dem Ressourcenmanager mit, wo sich die Ressourcen in Hauptbaugruppe oder Satellit befinden.

Leider müssen Sie in dieser Lösung einen Kulturnamen verwenden, nicht den Ressourcendateinamen. Sie können jedoch RM erweitern, um eine bestimmte Ressource nach Dateiname zu verwenden. Aber es ist einfacher, eine Standardkultur auszuwählen und Ihre Ressourcendatei in diese Kultur umzubenennen, und Sie haben die Lösung sofort einsatzbereit.