zurück zum Artikel

Entwicklungsteams fragen oft, ob man die deutsche oder die englische Version der IDE zum Programmieren von .NET-Anwendungen einsetzen solle. Es gibt handfeste Gründe gegen die deutsche Version.

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.

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.

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 [6] und Language Packs für .NET 3.5 SP1 [7]). 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 [8]). 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.

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".

Übersetzungsfehler

Übersetzungsfehler

Manche Übersetzung amüsiert, aber manchmal ist nur noch schwer, der Sinn zu erfassen. Ein weiteres Beispiel illustriert das Gegenüberstellen eines Klassendiagramms aus der deutschen und der englischen Visual-Studio-Dokumentation (siehe Abbildung 3). In der englischen Version zeigt das Diagramm eine Hierarchie von Klassen. In der deutschen wurden die Klassennamen zum Teil übersetzt ("Webverwaltungsereignis" statt "WebManagementEvent" und "WebBase-Ereignis" statt "WebBaseEvent"). Das ist ein schwerer Fauxpas, weil ein Entwickler, der die Abbildung sieht, nur schwerlich jemals die passenden Klassen findet.

In Abbildung 4 hat der Compiler natürlich Recht damit, dass "base" hier verboten ist. Das C#-Sprachschlüsselwort "base" heißt auch in der deutschen Version genau so. "Basis" gibt es hingegen nicht.

Der in Abbildung 5 erwähnte "eigene Namespace" in Visual Basic heißt im englischen Original "My Namespace", wobei "My" ein Schlüsselwort ist und nicht hätte übersetzt werden dürfen, während "Namespace" sich für eine Übersetzung angeboten hätte.

Lustig ist der Übersetzungsfehler in einem der mitgelieferten Code Snippets (siehe Abbildung 6). Was ist wohl mit "Zugriffsdaten in ein Dataset lesen" gemeint? In der englischen Version heißt es "Read Access Data into a Dataset". Es war eine Microsoft-Access-Datenbank gemeint, nicht "Zugriffsdaten".

Das "Schießen des Dialogfelds beenden" heißt es in der deutschen Dokumentation (siehe Abbildung 7). Selbst wenn man sich das fehlende "l" hinzudenkt, bleibt der Satz schwer verständlich. Im Englischen heißt es "stop the closing". Eine verständliche deutsche Übersetzung wäre gewesen "verhindern, dass sich das Dialogfeld schließt".

Abbildung 8 zeigt einen Fall, bei dem die deutsche Übersetzung überhaupt nicht verständlich ist.

Schwierigkeiten mit dem Plural

Schwierigkeiten mit dem Plural

Während die obigen Beispiele noch lustig sind, können Ungereimtheiten bei der Übersetzung von Visual Studio zu Kompilierungsfehlern führen, wie man bei den objekt-relationalen Mappern LINQ-to-SQL und ADO.NET Entity Framework [9] sieht. Ersterer erzeugt beim Generieren eines Objektmodells aus einer Datenbank für jede Tabelle eine Klasse und im Kontextobjekt ein Attribut, das die Menge aller Instanzen liefert. Das Attribut setzt Visual Studio in der englischen Version durch Anhängen eines "s" automatisch in den Plural. Aus der Tabelle "Rechnung" wird plötzlich "Rechnungs". Die Visual-Studio-Übersetzer haben sich überlegt, dass das für deutsche Wörter keinen Sinn ergibt, und die "Pluralisierung" in den Visual-Studio-Optionen im Standard ausgeschaltet. Das ist so lange nicht schlimm, wie alle Entwickler in einem Team entweder die deutsche oder die englische Version verwenden.

Kommt es zur Sprachmischung, besteht Kollisionsgefahr. Denn für ein englisches Modell geschriebener Code kompiliert nicht mehr, sobald es ein Entwickler mit einer deutschen Version ändert. Umgehen kann man das, indem man in Visual Studio unter Tools | Options | Database Tools | O/R Designer | Pluralization of name einheitlich auf allen Systemen "true" oder "false" wählt. Der Autor hat leider einige Entwickler getroffen, die lange mit dem plötzlich verschwindenden und wiederkehrenden "s" kämpfen mussten, denn eine Warnung davor gibt es nirgendwo in der Dokumentation.

