Ubiquitär/Ubiquitous

Eigentlich hatte ich geglaubt, dass das Thema der Programmiersprachen-Sprache schon mit dem Blog-Eintrag Lingua Franca erledigt gewesen wäre. Aber die Reaktionen auf jenen und den letzten Eintrag haben mich dazu bewogen, doch noch die eine oder andere Bemerkung zu machen. Denn obwohl Englisch in der IT eine große Rolle spielt, scheint es mir dennoch nicht nötig, dass alle Softwareentwickler ab sofort nur noch Englisch reden und schreiben – das geht mir dann doch etwas zu weit.

Wer etwa ein Open-Source-Projekt startet, das möglichst weite Verbreitung finden soll, tut gut daran, die Dokumentation in Englisch zu verfassen. Nicht etwa, weil Englisch die tollste aller Sprachen wäre, sondern weil es viele anderen auch in Englisch machen und man sich damit automatisch dieses Klientel erschließt. Aber wenn man alleine oder in einer kleinen Gruppe zum Beispiel eine Banken-Software für den deutschen Markt schreibt, warum soll man dann nicht auch Deutsch nutzen dürfen? In diesem Fall muss man nämlich keinen einzigen Gedanken daran verschwenden, Fachbegriffe zu übersetzen, Sätze in einer Fremdsprache zu formulieren und korrekte Idiome zu finden.

Die Wahl der Sprache scheint mir dann doch eher eine Sache der Ziele zu sein. An der Stelle sei erwähnt, dass es sich über Ziele – wie Fragen des Geschmacks – per definitionem nicht zu streiten lohnt, weil es eigentlich immer willkürlich festgelegte Ziele sind. Bei den Zielen kann also allenfalls danach gefragt werden, wie diese motiviert sind, aber eigentlich ist es irrelevant, ob sie sinnvoll sind oder taugen (solange sie nicht gegen die Moral oder präziser gegen das Gesetz – als moralisches Minimum – und allgemein gültige Prinzipien verstoßen).

Die Wahl der Mittel, die möglicherweise Einschränkungen unterliegen, lässt sich dann ausschließlich unter Berücksichtigung der festgelegten Ziele bewerten. Hierbei sollte man nicht aus den Augen verlieren, dass es dann in der Regel darum geht, diese Ziele – nicht allein aus wirtschaftlichen Gründen – möglichst effizient zu erreichen. Die einzige Ausnahme dabei ist, dass der Weg das Ziel ist; dann kann man sich Zeit lassen.

Grundsätzlich gibt es also erst einmal keinen Grund, warum man nicht mit seiner Muttersprache vorlieb nehmen sollte. Ich halte es persönlich schon für schwierig genug, in einem vernünftigen Deutsch zu schreiben. Wann immer ich es einrichten kann, versuche ich also, eine Fremdsprache zu vermeiden. Denn es scheint mir nicht ganz so einfach zu sein, "Spitzfindigkeiten", "das Allerletzte" oder eingängige Phrasen wie "Konkurrenz belebt das Geschäft" oder "Auf dem Holzweg" zu übersetzen.

Ganz unabhängig davon gibt es unzählige Softwareentwickler, die Englisch nie oder nur zu kurz in der Schule gelernt haben. Dennoch finden sich viele zwar lesend ganz gut zurecht, tun sich aber beim Schreiben sehr schwer. Aber auch Englisch zu verstehen ist nicht ganz einfach. Bei der Beschreibung einer Programmbibliothek kann man sich ja noch das eine oder andere zusammenreimen, aber ohne Kontext ist das deutlich schwieriger. Wer das nicht glaubt, muss einfach nur Überschriften in englischsprachigen Zeitungen und Boulevard-Blättern lesen.

Im Jahr 2003 wurde in einer Studie untersucht, inwieweit in Deutschland englischsprachige Slogans verstanden werden. Während "Every time a good time" (McDonalds) noch von 59 Prozent korrekt übersetzt wurde, waren es bei "Powered by emotion" (SAT.1) nur noch 33 Prozent und bei "One Group. Multi Utilities." (RWE) erbärmliche 8 Prozent. Der Einfallsreichtum bei den Übersetzungen sucht dann auch seinesgleichen. "Jede Zeit ist eine gute Zeit" heißt es da; "Kraft durch Freude", "Strom bei Emotion" und "Kraft und Gefühle" beziehungsweise "Viele Werkzeuge für eine Gruppe" oder "Ohne Gruppe Multi Kulti". Aber gerade die Spitzfindigkeiten entscheiden darüber, ob ein Lock wieder freigegeben wird, ob eine Funktion Thread-sicher ist, ob der Cache invalidiert wird und ob die Daten gelöscht (im Sinne von zerstören) oder nur (im Sinne von verschieben) entfernt werden.

Je jünger die Leute bei der Studie waren, desto besser klappte es mit dem Englisch. Aber bei den Überdreißigjährigen wurde es schon dünner. Aber allein unter dem Gesichtspunkt, dass sich der eine oder andere jener "über Dreißig" in unserer Branche noch zwanzig, dreißig Jahre mit Spezifikationen, Büchern und Vorträgen beschäftigen muss, halte ich es doch für sehr vermessen, diesen zu einer Lektüre auf Englisch zu zwingen. Und wären alle wirklich so gut in Englisch, wie es uns manche glauben machen wollen, gäbe es in den Buchhandlungen zum Thema IT bestimmt kein einziges deutsches Buch mehr, wäre dieser Blog auf Englisch zu lesen und die darauf bezogenen Kommentare natürlich auch in Englisch zu schreiben.

