Bezeichnungen in deutsch oder englisch?

[nachtfeuer]

Ich denke auch, das kann keine Geschmacks oder Stiel...(oder Steil?) - Frage sein, ob man Bezeichnungen auf deutsch oder englisch wählt.

Der Mehrheit fehlt es einfach an ganz allgemein an Verständnis für grammatikalische Fragen oder grammatikalische Zusammenhänge.

Warum sonst werden wir von beknaktem Beamtendeutsch oder englisch geschriebenen Aufsätzen für die örtliche Häkelgruppe genervt? - Oder von zweifelhaften Unterscheidungen wie 'Daten' und 'Code' oder noch schlimmer noch, .data vs .text oder von absurden Codierbefehlen?

Man muss unterscheiden können: Bei Programmiergruppen muss man sich vielleicht sowieso auf einen Standard einigen, für Demonstrationszwecke, auch für Anfänger, in einem deutschen Forum, sind deutsche Bezeichner hilfreich, für Endversionen für Internetdownloads mit Sourcecode ist englisch sinnvoll, die Democodes für die Demoszene muss wenigstens ich selber wieder lesen können (falls überhauptnochmal)(nix open source), ich würde dann für mich also eher deutsche Bezeichner wählen.

[eggsperrde]

Alles auf Okzitanisch. Ist doch klar.

[0000000000000000000000000]

sprachpurist schrieb:

Aber das hat mich gerade auf die Idee gebracht, deutsche Ausdrücke mit den englischen zu vergleichen:

struct   plan
class    bund
char     stab
int      zahl
short    kurz
long     lang
unsigned nat
include  hol
return   wirf

pointer  zeiger
array    feld
string   kette
vector   liste
list     knüpfe
node     glied
stream   strom
map      kartei

string sollte mit Unterhose ersetzt werden.

Im Prinzip ist das einzige Argument für Deutsch, dass man Englisch nicht richtig kann.

[Marc++us]

Dravere schrieb:

Ich bin jedenfalls grundsätzlich für Englisch.

Ich stelle diese Forderung nach Grundsätzlichkeit grundsätzlich in Abrede.

Ja, in vielen Programmteilen ist das ok, weil der Programmierer auch keinen großen Schaden anrichtet wenn er semantisch printData mit showData verwechselt.

Aber wenn die Firma nun eine Software für die Steuerung von Rangierbahnhöfen für die Deutsche Bahn schreibt, diese Software wird vom Eisenbahnbundesamt zertifiziert und nie außerhalb von Deutschland eingesetzt. Ist es dann sinnvoll, die Begriffe Englisch zu benennen? Ähnliche Fälle gibt es in der individuellen Softwareentwicklung viele. Beim Kunden gab es zuvor eine jahrelange Begriffsbildung mit deutschen Begriffen, eine Überführung in Englisch schafft nicht mehr Klarheit, sondern verschlechtert die Produktqualität. Oder diskutiert Ihr nie mal ein Ablaufdiagramm mit einem Kunden? Wenn nun die Begriffe anders heißen als beim Kunden, erscheint das jemandem sinnvoll?

Bei einem Hotelreservierungssystem ist Englisch dagegen kein Problem, der Käufer will sicherlich das System breiter ausrollen und es gibt einen englischen Glossar der Begriffe.

Und ich stelle noch eine häufig zu hörende Argumentation eines Automatismus in Abrede: Doku in IT ist sowieso immer Englisch, dann muß der Programmierer das verstehen und kann auch in Englisch schreiben.

Was ist das für eine Kausalität? Weil jemand englische Dokus LESEN kann, kann er englische abgekürzte 2/3-Wort-Kurzbegriffe SCHREIBEN? :xmas2:

[elise]

Marc++us schrieb:

Ich stelle diese Forderung nach Grundsätzlichkeit grundsätzlich in Abrede.

*zustimm*, vor allem in blickrichtung kommunikation mit dem kunden und darüber hinaus einsatzbereich...

im übrigen sträube ich mich ebenso von vornherein gegen "grundsätzliches", mit dem tenor einer "regel".

:xmas1:

[geben Sie einen Benutzern]

Marc++us schrieb:

