Wenn Sie WPF-basierte Benutzeroberflächeen entwerfen, sollten Sie die Implementierung der empfohlenen Vorgehensweisen in Erwägung ziehen:

• Schreiben Sie Benutzeroberflächen in XAML, und vermeiden Sie das Erstellen von Benutzeroberflächen in Code. Wenn Sie die Benutzeroberfläche mit XAML erstellen, machen Sie sie durch integrierte Lokalisierungs-APIs verfügbar.

• Vermeiden Sie beim Darstellen von Inhalt absolute Positionen und feste Größen, und verwenden Sie stattdessen die relative oder automatische Größenanpassung.

  • Verwenden Sie SizeToContent. Breite und Höhe sollten auf Auto festgelegt bleiben.

  • Vermeiden Sie die Verwendung von Canvas, um Benutzeroberflächeen darzustellen.

  • Verwenden Sie Grid und dessen Feature für gemeinsame Größenänderung.

• Stellen Sie zusätzlichen Abstand an den Rändern bereit, da lokalisierter Text häufig mehr Platz beansprucht. Durch zusätzlichen Abstand entsteht Platz für mögliche überhängende Zeichen.

• Aktivieren Sie TextWrapping für TextBlock, um das Abschneiden von Daten zu vermeiden.

• Legen Sie das xml:lang-Attribut fest. Dieses Attribut beschreibt die Kultur eines bestimmten Elements und seiner untergeordneten Elemente. Der Wert dieser Eigenschaft ändert das Verhalten mehrerer Features in WPF. So wird z. B. das Verhalten der Silbentrennung, der Rechtschreibprüfung, der Zahlenersetzung, der komplexen Skriptgestaltung sowie der automatischen Schriftartauswahl geändert. Weitere Informationen zum Festlegen von xml:lang-Behandlung in XAML finden Sie unter Globalisierung für Windows Presentation Foundation.

• Erstellen Sie eine benutzerdefinierte zusammengesetzte Schriftart, um die in unterschiedlichen Sprachen verwendeten Schriftarten besser steuern zu können. Standardmäßig verwendet WPF die Schriftart GlobalUserInterface.composite im Verzeichnis Windows\Fonts.

• Wenn Sie eine Navigationsanwendung erstellen, die möglicherweise in eine Kultur lokalisiert wird, in der Texte im Rechts-nach-Links-Format wiedergegeben werden, legen Sie FlowDirection von jeder Seite ausdrücklich fest, um sicherzustellen, dass FlowDirection aus NavigationWindow nicht von der Seite übernommen wird.

• Wenn Sie eigenständige Navigationsanwendungen erstellen, die außerhalb eines Browsers gehostet werden, legen Sie StartupUri für die Originalanwendung auf NavigationWindow anstatt auf eine Seite fest (z. B. <Application StartupUri="NavigationWindow.xaml">). Dieser Entwurf ermöglicht es Ihnen, FlowDirection des Fensters und der Navigationsleiste zu ändern. Weitere Informationen und ein Beispiel finden Sie unter Beispiel zu globalisierter Startseite.

Wenn Sie WPF-basierte Anwendungen lokalisieren, sollten Sie die Implementierung dieser empfohlenen Vorgehensweisen erwägen:

• Verwenden Sie Lokalisierungskommentare, um zusätzlichen Kontext für Lokalisierer bereitzustellen.

• Verwenden Sie Lokalisierungsattribute zur Steuerelementlokalisierung, statt Uid-Eigenschaften für Elemente selektiv wegzulassen. Weitere Informationen finden Sie unter Lokalisierungsattribute und -kommentare.

