So wird’s gemacht: Laden von Zeichenfolgenressourcen (HTML)

Artikel
01/29/2016

[ Dieser Artikel richtet sich an Windows 8.x- und Windows Phone 8.x-Entwickler, die Windows-Runtime-Apps schreiben. Wenn Sie für Windows 10 entwickeln, finden Sie weitere Informationen unter neueste Dokumentation ]

Sie können Zeichenfolgenressourcen aus Objekten wie Ressourcendateien, Bibliotheken, Steuerelementen sowie App-Paketen und -Manifesten laden.

Laden von Zeichenfolgen aus Ressourcendateien

Zeichenfolgenressourcen werden in Ressourcendateien erstellt. Der Verweis auf Zeichenfolgenressourcen erfolgt mithilfe von Ressourcenbezeichnern. Eine grundlegende Einführung in das Laden von Zeichenfolgenressourcen finden Sie unter Schnellstart: Verwenden von Zeichenfolgenressourcen.

Die meisten Apps benötigen lediglich eine einzelne Standardressourcendatei pro Sprache (<language>/Resources.resjson) und können auf ihre Ressourcen verweisen, indem sie einen relativen Pfad zu Schlüsseln in dieser Datei (z. B. /String1) verwenden. In bestimmten Anwendungen ist es jedoch angebracht, Ressourcen auf mehrere Ressourcendateien aufzuteilen, um die Komponenten voneinander zu trennen.

Beispiel:

Dateiname:

Strings/en-US/Errors.resjson

Verweis im Markup:

<span data-win-res="{textContent: '/Errors/AlreadyRegistered'}"></span>

Verweis im Code:

WinJS.Resources.getString('/Errors/AlreadyRegistered');