Aber wenn die Firma nun eine Software für die Steuerung von Rangierbahnhöfen für die Deutsche Bahn schreibt, diese Software wird vom Eisenbahnbundesamt zertifiziert und nie außerhalb von Deutschland eingesetzt. Ist es dann sinnvoll, die Begriffe Englisch zu benennen?

Ja, dann kann man auch was im Ausland entwickeln lassen.

Ähnliche Fälle gibt es in der individuellen Softwareentwicklung viele. Beim Kunden gab es zuvor eine jahrelange Begriffsbildung mit deutschen Begriffen, eine Überführung in Englisch schafft nicht mehr Klarheit, sondern verschlechtert die Produktqualität. Oder diskutiert Ihr nie mal ein Ablaufdiagramm mit einem Kunden? Wenn nun die Begriffe anders heißen als beim Kunden, erscheint das jemandem sinnvoll?

Was man dem Kunden zeigt muss ja nicht wortwörtlich in den Code. Bei irgendwelchen Eigennamen für die es keine englische Bezeichnung gibt, kann man die deutsche Bezeichnung verwenden, aber sonst alles englisch.

fenster.close()
if drueckknopf.getState() == PRESSED

sieht doch nur dämlich aus.

[Dravere]

Marc++us schrieb:

Ich stelle diese Forderung nach Grundsätzlichkeit grundsätzlich in Abrede.

Klingt irgendwie nach einem Widerspruch in sich selbst

Marc++us schrieb:

Ja, in vielen Programmteilen ist das ok, weil der Programmierer auch keinen großen Schaden anrichtet wenn er semantisch printData mit showData verwechselt.

Halte ich persönlich bereits für ein Problem, wenn dies in einer Schnittstelle passiert.

Marc++us schrieb:

Aber wenn die Firma nun eine Software für die Steuerung von Rangierbahnhöfen für die Deutsche Bahn schreibt, diese Software wird vom Eisenbahnbundesamt zertifiziert und nie außerhalb von Deutschland eingesetzt.

Mich stört ein wenig dieses "nie". Es gibt so viele Projekte, wo gesagt wurde, dass man es nur in diesem Bereich einsetzen wird und nie ausserhalb und am Ende kam es anders raus. Und dann hast du ein riesen Problem und kannst die Software geradezu neu schreiben.

Rangierbahnhof Software erinnert mich jetzt gerade an Simutrans. Das Beispiel stimmt zwar nicht überein, da es ein OpenSource Spiel ist, aber es ist so ein Fall. Das Spiel wurde auf Deutsch entwickelt und jetzt wo es plötzlich international wird und entsprechende Unterstützung bekommt, mussten sie die Richtlinien ändern. Jetzt haben sie erst recht ein Durcheinander im Code und müssen mühsam immer wie mehr übersetzen. Sieht aktuell schrecklich aus. Da schaltet es einem regelrecht ab, wenn man den Code probiert zu lesen.

Marc++us schrieb:

Ist es dann sinnvoll, die Begriffe Englisch zu benennen? Ähnliche Fälle gibt es in der individuellen Softwareentwicklung viele. Beim Kunden gab es zuvor eine jahrelange Begriffsbildung mit deutschen Begriffen, eine Überführung in Englisch schafft nicht mehr Klarheit, sondern verschlechtert die Produktqualität. Oder diskutiert Ihr nie mal ein Ablaufdiagramm mit einem Kunden? Wenn nun die Begriffe anders heißen als beim Kunden, erscheint das jemandem sinnvoll?

Ich stimme dir zu, dass dies ein Problem sein kann. Die Kommunikation mit dem Kunde kann unter Umständen von deutschen Begriffen profitieren. Aber die Qualität des Codes wird ganz sicher darunter leiden. Im allgemeinen verwendet man für jedes Projekt heutzutage irgendwelche Bibliotheken, seien es nur die Standardbibliotheken. Da ist es unweigerlich, dass du ein übles Mischmasch im Code bekommst. Und das hilft dann beim Verständnis auch überhaupt nicht.
Wenn man Deutsch und Englisch vermischt, dann fangen erst recht viele an, die Englischen Ausdrücke falsch zu interpretieren. Dann bekommst du ein völliges durcheinander was die Begriffe betrifft. Es ist sinnvoll einheitlich zu bleiben.