• Verwenden Sie msbuild /t:updateuid und /t:checkuid, um Uid-Eigenschaften in XAML hinzuzufügen und zu überprüfen. Verwenden Sie Uid-Eigenschaften, um die Änderungen zwischen Entwicklung und Lokalisierung zu verfolgen. Uid-Eigenschaften ermöglichen die Lokalisierung neuer Entwicklungsänderungen. Wenn Sie einer BenutzeroberflächeUid-Eigenschaften manuell hinzufügen, ist die Aufgabe i. d. R. zeitraubend und wenig genau.

  • Bearbeiten oder ändern Sie Uid-Eigenschaften nicht, nachdem Sie mit der Lokalisierung begonnen haben.

  • Verwenden Sie keine doppelten Uid-Eigenschaften (denken Sie daran, wenn Sie die Befehle Kopieren und Einfügen verwenden).

  • Legen Sie die UltimateResourceFallback-Position in AssemblyInfo.* fest, um die entsprechende Sprache für Fallback (z. B. [assembly: NeutralResourcesLanguage("en-US", UltimateResourceFallbackLocation.Satellite)]) anzugeben.

    Wenn Sie die Ausgangssprache in der Hauptassembly durch Auslassen des <UICulture>-Tags in die Projektdatei einfügen, legen Sie die UltimateResourceFallback-Position anstelle des Satelliten (z. B. [assembly: NeutralResourcesLanguage("en-US", UltimateResourceFallbackLocation.MainAssembly)]) als Hauptassembly fest.

Wenn Sie eine WPF-Anwendung entwickeln, verläuft der Buildprozess für die Lokalisierung folgendermaßen:

• Der Entwickler erstellt und globalisiert die WPF-Anwendung. In der Projektdatei legt der Entwickler <UICulture>en-US</UICulture> fest, sodass bei der Kompilierung einer Anwendung eine sprachneutrale Hauptassembly generiert wird. Diese Assembly verfügt über die Satellitendatei .resources.dll, die alle lokalisierbaren Ressourcen enthält. Wahlweise können Sie die Ausgangssprache in der Hauptassembly speichern, da die Lokalisierungs-APIs die Extraktion aus der Hauptassembly unterstützen.

• Bei der Kompilierung der Datei in den Build wird XAML in BAML konvertiert. Die kulturell neutralen MyDialog.exe- und die kulturspezifischen MyDialog.resources.dll-Dateien (Englisch) werden für den englischsprachigen Kunden freigegeben.

Der Lokalisierungsprozess beginnt nach Erstellen der nicht lokalisierten MyDialog.resources.dll-Datei. Die Benutzeroberflächenelemente und -Eigenschaften in der ursprünglichen XAML werden von BAML in Schlüssel/Wert-Paare extrahiert. Dazu werden APIs unter System.Windows.Markup.Localizer verwendet. Lokalisierer verwenden die Schlüssel/Wert-Paare zum Lokalisieren der Anwendung. Nach Abschluss der Lokalisierung können Sie anhand der neuen Werte eine neue Datei .resource.dll erstellen.

Die Schlüssel des Schlüssel/Wert-Paares sind x:Uids, die vom Entwickler in der ursprünglichen XAML eingefügt werden. Diese x:Uids aktivieren die API zum Nachverfolgen und Zusammenführen von Änderungen, die im Verlauf der Lokalisierung zwischen dem Entwickler und dem Lokalisierer vorkommen. Wenn der Entwickler beispielsweise die Benutzeroberfläche ändert, nachdem der Lokalisierer die Lokalisierung begonnen hat, können Sie die Entwicklungsänderung mit der bereits abgeschlossenen Lokalisierung zusammenführen, um zu gewährleisten, dass nur ein Minimum der Übersetzung verloren geht.

In der folgenden Grafik wird ein typischer Lokalisierungsworkflow dargestellt, der auf BAML basiert. In diesem Diagramm wird davon ausgegangen, dass der Entwickler die Anwendung auf Englisch schreibt. Der Entwickler erstellt und globalisiert die WPF-Anwendung. In der Projektdatei legt der Entwickler <UICulture>en-US</UICulture> so fest, dass im Buildvorgang eine sprachneutrale Hauptassembly mit einer Satellitendatei .resources.dll, die alle lokalisierbaren Ressourcen enthält, generiert wird. Alternativ dazu können Sie die Ausgangssprache in der Hauptassembly speichern, da die WPF-Lokalisierungs-APIs  die Extraktion aus der Hauptassembly unterstützen. Nach dem Buildprozess wird die XAML in BAML kompiliert. Die kulturell neutrale Datei MyDialog.exe.resources.dll wird an den englischsprachigen Kunden ausgeliefert.

