Mehrsprachigkeit für WinForms/WPF-Anwendungen ── resx, Satelliten-Assemblies und Kulturumschaltung in der Praxis

„Wir möchten dieselbe Anwendung auch in unseren Auslandsstandorten einsetzen“, „In der Fabrik arbeiten immer mehr fremdsprachige Mitarbeiter, daher soll die Oberfläche auch auf Englisch verfügbar sein“ ── die Mehrsprachigkeit einer Windows-Desktopanwendung klingt als Anforderung einfach, doch sobald man sich an die Umsetzung macht, häufen sich die Entscheidungsfragen: „Wie setzt man resx richtig ein?“, „WPF bietet mehrere Ansätze – welcher ist der richtige?“, „Lässt sich die Sprache zur Laufzeit umschalten?“

In diesem Artikel gehen wir von WinForms/WPF-Businessanwendungen aus und ordnen die Grundlagen der .NET-Lokalisierung (Kulturen und Ressourcen-Fallback), die Funktionsweise von resx und Satelliten-Assemblies, die je nach Framework realistischen Ansätze, die Umschaltung zur Laufzeit sowie Themen jenseits reiner Zeichenketten (Formatierung, Layout, RTL) in der Reihenfolge, in der in der Praxis Entscheidungsschwierigkeiten auftreten.

1. Fazit vorab (Entscheidungstabelle)

Der geeignete Ansatz zur Mehrsprachigkeit ergibt sich aus der Kombination von Framework und Anforderungen.

Die wichtigsten Punkte vorab:

• CurrentCulture (Formatierung) und CurrentUICulture (Ressourcensprache) sind zwei verschiedene Dinge. Diese Unterscheidung bildet das Fundament des gesamten Designs für Mehrsprachigkeit (Kapitel 2).
• Ressourcen bestehen konkret aus „Ressourcen der neutralen Sprache + sprachspezifischen Satelliten-Assemblies“, und der Fallback erfolgt automatisch. Die Suche verläuft in der Reihenfolge ja-JP → ja → neutral, sodass die Anwendung auch bei fehlender Übersetzung nicht abstürzt, sondern die Standardsprache anzeigt².
• Bei WinForms besteht die praxistaugliche Lösung in der Kombination aus Designer-Ansatz (Localizable = true) und gemeinsamer resx. Bildschirme werden über den Designer-Ansatz behandelt, Meldungsfenster und gemeinsame Texte über gemeinsame resx (Kapitel 4).
• Der in der offiziellen Walkthrough-Dokumentation für WPF beschriebene LocBaml-Ansatz funktioniert unter .NET (Core) nicht¹. In der heutigen Praxis ist der resx-Ansatz mit x:Static (oder Bindung) die erste Wahl (Kapitel 5).
• Für die Sprachumschaltung zur Laufzeit sollte „Wirksam ab dem nächsten Start“ die erste Wahl sein. Denn die Ressourcen bereits angezeigter Bildschirme werden nicht automatisch ausgetauscht (Kapitel 6).
• Die Übersetzung von Zeichenketten macht nur die Hälfte der Mehrsprachigkeit aus. Die andere Hälfte umfasst die Layoutanpassung an die übersetzte Textlänge, die Formatierung von Datum und Zahlen, Schriftarten sowie die Unterstützung von rechts-nach-links geschriebenen Sprachen (RTL) (Kapitel 7).

2. Grundlagen ── Der Unterschied zwischen CurrentCulture und CurrentUICulture

Bei den Kultureinstellungen (Culture) in .NET gibt es zwei Eigenschaften mit unterschiedlichen Aufgaben³.

Diese beiden lassen sich unabhängig voneinander einstellen. Eine Kombination wie „Oberfläche auf Englisch, aber Datum und Währung im japanischen Format“ (eine häufige Anforderung bei Businessanwendungen für fremdsprachige Mitarbeiter in Japan) lässt sich mit CurrentUICulture = en und gleichzeitig CurrentCulture = ja-JP natürlich abbilden.

Da beide Standardwerte von den Betriebssystemeinstellungen abgeleitet werden, gilt als Ausgangspunkt: „Ohne weiteres Zutun folgt die Anwendung dem Betriebssystem.“ Wenn die Sprache für die gesamte Anwendung explizit umgeschaltet werden soll, ersetzt man nicht die Einstellung pro Thread, sondern die Standardwerte selbst.

