Visual Studio auf Deutsch oder auf Englisch?

Werkzeuge  –  Kommentare

Entwicklungsteams fragen oft, ob man die deutsche oder die englische Version von Visual Studio zum Programmieren von (.NET-)Anwendungen einsetzen solle. Es gibt lustige und handfeste Gründe gegen die deutsche Version.

10 wichtige Fragen zu .NET

In dieser zehnteiligen Serie liefert .NET-Experte Holger Schwichtenberg Antworten auf die am häufigsten gestellten Fragen, die .NET-Entwickler beschäftigen.

  1. .NET 2.0 oder .NET 3.5?
  2. VB oder C#?
  3. Express oder Professional?
  4. Windows Forms oder WPF?
  5. LINQ-to-SQL oder ADO.NET Entity Framework?
  6. Visual Studio auf Deutsch oder auf Englisch?

Microsofts Visual Studio gibt es in zahlreichen Sprachen, darunter Deutsch und Englisch. Auch das .NET Framework kennt Sprachversionen, allerdings ist die Grundversion immer englisch. Durch optionale Sprachpakete (.NET Framework Language Packs) lassen sich zusätzliche Sprachen installieren. Man könnte vermuten, dass sich die Visual-Studio-Sprachversion nur auf den Entwickler und die des .NET Framework nur auf die Laufzeit der Anwendung auswirkt. Im Wesentlichen stimmt das, aber es gibt leider Ausnahmen.

.NET-Sprachpakete

Die .NET-Sprachpakete haben Einfluss auf die Fehlermeldungen und die in den Steuerelementen hinterlegten Texte. Dafür verantwortlich zeichnen die .NET-Laufzeitumgebung und die Fehlerklasse aus der .NET-Klassenbibliothek. Einige komplexere Steuerelemente wie ReportViewer (in Windows Forms) oder Login (in ASP.NET) enthalten zahlreiche Texte (zum Beispiel "Next Page", "Print", "Find", "Username", "Password"). Standardmäßig stehen beide Textarten zur Laufzeit einer .NET-Anwendung auf Englisch. Durch Installation der .NET-Sprachpakete lassen sich andere Sprachen einsetzen. Maßgeblich hierfür ist die Windows-Anzeigesprache, die nicht zu verwechseln ist mit der Tastatur- oder Formatsprache. Die meisten Windows-Betriebssysteminstallationen besitzen nur eine Anzeigesprache, die auf dem CD-Cover steht. Um eine solche Sprache wählen zu können, sind eine sogenannte Multi-User-Interface-Installation (MUI) oder spezielle Sprachpakete erforderlich, die es ab Windows Vista gibt.

Auf dem System sind Deutsch und US-Englisch für .NET 2.0, 3.0 und 3.5 installiert. Für .NET 1.1 und .NET 4.0 gibt es nur Englisch (Abb. 1).

Existiert für die aktuelle Sprache auf dem System ein .NET-Sprachpaket, verwendet man das. Andernfalls kommt Englisch zum Einsatz. Ein fremdsprachiges Betriebssystem, das ein .NET Framework enthält, besitzt automatisch das passende Paket. Ein .NET-Programm zeigt daher auf einem englischen Betriebssystem englische und auf einem deutschen System deutsche Fehlermeldungen. Anders verhält es sich, wenn man zusätzlich eine andere Version des .NET Framework installiert. Sie ist zunächst nur englisch. Man muss die Sprachpakete nachinstallieren, wobei es spezifische Pakete für jede .NET-Version und jedes Service Pack gibt (zum Beispiel Language Packs für .NET 2.0 SP1 und Language Packs für .NET 3.5 SP1). Welche Pakete installiert sind, kann man in der Registry unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NETFramework Setup\NDP (siehe Bildschirmabbildung) sehen. 1031 steht für Deutsch und 1033 für US-Englisch.

Zu beachten ist wieder, dass auf Vista, Windows 7 und Windows Server 2008 (einschließlich R2) der Sprachwechsel für .NET 2.0 und 3.0 nicht durch Installieren der .NET-Sprachpakete erfolgen kann, sondern die entsprechenden Betriebssystempakete zu installieren sind (siehe Microsoft Knowledge Base Beitrag Nummer 928637). Allerdings sind in der Registry die installierten .NET-Sprachpakete nicht zu erkennen.

Als Entwickler kann man im Programmcode die Anzeigesprache für die aktuelle Anwendung abweichend von der des Betriebssystems festlegen, indem man die Spracheinstellung des aktuellen Threads ändert:

System.Threading.Thread.CurrentThread.CurrentCulture = New
System.Globalization.CultureInfo("EN-US")

Alle .NET-Klassen orientieren sich an CurrentCulture – sofern das zugehörige Sprachpaket installiert ist. Ein Änderungsbefehl der CurrentCulture ist aber vor dem Öffnen eines Fensters auszuführen. Wurde das Fenster bereits gezeichnet, ist ein Sprachwechsel nicht mehr möglich.

Ausnahmen der Regel

Leider sind einige der .NET-Steuerelemente Spielverderber. Das bekannteste Beispiel ist BindingNavigator zum Navigieren in Datensätzen und Objektmengen in Windows Forms. Wenn der Entwickler es in ein Fenster legt, erzeugt Visual Studio neben diesem eine Reihe untergeordneter Steuerelemente für jede Schaltfläche im BindingNavigator. Visual Studio belegt die Schaltfläche mit Standardtexten, korrespondierend mit der Sprache der Entwicklungsumgebung. Folglich gehorchen die Texte zur Laufzeit nicht der Anzeigesprache des Betriebssystems. Der Entwickler muss durch Ressourcendateien die Übersetzungen hinterlegen. Gleiches gilt für Steuerelemente in ASP.NET, die man in Vorlagen zerlegen kann, um eine bessere Kontrolle über die Gestaltung zu bekommen. In den generierten Vorlagen ist die Sprache der verwendeten Entwicklungsumgebung fest verdrahtet.

Denglisch

Zum Glück ist die Anzahl der genannten Fälle gering. Entwickler haben im Wesentlichen bei der Sprache der Entwicklungsumgebung die freie Wahl. Wer Wert auf eine deutsche Visual-Studio-Oberfläche legt, braucht aber ein deutsches Betriebssystem oder zumindest ein MUI-Betriebssystem mit deutscher Anzeigesprache. Was passiert, wenn man ein deutsches Visual Studio auf einem englischen Betriebssystem installiert, zeigt Abbildung 2. Die zentralen Menüs und Dialoge sind zwar deutsch, man findet dennoch Englisch an vielen Orten. Dass die Steuerelement- und Attributnamen im Eigenschaftenfenster nicht übersetzt sind, ist gut. Aber auch die Kontextmenüs der Steuerelemente im Designer und die Rubriknamen im Eigenschaftsfenster erscheinen in Englisch, und die im Codeeditor angezeigten Kurzhilfen zu Klassen und Klassenmitgliedern sind wiederum deutsch.

Ein deutsches Visual Studio auf einem englischen Betriebssystem führt zu viel Sprachchaos (Abb. 2).

Selbst wenn man ein deutsches Visual Studio auf deutschem Betriebssystem verwendet, kommt man um Englisch nicht herum. Microsoft spricht auch dort von "Toolbox" statt "Werkzeugleiste" und bezeichnet mit "Any CPU" und "Mixed Plattforms" die unterschiedlichen "Build"-Konfigurationen. Auch "WCF Service Configuration Editor" ist zu lesen, obwohl es an anderer Stelle heißt "Dienstverweis hinzufügen".