Der Lokalisierungsprozess beginnt, nachdem die nicht lokalisierte Datei MyDialog.resources.dll erstellt wurde. Die Elemente und Eigenschaften der Benutzeroberfläche in der ursprünglichen XAML können mithilfe der APIs im System.Windows.Markup.Localizer-Namespace aus der BAML in Schlüssel/Wert-Paare extrahiert werden. Lokalisierer verwenden dann die Schlüssel/Wert-Paare zum Lokalisieren der Anwendung. Nach Abschluss der Lokalisierung kann dann anhand der neuen Werte eine neue Datei .resource.dll erstellt werden.

Die Schlüssel der Schlüssel/Wert-Paare sind x:UIds, die vom Entwickler in der ursprünglichen XAML eingefügt werden. Diese x:UIds aktivieren die API zum Nachverfolgen und Zusammenführen von Änderungen, die im Verlauf der Lokalisierung zwischen dem Entwickler und dem Lokalisierer vorkommen. Wenn der Entwickler beispielsweise eine Änderung an der Benutzeroberfläche vornimmt, nachdem der Lokalisierer bereits mit der Lokalisierung begonnen hat, kann die Entwicklungsänderung mit der bereits abgeschlossenen Lokalisierung zusammengeführt werden, um zu gewährleisten, dass nur ein Minimum der Übersetzung verloren geht.

Beispiel für das Dialogfeld Ausführen

In der folgenden Grafik wird die Ausgabe des Beispiels für das Dialogfeld Ausführen gezeigt.

Englisch:

Deutsch:

Entwerfen eines globalen Dialogfelds Ausführen

In diesem Beispiel wird das Dialogfeld Ausführen mit WPF und XAML erzeugt. Dieses Dialogfeld ist identisch mit dem Dialogfeld Ausführen, das im Microsoft Windows-Startmenü zur Verfügung steht.

Das vollständige Beispiel finden Sie unter Beispiel für das Globalisieren des Dialogfelds zum Ausführen.

Beim Erstellen von globalen Dialogfeldern ist Folgendes zu betonen:

Automatic Layout

In Window1.xaml:

<Window SizeToContent="WidthAndHeight">

Die vorherige Window-Eigenschaft passt die Größe des Fensters automatisch an die Größe des Inhalts an. Durch diese Eigenschaft wird verhindert, dass Inhalt, der nach der Lokalisierung an Größe zunimmt, abgeschnitten wird. Sollte der Inhalt nach der Lokalisierung an Größe abnehmen, wird nicht benötigter Platz außerdem entfernt.

<Grid x:Uid="Grid_1">

Uid-Eigenschaften werden benötigt, damit die WPF-Lokalisierungs-APIs ordnungsgemäß ausgeführt werden.

Sie werden durch WPF-Lokalisierungs-APIs verwendet, um Änderungen zwischen der Entwicklung und der Lokalisierung der Benutzeroberfläche (user interface, UI) nachzuverfolgen. Mithilfe der Uid-Eigenschaften können Sie eine neuere Version der Benutzeroberfläche mit einer älteren Lokalisierung der Benutzeroberfläche zusammenführen. Sie fügen eine Uid-Eigenschaft hinzu, indem Sie msbuild /t:updateuid RunDialog.csproj in der Windows SDK-Befehlsshell ausführen. Hierbei handelt es sich um die empfohlene Methode zum Hinzufügen von Uid-Eigenschaften, da manuelles Hinzufügen normalerweise sehr zeitaufwändig und wenig präzise ist. Sie können überprüfen, ob Uid-Eigenschaften ordnungsgemäß festgelegt sind, indem Sie msbuild /t:checkuid RunDialog.csproj ausführen.