using System.Globalization;

// Ersetzt die Standardkultur aller ab jetzt erzeugten Threads
// (vor Erzeugung des UI-Threads ausführen, d. h. vor Application.Run)
CultureInfo.DefaultThreadCurrentUICulture = new CultureInfo("en"); // Ressourcensprache
CultureInfo.DefaultThreadCurrentCulture = new CultureInfo("ja-JP"); // Formatierung

Eine Zuweisung an Thread.CurrentThread.CurrentUICulture wirkt sich nur auf diesen einen Thread aus. Bei Businessanwendungen, die durch async/await oder Hintergrundverarbeitung threadübergreifend arbeiten, ist es sicherer, die Standardwerte selbst über DefaultThreadCurrentUICulture / DefaultThreadCurrentCulture zu ändern³.

Für Protokolle, Dateiausgaben und die Formatierung bei der Kommunikation zwischen Systemen sollte man nicht der Kultur des Benutzers folgen, sondern sie fest auf CultureInfo.InvariantCulture setzen. Zum Gesamtdesign der Datumsformatierung siehe „Datum, Uhrzeit und Zeitzonen-Design für Businessanwendungen“.

3. Funktionsweise der Ressourcen ── resx, Satelliten-Assemblies und Fallback

Die Lokalisierung in .NET folgt einem „Hub-and-Spoke“-Modell. Die Ressourcen der Standardsprache (neutral) werden in die Hauptassembly eingebettet, während sprachspezifische Ressourcen in separate DLLs, die sogenannten Satelliten-Assemblies, ausgelagert werden⁴.

Nach dem Build ergibt sich für die sprachspezifischen resx-Dateien folgende Ausgabestruktur:

MyApp.exe                     ← Hauptprogramm (enthält die neutralen Ressourcen)
MyApp.dll
ja/MyApp.resources.dll        ← Satelliten-Assembly für Japanisch
en/MyApp.resources.dll        ← Satelliten-Assembly für Englisch

Zur Laufzeit sucht der Ressourcen-Manager ausgehend von CurrentUICulture die Ressourcen in der Reihenfolge spezifische Kultur (ja-JP) → neutrale Kultur (ja) → Standard (Hauptassembly)². Dank dieses automatischen Fallbacks stürzt die Anwendung auch bei einer fehlenden Übersetzung nicht ab, sondern zeigt die Zeichenkette der Standardsprache an. Umgekehrt ist es ein Zeichen für eine fehlende Übersetzung, wenn auf einer eigentlich englischen Oberfläche vereinzelt Japanisch auftaucht – das lässt sich als Testkriterium nutzen (Kapitel 8).

In der Praxis sind folgende zwei Punkte zu beachten:

• Wenn man mit dem Attribut NeutralResourcesLanguage deklariert, welcher Kultur die Standardsprache entspricht, entfällt bei der Standardkultur die unnötige Suche nach einer Satelliten-Assembly, und der Endpunkt des Fallbacks wird eindeutig⁴.
• Satelliten-Assemblies funktionieren erst, wenn sie zusammen mit der Hauptassembly ausgeliefert werden, daher müssen die Sprachordner beim Design von Installationsprogrammen oder Kopierverteilungen berücksichtigt werden (Kapitel 8).

4. WinForms in der Praxis ── Designer-Ansatz und gemeinsame resx

Bei WinForms gibt es zwei Ansätze, die in der Praxis kombiniert eingesetzt werden.

4.1 Bildschirme über den Designer-Ansatz (Localizable = true)

Setzt man in den Eigenschaften der Form Localizable auf true, wechselt die Language-Eigenschaft zur Zielsprache (z. B. Englisch) und bearbeitet dann die Text-Eigenschaft von Beschriftungen und Schaltflächen, erzeugt Visual Studio automatisch eine sprachspezifische resx-Datei wie Form1.en.resx⁵.