Bei der Kommunikation mit dem Kunden muss daher eine Zwischenschicht rein. Falls der Kunde Mühe mit den englischen Begriffen hat, muss halt ein Übersetzungskatalog her.

Marc++us schrieb:

Und ich stelle noch eine häufig zu hörende Argumentation eines Automatismus in Abrede: Doku in IT ist sowieso immer Englisch, dann muß der Programmierer das verstehen und kann auch in Englisch schreiben.

Was ist das für eine Kausalität? Weil jemand englische Dokus LESEN kann, kann er englische abgekürzte 2/3-Wort-Kurzbegriffe SCHREIBEN? :xmas2:

Naja, wenn jemand eine Sprache lernen will, empfiehlt man ihm immer, dass er zuerst Bücher in der Sprache lesen und danach in der Sprache sprechen soll. Durch das Lesen kann man definitiv eine Gefühl für die Sprache entwickeln. Aber grundsätzlich hast du natürlich schon recht, dass man dies nicht einfach so annehmen darf. Zwischen Lesen und Schreiben ist doch nochmals ein gewisser Unterschied.

elise schrieb:

im übrigen sträube ich mich ebenso von vornherein gegen "grundsätzliches", mit dem tenor einer "regel".

Ich habe es jetzt eher als eine Richtlinie gemeint. Allerdings sind mir bisher nur sehr wenige Ausnahmen über den Weg gelaufen.

Grüssli

[Anmerker]

Wenn man eine Software speziell fuer den deutschen Markt schreibt mit viel Fachterminologie (z.B. ne Verwaltungssofware fuer ne Komune, Stadt. Oder Steuersoftware etc.), dann machen deutsche Bezeichner mehr Sinn, weil diese extremen Fachterminologien der Behoerden/Steuerwelt etc. nahezu nicht uebersetzbar sind.

Meine Meinung deswegen: In der Regel Englisch, in Spezialfaellen Deutsch.

[Marc++us]

Dravere schrieb:

Mich stört ein wenig dieses "nie". Es gibt so viele Projekte, wo gesagt wurde, dass man es nur in diesem Bereich einsetzen wird und nie ausserhalb und am Ende kam es anders raus. Und dann hast du ein riesen Problem und kannst die Software geradezu neu schreiben.

... es gab aber mehr Projekte, bei denen man am Anfang nicht nur für die eine geplante und verkaufte Anwendung entwickelte, sondern für weitere denkbare Einsätze, wodurch die Software extrem komplex und weitschweifig wurde - mit Zeitüberschreitung, Budgetüberschreitung, und evtl. sogar Einstellung des Projekts.

Es ist zwar technisch reizvoll die Eisenbahnsoftware generisch so auszulegen, daß sie auch Fluglinien bedienen kann, aber es ist auch gleichzeitig ein guter Weg das Projekt in den Untergang zu treiben.

Dieser Pfad, zur dunklen Seite er führt.

Daß es auf irgendeiner Ebene dann mal einen Sprachenmix zwischen User-Domain und Bibliotheken gibt ist eben so... man kann ja auch den Glossar durch simples Mapping von Klassen, Objekten, Tabellen, etc, technisch realisieren.

Ich würde aber nie empfehlen mittels Glossar mit dem Kunden zu kommunizieren. Es ist ein erheblicher Vorteil, wenn man als Dienstleister die gleiche (natürliche) Sprache spricht wie der Kunde, warum sollte man diesen (Wettbewerbs-)Vorteil leichtfertig aufgeben, nur um ein rein intern-organisatorisch-schönheitswettbewerbstechnisches Regelwerk einzuhalten? Da wackelt dann der Schwanz mit dem Hund.

[Sebastian Meier]

+1 für Fachbegriffe in Deutsch.

