ResX-Dateien und Ressourcendatei-Editoren: Der vollständige .NET-Lokalisierungsleitfaden

ResX-Dateien und Ressourcendatei-Editoren: Der vollständige .NET-Lokalisierungsleitfaden

Wenn Sie jemals einer .NET-Anwendung eine zweite Sprache hinzugefügt haben, sind Sie auf .resx-Dateien gestoßen. Sie bilden das Rückgrat der .NET-Lokalisierung — und existieren seit .NET Framework 1.0. Dieser Leitfaden erklärt, wie .resx-Dateien funktionieren, wie eine Lokalisierungsstruktur sowohl in ASP.NET Core als auch in WinForms/WPF korrekt aufgebaut wird, welche Editoren die Arbeit handhabbar machen und wann es sich lohnt, Alternativen zu betrachten.

TL;DR / Wesentliche Erkenntnisse

• Eine .resx-Datei ist eine XML-basierte Ressourcendatei, die .NET zum Speichern von lokalisierten Zeichenketten, Bildern und anderen Daten verwendet. Die Laufzeit lädt die korrekte Datei basierend auf der aktuellen Thread-Kultur.
• Das Satellitenassembly-Modell kompiliert gebietsschemaspezifische .resx-Dateien in separate .dll-Dateien, sodass Ihre Hauptanwendung ohne eingebettete Übersetzungen ausgeliefert wird.
• Visual Studio verfügt über einen eingebauten .resx-Editor, der jedoch bei mehr als einer Handvoll Sprachen schnell unhandlich wird. Drittanbieter-Tools wie ResXManager oder Zeta Resource Editor verbessern das mehrsprachige Bearbeitungserlebnis erheblich.
• Die .resx-Lokalisierung ist die richtige Standardwahl für Offline-Desktop-Anwendungen (WPF, WinForms, MAUI), bei denen alle Assets gebündelt werden müssen.
• Für Webanwendungen können CDN-basierte Auslieferungsplattformen .resx-Workflows ergänzen oder ersetzen und so die Zyklen aus Neukompilierung und erneutem Deployment für Übersetzungsaktualisierungen reduzieren.

Was sind ResX-Dateien?

Eine .resx-Datei ist eine XML-Ressourcendatei, die .NET verwendet, um benannte Schlüssel-Wert-Paare — typischerweise Zeichenketten — für eine bestimmte Sprache oder Kultur zu speichern. Wenn Ihre Anwendung ausgeführt wird, lädt die ResourceManager-Klasse die korrekte .resx-Datei basierend auf dem CultureInfo-Wert des aktuellen Threads und greift auf die Standard-Ressourcendatei (neutral) zurück, wenn keine gebietsschemaspezifische Datei vorhanden ist.

Die XML-Struktur

<?xml version="1.0" encoding="utf-8"?>
<root>
  <resheader name="resmimetype">
    <value>text/microsoft-resx</value>
  </resheader>
  <resheader name="version">
    <value>2.0</value>
  </resheader>
  <data name="WelcomeMessage" xml:space="preserve">
    <value>Willkommen in unserer Anwendung!</value>
    <comment>Wird im Hero-Bereich der Startseite angezeigt</comment>
  </data>
  <data name="SubmitButton" xml:space="preserve">
    <value>Absenden</value>
  </data>
</root>

Für eine französische Übersetzung erstellen Sie Strings.fr.resx neben Strings.resx. Die Laufzeit durchläuft die Kulturhierarchie vom Spezifischsten (fr-CA) über Neutral (fr) bis zum Standard (Strings.resx).

Satellitenassemblys

Der .NET-Compiler kompiliert gebietsschemaspezifische .resx-Dateien in Satellitenassemblys — separate .dll-Dateien in kulturcodierten Unterverzeichnissen. Laut Microsofts Dokumentation ermöglicht dies Teams, Sprachen unabhängig voneinander zu aktualisieren.

Einrichten der ResX-basierten Lokalisierung

Schritt 1: Ressourcendateien erstellen

Resources/
  Strings.resx         ← Standard (Englisch)
  Strings.fr.resx      ← Französisch
  Strings.de.resx      ← Deutsch
  Strings.ja.resx      ← Japanisch

Schritt 2: Auf Ressourcen in C# zugreifen

using MyApp.Resources;
string message = Strings.WelcomeMessage;

Schritt 3: Kultur festlegen

Thread.CurrentThread.CurrentUICulture = new CultureInfo("fr");

Verwenden Sie in ASP.NET Core RequestLocalizationMiddleware.

Schritt 4: IStringLocalizer verwenden

public class HomeController : Controller
{
    private readonly IStringLocalizer<HomeController> _localizer;
    public HomeController(IStringLocalizer<HomeController> localizer) => _localizer = localizer;
    public IActionResult Index()
    {
        ViewData["Message"] = _localizer["WelcomeMessage"];
        return View();
    }
}

Siehe die ASP.NET Core-Lokalisierungsdokumentation.

Schritt 5: WPF und WinForms

<TextBlock Text="{x:Static props:Strings.WelcomeMessage}" />

Die besten Ressourcendatei-Editoren

ResXManager ist das am häufigsten verwendete Tool — Open-Source, nebeneinander liegende Bearbeitung, Hervorhebung fehlender Übersetzungen.

Häufige Probleme

Übersetzungen werden nicht angezeigt? Überprüfen Sie die Groß-/Kleinschreibung bei Dateinamen (Linux/macOS), das Vorhandensein der Satellitenassembly und ResourcesPath in AddLocalization().

Kultur-Fallback: fr-CA → fr → Standard. Fehlende Schlüssel fallen stillschweigend zurück.

Tausende von Schlüsseln? Nach Funktionsbereich aufteilen: Strings.Common.resx, Strings.Checkout.resx usw.

Dateien synchron halten? Verwenden Sie die Ansicht für fehlende Übersetzungen in ResXManager oder eine Überprüfung zur Build-Zeit.

Moderne Alternativen

JSON-basiert: IStringLocalizer<T> funktioniert mit JSON-Anbietern. In Pull Requests besser lesbar, aber kein stark typisierter Wrapper.

CDN-basiert: Better i18n liefert Übersetzungen vom Edge-Netzwerk von Cloudflare. Zeichenketten ohne erneutes Deployment aktualisieren.

Wann .resx weiterhin die richtige Wahl ist: Desktop-Anwendungen (WPF, WinForms, MAUI), die offline funktionieren müssen. Satellitenassemblys sind das korrekte Modell dafür.

Fazit

Beginnen Sie für jedes .NET-Projekt mit .resx und Visual Studio. Fügen Sie ab 3 oder mehr Sprachen ResXManager hinzu. Erwägen Sie JSON oder CDN für web-orientierte Projekte. Behalten Sie .resx für Desktop-Anwendungen bei.

Referenzen

• ASP.NET Core-Lokalisierung
• Satellitenassemblys
• ResourceManager
• ResXManager
• Zeta Resource Editor

Zuletzt aktualisiert: März 2026