Die Stärke dieses Ansatzes liegt darin, dass nicht nur die Zeichenketten, sondern auch Größe und Position der Steuerelemente pro Sprache gespeichert werden. Ein Problem wie „登録“ (Register), das auf Japanisch in eine Schaltfläche passt, auf Englisch als „Register“ aber darüber hinausragt, lässt sich im Designer für jede Sprache separat anpassen. Andererseits vervielfacht sich die Anzahl der resx-Dateien mit Anzahl der Sprachen mal Anzahl der Formulare, und bei jeder Layoutänderung eines Formulars müssen alle Sprachen erneut geprüft werden – das erzeugt Wartungskosten. Wenn mit einer wachsenden Sprachenzahl zu rechnen ist, sollten Sie den Layoutmaßnahmen aus Kapitel 7 den Vorzug geben und Bildschirme von vornherein so konstruieren, dass sie auch ohne Nachjustierung nicht auseinanderbrechen.

4.2 Meldungen und gemeinsame Texte über gemeinsame resx

Zeichenketten, die aus dem Code heraus verwendet werden – Texte von Meldungsfenstern, Bestätigungsdialogen, Statusleistenanzeigen usw. – werden in der projektweiten Resources.resx gesammelt, ergänzt um sprachspezifische Dateien wie Resources.en.resx. Da aus der resx automatisch eine typisierte Klasse generiert wird, lässt sich aus dem Code ohne Tippfehler bei den Schlüsseln darauf zugreifen.

// Zugriff über die generierte typisierte Klasse.
// Die zurückgegebene Zeichenkette wechselt automatisch entsprechend CurrentUICulture
MessageBox.Show(
    Properties.Resources.ConfirmDeleteMessage,
    Properties.Resources.ConfirmTitle,
    MessageBoxButtons.YesNo);

Die wichtigste Regel dabei lautet: Zeichenketten, die dem Benutzer angezeigt werden, nicht direkt im Code hartcodieren. Der Aufwand für die Mehrsprachigkeit fließt nicht in die Einführung des Mechanismus, sondern in das „Einsammeln der verstreuten, hartcodierten Zeichenketten“. Genau darin liegt der Wert, schon in der einsprachigen Betriebsphase über resx zu arbeiten.

5. WPF in der Praxis ── resx statt LocBaml als erste Wahl

Die Mehrsprachigkeit bei WPF ist ein Bereich, in dem Informationen leicht durcheinandergeraten. In der offiziellen Walkthrough-Dokumentation wird ein Ansatz beschrieben, bei dem UICulture in der Projektdatei gesetzt wird, um BAML-Ressourcen zu erzeugen, und Übersetzungen anschließend mit dem Tool LocBaml eingefügt werden. LocBaml ist jedoch ein Beispieltool ausschließlich für WPF unter .NET Framework und funktioniert bei WPF unter .NET (Core) nicht¹. Betrachten Sie diesen Ansatz nicht als Option für Neuentwicklungen.

Die erste Wahl in der Praxis besteht darin, denselben gemeinsamen resx-Ansatz wie bei WinForms zu verwenden und ihn aus XAML heraus zu referenzieren.

<!-- Zugriffsmodifizierer der resx auf Public setzen und dann über x:Static referenzieren -->
<Window xmlns:res="clr-namespace:MyApp.Properties"
        Title="{x:Static res:Resources.MainWindowTitle}">
    <Button Content="{x:Static res:Resources.SaveButton}" />
</Window>

Der Vorteil dieses Ansatzes ist, dass der Ressourcenmechanismus (Satelliten-Assemblies, Fallback) vollständig mit WinForms übereinstimmt, sodass sich Texte auch in gemischten Solutions zentral verwalten lassen. Da x:Static eine statische Referenz ist, die beim Start aufgelöst wird, sollte man bei Bedarf einer Laufzeitumschaltung zu Bindung mit Änderungsbenachrichtigung übergehen (Kapitel 6).

Setzt man zusätzlich im XAML das xml:lang-Attribut des Wurzelelements, funktionieren sprachabhängige WPF-Funktionen wie Silbentrennung, Font-Fallback und Zahlendarstellung korrekt¹.

Zur Entscheidung, ob man mit WinForms oder WPF entwickeln sollte, siehe „Entscheidungstabelle für die Wahl zwischen WinForms, WPF und WinUI“.

6. Sprachumschaltung zur Laufzeit ── „Wirksam ab dem nächsten Start“ als erste Wahl

Wenn die Anforderung besteht, die Sprache im Einstellungsbildschirm auswählen zu lassen, wählt man zwischen zwei Varianten, wann die Änderung wirksam wird.

