GB英語、それともアメリカ英語？

https://stackoverflow.com/questions/157807

03-07-2019
|

質問

APIを所有していて、非常に国際的な視聴者を抱える英国ベースの開発者である場合、APIを使用する必要があります

setColour()

または

setColor()

（簡単な例として1つの単語を使用します。）

英国を拠点とするエンジニアは、しばしば彼らの「正しい」綴りに対してかなり防御的ですが、米国の綴りは国際市場でより「標準的」であると主張できます。

問題はそれが問題なのでしょうか？他のロケールの開発者はGBスペリングに苦労していますか、それとも通常は何が意味するのかはっきりしていますか？

それはすべて米国英語ですか？

解決

他のAPIで標準となっている米国英語を使用する傾向があります。英語のプログラマーとして言えば、たとえば「色」を使用しても問題ありません。

他のヒント

私はネイティブスピーカーではありません。執筆では、常に en-gb を使用しようとします。ただし、プログラミングでは、識別子にドイツ語やフランス語を使用しないのとほぼ同じ理由で、イギリス英語の代わりに常に en-us を使用します。

ほとんどの顧客をどこで見るかによって異なります。個人的にはプライベートコードでEnglish-GB（例：カラー）を使用することを好みますが、外部公開アプリケーション/ API /コードの場合はColorにアクセスします！

一般的に私はGBスペリングにこだわりますが、一貫性があり、私が見つけたコードの方がずっと読みやすいと思います：

Color lineColor = Color.Red;

より見栄えを良くするには：

Color lineColour = Color.Red;

最終的にそれは実際には問題ではないと思います。

私は通常、正しいスペルについては非常に熱心ですが、英国の開発者としては常にアメリカの「カラー」スペルを使用します。私が遭遇したすべてのプログラミング言語では、このようになっています。そのため、一貫性を保つために、「色」を使用することは非常に理にかなっています。

これがJavaまたはC＃APIであると仮定すると、IDEのオートコンプリート機能の普及を考えるとおそらく問題ではありません。これが動的言語または現代のIDEが標準ではない言語の場合、私はアメリカの綴りを使用します。もちろん私はアメリカ人なので、明らかに偏見がありますが、英語を母国語としない開発者から見たコードのほとんどは、変数名などにアメリカのスペリングを使用しているようです

英語のプログラマーとして、ソフトウェア開発にen-USを使用しています。アメリカ英語は、他のほとんどすべてのAPIで非常に優勢であるため、1種類のスペルに固執してあいまいさを排除する方がはるかに簡単です。スペルのローカライズにより、スペルが1文字ずれていることを見つけるだけの方法を探すのは時間の無駄です。

現在の標準を使用して、米国英語のスペルを選択します。 HTMLとCSSは、スペルが「色」の標準として認められています。2つ目は、.NETなどのフレームワークを使用している場合、異なる名前空間で既に色を使用できる可能性があることです。

2つのスペルを処理する必要があるという精神的負担は、開発者を支援するのではなく妨げになります。

Label myLabel.color = setColour();

米国英語以外のAPIに問題があります。スペルの違いだけのため。言葉の意味は知っていますが、スペルが違うと私は気が遠くなります。

私がよく知っているライブラリとフレームワークのほとんどは、米国の綴りを使用しています。もちろん、私はアメリカ人です...アメリカ英語は私の母国語です。

開発ドキュメントの大半（MSDNと同様）はアメリカ英語です。

したがって、海外の視聴者を対象とする場合は、メインストリームに留まり、APIでアメリカ英語を使用する方が良い場合があります。

別のサンプルがありました：Serialize and Serialize。：）

個人的には、それはそれほど重要ではないと思います。私は、英国英語のスペリング国を使用しているプロジェクトに取り組んでおり、彼らは英国のスペリングを使用しています。まだ英語であり、IntelliSenseのおかげでそれほど重要ではありません。

