Mui Grundlegende Konzepte erläutert

• Voraussetzung für MUI
• Trennung des Quellcodes von sprachspezifischen Ressourcen
  • Die Anfangszeit: Code und Ressourcen leben zusammen
  • Logische Trennung von Code und lokalisierbaren Ressourcen
  • Physisches Trennen von Code und Ressourcen
• Dynamisches Laden sprachspezifischer Ressourcen
• Erstellen von MUI-Anwendungen

Voraussetzung für MUI

Die Grundvoraussetzung für die Erstellung einer MUI-konformen Anwendung für Windows Vista und darüber hinaus besteht darin, die Anwendung gemäß den Windows-Globalisierungsrichtlinien zu entwerfen.

Trennung des Quellcodes von sprachspezifischen Ressourcen

Eine der grundlegenden Voraussetzungen der MUI-Technologie ist die Trennung des Anwendungsquellcodes von sprachspezifischen Ressourcen, um mehrsprachige Szenarien in Anwendungen effizienter zu ermöglichen. Die Trennung von Code und Ressourcen wurde über verschiedene Mechanismen und in unterschiedlichem Grad im Laufe der Zeit erreicht, wie in den folgenden Abschnitten beschrieben. Jede Methode bot ein unterschiedliches Maß an Flexibilität beim Erstellen, Bereitstellen und Warten der Anwendung.

Die empfohlene Lösung für MUI-konforme Anwendungen ist die letzte hier beschriebene Methode, nämlich die physische Trennung von Anwendungsquellcode und Ressourcen, wobei die Ressourcen selbst weiter in eine Datei pro unterstützter Sprache unterteilt werden, um maximale Flexibilität beim Erstellen, Bereitstellen und Warten zu gewährleisten.

Die Anfangszeit: Code und Ressourcen leben zusammen

Zunächst wurden lokalisierte Anwendungen erstellt, indem der Quellcode bearbeitet und die Ressourcen (in der Regel Zeichenfolgen) im Code selbst geändert und die Anwendungen neu kompiliert wurden. Dies bedeutete, dass zum Erstellen einer lokalisierten Version der ursprüngliche Quellcode kopiert, die Textelemente (Ressourcen) im Quellcode übersetzt und der Code neu kompiliert werden musste. Die folgende Abbildung zeigt Anwendungscode mit Text, der lokalisiert werden muss.

Dieser Ansatz ermöglicht zwar die Erstellung lokalisierter Anwendungen, hat aber auch erhebliche Nachteile:

• Es sind mehrere Versionen des Quellcodes erforderlich, mindestens eine für die Quellsprache und eine für jede der Zielsprachen. Dies führt zu erheblichen Problemen beim Synchronisieren der verschiedenen Sprachversionen der Anwendung. Insbesondere, wenn ein Fehler im Code behoben werden muss, muss der Fehler in jeder Kopie des Quellcodes (eine pro Sprache) behoben werden.
• Es ist auch äußerst fehleranfällig, da Lokalisierer , die keine Entwickler sind, Änderungen am Quellcode vornehmen mussten, was zu einem erheblichen Risiko in Bezug auf die Codeintegrität führt.

Die Kombination dieser Nachteile macht dies zu einem äußerst ineffizienten Ansatz, und es wurde ein besseres Modell benötigt.

Logische Trennung von Code und lokalisierbaren Ressourcen

Eine deutliche Verbesserung gegenüber dem vorherigen Modell ist die logische Trennung von Code und lokalisierbaren Ressourcen für eine Anwendung. Dadurch wird der Code von den Ressourcen isoliert und sichergestellt, dass Code unverändert bleibt, wenn Ressourcen durch Lokalisierung geändert werden. Aus Implementierungssicht werden Zeichenfolgen und andere Benutzeroberflächenelemente in Ressourcendateien gespeichert, die relativ einfach zu übersetzen sind und logisch von den Codeabschnitten getrennt sind.

Im Idealfall kann das Hinzufügen von Unterstützung für eine bestimmte Sprache so einfach sein, wie das Übersetzen der lokalisierbaren Ressourcen in diese neue Sprache und die Verwendung dieser übersetzten Ressourcen, um eine neue lokalisierte Version der Anwendung zu erstellen – ohne dass Code geändert werden muss. Die folgende Abbildung veranschaulicht, wie Code und lokalisierbare Ressourcen innerhalb einer Anwendung logisch voneinander getrennt werden sollen.

Dieses Modell ermöglicht eine einfachere Erstellung lokalisierter Versionen einer Anwendung und stellt eine deutliche Verbesserung gegenüber dem vorherigen Modell dar. Dieses Modell, das durch die Verwendung von Ressourcenverwaltungstools implementiert wurde, war im Laufe der Jahre sehr erfolgreich und wird auch heute noch häufig von vielen Anwendungen verwendet. Es hat jedoch erhebliche Nachteile:

• Obwohl logisch getrennt, sind Code und lokalisierte Ressourcen weiterhin physisch in einer ausführbaren Datei verknüpft. Insbesondere ist die Bedienungsfähigkeit nach wie vor problematisch, da für denselben Codefehler (in allen Sprachversionen identisch) ein Patch pro Sprache erforderlich ist. Wenn die Anwendung in 20 Sprachen versendet wird, muss daher 20 Mal (einer für jede Sprache) ein Dienstpatch ausgegeben werden, obwohl der Code nur einmal behoben ist.
• Die Verteilung und Verwendung mehrsprachiger Anwendungen wird von diesem Modell nicht ausreichend unterstützt. Dies kann in OEM- und Unternehmensszenarien ein erhebliches Problem sein. Wenn ein Computer für instance von zwei Benutzern mit unterschiedlichen Sprachen gemeinsam genutzt werden soll, müssen Anwendungen zweimal mit diesem Modell installiert werden, und dann muss ein Mechanismus aktiviert werden, um zwischen den beiden Installationen zu wechseln. Dabei wird davon ausgegangen, dass keine zusätzlichen Abhängigkeiten vorhanden sind, die die Implementierung dieses Szenarios verhindern. Die folgende Abbildung zeigt ein Beispiel für einen einzelnen Codefehler, der zwei Patches erfordert.

Es ist klar, dass dieses Modell zwar in einigen Szenarien gut funktioniert, seine Einschränkungen für mehrsprachige Anwendungen und deren Bereitstellungen jedoch sehr problematisch sein können.

Eine Variante dieses Modells, die einige der Probleme mit mehrsprachigen Anwendungen lindert, ist das Modell, bei dem die lokalisierbaren Ressourcen eine Reihe verschiedener Sprachressourcen enthalten. Dieses Modell verfügt über eine gemeinsame Codebasis und mehrere Ressourcen für verschiedene Sprachen in derselben Anwendung. Beispielsweise kann eine Anwendung mit Englisch, Deutsch, Französisch, Spanisch, Niederländisch und Italienisch im selben Paket geliefert werden. Die folgende Abbildung zeigt eine Anwendung, die mehrere Sprachressourcen enthält.

Dieses Modell erleichtert die Verwaltung der Anwendung, wenn ein Codefehler behoben werden muss – was eine Verbesserung darstellt –, verbessert sich jedoch nicht gegenüber früheren Modellen, wenn es um die Unterstützung zusätzlicher Sprachen geht. In diesem Fall muss weiterhin eine neue Version der Anwendung veröffentlicht werden (und diese Version wird möglicherweise durch die Notwendigkeit erschwert, sicherzustellen, dass alle Sprachressourcen innerhalb derselben Distribution synchronisiert werden).

Physisches Trennen von Code und Ressourcen

Der nächste evolutionäre Schritt besteht darin, Code und Ressourcen physisch zu trennen. In diesem Modell werden die Ressourcen vom Code abstrahiert und physisch in verschiedenen Implementierungsdateien getrennt. Dies bedeutet insbesondere, dass der Code wirklich sprachunabhängig werden kann; Derselbe physische Code wird tatsächlich für alle lokalisierten Versionen einer Anwendung ausgeliefert. Die folgende Abbildung veranschaulicht, dass Code und lokalisierbare Ressourcen physisch getrennt werden müssen.

Dieser Ansatz hat gegenüber den vorherigen Ansätzen mehrere Vorteile:

• Die Bereitstellung mehrsprachiger Lösungen wird erheblich vereinfacht. Das Hinzufügen von Unterstützung für eine bestimmte Sprache erfordert nur den Versand und die Installation einer neuen Gruppe von Sprachressourcen für diese bestimmte Sprache. Dies ist besonders wichtig, wenn nicht alle Sprachressourcen gleichzeitig verfügbar sind. Mit diesem Modell kann eine Anwendung in einer Reihe von Kernsprachen bereitgestellt und die Anzahl der unterstützten Sprachen im Laufe der Zeit erhöht werden, ohne den tatsächlichen Code ändern oder erneut bereitstellen zu müssen. Dieser Vorteil wird durch einen Fallbackmechanismus erweitert, der eine teilweise Lokalisierung von Anwendungen und Systemkomponenten in einer bestimmten Sprache ermöglicht, indem sichergestellt wird, dass Ressourcen, die nicht in dieser bevorzugten Sprache gefunden werden, auf eine andere Sprache zurückgreifen, die die Benutzer auch verstehen. Insgesamt trägt dieses Modell dazu bei, die erhebliche Belastung globaler Unternehmen bei der Bereitstellung von Anwendungen in mehreren Sprachen zu verringern, da es die Bereitstellung einzelner Images auf viel effektivere Weise ermöglicht.
• Die Dienstbarkeit wurde verbessert. Ein Codefehler muss nur einmal behoben und bereitgestellt werden, da der Code vollständig lokalisierungsunabhängig ist. Bei diesem Modell ist das Ausstellen einer Korrektur für einen Codefehler, sofern die Änderung nicht auf die Benutzeroberfläche bezieht, viel einfacher und kostengünstiger als bei allen vorherigen Modellen.