Habe lange Bankensoftware entwickelt und denke es ist sehr wichtig, dass Entwickler und Kunden die gleiche Sprache sprechen. Beispielsweise hat bei uns mal ein Entwickler das Businessobjekt für Umsätze "Turnover" genannt. Ich weiß bis heute nicht, ob das überhaupt der passende Begriff ist. Jedenfalls hat sich das durch die ganze Anwendung gezogen und im morgendlichen Scrum-Meeting haben wir dann über "getTurnover" und das "TurnoverPanel" geredet. Aber wenn zehn Minuten später der Kunde anrief, mussten wir auf "Umsatz" umschalten. Dazu kam, dass eine andere Abteilung sich für "Transaction" entschieden hatte , so dass sogar unsere Abteilungen begrifflich nicht auf einer Wellenlänge waren.

Und "Umsatz" ist noch einfach. Ich will gar nicht erst mit "Dispokredit-Linie" oder "Abwicklungskunde" anfangen.

[hustbaer]

@Sebastian Meier & Marc++us

Ich verstehe eure Argumentation vollkommen und will auch gar nicht widersprechen.

Hätte aber ein paar Fragen...

Wie macht ihr es dann mit deutschen Fachbegriffen?
Alles auf Englisch bis auf die Fachbegriffe? Also "GetUmsatzView" und "CreateDispokreditBerechnungImpl"?

Und habt ihr einen guten Richtwert/Faustregel wo man in solchen Fällen die Grenze ziehen sollte?

Und ... führt ihr - mehr oder weniger - verbindliche Listen von Fachbegriffen? Sonst passiert ja sowieso wieder das was Du (Sebastian) beschrieben hast: einer sagt so, der andere anders. Deutsche Fachbegriffe zu verwenden schützt ja nicht gegen z.B. Kellerspeicher vs. Stapelspeicher.

----

Ich selbst hatte noch nie ein Projekt wo viele derartige Fachbegriffe vorgekommen wären, worüber ich auch sehr froh bin
Ich meine nur: wenn es KEINEN derart guten Grund gibt Dinge deutsch zu benennen, dann finde ich sollte man es auch bleiben lassen. Nur "ja weil ich mich auf Deutsch leichter tue" ist für mich eben kein ausreichender Grund.

[seldon]

Sebastian Meier: Volle Zustimmung. Wichtig ist am Ende, dass jemand, der in den Code kuckt, sofort versteht, worum es grob geht. Wenn dabei Denglisch rauskommt, dann ist das halt so. Man muss es nicht mögen, aber es ist besser, als "Abgeltungsteuer" im Code durch eine hausgemachte Übersetzung zu ersetzen, die keiner kennt oder versteht.

hustbaer: Häufig stellt sich die Frage überhaupt nicht, wenn man nicht in jeden zweiten Funktionsnamen "set" oder "get" schreiben will. Dort, wo es mal vorkommt, verhalte ich mich in der Regel so, wie ich vermute, dass es auch ein englischsprachiger Mensch, der mit ausländischen Sachverhalten zu tun hat, täte - ich lasse die nicht übersetzbaren Teile unübersetzt. Bei deinen Beispielen liefe das wahrscheinlich "UmsatzView" und "CreateDispoKreditCalculationImpl" oder etwas vergleichbares hinaus. Obwohl "Umsatz" vermutlich mit etwas Nachdenken auch sinnvoll übersetzbar wäre; da bin ich leidenschaftslos.

Letztendlich ist das aber natürlich ein großes Stück weit einfach Geschmackssache, und über Geschmack lässt sich bekanntlich lange und ergebnislos streiten.

Zum Programmieren in Landessprachen generell noch eins - ich hatte vor einiger Zeit eine sehr interessante Diskussion mit einem portugiesischsprachigen Programmierer, der höchst unerfreut darüber war, dass er in Quellcode auf das basic source character set beschränkt war - im konkreten Fall, dass er "ñ" nicht benutzen konnte. So stand überall in seinem Code, wo er "Jahre" meinte, "Anus". Da haben wir als Deutsche es mit drei Umlauten und ß doch noch richtig gut und einfach.

[EOP]

seldon schrieb:

Zum Programmieren in Landessprachen generell noch eins - ich hatte vor einiger Zeit eine sehr interessante Diskussion mit einem portugiesischsprachigen Programmierer, der höchst unerfreut darüber war, dass er in Quellcode auf das basic source character set beschränkt war - im konkreten Fall, dass er "ñ" nicht benutzen konnte. So stand überall in seinem Code, wo er "Jahre" meinte, "Anus".