• Variante A: Wirksam ab dem nächsten Start (empfohlen). Die gewählte Sprache wird in einer Konfigurationsdatei gespeichert, und DefaultThreadCurrentUICulture wird beim Start vor Application.Run (bei WPF vor dem Start der Application) gesetzt. Die Implementierung ist einfach, und Probleme, die mit einem Neuaufbau der Oberfläche einhergehen (Verlust gerade eingegebener Daten, doppelte Registrierung von Event-Handlern usw.), können strukturell gar nicht erst auftreten.
• Variante B: Sofortige Wirksamkeit. Selbst wenn man CurrentUICulture ändert, werden die Zeichenketten bereits angezeigter Bildschirme nicht automatisch ausgetauscht. Beim WinForms-Designer-Ansatz müsste man die Ressourcen mit ComponentResourceManager.ApplyResources erneut auf die geöffneten Formulare anwenden, bei WPF die Zeichenketten über Bindung mit Änderungsbenachrichtigung liefern – in jedem Fall setzt diese Umsetzung voraus, dass alle Bildschirme die erneute Anwendung von Ressourcen unterstützen.

Bei Businessanwendungen steht der Implementierungs- und Testaufwand von Variante B angesichts der Häufigkeit eines Sprachwechsels (in der Regel einmalig bei der Einführung) oft in keinem Verhältnis zum Nutzen. Es empfiehlt sich daher, Variante A als Standard zu wählen und Variante B nur dann einzusetzen, wenn sie als Anforderung wirklich zwingend ist. Da die Spracheinstellung eine benutzerbezogene Einstellung ist, ist als Speicherort %LOCALAPPDATA% angemessen. Zur Entscheidung über den Ablageort von Einstellungen siehe die Entscheidungstabelle in „Konfigurationsverwaltung für Windows-Businessanwendungen in der Praxis“.

7. Mehrsprachigkeit jenseits von Zeichenketten ── Layout, Formatierung, Schriftarten und RTL

Auch wenn die Übersetzung abgeschlossen ist, bleibt bei der Mehrsprachigkeit noch die halbe Arbeit übrig.

• Layoutflexibilität. Selbst bei inhaltlich gleicher Bedeutung unterscheidet sich die Länge eines Textes stark je nach Sprache (Japanisch „保存“ → Deutsch „Speichern“). Ein Layout mit festen Koordinaten und festen Größen bricht bei jeder Übersetzung auseinander; bei WinForms ist die von Microsoft offiziell empfohlene Methode, TableLayoutPanel mit AutoSize zu kombinieren, damit sich das Layout an die Textlänge anpasst⁶. Da das Layoutsystem von WPF von Haus aus flexibel ist, reicht es meist aus, feste Breiten zu vermeiden. Es empfiehlt sich, dies zugleich mit Maßnahmen gegen Darstellungsprobleme bei hoher DPI zu konzipieren („WinForms-Leitfaden für hohe DPI“, „WPF-Leitfaden für hohe DPI“), um spätere Nacharbeiten zu vermeiden.
• Formatierung von Datum, Zahlen und Währung. Überlassen Sie die Bildschirmanzeige CurrentCulture und reduzieren Sie fest codierte Aufrufe wie ToString("yyyy/MM/dd") im Bildschirmcode. Für Dateien, Protokolle und Austauschdaten gilt umgekehrt die feste Bindung an InvariantCulture (Kapitel 2).
• Schriftarten. Prüfen Sie, ob die Zeichen der Zielsprache in der Schriftart enthalten sind. Kommen Chinesisch (vereinfacht/traditionell) oder Koreanisch hinzu, können die Zeichenformen bei einer für Japanisch ausgelegten Schriftart unnatürlich wirken (das bekannte CJK-Glyphenproblem). Bündelt man die Angabe der UI-Schriftart an einer zentralen Stelle, wird die Änderung beim Hinzufügen weiterer Sprachen einfacher.
• Von rechts nach links geschriebene Sprachen (RTL). Für die Unterstützung von Arabisch oder Hebräisch braucht es neben der Übersetzung der Zeichenketten auch eine Spiegelung des Layouts. Bei WinForms steuert man dies über die Eigenschaften RightToLeft / RightToLeftLayout, bei WPF über die Eigenschaft FlowDirection. Da eine nachträgliche RTL-Unterstützung eine Überarbeitung sämtlicher Bildschirme bedeutet, sollten Sie sie von Anfang an in die Anforderungen aufnehmen, falls eine solche Zielsprache in Betracht kommt.
• Text in Bildern und Symbolen. In Bilder eingebrannte Zeichenketten lassen sich über den Ressourcenmechanismus nicht umschalten. Vermeiden Sie Bilder mit eingebettetem Text und setzen Sie stattdessen auf eine Kombination aus Bild und separatem Textlabel, um auf der sicheren Seite zu sein.