Dynamisches Laden sprachspezifischer Ressourcen

Die grundlegenden Konzepte der MUI, Quellcode physisch von sprachspezifischen Ressourcen zu trennen und eine sprachneutrale Kernbinärdatei für eine Anwendung zu erstellen, richten im Wesentlichen eine Architektur ein, die für die Implementierung des dynamischen Ladens sprachspezifischer Ressourcen basierend auf Benutzer- und Systemspracheinstellungen förderlich ist.

Anwendungsquellcode, der in der sprachneutralen Kernbinärdatei gebündelt ist, kann MUI-APIs auf der Windows-Plattform verwenden, um die Auswahl der entsprechenden Anzeigebenutzeroberflächensprache für einen bestimmten Kontext zu abstrahieren. MUI unterstützt dies durch:

• Erstellen einer priorisierten Liste der Anzeigesprachen der Benutzeroberfläche basierend auf Einstellungen auf System-, Benutzer- und Anwendungsebene, Benutzerebene und Systemebene.
• Implementieren eines Fallbackmechanismus, der basierend auf der Verfügbarkeit lokalisierter Ressourcen einen geeigneten Kandidaten aus dieser priorisierten Liste von Sprachen auswählt.

Die Vorteile des dynamischen Ladens von Benutzeroberflächenressourcen mit priorisiertem Fallback sind:

• Es ermöglicht die teilweise Lokalisierung von Anwendungen und Systemkomponenten in einer bestimmten Sprache, da Ressourcen, die nicht in dieser bevorzugten Sprache gefunden werden, automatisch auf die nächste Sprache in der priorisierten Liste zurückfallen.
• Es ermöglicht Szenarien wie den dynamischen Wechsel von einer Sprache in eine andere.
• Es ermöglicht die Erstellung regionaler oder weltweiter Einzelbereitstellungsimages, die eine Reihe von Sprachen für OEMs und Unternehmen abdecken.

Erstellen von MUI-Anwendungen

In den vorherigen Abschnitten wurden die Optionen zum Trennen von Quellcode von sprachspezifischen Ressourcen und der daraus resultierende Vorteil erläutert, dass zentrale Windows-Plattform-APIs zum dynamischen Laden lokalisierter Ressourcen verwendet werden können. Dies sind zwar Richtlinien, aber es sollte auch darauf hingewiesen werden, dass es keine spezifische, präskriptive Möglichkeit gibt, eine MUI-Anwendung für die Windows-Plattform zu entwickeln.

Anwendungsentwickler haben die volle Wahl, wie sie verschiedene Benutzeroberflächenspracheinstellungen, Ressourcenerstellungsoptionen und Methoden zum Laden von Ressourcen behandeln. Entwickler können die in diesem Dokument bereitgestellten Richtlinien auswerten und eine Kombination auswählen, die ihren Anforderungen und ihrer Entwicklungsumgebung entspricht.

In der folgenden Tabelle sind die verschiedenen Entwurfsoptionen zusammengefasst, die Anwendungsentwicklern zur Verfügung stehen, die eine MUI-Anwendung für die Windows-Plattform erstellen möchten.

Spracheinstellungen für die Benutzeroberfläche	Ressourcenerstellung	Laden von Ressourcen
Befolgen Sie die Benutzeroberflächenspracheinstellungen im Betriebssystem${REMOVE}$	Einzelne Sprache in einer geteilten Ressourcenbinärdatei (MUI Resource Technology) Oder Mehrere Sprachen in einer nicht geteilten Ressourcenbinärdatei	Die Anwendung ruft Standardfunktionen zum Laden von Ressourcen auf. Ressourcen werden in den Sprachen zurückgegeben, die den Betriebssystemeinstellungen entsprechen.
	Anwendungsspezifischer Ressourcenmechanismus	Die Anwendung ruft die MUI-API auf, um die vom Thread bevorzugten Benutzeroberflächensprachen oder von Prozessen bevorzugten UI-Sprachen aus dem Betriebssystem abzurufen und diese Einstellungen zum Laden eigener Ressourcen zu verwenden.
Anwendungsspezifische Benutzeroberflächenspracheinstellungen${REMOVE}$	Einzelne Sprache in einer geteilten Ressourcenbinärdatei Oder Mehrere Sprachen in einer nicht geteilten Ressourcenbinärdatei	Die Anwendung ruft die MUI-API auf, um anwendungsspezifische Benutzeroberflächensprachen oder von Prozessen bevorzugte Benutzeroberflächensprachen festzulegen, und ruft dann Standardfunktionen zum Laden von Ressourcen auf. Ressourcen werden in den sprachen zurückgegeben, die von der Anwendung oder den Systemsprachen festgelegt werden. Oder Die Anwendung testet Ressourcen in einer bestimmten Sprache und verarbeitet ihre eigene Ressourcenextraktion aus den abgerufenen Binärdaten.
	Anwendungsspezifischer Ressourcenmechanismus	Die Anwendung verwaltet ihr eigenes Laden von Ressourcen.