GB Englisch oder US Englisch?

Wenn Sie über eine API verfügen und ein in Großbritannien ansässiger Entwickler mit einem sehr internationalen Publikum sind, sollte dies Ihre API sein

setColour()

oder

setColor()

(Um ein Wort als einfaches Beispiel zu nehmen.)

In Großbritannien ansässige Ingenieure sind in Bezug auf ihre „korrekten“ Schreibweisen oft recht defensiv, aber es könnte argumentiert werden, dass die US-Rechtschreibung auf dem internationalen Markt eher „Standard“ ist.

Ich denke die Frage ist, ist es wichtig? Haben Entwickler in anderen Regionen Probleme mit der Rechtschreibung von GB oder ist normalerweise klar, was die Dinge bedeuten?

Sollte alles US-Englisch sein?

Ich würde eher US-Englisch verwenden, da dies in anderen APIs zur Norm geworden ist. Als englischer Programmierer habe ich zum Beispiel kein Problem damit, "Farbe" zu verwenden.

Ich bin kein Muttersprachler. Beim Schreiben versuche ich immer zu verwenden en-gb. Beim Programmieren verwende ich jedoch immer en-usanstelle von britischem Englisch, aus dem gleichen Grund, aus dem ich für meine Bezeichner weder Deutsch noch Französisch verwende.

Kommt darauf an, wo Sie die meisten Ihrer Kunden sehen. Ich persönlich bevorzuge die Verwendung von Englisch-GB (z. B. Farbe) in meinem privaten Code, aber ich gehe zu Farbe für extern veröffentlichte Anwendungen / API / Code!

Im Allgemeinen wäre ich ein Verfechter der GB-Rechtschreibung, aber ich denke, dass der Code viel besser liest, wenn er konsistent ist und ich finde:

Color lineColor = Color.Red;

viel besser aussehen als:

Color lineColour = Color.Red;

Ich denke, dass es letztendlich nicht wirklich wichtig ist.

Obwohl ich in Bezug auf die korrekte Rechtschreibung normalerweise sehr umständlich bin, würde ich als britischer Entwickler immer die amerikanische "Farb" -Schreibweise verwenden. In allen Programmiersprachen, auf die ich gestoßen bin, ist es so. Aus Gründen der Konsistenz ist die Verwendung von 'Farbe' sehr sinnvoll.

Angenommen, dies ist eine Java- oder C # -API, spielt dies wahrscheinlich keine Rolle, da die Funktionen zur automatischen Vervollständigung in den IDEs allgegenwärtig sind. Wenn dies für eine dynamische Sprache ist oder eine, in der moderne IDEs nicht die Norm sind, würde ich mich für die amerikanische Schreibweise entscheiden. Natürlich bin ich Amerikaner und daher offensichtlich voreingenommen, aber es scheint, als würde der größte Teil des Codes, den ich von Entwicklern sehe, die nicht Englisch als Muttersprache haben, US-Schreibweisen für ihre Variablennamen usw. verwenden.

Als englischer Programmierer verwende ich en-US für meinen Softwareentwickler. Amerikanisches Englisch dominiert in fast jeder anderen API so gut, dass es viel einfacher ist, sich an eine Schreibweise zu halten und die Mehrdeutigkeit zu beseitigen. Es ist Zeitverschwendung, nach einer Methode zu suchen, nur um herauszufinden, dass die Rechtschreibung aufgrund von Rechtschreiblokalisierungen um einen Buchstaben abweicht.

Ich würde mit den aktuellen Standards gehen und die US-englische Schreibweise wählen. HTML und CSS sind anerkannte Standards mit der Schreibweise "Farbe". Wenn Sie mit einem Framework wie .NET arbeiten, ist möglicherweise bereits Farbe in verschiedenen Namensräumen verfügbar.

Die mentale Steuer, mit zwei Schreibweisen umgehen zu müssen, würde den Entwicklern eher helfen als helfen.

Label myLabel.color = setColour();

Ich habe Probleme mit APIs, die nicht in US-Englisch verfügbar sind. Nur wegen der Rechtschreibunterschiede. Ich weiß, was die Wörter bedeuten, aber die unterschiedliche Schreibweise stört mich.

Die meisten Bibliotheken und Frameworks, mit denen ich vertraut bin, verwenden die US-Schreibweise. Natürlich bin ich Amerikaner, also ... US-Englisch ist meine Muttersprache.

Der Großteil der Entwicklungsdokumentation (genau wie MSDN) ist in amerikanischem Englisch.

Daher ist es möglicherweise besser, beim Mainstream zu bleiben und amerikanisches Englisch in Ihrer API zu verwenden, wenn Sie sich an ein internationales Publikum wenden.

Ich habe ein weiteres Beispiel: Serialisieren und Serialisieren. :) :)

Persönlich denke ich nicht, dass es viel ausmacht. Ich habe an Projekten gearbeitet, die britisch-englische Rechtschreibländer verwenden und die britische Rechtschreibung verwenden. Es ist immer noch Englisch und es spielt aufgrund von Intellisense keine große Rolle.

Als Kanadier stoße ich die ganze Zeit darauf. Es ist sehr schwierig für mich, "Farbe" einzugeben, da mein Muskelgedächtnis immer wieder nach dem "u" greift.

Ich neige jedoch dazu, die Sprache der Bibliotheken zu übernehmen. Java hat die Color-Klasse, daher verwende ich Farbe.

Ich versuche nach Möglichkeit alternative Wörter zu finden. Ich werde -ize gleiten lassen. Für Farbe könnte ich möglicherweise Farbton, Tinte, Vordergrund / Hintergrund verwenden ...

Wenn nicht, werde ich als Engländer en-GB verwenden, weil ich noch etwas Stolz auf mein Land und meine Herkunft habe.

Wenn es jedoch Teil eines größeren Projekts sein sollte, insbesondere eines internationalen, würde ich das gesamte Projekt konsistent halten, wobei ein kleiner Teil in einer Sprachvariante und der Rest in einer anderen enthalten wäre.

Ich werde mich auch auf die Seite von US-Englisch stellen müssen, um die Dinge konsistent zu halten (wie andere hier bereits bemerkt haben). Obwohl ich ein US-englischer Muttersprachler bin, habe ich Softwareprojekte mit deutschen und schwedischen Softwareunternehmen durchgeführt, und in beiden Fällen traf die Versuchung meine Teamkollegen gelegentlich, deutschen oder schwedischen Text im Code zu verwenden - normalerweise für Kommentare, aber manchmal auch für Variablen- oder Methodennamen. Obwohl ich diese Sprachen sprechen kann, erschüttert es die Augen sehr und macht es schwieriger, einen neuen Nicht-Sprecher in das Projekt einzubeziehen.

Die meisten europäischen Softwareunternehmen (zumindest die, mit denen ich zusammengearbeitet habe) verhalten sich genauso - der Code bleibt auf Englisch, einfach weil der Code dadurch internationaler wird, wenn ein anderer Programmierer an Bord kommt. Die interne Dokumentation erfolgt jedoch in der Regel in der Muttersprache.

Die Unterscheidung hier betrifft jedoch zwei verschiedene Dialekte des Englischen, was nicht ganz so extrem ist, als zwei völlig unterschiedliche Sprachen in derselben Quellcodedatei zu sehen. Also würde ich sagen, behalten Sie die API in US-Englisch, aber Ihre Kommentare in GB-Englisch, wenn es Ihnen besser passt.

Ich würde sagen, schauen Sie sich an, wie andere Bibliotheken in Ihrer Sprache ihre Konventionen auswählen und befolgen.

Die Designer der Programmiersprache und ihrer integrierten APIs haben eine Wahl getroffen, und ob die Benutzer international sind oder nicht, sie sind es gewohnt, Schreibweisen zu sehen, die mit dieser Wahl übereinstimmen. Sie richten sich nicht an Sprecher einer anderen Sprache, sondern an Benutzer einer Programmiersprache. Wahrscheinlich haben sie aus den integrierten APIs einige Wörter in der Fremdsprache gelernt, und sie wissen möglicherweise nicht, dass es Unterschiede zwischen US-Englisch und GB-Englisch gibt. Verwechseln Sie sie nicht, indem Sie die Seiten des Teichs wechseln.

Ich verwende hauptsächlich .NET-Sprachen und .NET Framework verwendet US-Englisch-Schreibweisen. Auf dieser Plattform würde ich mich an US-Englisch halten. Mir sind keine auf GB-Englisch standardisierten Sprachen bekannt, aber wenn Ihre dies getan haben, bleiben Sie auf jeden Fall mit der Sprache konsistent.

Ich stimme der "go for American" -Truppe zu. Ich selbst bevorzuge en-GB beim Schreiben von E-Mails und dergleichen, aber amerikanisches Englisch ist so ziemlich der Standard in allen Programmierkreisen.

Obwohl auf der ganzen Welt britisches Englisch gesprochen wird, empfehle ich die Verwendung von amerikanischem Englisch, das, wie andere Leute gesagt haben, den Markt dominiert.

Auf jeden Fall US-Englisch.

Erstens bin ich in den USA. In meinem aktuellen Projekt ist es immer "Farbe", aber das Wort, für das wir scheinbar keine Schreibweise auswählen können, ist "grau" gegen "grau".

Es ist eigentlich ziemlich nervig geworden.

Die Auswahl der Sprache für Bezeichnernamen hat nichts mit der Zielgruppe und alles mit der Originalsprache zu tun, in der das Framework oder die API entwickelt wurde.

Ich kenne nicht sehr viele Sprachen, aber ich kann mir keine einzige vorstellen, die etwas anderes als US-Englisch verwendet.

Die Gefahren der Einführung subtiler Fehler aufgrund unterschiedlicher Schreibweisen sind meiner Meinung nach zu groß.

Eine Funktionsüberschreibung kann leicht zu einer Pseudoüberladung werden.

Eine Konfigurationsdatei kann aufgrund unterschiedlicher Schreibweisen ungültig werden.

Es kann vorkommen, dass dasselbe konzeptionelle Objekt mithilfe mehrerer Klassen definiert wurde, wobei sowohl en-US als auch en-GB verwendet wurden.

Unabhängig davon, ob ein Code ausschließlich für den internen Gebrauch oder auch für den externen Gebrauch bestimmt ist, müssen die verwendeten Schreibweisen immer mit der Originalsprache der Plattform / des Frameworks / Compilers / der API übereinstimmen.

Wenn alle Ihre Programmierer Briten sind, verwenden Sie en-gb. Wenn Ihr Code von Programmierern außerhalb Großbritanniens gesehen wird, ist en-us die bessere Wahl.

Ein kleiner Punkt: Wir verlassen uns auf einen Übersetzungsdienst, um unsere Dokumentation in andere Sprachen zu kopieren. Wir haben festgestellt, dass wir bessere Übersetzungen erhalten, wenn wir en-us als Quelle verwenden.

Sie müssen Ihr Publikum berücksichtigen. Wer wird den Code verwenden und was erwarten sie zu sehen?

Ich arbeite in einem Unternehmen mit Niederlassungen in Kanada und den USA. Wir verwenden die kanadische Rechtschreibung (sehr ähnlich dem britischen Englisch), wenn wir Dokumentation und Code in Kanada und die US-Rechtschreibung für das erstellen, was in den USA verwendet wird.

Einige Dinge überschreiten Grenzen, aber der Unterschied in der Rechtschreibung ist selten ein Problem. Es kann akut einen interessanten Dialog erzeugen, wenn Amerikaner die unterschiedlichen Schreibweisen für Candian und British English nicht kennen. Manchmal sind sie damit einverstanden, manchmal bestehen sie darauf, dass die "richtige" Schreibweise geändert wird. Dies betrifft auch Datumsformate (TT / MM / JJJJ in Kanada und MM / TT / JJJJ in den USA).

Wenn es eine Sackgasse gibt, verwenden wir normalerweise die US-Rechtschreibung, da die Menschen in Kanada mit beiden Varianten vertraut sind.

Der Hauptgrund, warum ich gehört habe, dass ich US gegenüber britischem Englisch gewählt habe, ist, dass das britische Publikum, wenn es mit US-Rechtschreibung konfrontiert wird, erkennt, dass es sich um eine US-Anwendung handelt (oder davon ausgeht), während ein US-Publikum, das mit britischer Rechtschreibung konfrontiert ist, denkt: Hey, das ist falsch. Es ist Farbe, nicht Farbe.

Aber wie andere gesagt haben, standardisieren. Pick on und bleib dabei.

Es ist für mich selbstverständlich, in britischem Englisch zu arbeiten, ohne darüber nachzudenken. Wenn Sie jedoch interne Verfahren entwickeln, spielt dies keine Rolle. Wenn Sie APIs erstellen, die öffentlich verwendet werden, und Ihre Zielgruppe international ist, warum nicht beide implementieren?

Ich bevorzuge US-Englisch.

Ich bin einer dieser Leute, deren Herzfrequenz und Blutdruck jedes Mal steigen, wenn ich gezwungen bin, amerikanisches Englisch in Setup-Dateien usw. zu verwenden, da die Software keine Option für britisches Englisch bietet, aber das ist einfach so mich :)

Meine persönliche Meinung zu diesem Thema wäre jedoch, beide Schreibweisen anzugeben, ihnen setColor () und setColour () zu geben, den Code in einen von ihnen zu schreiben und nur den zweiten die Parameter durchlaufen zu lassen.

Auf diese Weise halten Sie beide Gruppen bei Laune, vorausgesetzt, Ihre Intelligenz wird etwas länger, aber zumindest können sich die Leute nicht darüber beschweren, dass Sie die „falsche“ Sprache verwenden.

Wenn Sie ein paar hundert Jahre zurückblicken, werden Sie feststellen, dass die Veränderung überhaupt nichts mit den USA zu tun hat, so wie es viele denken würden. Die Veränderungen sind auf europäische Einflüsse zurückzuführen, insbesondere auf die französischen. Vor dieser Zeit wurde das englische Wort "Farbe" tatsächlich "Farbe" geschrieben.

Der Versuch einer Standardisierung wäre zwecklos, da die Hälfte der chinesischen Kinder den voreuropäischen Einfluss und das Verständnis der USA für Englisch lernt, während die andere Hälfte den heutigen Stand der englischen Sprache aufgreift.

Wenn Sie der Meinung sind, dass Sprache ein Problem ist, sollten Sie das Taiwan Kg in Betracht ziehen, das 600 g wiegt. Ich habe noch nicht herausgefunden, wie sie das geschafft haben, aber ich hoffe, dass sie nie als Flugzeugbetankungspersonal beschäftigt sind!

Ich benutze immer en-GB für alle meine Programmierungen. Ich denke, das liegt an einem starken Einfluss britischer Romane.

Könnte es jedoch nicht möglich sein, zwei verschiedene Sätze von APIs zu haben (einen für en-US, einen für en-GB), die intern dieselbe Funktion aufrufen? Dies könnte jedoch die Header-Dateien aufblähen, also abhängig von einer Präprozessordefinition, einer bedingten Kompilierung? Wenn Sie C ++ verwenden, können Sie Folgendes tun ...

#ifdef ENGB
     typedef struct Colour
     {
      //blahblahblah
     };
     void SetColour(Colour c);
#else
    typedef struct Color
    {
      //blahblahblah
    };
    void SetColor(Color c);
#endif

Abhängig davon, ob der Client-Programmierer ENGB wie folgt definiert oder nicht

#define ENGB

Er könnte die APIs in der Kultur verwenden, die er bevorzugt. Vielleicht übertrieben für solch einen trivialen Zweck, aber hey, wenn es wichtig erscheint, warum nicht! :) :)