Zu allgemeinen Entscheidungen im UI-Design siehe auch „Entscheidungstabelle für das UX-Design von Windows-Anwendungen“.

8. Betrieb ── Übergabe von Übersetzungen, Erkennung fehlender Übersetzungen und Auslieferung

Zum Abschluss die betrieblichen Aspekte, nachdem der Mechanismus einmal steht.

• Bei der Übergabe von Übersetzungen Kontext mitliefern. Übergibt man nur Schlüssel und Ausgangstext der resx, wird die Qualität kurzer Texte wie „OK“ oder „Öffnen“ instabil. Praktikabel ist ein Austausch über eine Zuordnungstabelle (z. B. Tabellenkalkulation) mit Schlüssel, Ausgangstext, Übersetzung und einem Hinweis, „auf welchem Bildschirm und wofür der Text angezeigt wird“, die nach Erhalt in die resx übernommen wird.
• Fehlende Übersetzungen über den Fallback erkennen. Durch den Ressourcen-Fallback zeigen sich fehlende Übersetzungen dadurch, dass „auf dem Bildschirm dieser Sprache die Standardsprache durchscheint“². Es lohnt sich, eine einfache Prüfung (Skript oder Testcode) in die CI aufzunehmen, die die Schlüsselliste der sprachspezifischen resx mit der neutralen resx abgleicht, damit sich dies vor der Veröffentlichung maschinell erkennen lässt.
• Satelliten-Assemblies in die Auslieferung einbeziehen. Werden die Sprachordner wie ja/ oder en/ nicht mitgeliefert, fällt genau diese Sprache auf die Standardsprache zurück, und es entsteht der Zustand „übersetzt, aber die Übersetzung wirkt sich nicht aus“. Dass beim manuellen Kopieren ein Sprachordner vergessen wird, ist ein klassischer Fehler; daher sollte die gesamte Verzeichnisstruktur in das Installationsprogramm (MSI/MSIX usw.) aufgenommen werden. Bei der ClickOnce-Bereitstellung werden standardmäßig die Satelliten-Assemblies aller Sprachen in die Bereitstellung aufgenommen⁷. Zur Gesamtentscheidung über die Verteilungsmethode siehe „Auswahl der Verteilungsmethode für Windows-Anwendungen“.

Zusammenfassung

Die Mehrsprachigkeit von Desktopanwendungen beruht auf dem bewährten Mechanismus aus resx und Satelliten-Assemblies, und der Mechanismus selbst ist nicht schwierig. Über Erfolg oder Misserfolg in der Praxis entscheiden ein Design, das CurrentCulture und CurrentUICulture klar unterscheidet, die Disziplin, dem Benutzer angezeigte Zeichenketten nicht hartzucodieren, ein Layout, das der übersetzten Textlänge standhält, sowie die sorgfältige Prüfung der Anforderung, ob eine sofortige Umschaltung wirklich notwendig ist. Bei WPF sollte man sich nicht von veralteten Informationen zum LocBaml-Ansatz beeinflussen lassen – ein Aufbau auf resx-Basis ist die heute gängige Praxislösung.

Die Wahl des Ansatzes für die nachträgliche Mehrsprachigkeit einer bestehenden Anwendung und die Abschätzung der betroffenen Bereiche sowie die mehrsprachige Umsetzung von Bildschirmen, Berichten und Austauschdaten im Hinblick auf die Expansion ins Ausland erfordern häufig eine Beurteilung anhand des aktuellen Zustands der Codebasis. Zögern Sie im Zweifelsfall nicht, uns zu kontaktieren.

Verwandte Artikel