カナダ人として、私はいつもこれに遭遇します。「色」と入力するのは非常に困難です。私の筋肉の記憶が「u」に届き続けるので。

しかし、私はライブラリの言語を採用する傾向があります。 JavaにはColorクラスがあるため、色を使用します。

可能であれば、代替単語を見つけようとします。 -izeスライドさせます。色については、色相、インク、前景/背景を使用できます...

そうでない場合、イギリス人として、en-GBを使用します。これは、国と出身地に誇りが残っているためです。

ただし、より大きなプロジェクト、特に国際的なプロジェクトの一部である場合、上記のプロジェクト全体の一貫性を保ち、一部を特定の言語バリエーションに、残りを別の言語バリエーションに含めます。

また、物事の一貫性を保つためだけに、米国英語にも賛同しなければなりません（他の人がすでにここで述べているように）。私はアメリカ英語を母国語としていますが、ドイツとスウェーデンのソフトウェア会社の両方でソフトウェアプロジェクトを行いました。どちらの場合も、チームメイトがコードでドイツ語またはスウェーデン語のテキストを使用するように誘惑することがあります。変数名やメソッド名の場合もあります。私はそれらの言語を話せますが、目には本当に耳障りで、プロジェクトに新しい非スピーカーを持ち込むのが難しくなります。

ヨーロッパのほとんどのソフトウェア会社（少なくとも私が働いた会社）は同じように振る舞います-コードが英語のままであるのは、単に別のプログラマーが参加してもコードが国際的に使いやすくなるからです。ただし、内部ドキュメントは通常、ネイティブ言語で作成される傾向があります。

とはいえ、ここでの違いは英語の2つの異なる方言についてであり、同じソースコードファイルで2つのまったく異なる言語を見るほど極端ではありません。したがって、APIは英語（米国）のままにしておきますが、より適切な場合はGB-英語でコメントしてください。

お使いの言語の他のライブラリがどのように選択し、その規則に従うかを見てください。

プログラミング言語とその組み込みAPIの設計者が選択を行い、ユーザーが国際的かどうかにかかわらず、この選択と一致するスペルを見ることに慣れています。異なる言語のスピーカーではなく、プログラミング言語のユーザーをターゲットにしています。おそらく、彼らは組み込みAPIから外国語でかなり多くの単語を学んでおり、アメリカ英語とGB英語の違いがあることに気付かないかもしれません。池の側面を切り替えることでそれらを混同しないでください。

主に.NET言語を使用していますが、.NET Frameworkは米国英語のスペルを使用しています。このプラットフォームでは、アメリカ英語に固執します。 GB Englishで標準化されている言語については知りませんが、もしあなたがそうしているなら、どうしてもその言語との一貫性を保ちましょう。

「go for American」に同意します;劇団。私自身は、電子メールなどを書く際にen-GBを好みますが、アメリカ英語はほとんどすべてのプログラミングサークルの標準です。

イギリス英語は世界中で話されていますが、他の人が市場を支配していると言っているアメリカ英語を使用することをお勧めします。

間違いなく米国英語。

まず、私はアメリカにいます。私の現在のプロジェクトでは、常に「色」です。ただし、スペルを選択できないように思われる単語は「灰色」です。 vs＆quot; gray＆quot;。

実際にはかなり面倒です。

私は、セットアップファイルなどでアメリカ英語を使用せざるを得ないたびに心拍数と血圧が上昇する人の1人です。これは、ソフトウェアがイギリス英語のオプションを提供していないためです。しかし、それは私だけです：）

しかし、これに関する私の個人的な意見は、両方のスペルを提供し、それらにsetColor（）とsetColour（）を与え、それらの1つにコードを記述し、2番目のものにパラメーターを渡すだけです。

この方法では、両方のグループを幸せに保ち、インテリセンスが少し長くなりますが、少なくとも「間違った」言語を使用していると文句を言うことはできません。

識別子名の言語の選択は、対象者とは関係がなく、フレームワークまたはAPIが開発された元の言語とすべて関係があります。