Die Benutzeroberfläche wird mithilfe des Grid-Steuerelements strukturiert. Dieses Steuerelement eignet sich für automatische Layouts in WPF. Beachten Sie, dass das Dialogfeld in drei Zeilen und fünf Spalten geteilt wird. Keine der Zeilen- oder Spaltendefinitionen hat eine feste Größe. Daher können sich die Benutzeroberfläche-Elemente, die sich in jeder Zelle befinden, während der Lokalisierung an jede Größenänderung anpassen.

Die ersten beiden Spalten, in die die Bezeichnungen Öffnen: und ComboBox eingefügt sind, nehmen 10 Prozent der Gesamtbreite der Benutzeroberfläche ein.

Beachten Sie, dass im Beispiel das Feature für die gemeinsame Größenänderung von Grid verwendet wird. Die letzten drei Spalten nutzen diesen Umstand, indem sie in derselben SharedSizeGroup eingefügt werden. Wie aufgrund des Eigenschaftennamens zu erwarten ist, ermöglicht dies den Spalten, dieselbe Größe zu verwenden. Wenn also "Browse…" in die längere Zeichenfolge "Durchsuchen…" lokalisiert wird, nehmen alle Schaltflächen an Breite zu, anstatt dass eine kleine Schaltfläche "OK" und eine unverhältnismäßig große Schaltfläche "Durchsuchen…" angezeigt werden.

Xml:lang

Xml:lang="en-US"

Beachten Sie, dass xml:lang-Behandlung in XAML am Stammelement der Benutzeroberfläche platziert ist. Diese Eigenschaft beschreibt die Kultur eines bestimmten Elements und seiner untergeordneten Elemente. Dieser Wert wird von mehreren Features in WPF verwendet und sollte im Rahmen der Lokalisierung entsprechend geändert werden. Dieser Wert bestimmt, welches Sprachwörterbuch zur Silbentrennung und Rechtschreibprüfung verwendet wird. Außerdem wirkt er sich auf die Anzeige von Ziffern aus und bestimmt, welche Schriftart durch die automatische Schriftartauswahl ausgewählt wird. Schließlich beeinflusst diese Eigenschaft die Anzeige von Nummern und die Gestaltung von Text in komplexen Skripts. Der Standardwert ist "en-US".

Building a Satellite Resource Assembly

In .csproj:

<UICulture>en-US</UICulture>

Beachten Sie die zusätzliche UICulture-Eigenschaft. Wird diese auf einen gültigen CultureInfo-Wert festgelegt, z. B. en-US, wird durch das Erstellen des Projekts eine Satellitenassembly mit sämtlichen lokalisierbaren Ressourcen erzeugt.

<Resource Include="RunIcon.JPG">

<Localizable>False</Localizable>

</Resource>

Die Datei RunIcon.JPG muss nicht lokalisiert werden, da sie für alle Kulturen identisch angezeigt werden sollte. Localizable ist auf False festgelegt, damit es in der sprachneutralen Hauptassembly verbleibt anstatt in der Satellitenassembly. Für den Standardwert aller nicht kompilierbaren Ressourcen wird Localizable auf True festgelegt.

Lokalisieren des Dialogfelds Ausführen

Parse

Die Analyse der lokalisierbaren Ressourcen aus der Satellitenassembly ist der erste Schritt der Lokalisierung, nachdem die Anwendung erstellt wurde. Verwenden Sie für dieses Thema das LocBaml-Beispieltool, das sich unter Beispiel zum LocBaml-Tool befindet. Bedenken Sie, dass LocBaml lediglich ein Beispieltool und dafür konzipiert ist, Ihnen den Einstieg in das Erstellen eines Lokalisierungstools zu erleichtern, das sich dem Lokalisierungsprozess anpasst. Analysieren Sie mithilfe von LocBaml Folgendes: LocBaml /parse RunDialog.resources.dll /out:, um die Datei "RunDialog.resources.dll.CSV" zu generieren.

Localize