• Entscheidungstabelle für die Wahl zwischen WinForms, WPF und WinUI
• Entscheidungstabelle für das UX-Design von Windows-Anwendungen
• Datum, Uhrzeit und Zeitzonen-Design für Businessanwendungen
• WinForms-Leitfaden für hohe DPI
• WPF-Leitfaden für hohe DPI
• Nicht nur appsettings.json ── Konfigurationsverwaltung für Windows-Businessanwendungen in der Praxis
• Auswahl der Verteilungsmethode für Windows-Anwendungen (MSI / MSIX / ClickOnce / xcopy / eigener Updater)
• Funktionsweise des Windows-Benutzerprofils

Verwandte Beratungsbereiche

Komura Soft GmbH (合同会社小村ソフト) bietet technische Beratung zum Design und zur Implementierung der Mehrsprachigkeit von WinForms/WPF-Anwendungen sowie zur Auswahl des Ansatzes und zur Abgrenzung der Auswirkungen bei der nachträglichen Mehrsprachigkeit bestehender Anwendungen an.

• Windows-Anwendungsentwicklung
• Technische Beratung und Design-Review
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Kann eine bestehende, rein japanischsprachige Anwendung nachträglich mehrsprachig gemacht werden?

Ja, das ist möglich. Der Großteil der Arbeit besteht dabei jedoch nicht in der „Einführung des Ressourcenmechanismus“, sondern im „Auffinden und Ersetzen der im Code hartcodierten Zeichenketten“. Es müssen nicht nur die Texte der Bildschirme erfasst werden, sondern auch Meldungsfenster, Protokolle, Ausnahmemeldungen, Berichte sowie in der Datenbank gespeicherte Anzeigetexte – der Umfang bemisst sich weniger an der Anzahl der Bildschirme als an der Verteilung der Zeichenketten. Führt man bereits in der Neuentwicklungsphase zumindest die dem Benutzer angezeigten Zeichenketten über resx, sinken die künftigen Kosten für die Mehrsprachigkeit um Größenordnungen.

Reicht es, die Übersetzung mit maschineller Übersetzung zu erledigen?

Für interne Tools oder eine vorläufige Lösung ist es realistisch, mit maschineller Übersetzung zu beginnen. Businessanwendungen enthalten jedoch viele kurze Wörter auf Schaltflächen und in Menüs (z. B. „Registrieren“, „Abbrechen“), und in diesem Bereich steigt die Fehlerquote maschineller Übersetzung ohne Kontext deutlich an. Es empfiehlt sich, den Bildschirm zumindest einmal von einer Person durchsehen zu lassen, die die Zielsprache tatsächlich verwendet. Wichtiger als die Übersetzungsqualität selbst ist zudem, vorab über TableLayoutPanel und AutoSize sicherzustellen, dass ein längerer übersetzter Text das Layout nicht zerstört.

Sollten auch Protokolle und Fehlermeldungen übersetzt werden?

In der Praxis hat es sich bewährt, Meldungen, die dem Benutzer auf dem Bildschirm angezeigt werden, zu übersetzen, Inhalte, die in Protokolldateien oder das Ereignisprotokoll geschrieben werden, hingegen nicht zu übersetzen (die Sprache dort fest zu belassen). Protokolle werden nicht von Benutzern, sondern von Entwicklern und Betriebspersonal gelesen, und mehrsprachige Protokolle zerstören die Durchsuchbarkeit bei der Fehlersuche. Auch die Formatierung (Datum, Zahlen) sollte in Protokollen fest auf CultureInfo.InvariantCulture gesetzt werden. Ein Design, das CurrentCulture und CurrentUICulture getrennt behandelt, ermöglicht diese Unterscheidung ganz natürlich.

Sollte sich die Sprache der Anwendung unabhängig von der Anzeigesprache des Betriebssystems umschalten lassen?

Bei der Expansion an ausländische Standorte oder bei Businessanwendungen, die in Japan von fremdsprachigen Mitarbeitern genutzt werden, ist eine eigene Spracheinstellung in der Anwendung sehr wertvoll. Empfehlenswert ist ein zweistufiges Vorgehen: standardmäßig der Anzeigesprache des Betriebssystems folgen (Standardwert von CurrentUICulture) und diese nur überschreiben, wenn im Einstellungsbildschirm ausdrücklich eine andere Sprache gewählt wurde. Am sichersten ist es, die Umschaltung erst „beim nächsten Start“ wirksam werden zu lassen – das vereinfacht sowohl die Implementierung als auch die Erklärung im Betrieb.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.