GB英語、それとも米国英語？
APIをお持ちで、英国を拠点とする開発者であり、国際的な視聴者が多い場合、APIは
setColour()
または
setColor()
（簡単な例として1つの単語を取り上げます。）
英国を拠点とするエンジニアは、多くの場合、「正しい」スペルについてかなり防御的ですが、米国のスペルは国際市場ではより「標準的」であると主張することができます。
問題はそれが重要かということだと思います。他のロケールの開発者はGBのスペルに苦労していますか、それとも通常、何を意味するのかは明らかですか？
それはすべてアメリカ英語である必要がありますか？
他のAPIでは標準になっているので、私は米国英語を使用する傾向があります。英語のプログラマーとして言えば、例えば「色」を使っても問題ありません。
私はネイティブスピーカーではありません。書面では、私は常にen-gbを使用しようとします。ただし、プログラミングでは、識別子にドイツ語やフランス語を使用しないのとほぼ同じ理由で、イギリス英語の代わりに常にen-usを使用します。
あなたがあなたの顧客のほとんどを見る場所に依存します。私は個人的に英語-GB（例：Colour）をプライベートコードで使用することを好みますが、外部に公開されたアプリケーション/ API /コードについてはColorに行きます！
一般的に、私はGBスペルのこだわりを持っていますが、一貫性があり、次のことがわかった場合、コードの読み取りははるかに良くなると思います。
Color lineColor = Color.Red;
よりよく見えるために：
Color lineColour = Color.Red;
最終的には問題ではないと思います。
私は通常、正しいつづりについて非常に衒学者ですが、英国の開発者として、私は常にアメリカの「色」のつづりを使用します。私が遭遇したすべてのプログラミング言語では、このようなものなので、一貫性を保つために、「color」を使用することは非常に理にかなっています。
英語のプログラマーとして、私はソフトウェア開発にen-USを使用しています。アメリカ英語は他のほとんどすべてのAPIで非常によく支配されているため、1つのタイプのスペルに固執して、あいまいさを取り除く方がはるかに簡単です。スペルのローカリゼーションのために、スペルが1文字ずれていることを見つけるためだけにメソッドを検索するのは時間の無駄です。
これがJavaまたはC＃APIであると仮定すると、IDEのオートコンプリート機能の普及を考えると、おそらく問題ではありません。これが動的言語の場合、または最新のIDEがない言語の場合もちろん、私はアメリカ人なので、明らかに偏見がありますが、英語を母国語としない開発者から見たコードのほとんどは、変数名などに米国式のスペルを使用しているようです。
私は現在の基準を採用し、アメリカ英語のスペルを選びます。 HTMLとCSSは、「色」というスペルの標準として認められています。次に、.NETのようなフレームワークを使用している場合は、別の名前空間ですでに色を使用できる可能性があります。
2つのスペルを処理しなければならないという精神的な負担は、開発者を助けるのではなく、妨げるでしょう。
Label myLabel.color = setColour();
アメリカ英語以外のAPIに問題があります。スペルの違いのためだけに。私はその言葉が何を意味するのか知っていますが、つづりが違うと私はつまずきます。
私が精通しているライブラリとフレームワークのほとんどは、米国のスペルを使用しています。もちろん、私はアメリカ人なので...アメリカ英語は私の母国語です。
開発ドキュメントの大部分（MSDNと同様）はアメリカ英語です。
したがって、海外の視聴者をターゲットにしている場合は、主流にとどまり、APIでアメリカ英語を使用する方がよい場合があります。
別のサンプルを入手しました：SerialiseとSerialize。 :)
個人的には、それほど重要ではないと思います。私は英国英語のスペルの国を使用していたプロジェクトに取り組んできましたが、彼らは英国のスペルを使用しています。それはまだ英語であり、Intellisenseのおかげでそれほど重要ではありません。
カナダ人として、私はいつもこれに遭遇します。私の筋肉の記憶が「u」に到達し続けるので、「色」を入力するのは非常に困難です。
しかし、私は図書館の言語を採用する傾向があります。 JavaにはColorクラスがあるので、colorを使用します。
識別子名の言語の選択は、対象者とは関係がなく、フレームワークまたはAPIが開発された元の言語と関係があります。
私はあまり多くの言語を知りませんが、米国英語以外のものを使用する単一の言語を考えることはできません。
スペルが異なるために微妙なバグが発生する危険性は、私見では大きすぎます。
関数のオーバーライドは、簡単に疑似オーバーロードになる可能性があります。
スペルの違いにより、設定ファイルが無効になる可能性があります。
En-USとen-GBの両方を使用して、複数のクラスを使用して同じ概念オブジェクトが定義されている状況が発生する可能性があります。
したがって、コードの一部が純粋に内部使用であろうと外部使用であろうと、使用されるスペルは常にプラットフォーム/フレームワーク/コンパイラ/ APIの元の言語と一致する必要があります。
私は「アメリカに行く」部隊に同意します。私自身、メールなどを書くときはen-GBを好みますが、アメリカ英語はすべてのプログラミング界でほぼ標準です。
私はまた、単に物事の一貫性を保つために、米国英語を支持する必要があります（他の人がすでにここで述べているように）。私は米国英語を母国語としていますが、ドイツ語とスウェーデン語の両方のソフトウェア会社とソフトウェアプロジェクトを行ってきました。どちらの場合も、チームメートがコードでドイツ語またはスウェーデン語のテキストを使用するように誘惑されることがあります。通常はコメントですが、変数名やメソッド名の場合もあります。私はそれらの言語を話すことができますが、それは本当に目に不快であり、新しい非話者をプロジェクトに持ち込むことを難しくします。
ほとんどのヨーロッパのソフトウェア会社（少なくとも私が協力してきた会社）は同じように動作します。コードは英語のままです。これは、別のプログラマーが参加した場合にコードがより国際的に使いやすいためです。ただし、内部ドキュメントは通常、母国語で作成される傾向があります。
とは言うものの、ここでの違いは英語の2つの異なる方言についてであり、同じソースコードファイルで2つのまったく異なる言語を見るほど極端ではありません。つまり、APIは米国英語のままにしておきますが、コメントの方が適している場合はGB英語にします。
あなたの言語の他の図書館がどのように彼らの慣習を選択し、それに従うかを見てください。
プログラミング言語とその組み込みAPIの設計者が選択を行い、ユーザーが国際的であるかどうかにかかわらず、この選択と一致するスペルを見ることに慣れています。別の言語の話者ではなく、プログラミング言語のユーザーを対象としています。組み込みのAPIから外国語でかなりの数の単語を学んだ可能性があり、米国英語と英国英語の違いに気付いていない可能性があります。池の側面を切り替えて混乱させないでください。
私は主に.NET言語を使用し、.NETFrameworkは米国英語のスペルを使用します。このプラットフォームでは、私は米国英語に固執します。 GB英語で標準化されている言語はわかりませんが、標準化されている場合は、必ずその言語との一貫性を保ってください。
間違いなくアメリカ英語。
イギリス英語は世界中で話されていますが、他の人と同じように市場を支配していると言われているアメリカ英語を使用することをお勧めします。
まず、私はアメリカにいます。私の現在のプロジェクトでは、それは常に「色」ですが、スペルを選択できないように見える単語は「灰色」と「灰色」です。
それは実際にはかなり迷惑になっています。
可能であれば、別の単語を探すようにしています。スライドさせます。色については、色相、インク、前景/背景を使用できます...
そうでなければ、イギリス人として、私は自分の国と出身地に誇りを持っているので、en-GBを使用します。
しかし、それがより大きなプロジェクト、特に国際的なプロジェクトの一部である場合、私はプロジェクト全体の一貫性を保ち、小さな部分を1つの言語のバリエーションに、残りを別の言語のバリエーションに含めることにします。
私は、ソフトウェアがイギリス英語のオプションを提供していないという事実のために、セットアップファイルなどでアメリカ英語を使用することを余儀なくされるたびに心拍数と血圧が上昇するこれらの人々の1人ですが、それはただです私:)
ただし、これに関する私の個人的な意見は、両方のスペルを提供し、それらにsetColor（）とsetColour（）を与え、それらの1つにコードを記述し、2番目のスペルにパラメーターを渡すことです。
このようにして、インテリセンスが少し長くなることを前提として、両方のグループを幸せに保ちますが、少なくとも人々は「間違った」言語を使用してあなたについて不平を言うことはできません。
すべてのプログラマーが英国人である場合は、en-gbを使用してください。あなたのコードが英国以外のプログラマーに見られるのであれば、en-usの方が良い選択でしょう。
マイナーな点の1つは、ドキュメントを他の言語にコピーするために翻訳サービスに依存していることです。 en-usをソースとして使用すると、より良い翻訳が得られることがわかりました。
あなたはあなたの聴衆を考慮する必要があります。誰がコードを使用し、彼らは何を期待していますか？
私はカナダと米国の両方にオフィスを構える会社で働いています。カナダでドキュメントとコードを作成するときはカナダのスペル（イギリス英語に非常に似ています）を使用し、米国で使用されているものについては米国のスペルを使用します。
国境を越えるものもありますが、スペルの違いが問題になることはめったにありません。アメリカ人がイギリス英語とイギリス英語の異なるスペルを認識していない場合、それは実際にいくつかの興味深い対話を生み出す可能性があります。時々彼らはそれで大丈夫です、他の時には彼らはそれが「正しい」つづりに変わることを主張します。これは日付形式にも影響します（カナダではdd/mm/yyyy、米国ではmm/dd/yyyy）
行き詰まりがある場合、カナダの人々は両方のバリエーションに精通しているため、通常は米国のスペルを使用します。
私はすべてのプログラミングに常にen-GBを使用しています。イギリスの小説の影響が大きいからだと思います。
ただし、内部で同じ関数を呼び出す2つの異なるAPIセット（1つはen-US用、もう1つは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を使用することができました。たぶん、そのような些細な目的のためにやり過ぎかもしれませんが、それが重要であると思われる場合は、なぜですか？ :)
数百年を振り返ると、多くの人がそう思うように、この変化は米国とはまったく関係がないことがわかります。変化はヨーロッパの影響、特にフランスから生じています。それ以前は、英語の単語「color」は実際には「color」と綴られていました。
中国の子供たちの半数がヨーロッパ以前の影響と米国の英語の理解を学んでいる一方で、残りの半数は現在の英語としてそれを取り入れているので、標準化を試みることは無駄です。
言語が問題だと思うなら、600gの台湾Kgを検討する必要があります。彼らがそれをどのように管理したかはまだわかりませんが、彼らが航空機の燃料補給要員として雇用されないことを願っています！
私が英国の英語よりも米国を選んだ主な理由は、英国の聴衆が米国のスペリングに直面したとき、それが米国のアプリケーションであることに気付く（またはそうだと推測する）のに対し、英国のスペリングに直面した米国の聴衆は考えているからです。 。ねえ、それは間違っています..それは色ではなく色です」
しかし、他の人が言っているように、標準化してください。選んで、それに固執します。
何も考えずにイギリス英語で仕事をするのは当然のことです。ただし、内部手順を開発している場合、それは実際には重要ではありません。公に使用されるAPIを作成していて、対象者が国際的である場合は、両方を実装してみませんか？
私はアメリカ英語が好きです。