あまり多くの言語を知らないが、アメリカ英語以外のものを使用する単一の言語を考えることはできない。

スペルが異なるために微妙なバグが発生する危険性は非常に大きいです。

関数のオーバーライドは、簡単に疑似オーバーロードになります。

構成ファイルは、スペルの違いにより無効になる可能性があります。

en-USとen-GBの両方を使用して、複数のクラスを使用して同じ概念オブジェクトが定義されている状況が発生する場合があります。

したがって、コードの一部が純粋に内部で使用される場合でも、外部で使用される場合でも、使用されるスペルは常にプラットフォーム/フレームワーク/コンパイラ/ APIの元の言語と一致する必要があります。

すべてのプログラマが英国人の場合、en-gbを使用します。もしあなたのコードがイギリス国外のプログラマに見られるなら、en-usがより良い選択でしょう。

1つの小さな点は、翻訳サービスを利用してドキュメントを他の言語にコピーすることです。 en-usをソースとして使用すると、より良い翻訳が得られることがわかりました。

視聴者を考慮する必要があります。誰がコードを使用するのか、彼らは何を期待しているのですか？

カナダとカナダの両方にオフィスがある会社で働いています。米国。カナダでのドキュメントとコードの作成時にカナダのスペル（イギリス英語に非常に類似）を使用し、米国で使用されるものの米国のスペルを使用します。

国境を越えるものもありますが、スペルの違いが問題になることはめったにありません。アメリカ人がカナダ英語とイギリス英語の異なるスペルを認識していない場合、実際に興味深い会話を生成できます。時には彼らはそれで問題ないが、そうでない場合は「正しい」に変更することを主張する。つづり。これは日付形式にも影響します（カナダではdd / mm / yyyy、米国ではmm / dd / yyyy）

行き詰まりがある場合、カナダの人々は両方のバリエーションに精通しているため、通常は米国式のスペルを使用します。

イギリス英語よりもアメリカを選んだ主な理由は、イギリスの視聴者がアメリカのスペリングに直面したとき、それがアメリカのアプリケーションであることに気づいているからです（または、そうだと思われます）。「...ねえ、それは間違っています。色ではなく色です」

しかし、他の人が言ったように、標準化してください。選んでそれを使い続けます。

イギリスの英語で仕事をすることさえ考えずに仕事をすることは私にとって自然なことです。ただし、内部手順を開発している場合、それは実際には重要ではありません。公に使用されるAPIを作成していて、視聴者が国際的な場合、両方を実装してみませんか？

アメリカ英語が好きです。

数百年を振り返ると、変化は米国とは何の関係もありません。多くの人がそう思うでしょう。この変化はヨーロッパの影響、特にフランスの影響に起因しています。その前に、英語の単語「色」その後、実際には「色」と綴られていました。

標準化を試みることは、中国の子供の半分が英語の前ヨーロッパの影響とアメリカの理解を学んでおり、残りの半分は英語として今日それを取り扱っているので、無駄になります。

言語に問題があると思われる場合は、重量が600gの台湾Kgを考慮する必要があります。彼らがどのようにそれを管理したかはまだわかりませんが、彼らが航空機の燃料補給要員として雇われていないことを願っています！

すべてのプログラミングで常にen-GBを使用しています。イギリスの小説の影響が大きいためだと思います。

ただし、同じ関数を内部的に呼び出す2つの異なるAPIセット（en-US用、en-GB用）を使用できない場合がありますか？ただし、ヘッダーファイルが肥大化する可能性があるため、プリプロセッサの定義、条件付きコンパイルに依存する可能性があります。 C ++を使用している場合、以下のようなことができます...

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

クライアントプログラマがENGBを以下のように定義しているかどうかによって異なります

#define ENGB

彼は好みの文化でAPIを使用できます。このような些細な目的のために多すぎるかもしれませんが、それが重要だと思えば、なぜそうではありません！：）

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow