Bezeichnungen in deutsch oder englisch?
-
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
-
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.
-
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.
-
+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.
-
@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.
-
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.
-
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).
-
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
-
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.
-
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.!")
-
+1 für die Leute, die Deutsch in sinnvollen Fällen benutzen.
Eine Faustregel wie IMMER Englisch ist sinnfrei.
-
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übelnMfG :xmas1:
-
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?
-
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).
-
icarus2 schrieb:
(Ich hatte gerade eine Vorlesung in diesem Semester, in der z.B. Subscriber zu Subskribent oder Publisher zu Herausgeber wurde ==> äusserst mühsam).
Das Beispiel ist ziemlich sinnfrei, denn das ist ja genau da, wo man sich auf Bibliotheksebene bewegt... da tut das keinem Weh, was die Entwickler so anstellen.
-
icarus2 schrieb:
Dieses Gemisch aus Deutsch und Englisch (Denglisch) ist erstens unschön und zweitens verstehen halt nicht alle Deutsch.
Es verstehen auch nicht alle Englisch. Sie glauben es zwar, aber...
Noch besser wäre es ja mit einer französischen Firma zusammen zu arbeiten, und dann aus Gründen der Verständlichkeit alle Begriffe auf Englisch zu formulieren.
-
SeppJ schrieb:
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?
Es gibt nicht übersetzbare deutsche Fachterminologie, genauso wie im Deutschen englische Begriffe verwendet werden, weil wir keine eigenen entwickelt haben. Die Bereiche kann man sicherlich an einer Hand abzählen, aber es ist so. Der Bahnbereich ist ein gutes Beispiel. Bahn funktioniert in England, Frankreich, Deutschland und Amerika eben anders. Und im Rest der Welt so, wie in einem der Vorgenannten.
-
SeppJ schrieb:
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".
Nochmal, solange dadurch der heute verkaufbare Wert des Produkts nicht erhöht wird - dieses Feature also nicht wertschöpfend ist - macht es keinen Sinn dafür Geld aufzuwenden. Wenn die berühmte User-Domain bereits englischsprachig ist, dann hat man Glück, und es fällt leicht alle Begriffe entsprechend zu behandeln. Aber wenn dem nicht der Fall ist muß man das bewerten - Argumentation in meiner Antwort an Dravere.
Aber für den Automatismus "es ist eleganter und könnte mal mehr Geld bringen" würde ich kein Geld spendieren.
-
Marc++us schrieb:
icarus2 schrieb:
Dieses Gemisch aus Deutsch und Englisch (Denglisch) ist erstens unschön und zweitens verstehen halt nicht alle Deutsch.
Es verstehen auch nicht alle Englisch. Sie glauben es zwar, aber...
Dann sind sie eben nicht qualifiziert, um gute Software zu entwickeln. Das ist dann genauso wie ein Programmierer der durch andere Stilfehler schlecht wartbaren Code schreibt. Da besteht meines erachtens nach kein großer Unterschied zwischen jemandem der Spagetthiode schreibt und jemandem der deutsche Bezeichner benutzt. Den Spagetticode kann dann nur ein Genie durchschauen, den deutschen Code nur jemand der Deutsch spricht. Der Unterschied ist bloß die unterschiedliche Anzahl von Deutschsprechern und Genies auf der Welt. Letztlich ist beides für große Teile der Weltbevölkerung unverständlich.
Gegenfrage: Wären Bezeichner auf chinesisch ok? Oder was ist wenn wir eine noch seltenere Sprache als Deutsch sprechen würden, z.B. baskisch. Ist es für einen baskischen Programmierer ok, baskische Bezeichner zu benutzen?
-
SeppJ schrieb:
Marc++us schrieb:
icarus2 schrieb:
Dieses Gemisch aus Deutsch und Englisch (Denglisch) ist erstens unschön und zweitens verstehen halt nicht alle Deutsch.
Es verstehen auch nicht alle Englisch. Sie glauben es zwar, aber...
Dann sind sie eben nicht qualifiziert, um gute Software zu entwickeln. Das ist dann genauso wie ein Programmierer der durch andere Stilfehler schlecht wartbaren Code schreibt. Da besteht meines erachtens nach kein großer Unterschied zwischen jemandem der Spagetthiode schreibt und jemandem der deutsche Bezeichner benutzt. Den Spagetticode kann dann nur ein Genie durchschauen, den deutschen Code nur jemand der Deutsch spricht. Der Unterschied ist bloß die unterschiedliche Anzahl von Deutschsprechern und Genies auf der Welt. Letztlich ist beides für große Teile der Weltbevölkerung unverständlich.
Gegenfrage: Wären Bezeichner auf chinesisch ok? Oder was ist wenn wir eine noch seltenere Sprache als Deutsch sprechen würden, z.B. baskisch. Ist es für einen baskischen Programmierer ok, baskische Bezeichner zu benutzen?
zieh dir doch mal php sourcecode rein, die erlauben ja unicode in bezeichnern. ich hab mich da gelegentlich schon ganz schön geärgert...