Die oben dargestellte Option wirkt sich interessanterweise nicht auf das ADO.NET Entity Framework aus. Hier erfolgt die Pluralbildung nicht mit angefügtem "s", sondern durch Anhängen des Worts "Set". Aus "Rechnung" wird "RechnungSet" – aber nur in der englischen Version. Die deutsche macht daraus "RechnungMenge", und schon ist das Problem wieder vorhanden, wenn man deutsche und englische Visual-Studio-Ausgaben in einem Team mischt.

Noch mehr Argumente

Wer immer noch amüsiert ist, dem seien zwei handfeste Vorteile einer englischen Version genannt:

1. Da es auf der Welt mehr englisch- als deutschsprachige Entwickler gibt, wird man bei der Suche nach Hilfen und Tipps im World Wide Web besser fündig, wenn man den englischen Fehlertext oder einen Begriff aus einem Dialog in eine Suchmaschine eingibt.
2. Es gibt immer wieder Visual-Studio-Erweiterungen, die nur in englischer Sprache verfügbar sind. Die Werkzeuge kann man dann entweder gar nicht installieren, oder der Entwickler erhält eine noch verwirrendere Mischung aus deutscher und englischer Benutzeroberfläche.

Fazit

Der Autor ist kein Verächter der deutschen Sprache, sondern setzt sich aktiv gegen unnötige Anglizismen in der Fachsprache ein (zum Beispiel "Protokoll" statt "Log" und "heruntergeladen" statt – wie Windows es meint – "downgeloaded"). Bei der täglichen Entwicklungsarbeit verwendet er (wie die meisten seiner Kollegen) ausschließlich eine englische Visual-Studio-Version, weil er damit produktiver ist. Das ist auch sein Rat an jeden .NET-Entwickler in Deutschland, sofern er nur etwas der englischen Sprache mächtig ist. Die wenigen Steuerelemente, die sich nach der Sprache der Entwicklungsumgebung richten, kann man besser in den Griff bekommen als die holprigen Übersetzungen.

Dr. Holger Schwichtenberg
bietet mit seinem Unternehmen www.IT-Visions.de [10] Beratung und Schulungen im .NET-Umfeld. Er hält Vorträge auf Fachkonferenzen und ist Autor zahlreicher Fachbücher. (ane [11])

URL dieses Artikels:
https://www.heise.de/-403653

Links in diesem Artikel:
[1] https://www.heise.de/hintergrund/Reicht-NET-2-0-oder-muss-man-NET-3-5-einsetzen-227230.html
[2] https://www.heise.de/hintergrund/C-oder-Visual-Basic-Die-richtige-Programmiersprache-fuer-NET-Entwickler-227234.html
[3] https://www.heise.de/hintergrund/Genuegt-das-kostenfreie-Visual-Studio-Express-oder-muss-man-eine-Professional-Variante-kaufen-227246.html
[4] https://www.heise.de/hintergrund/NET-Oberflaechen-mit-Windows-Forms-oder-WPF-227252.html
[5] https://www.heise.de/hintergrund/Verwirrung-um-objekt-relationale-Mapper-LINQ-to-SQL-oder-ADO-NET-Entity-Framework-227256.html
[6] http://www.microsoft.com/downloads/details.aspx?FamilyID=5f7f4632-c9c0-4e79-b269-c2aee9d1962e&displaylang=en
[7] http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=8489ed13-b831-4855-96f7-dd35e4c02a20
[8] http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=8489ed13-b831-4855-96f7-dd35e4c02a20
[9] https://www.heise.de/hintergrund/Verwirrung-um-objekt-relationale-Mapper-LINQ-to-SQL-oder-ADO-NET-Entity-Framework-227256.html
[10] http://www.IT-Visions.de
[11] mailto:ane@heise.de

Copyright © 2009 Heise Medien