LOL - wenigtens etwas Lustiges in diesem thread (Faden :p).

[Dravere]

Marc++us schrieb:

Es ist zwar technisch reizvoll die Eisenbahnsoftware generisch so auszulegen, daß sie auch Fluglinien bedienen kann, aber es ist auch gleichzeitig ein guter Weg das Projekt in den Untergang zu treiben.

Bitte bleib im Kontext. Es ging um die Begriffe und Kunden. Mir ging es darum, dass ein französischer Bahnbetreiber von der Software etwas mitbekommen hat. Er ist sich das bei der DB anschauen gegangen und war begeistert. Nun fragt er dich an, ob er die Software auch für seinen Rangierbahnhof haben kann. Es gibt schliesslich gewisse europäische Standards im Schienenverkehr, wodurch sowas durchaus möglich wäre. Und nun? Deine ganze Software ist in Deutsch und du hast plötzlich einen französisch sprechenden Kunden.

Wobei ich sagen muss, dass bei Begriffen wie "Dispokredit-Linie" oder "Abwicklungskunde" man sich schon berechtigt fragen sollte, ob man diese Begriffe sinnvoll übersetzen kann. Allerdings fragt sich auch, ob solche Begriffe wirklich 1:1 als Bezeichner in der Software vorkommen werden. Hängt natürlich auch etwas von der Anwendung ab. Aber das würde nichts daran ändern, dass ich grundsätzlich zuerst für Englisch wäre. Ausnahmen habe ich ja nicht ausgeschlossen.

Früher hat man Wert auf die technischen Aspekte gelegt und die Kommunikation mit dem Kunden vernachlässigt. Heute legt man Wert auf die Kommunikation mit dem Kunden und fängt meiner Meinung nach an, die internen Teile zu vernachlässigen, bis sich die Techniker untereinander nicht mehr verstehen. Ist beides keine gute Idee.

Wenn jemand zu mir kommt und meint, dass er eine Datenreihe im Keller angelegt hat, dann ist mein erster Gedanke sicher nicht bei einem Array auf dem Stack

Grüssli

[Marc++us]

Dravere schrieb:

Es ging um die Begriffe und Kunden. Mir ging es darum, dass ein französischer Bahnbetreiber von der Software etwas mitbekommen hat. Er ist sich das bei der DB anschauen gegangen und war begeistert. Nun fragt er dich an, ob er die Software auch für seinen Rangierbahnhof haben kann. Es gibt schliesslich gewisse europäische Standards im Schienenverkehr, wodurch sowas durchaus möglich wäre. Und nun? Deine ganze Software ist in Deutsch und du hast plötzlich einen französisch sprechenden Kunden.

Wenn der Kunde begeistert ist, wird er es mir nicht übelnehmen, wenn ich für entsprechende Anpassungen Geld verlange.

Ich mache Dir mal eine beispielhafte Rechnung auf, warum dieser Weg sinnvoll ist - denn Du fällst auf ein Muster mit dem Namen "Premature Optimization" rein - Du optimierst Dein Produkt für eine Anforderung, die es geben KÖNNTE, aber zur Zeit nicht GIBT.

Szenario 1:

Du erkennst, daß man die Software auch in Frankreich einsetzen könnte. Die Entwicklung für DE würde 1 Mio kosten und 12 Monate dauern. Gewinn mit dem Produkt 150kEUR. Durch dieses generische Feature erhöhen sich die Entwicklungskosten auf 1,3 Mio und es dauert 15 Monate.

Der Kunde ist sauer. Und er zahlt keine zusätzlichen 300kEUR, da er das nicht benötigt. Nach langer Diskussion mit dem Produktmanagement kommt Ihr intern zur Schlußfolgerung, daß die Hälfte der Mehrkosten vom Entwicklungsbudget getragen wird, der Kunde bezahlt zähneknirschend 150kEUR mehr.

Das Produkt wird geliefert, alles prima. Der Kunde ist immer noch bißchen zerknirscht über die Mehrkosten und längere Zeit, und der Ruf von Eurem Produkt ist nicht so toll.

Ihr findet nie mehr einen weiteren Kunden in diesem Markt.