Verwenden Sie Ihren bevorzugten CSV-Editor, der Unicode unterstützt, um diese Datei zu bearbeiten. Filtern Sie alle Einträge mit der Lokalisierungskategorie "None" heraus. Folgende Einträge sollten angezeigt werden:

Resource key	Localization Category	Value
Button_1:System.Windows.Controls.Button.$Content	Button	OK
Button_2:System.Windows.Controls.Button.$Content	Button	Cancel
Button_3:System.Windows.Controls.Button.$Content	Button	Browse...
ComboBox_1:System.Windows.Controls.ComboBox.$Content	ComboBox
TextBlock_1:System.Windows.Controls.TextBlock.$Content	Text	Geben Sie den Namen eines Programms, Ordners, Dokuments oder einer Internetressource ein, die daraufhin von Windows für Sie geöffnet wird.
TextBlock_2:System.Windows.Controls.TextBlock.$Content	Text	Open:
Window_1:System.Windows.Window.Title	Title	Run

Eine Lokalisierung der Anwendung ins Deutsche macht folgende Übersetzungen erforderlich:

Ressourcenschlüssel	Lokalisierungskategorie	Wert
Button_1:System.Windows.Controls.Button.$Content	Schaltfläche	OK
Button_2:System.Windows.Controls.Button.$Content	Schaltfläche	Abbrechen
Button_3:System.Windows.Controls.Button.$Content	Schaltfläche	Durchsuchen…
ComboBox_1:System.Windows.Controls.ComboBox.$Content	ComboBox
TextBlock_1:System.Windows.Controls.TextBlock.$Content	Text	Geben Sie den Namen eines Programms, Ordners, Dokuments oder einer Internetressource ein, die daraufhin von Windows für Sie geöffnet wird.
TextBlock_2:System.Windows.Controls.TextBlock.$Content	Text	Öffnen:
Window_1:System.Windows.Window.Title	Titel	Ausführen

Generate

Der letzte Lokalisierungsschritt umfasst das Erstellen der neu lokalisierten Satellitenassembly. Dies kann mit dem folgenden LocBaml-Befehl ausgeführt werden:

LocBaml.exe /generate RunDialog.resources.dll /trans:RunDialog.resources.dll.CSV /out: . /cul:de-DE

Wenn diese Datei resources.dll im deutschen Windows in den Ordner de-DE neben der Hauptassembly platziert wird, dann wird automatisch diese Ressource anstelle der Ressource im Ordner es-US geladen. Wenn Sie keine deutsche Version von Windows besitzen, um das zu testen, legen Sie die Kultur auf eine beliebige Kultur des verwendeten Windows fest (z. B. en-US). Ersetzen Sie anschließend die ursprüngliche resources.dll-Datei.

Satellite Resource Loading

MyDialog.exe	en-US\MyDialog.resources.dll	de-DE\MyDialog.resources.dll
Code	Ursprüngliche englische BAML	Lokalisierte BAML
Kulturell neutrale Ressourcen	Weitere Ressourcen auf Englisch	Weitere ins Deutsche lokalisierte Ressourcen

Basierend auf der Thread.CurrentThread.CurrentUICulture der Anwendung wählt .NET Framework die zu ladende Satellitenressourcenassembly automatisch aus. Dies wird die Standardkultur des Windows-Betriebssystems. Wenn Sie also das deutsche Windows verwenden, wird de-DE\MyDialog.resources.dll geladen und beim englischen Windows wird en-US\MyDialog.resources.dll geladen. Sie können für die Anwendung die endgültige Fallbackressource festlegen, indem Sie NeutralResourcesLanguage in der Datei AssemblyInfo.* des Projekts angeben. Wenn Sie beispielsweise Folgendes angeben:

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

wird die en-US\MyDialog.resources.dll mit der deutschen Windows-Version verwendet, falls weder de-DE\MyDialog.resources.dll noch de\MyDialog.resources.dll verfügbar sind.

In der folgenden Grafik wird eine englische und eine arabische Homepage angezeigt. Das vollständige Beispiel, das in dieser Grafik dargestellt wird, finden Sie unter Beispiel zu globalisierter Startseite.

