Verwendung von Übersetzungen im Wiki

Aus einer Diskussion zwischen Kerli und Xin, als Richtlinie für das Wiki.

Übersetzungen von Fachwörtern

Die Informatik ist nunmal voll mit englischen Begriffen und entweder nehmen wir übliche Begriffe - die dann häufig englisch sind - oder wir deutschen alles ein, so dass keiner mehr versteht wo was zu finden ist ^^


Ok, stimmt eigentlich. Normalerweise muss ich mich eh bemühen dass bei solchen Artikeln nicht zu viel Englisch durchkommt. Und gerade heute hat ein Professor bei uns andauernd von Halden gesprochen, womit er Heaps gemeint hat

Ich bemühe mich selbst auch, englische oder pseudoenglische Begriffe in deutscher Sprache zu vermeiden. Ein Mobiltelefon ist für mich ein Händi, aber kein Handy. Mein persönlicher Favorit war, als der Verzähler („Discounter“) Lidl für Rucksäcke einen trendigen Begriff suchte und ihn deswegen ins englische übersetzte. Die korrekte Übersetzung von Rucksack ins englische ist aber Rucksack, da die Engländer den deutschen Begriff übernommen haben. So kommt man also nicht weiter, als wurden die Marketingstrategen kreativ und verkaufte daher trendige „Bodybags“. Vermutlich meinten sie Taschen, die man am Körper trägt…

Inzwischen findet man Body-Bags auch bei Amazon, bei dict.cc (aber nicht bei dict.leo.org). Als ich die Geschichte einem Schotten erzählte, hat der sich schrullig gelacht. Bodybags sind unmissverständlich Leichensäcke und ein Rucksack ist ein Rucksack.

Allerdings bitte ich von Übersetzungen wie „Halden“ Abstand zu nehmen. Wer daran Spaß hat, kauft sich bitte die deutsche Ausgabe von 'Design Patterns'. In dem Fall möchte ich schon fast Abstand von „Heaps“ nehmen, denn der Speicher ist keine Halde oder ein Heap, wo man oben was drauf packt, sondern ein fragmentiertes Etwas, also eher ein Apothekerschrank. Arbeitsspeicher ist Arbeitsspeicher. new öffnet ein Apotheker-Schrank-Türchen und dann kann man da was reinpacken. Ein erneutes new bewirkt nicht zwangsläufig, dass das Türchen da drüber aufgeht und man damit etwas quasi auf Halde legen kann. Die Tür kann auch im Nachbarort aufgehen oder darunter. Da werden dann aber weder Daten in den Nachbarort transportiert, noch die Halde umgebaggert, damit man die neuen Daten unter die alten bekommt.

Was übersetzt wird, sollte - sofern vorhanden - den englischen Begriff mindestens einmal nennen, wenn der englische Begriff geläufiger ist, z.B. Übersetzer (Compiler). Übersetzungen, die überhaupt nicht geläufig sind, wie „Halden“ oder wo eine Übersetzung gewissermaßen erzwungen ist, da würde ich sie weglassen oder man nennt den deutschen Ausdruck einmalig der Vollständigkeit halber, z.B.: Der Stack (gelegentlich auch als Stapelspeicher, Kellerspeicher genannt)…

Seitennamen

Links (also Seitennamen und Namensräume) bleiben grundsätzlich englisch.

Zum Aufbau eines neuen Tutorials

Aus einer Mail zwischen Yoghurt und Xin:

also ich schau jetzt wie ich das am besten in Namensräume organisiere und versuche mich da am C-Tutorial zu orientieren.
Ich bin jetzt gerade am überlegen, ob ich das eigentliche Java-Tutorial auch in java:tutorial: stecke. Was meinst du?

Grundsätzlich ist das durchaus passend. Tutorial war eigentlich aus der Not geboren, dass der Namensraum schon mit einem sehr alten Tutorial von mir belegt war und ich das eben besser aufbauen wollte. Aber ich glaube, das hat weiterhin Sinn, so kann man direkt abgrenzen, was zum Tutorial (=Basiswissen) gehört und was aufbauende Themen sind (sprache:article:topic).

Dann ist halt immer die Frage was genau gehört jetzt zum Tutorial und was nicht… z. B. die Typen hätte ich jetzt spontan auch ins Tutorial gesteckt, wobei das im C-Tutorial ja anders gemacht ist und so auch Sinn macht.

c:type:… ist wie ein Glossar oder eine Referenz. Wenn man was zu einem konkreten Typen wissen will, kann man einfach c:type:int nehmen und weiß, was das für ein Typ ist. Gut zu verlinken, aber keiner lernt INT_MAX oder ähnliches auswendig, um eine Sprache zu lernen.

Die Seiten gehören auch noch zum alten Tutorial. Hier sind sicherlich noch Anpassungen fällig - aber c:type:… wird bleiben.

c:tutorial ist sozusagen das Template, c:type bleibt, c:lib bleibt - hier kommt also alles rein, was zur C-Standard-Lib gehört, entsprechend würde java:lib das Framework um Java vorstellen. Das werden wir aber wohl kaum leisten, dafür gibt es die Online-Doku bei Oracle. Aber unter java:lib kann man halt grundlegendes auf Deutsch vorstellen. Irgendwann mal… die c:lib ist ja auch noch in Arbeit. lib ist eine Referenz. Der Namensraum article würde Besonderheiten als Minitutorial beschreiben, um die man sich kümmern kann, wenn man das richtige Tutorial gelesen hat. Wie funktioniert JNI zum Beispiel. Aber das ist alles Zukunftsmusik.

Ansonsten bleiben noch faq und compiler, wobei Du die Vorbedingungen, wie Installation etc. statt nach Compiler vielleicht nach java:start:… legen könntest. Python etc. haben keinen Compiler, installieren muss man es aber trotzdem. ^^ java:start: passt entsprechend zu unseren Namensraum start:, der den Einstieg in die Programmierung beschreibt - java:start wäre dann der Einstieg in die Java-Programmierung.

Fragen?

Einfach im Forum im Board Tutorials stellen