Gewinn mit diesem Produkt: 0 EUR. Ein Jahr gearbeitet ohne Bonus.

Szenario 2:

Ihr liefert das Produkt wie ursprünglich geplant, 1 Mio EUR, 12 Monate. Ihr seid sauschnell, weil Ihr nur macht was der Kunde wollte.

Gewinn nach dem 1. Produkt: 100kEUR. Der Chef zahlt einen Bonus.

Der Kunde ist von dem Produkt begeistert, so daß er es auf einer europäischen Bahnkonferenz erwähnt. Der Einkäufer aus Frankreich ruft bei Euch an.

Eurer Produktmanager ist einige Tage bißchen zerknirscht, weil nun einige Applikation-Layer angepasst werden müssen. Aber nach der Kalkulation stellt Ihr fest, daß Ihr an diesem Produkt Mehraufwände in Höhe von 600kEUR habt - fast doppelt so viel wie es gekostet hätte, wenn ihr es gleich gemacht hättet. Aber der Verkäufer kann vom Kunden trotzdem 1 Mio EUR im Vertrag als Kaufpreis festlegen. Ihr seid happy wie die Schneekönige, weil das 2. Produkt richtig Marge abwirft. Vom Bonus kaufst Du Dir ein <OBJECT>.

Natürlich konstruiert. Du wirst sicherlich einwerfen, daß die Mehrkosten bei Szenario 1 nicht so hoch wären. Eigentlich sind sie sogar kostenlos.

Aber das stimmt nicht - es gibt keine kostenlosen Features. Vielleicht verursacht ein Feature keine Codingkosten. Trotzdem wird es Kosten in der Dokumentation oder im Testaufwand verursachen, oder später bei der Hotline im Support, weil der Kunde sich an eine komplexere Ausgestaltung gewöhnen muß. Jedes zusätzliche Feature verursacht irgendwo in der Entwicklungskette einen Mehraufwand. Daher ist es unbedingt notwendig sich auf wertschöpfende Features festzulegen.

Und da ist die Sprachwahl im Code in zahlreichen Fällen nicht ausreichend qualifiziert.

Zum Thema "Dispokredit-Linie" - im tiefen Code kommt das sicherlich nicht vor, ich will Dir Deine CustomerAccountView(list<Customer>& customers) ja gar nicht klauen - aber auf der Ebene von Use Case Tests oder Domain-Klassen kommt der Begriff sicherlich vor.

[Marc++us]

Hustbaer schrieb:

Wie macht ihr es dann mit deutschen Fachbegriffen?
Alles auf Englisch bis auf die Fachbegriffe? Also "GetUmsatzView" und "CreateDispokreditBerechnungImpl"?

Und habt ihr einen guten Richtwert/Faustregel wo man in solchen Fällen die Grenze ziehen sollte?

Und ... führt ihr - mehr oder weniger - verbindliche Listen von Fachbegriffen? Sonst passiert ja sowieso wieder das was Du (Sebastian) beschrieben hast: einer sagt so, der andere anders. Deutsche Fachbegriffe zu verwenden schützt ja nicht gegen z.B. Kellerspeicher vs. Stapelspeicher.

Was gefällt Dir nicht an "CreateDispokreditBerechnungImpl"? Es ist reine Gewohnheit. Würdest Du es immer machen, würde es Dir nicht mal mehr auffallen.

Zu der Grenze: es gibt - naja, sollte - irgendwo eine Grenze zwischen dem Kundenmodell geben, also den berühmten Domainenklassen, und der eigentlichen Implementation. Diese Ebene bietet sich doch an. Das oberste Modell ist dann in der Kundensprache, auch Workflows, Begriffe und Interaktionen sind dann in der Kundensprache. Damit ideal testbar, für den Kunden verständlich und diskutierbar, Tester und Dokumentation freuen sich auch darüber.

Hält man das zu 90% durch dürfte eine gute Trennung gelingen. 100% sind zwar ein tolles Ziel, der Aufwand ist aber oftmals diesen "Resterfolg" nicht Wert.

Daher dürfte es auch nicht zu so einem Konflikt kommen, daß jemand Daten auf dem Kellerspeicher ablegt, die Programmierer sprechen vom Stack, und auf Kundenebene ist das ja einfach nur ein "KundenVorgangsstapel".