Englisch:

Arabisch:

Mit der Simulierung der Microsoft-Website für Saudi-Arabien werden die Globalisierungsfeatures veranschaulicht, die für Sprachen mit Schreibrichtung von rechts nach links zur Verfügung gestellt werden. Sprachen wie Hebräisch und Arabisch haben eine Leserichtung von rechts nach links, sodass das Layout der Benutzeroberfläches oftmals ganz anders ausgerichtet werden muss, als das in Sprachen mit einer Schreibrichtung von links nach rechts (z. B. Englisch) der Fall wäre. Das Lokalisieren einer von links nach rechts geschriebenen Sprache in eine von rechts nach links geschriebene Sprache oder umgekehrt kann sich als recht schwierig erweisen. WPF wurde entwickelt, um solche Lokalisierungen erheblich zu erleichtern.

FlowDirection

Homepage.xaml:

Beachten Sie die FlowDirection-Eigenschaft auf der Seite. Eine Änderung dieser Eigenschaft in "RightToLeft" zieht eine Änderung der FlowDirection der Seite und deren untergeordneter Elemente nach sich, sodass das Layout der Benutzeroberfläche gekippt wird, um entsprechend der Erwartung eines araberischen Benutzers von rechts nach links ausgerichtet zu sein. Das Vererbungsverhalten lässt sich überschreiben, indem Sie eine explizite FlowDirection für jedes Element angeben. Die FlowDirection-Eigenschaft steht jedem FrameworkElement oder dokumentbezogenen Element zur Verfügung und hat den impliziten Wert LeftToRight.

Beachten Sie, dass sogar der Farbverlaufhintergrund ordnungsgemäß gekippt wird, wenn die FlowDirection der Stammseite geändert wird:

FlowDirection="LeftToRight"

FlowDirection="RightToLeft"

Vermeiden der Verwendung fester Abmessungen für Bereiche und Steuerelemente

Wenn Sie sich Homepage.xaml anschauen, wird Ihnen neben der festen Breite und Höhe, die für die Benutzeroberfläche im oberen DockPanel angegeben wurde, auffallen, dass es keine weiteren festen Abmessungen gibt. Vermeiden Sie die Verwendung von festen Abmessungen, um das Abschneiden von lokalisiertem Text zu verhindern, der u. U. länger als der Ausgangstext ist. WPF-Bereiche und -Steuerelemente werden basierend auf dem enthaltenen Inhalt automatisch angepasst. Außerdem enthalten die meisten Steuerelemente minimale und maximale Abmessungen, die Sie für weitere Steuerelemente festlegen können (z. B. MinWidth= "20"). Mit Grid können Sie auch relative Breiten und Höhen festlegen, indem Sie ‘*’ (z. B. Width= "0.25*") oder das Feature für gemeinsame Zellengrößen verwenden, wie im Beispiel RunDialog unter Beispiel für das Globalisieren des Dialogfelds zum Ausführen dargestellt.

Lokalisierungskommentare

In vielen Fällen ist der Inhalt mehrdeutig und schwierig zu übersetzen. Der Entwickler oder Designer kann dem Lokalisierer über Lokalisierungskommentare zusätzlichen Kontext und entsprechende Kommentare zur Verfügung zu stellen. Im Folgenden wird durch Localization.Comments die Verwendung des Zeichens ‘|’ erläutert.

Dieser Kommentar wird dem Inhalt von TextBlock_1 zugeordnet. Im Fall des LocBaml-Tools (siehe Gewusst wie: Lokalisieren einer Anwendung) wird er in der sechsten Spalte der Zeile TextBlock_1 in der CSV-Ausgabedatei angezeigt:

Kommentare können für den Inhalt oder die Eigenschaft eines beliebigen Elements mit folgender Syntax eingefügt werden:

Lokalisierungsattribute