Schließlich muss es ja Gründe gegeben haben, warum die Java-Spezifikation in der Anfangszeit auch in Japanisch erhältlich war. Für Apple-Rechner gab es früher für das Betriebssystem neben der amerikanischen Version auch eine englische. Alle modernen Rechner inklusive der Smartphones lassen sich heute auch auf Deutsch bedienen. Warum sollte dann nicht auch in der Muttersprache dokumentiert werden. Und ein wesentlicher Teil der Dokumentation sind Variablen und Klassennamen. (Was es übrigens unmöglich macht, mit ASCII-Zeichen auszukommen und nach heutigem Stand der Technik zwangsläufig zum Unicode führt.)

Was im Übrigen die Schlüsselwörter in einer Programmiersprache anbetrifft, könnten diese eigentlich auch in Deutsch oder gar Französisch sein, wenn diese taugt. Ob irgendwo wenn … dann oder if … then steht, ist völlig egal – dem Chinesen wie dem Thailänder oder dem Georgier. Wenn man den Begriff nicht versteht, dann muss man ihn halt lernen. Das Doppelstrich-Z (ℤ) ist ein Beispiel für einen international gültigen Begriff, den (hoffentlich) jeder (Softwareentwickler) versteht und der – man höre und staune – aus dem Deutschen kommt. Der steht nämlich für "Zahlen", und wer dies nicht weiß, der hat eben keine Eselsbrücke.

Dass ich mich in meiner Programmiersprache für englische Schlüsselwörter entschieden habe, hat also nur einen einzigen Grund: Wenn ich if schreibe, brauche ich all denen, die bereits eine Sprache benutzen, die auch eine if-Anweisung hat, nicht mehr erklären, was mein if macht (unter der Annahme, dass mein if tatsächlich auch das Gleiche macht). Allen anderen ist es egal, weil ich ihnen überhaupt erst einmal erklären muss, was denn eine if-Anweisung tut. Wenn ich das aber nicht erklären möchte, dann ist mir im Deutschen mit einem wenn … dann besser geholfen als mit allem anderen.

Das Englische ist aber auch dann nicht hilfreich, wenn man auf kompakte, aber eher exotische Wörter zurückgreifen muss. Deshalb hatte ich damals in oben genanntem Blog geschrieben: "Ein bisschen schwieriger ist es da mit Exoten wie coerces und comprises. (An dieser Stelle würde mich interessieren, ob sich jemand – ohne zu schummeln – vorstellen kann, wozu diese Wörter gut sein könnten.)" Zu diesem Thema hat sich natürlich keiner geäußert, und ich befürchte, dass das nicht ausreichenden Englischkenntnissen geschuldet ist. Das finde ich keinesfalls verwunderlich, denn ich musste die Wörter nachschlagen. Seinerzeit habe ich natürlich keine Rückmeldung bekommen, aber das kann ja jetzt nachgeholt werden.

Nebenbei sei noch bemerkt, dass aus rein technischer Sicht der Einsatz landessprachlicher Schlüsselwörter oder (intrinsischer) Funktionen nur dann problematisch ist, wenn es unterschiedliche Sprachversionen gibt und man beispielsweise die deutsche Version unter dem englischen Interpreter zum Laufen zu bringen versucht. Aber dieses Problem lässt sich eigentlich trivial dadurch lösen, indem man die benutze Sprache einfach immer in einer Präambel angibt. Bei HTML-Seiten wird diese Methode im Zusammenhang mit dem Zeichensatz angewandt und funktioniert nur genau dann nicht, wenn diese charset-Angabe fehlt.

Ich für meinen Teil habe übrigens beschlossen, die Dokumentation, die Spezifikation und die Einführung für meine Programmiersprache zunächst mit dem für meine Ziele (die ich auch beizeiten kund tun werde) am besten geeigneten und mir vertrautesten Werkzeug zu schreiben: in Deutsch. Alles dauert schon lange genug, und deshalb bin ich heilfroh, dass ich mich nicht auch noch um einen passenden Englischstil kümmern, dauernd nach passenden Wörtern suchen und Vokabeln nachschlagen muss. Schließlich denke ich ja auch nicht in Englisch und so kann ich mich viel einfacher auf das Wesentliche konzentrieren.

Was den Programmtext anbetrifft, schreibe ich Klassennamen und Variablen trotzdem in Englisch, weil ich mich da ja auch in einer Domäne bewege, deren berühmteste Literatur englischsprachig ist. Das Wort Compiler ließe sich ja noch schön mit Übersetzer übersetzen, aber etwa für Token würden mir dann doch eine passende Übersetzung fehlen. Öffentliche Schnittstellen in Englisch zu halten ist auch deswegen vernünftig, weil der Compiler erweiterbar sein soll. Mit Englisch glaube ich, da tatsächlich die größten Chancen zu haben, aber die dazugehörige Dokumentation will beizeiten erst noch ins Englische übersetzt werden.

Sollte sich tatsächlich außer mir noch jemand, der des Deutschen nicht mächtig ist, für meine Sprache interessieren, dann kann ich die Dokumente – in der Annahme, dass es sich lohnt – ja immer noch übersetzen. ()