Zu den Begriffen: in jedem Projekt sollte es ohnehin ein Glossar der Begriffe geben, allerdings ist das nach meiner Erfahrung oft so, daß die schlimmsten und übelsten Dinge zu Beginn da mal verzeichnet werden - denn über diesen Begriff waren alle Leute erstaunt - aber er deckt nicht 100% der Begriffe ab und wurde irgendwann nicht mehr gepflegt. Das macht nämlich verdammt viel Mühe das zu führen, und es macht noch mehr Mühe den ganzen Leuten im Team die Begriffe in den Kopf zu prügeln ("hey, es gibt eine neue Version vom Glossar, bitte auswendig lernen bis zum X.Y.!")

[this-*gt*that]

+1 für die Leute, die Deutsch in sinnvollen Fällen benutzen.
Eine Faustregel wie IMMER Englisch ist sinnfrei.

[*rant*]

this->that schrieb:

Eine Faustregel wie IMMER Englisch ist sinnfrei.

Ja, ich halte das eher für eine Richtlinie, wobei ich, wenn ich die Wahl habe, eigentlich immer Englisch arbeite (schliesst auch Kommentar ein). Im Fall der Fälle zwanghaft etwas übersetzen zu wollen artet aber meistens in diesen grauenhaften Wortvergewaltigungen aus, die bei Informatikern bereits oft genug vorkommen. Das sollte man gefälligst lassen.

Wir hatten bei grossen Projekten bei wichtigen Kunden zum Glück meistens Fachidioten, die uns sehr genau sagen konnten, wie wir die Dinge im Englischen nennen sollen. Gerade im Finanz- und Bankensektor ist es doch unmöglich, dass man sich als Informatiker ohne solche Begleitung durch die Projekte kämpfen muss, da man die Begriffe gar nicht kennen kann, wenn man nicht wirklich damit arbeitet.

Meine Favoriten sind natürlich diese Buzz-Begriffe wie "Merchant Transaction Consolidation ID" welche sich inklusive Berücksichtigung spezieller Notationen und Abkürzungen (à la " unser_praefix_kunden_praefix_merchant_trx_consolidation_id_beliebige_nummer ") durch den Quelltext ziehen - und dann für etwas völlig anderes gebraucht werden, als der Name suggeriert. Dann kommt man schon ins Grübeln

MfG :xmas1:

[SeppJ]

this->that schrieb:

+1 für die Leute, die Deutsch in sinnvollen Fällen benutzen.
Eine Faustregel wie IMMER Englisch ist sinnfrei.

Und ich halte es für kurzsichtige Kleinstaaterei. Argumentation siehe Draveres Beiträge. "Nein, unsere Software wird für alle Zeiten nur von Programmierern angesehen werden die Deutsch als Muttersprache haben. Wir werden sie niemals exportieren, niemals mit anderer Software kombinieren und niemals ausländische Programmierer einstellen". Das ist vielleicht bei einem privaten Hobbyprojekt noch realistisch aber sonst nicht.

Das Argument, dass es keine englischen Begriffe gäbe kann ich auch nicht gelten lassen. Wie unterhalten sich denn deutsche Bankkaufleute mit ausländischen Kollegen?

[icarus2]

Da ich gerade Ferien habe kann ich ja mal auch noch meinen Senf dazugeben: ^^

Ich finde, dass man grundsätzlich Englisch verwenden sollte. Dieses Gemisch aus Deutsch und Englisch (Denglisch) ist erstens unschön und zweitens verstehen halt nicht alle Deutsch.

Der einzige Ort an dem aus meiner Sicht Deutsch sinnvoll sein kann ist in einem Deutschen Tutorial für Anfänger. Da kann es vielleicht von Vorteil sein, da es leicht ersichtlich ist für Anfänger welche Teile des Programms selber gemacht sind und welche von irgendwo sonst herkommen. (Ging zumindest mir teilweise so).

Aber sonst aus meiner Sicht IMMER Englisch verwenden. (Ich hatte gerade eine Vorlesung in diesem Semester, in der z.B. Subscriber zu Subskribent oder Publisher zu Herausgeber wurde ==> äusserst mühsam).