Häufig müssen Entwickler oder Lokalisierungsmanager einschränken, was Lokalisierer lesen und ändern dürfen. Wenn Sie beispielsweise nicht möchten, dass der Lokalisierer den Namen Ihres Unternehmens oder Rechtstexte übersetzt, stellt WPF Attribute bereit, mit deren Hilfe Sie die Lesbarkeit, Änderbarkeit und Kategorie von Elementinhalt und -eigenschaften festlegen können, die Ihr Lokalisierungstool zum Sperren, Ausblenden oder Sortieren von Elementen verwenden kann. Weitere Informationen finden Sie unter AttributesProperty. In diesem Beispiel gibt das LocBaml-Tool lediglich die Werte dieser Attribute aus. Alle WPF-Steuerelemente besitzen Standardwerte für diese Attribute, die Sie jedoch überschreiben können. Im Folgenden werden beispielsweise die standardmäßigen Lokalisierungsattribute für TextBlock_1 überschrieben. Der Inhalt bleibt für Lokalisierer lesbar, kann aber nicht von ihnen bearbeitet werden.

<TextBlock
x:Uid="TextBlock_1"
Localization.Attributes=
"$Content(Readable Unmodifiable)">
  Microsoft Corporation
</TextBlock>

Neben den Lesbarkeits- und Änderbarkeitsattributen stellt WPF eine Enumeration allgemeiner Benutzeroberflächenkategorien zur Verfügung, mit deren Hilfe Lokalisierern mehr Kontext bereitgestellt wird: Text, Titel, Label, Button, CheckBox, ComboBox, ListBox, Menu, RadioButton, ToolTip, Hyperlink, Dokument, XmlData und Schriftart. Die standardmäßigen WPF-Kategorien für Plattformsteuerelemente können in XAML ebenfalls überschrieben werden:

<TextBlock x:Uid="TextBlock_2">
<TextBlock.ToolTip>
<TextBlock
x:Uid="TextBlock_3"
Localization.Attributes=
"$Content(ToolTip Readable Unmodifiable)">
Microsoft Corporation
</TextBlock>
</TextBlock.ToolTip>
Windows Vista
</TextBlock>

Mithilfe von Code können auch die von WPF zur Verfügung gestellten standardmäßigen Lokalisierungsattribute überschrieben werden. Anschließend können Sie die richtigen Standardwerte für benutzerdefinierte Steuerelemente ordnungsgemäß festlegen. Beispiel: 

[Localizability(Readability = Readability.Readable, Modifiability=Modifiability.Unmodifiable, LocalizationCategory.None)]

public class CorporateLogo: TextBlock

{

…

..

.

}

Die in XAML festgelegten Beispielattribute haben Vorrang gegenüber Werten, die im Code für benutzerdefinierte Steuerelemente festgelegt wurden. Weitere Informationen zu Attributen und Kommentaren finden Sie unter Lokalisierungsattribute und -kommentare.

Automatische Schriftartauswahl und zusammengesetzte Schriftarten

Wenn Sie eine Schriftart angeben, die einen gegebenen Codepunktbereich nicht unterstützt, sucht WPF automatisch eine Schriftart aus, die dies erfüllt. Hierzu wird Global User Interface.compositefont im Verzeichnis Windows\Fonts verwendet. Zusammengesetzte Schriftarten funktionieren wie jede andere Schriftart. Sie können durch Festlegen der FontFamily (z. B. FontFamily= "Global User Interface") eines Elements explizit verwendet werden. Sie können Ihre eigenen Einstellungen für die automatische Schriftartauswahl angeben, indem Sie eine eigene zusammengesetzte Schriftart erstellen und die Schriftart angeben, die für spezielle Codepunktbereiche und Sprachen verwendet werden soll.

Weitere Informationen zu zusammengesetzten Schriftarten finden Sie unter FontFamily.

Lokalisieren der Microsoft-Homepage

Führen Sie zum Lokalisieren dieser Anwendung dieselben Schritte aus wie für das Beispieldialogfeld Ausführen. Die lokalisierte CSV-Datei für Arabisch steht Ihnen unter Beispiel zu globalisierter Startseite zur Verfügung.