Der Ressourcenbezeichner hat das Format **/ResourceFileName/**StringName. Beachten Sie, dass der Ressourcendateiname weder die Erweiterung noch den Ordnerpfad enthält. Daher müssen alle Ressourcendateinamen in einer Komponente oder in einem Projekt eindeutig sein.

Laden von Zeichenfolgen aus Bibliotheken und Steuerelementen

Apps verfügen häufig über mehrere Komponenten oder sind von Bibliotheken abhängig, z. B. portablen .NET-Klassenbibliotheken, anderen kompatiblen Klassenbibliotheken und Steuerelementbibliotheken.

Steuerelemente und Bibliotheken sollten möglichst immer dazu beitragen, die Ressourcenanzahl zu verringern, da diese von der App bereitgestellt werden sollten. Wenn eine Bibliothek Ressourcen bereitstellen muss, sollte sie es den Apps ermöglichen, diese Ressourcen als Eingabe zu ersetzen. Dies kann erforderlich sein, wenn die Bibliothek nicht im gleichen Umfang lokalisiert ist wie die App, die sie verwendet.

Beispiel:

var rating = new WinJS.UI.RatingsControl(el, {label: 'Please Rate', image: 'images/star.png'});

Das Steuerelement sollte benutzerdefinierte Zeichenfolgen genau so anzeigen, wie sie übergeben wurden, und nach Möglichkeit sollte die Lokalisierung durch die App erfolgen.

var control = new Control(el, {commands: [
    {label: R.getString('Reply')}, 
    {label: R.getString('ReplyAll')
    ]});

Komponenten- oder Bibliotheksdateien werden – ähnlich wie die zugehörigen Zeichenfolgenressourcen – üblicherweise einem Unterordner des Pakets hinzugefügt, in das sie im Rahmen des Erstellungsprozesses eingefügt wurden. Der jeweilige Ressourcenbezeichner besitzt in der Regel folgendes Format:

ClassLibraryOrAssemblyName**/ResourceFileName/**StringName

Bibliotheken können programmgesteuert auch einen eigenen ResourceLoader für ihre Ressourcen erhalten. So veranschaulicht der folgende Code beispielsweise, wie eine Bibliothek mit einem ResourceLoader für ihre eigene Ressourcendatei versehen werden kann:


var resources = Windows.ApplicationModel.Resources;
var RL = new resources.ResourceLoader('ContosoControl/Resources');
RL.getString('loadingStr'); // which came from ContosoControl's Resources

Laden von Zeichenfolgen aus anderen Paketen

Die Ressourcen für die einzelnen App-Pakete werden getrennt verwaltet. Der Zugriff erfolgt über getrennte ResourceMap-Objekte auf der obersten Ebene, die über das aktuelle ResourceManager-Objekt zugänglich sind. In jedem Paket können verschiedene Komponenten jeweils über eigene ResourceMap Subtree-Werte verfügen.

Framework-Pakete können auf ihre eigenen Ressourcen mit einem absoluteren Ressourcenbezeichner-URI zugreifen:

Ausführlichere Informationen zu ms-resource-URIs finden Sie unter URI-Schemas.

Laden von Zeichenfolgen aus JavaScript-Steuerelementen

JavaScript-Steuerelemente, die Standardzeichenfolgen bereitstellen, sollten ihre eigenen Zeichenfolgen mithilfe von WinJS.Resources.getString abrufen.

HTML-Dokumente, die (mithilfe von ms-app-web:) in den Webkontext geladen werden, haben keinen Zugriff auf Windows-Runtime-APIs. Fügen Sie daher in den JavaScript-Code JavaScript-Steuerelemente ein, die für die Verwendung von WinJS.Resources.getString geschrieben wurden. Im Webkontext sucht WinJS.Resources.getString nach dem angegebenen Bezeichner als Eigenschaft eines globalen Zeichenfolgenobjekts.

var strings = { 'String1' : 'Hello' };
WinJS.Resources.getString('String1');

Sie können WinJS.Resources.getString auch überschreiben, um Ressourcen von einem anderen Ort abzurufen.

WinJS.Resources.getString = function(id){
    return getStringFromOtherService(id);
}

Laden von Zeichenfolgen aus dem App-Manifest

Alle anzeigbaren Zeichenfolgen und Logos im Manifest sind lokalisierbar. Logos können auch für die Skalierung und für hohen Kontrast angepasst werden. Anstelle einer hartcodierten Zeichenfolge können Zeichenfolgenverweise hinzugefügt werden. Platzieren Sie hierzu einen per ms-resource:-Schema angegebenen URI in den Manifestdaten. (Dies geschieht normalerweise in der Visual Studio-Benutzeroberfläche im Registerkartenformat zum Bearbeiten von „appxmanifest“). ms-resource:String1 bezieht sich z. B. auf eine Zeichenfolge mit dem Namen String1 in der Ressourcendatei Resources.resw, während sich ms-resource:/ManifestStrings/Shortname auf eine Zeichenfolge mit dem Namen Shortname in der Ressourcendatei ManifestStrings.resw bezieht.

Laden von Zeichenfolgen für eine bestimmte Sprache oder einen bestimmten Kontext

Der standardmäßige ResourceContext (ein aus dem ResourceManager abgerufenes Objekt) steht für den aktuellen Zustand, auf den die Ressourcen abgestimmt werden. Der ResourceContext enthält all die unterschiedlichen Qualifiziererwerte für den aktuellen Benutzer und den aktuellen Computer. Sie können die einzelnen Qualifizierer zwar überschrieben, aber von dieser Vorgehensweise wird abgeraten. Die meisten Qualifizierer besitzen einen Systemdatenanbieter. Dieser wird in einigen Fällen am besten über eine separate API (also PrimaryLanguageOverride) geändert oder unverändert gelassen.

Ausführliche Informationen zu den verschiedenen Qualifizierern finden Sie unter So wird's gemacht: Benennen von Ressourcen mithilfe von Qualifizierern.

ResourceManager verwaltet das Standardkontextobjekt, mit dessen Hilfe Ressourcensuchvorgänge ausgeführt werden. In einigen Fällen ist es hilfreich, beim Laden von Ressourcen durch die App explizit die Sprache, die Skalierung oder andere Kontextqualifizierer anzugeben. So kann es eine App einem Benutzer beispielsweise ermöglichen, eine alternative Sprache für QuickInfos oder Fehlermeldungen auszuwählen. Suchvorgänge können ihr eigenes explizit überschriebenes Kontextobjekt angeben, um die Ressourcenauswahl zu beeinflussen. So geben Sie einen expliziten Kontext an, in dem die Languages-Eigenschaft absichtlich überschrieben wird

var rcns = Windows.ApplicationModel.Resources.Core;

var context = new rcns.ResourceContext(); // deliberately not using getForCurrentView()
context.languages = new Array('fr-fr');
var resourceMap = rcns.ResourceManager.current.mainResourceMap.getSubtree('Resources');
var str = resourceMap.getValue('string1', context).ValueAsString;

Eine andere Möglichkeit besteht darin, ResourceContext.SetGlobalQualifierContext vor ResourceContext.GetForCurrentView aufzurufen. Für das Sprachszenario würden Sie den language-Qualifizierer auf einen neuen Wert festlegen. Der Unterschied besteht in diesem Fall darin, dass der Qualifizierer und die Kontextänderung jetzt für alle Ressourcensuchen gelten und nicht nur für das spezifische ResourceContext-Element, das Sie für den einzelnen GetValue-Aufruf erstellt haben. Weitere Informationen finden Sie auch unter ApplicationLanguages.PrimaryLanguageOverride.

Ereignisse und Kontextänderungen

Eine App kann noch ausgeführt werden, während eine Änderung am System vorgenommen wird. Dies führt dazu, dass ein anderer Satz von Qualifizierern verwendet wird. Eine solche Änderung liegt z. B. vor, wenn der Benutzer hohen Kontrast einschaltet. Durch verschiedene Systemänderungen werden Ereignisse für das ResourceContext-Objekt aufgerufen.

In JavaScript können Sie am einfachsten mit der addEventListener-Methode auf diese Ereignisse lauschen:

WinJS.Resources.addEventListener('contextchanged', refresh, false);

Nach dem Erkennen eines Ereignisses können Apps das Dokument erneut verarbeiten, sodass die korrekte Ressource geladen werden kann.

function refresh(){
    WinJS.Resources.processAll(); // Refetch string resources.
}

Die erneute Verarbeitung von Ressourcen kann dazu führen, dass datengebundene Werte in der Ressource erneut festgelegt werden, wenn die neue Ressource direkt auf die Eigenschaft des Elements angewendet wird. Wenn die Ressource datenbindende Positionen enthält, müssen Sie dafür sorgen, dass diese bei der erneuten Verarbeitung neu gebunden werden.