APIを使用していて、非常に国際的なオーディエンスを持つ英国ベースの開発者である場合、APIは
setColour()
または
setColor()
（1つの単語を簡単な例として取り上げます。）
英国に拠点を置くエンジニアは、多くの場合、「正しい」スペルについてかなり防御的ですが、米国のスペルは国際市場ではより「標準的」であると主張できます。
問題はそれが問題なのでしょうか？他のロケールの開発者はGBスペルに苦労していますか、それとも通常、意味がかなり明白ですか？
すべてを米国英語にする必要がありますか？
回答:
ほとんどの顧客がいる場所によって異なります。私個人的には、プライベートコードでEnglish-GB（例：Colour）を使用することを好みますが、外部で公開されたアプリケーション/ API /コードについてはColorに行きます！
これがJavaまたはC＃APIであると仮定すると、IDEのオートコンプリート機能が広く普及していることを考えると、おそらく問題ではありません。これが動的言語または現代のIDEが標準ではない言語の場合は、アメリカのスペルを使用します。もちろん私はアメリカ人なので、明らかに偏っていますが、英語を母国語としない開発者から見たコードのほとんどは、変数名に米国のスペルを使用しているようです。
開発ドキュメントの大部分（MSDNと同様）はアメリカ英語です。
したがって、海外の視聴者をターゲットにする場合は、APIで主流にとどまり、アメリカ英語を使用する方がよい場合があります。
私は別のサンプルを得ました：SerializeとSerializeです。:)
個人的にはそれほど重要ではないと思います。私は英国英語のスペルの国を使用していたプロジェクトに取り組み、彼らは英国のスペルを使用しています。それはまだ英語であり、それはIntellisenseのためにそれほど重要ではありません。
できれば別の単語を探します。スライド化します。色については、色相、インク、前景/背景を使用できます...
そうでない場合は、イギリス人としてen-GBを使用します。国と出身国に誇りがあるからです。
しかし、それがより大きなプロジェクトの一部、特に国際的なプロジェクトの一部である場合、私はプロジェクト全体の一貫性を保ち、一部を1つの言語バリエーションに、残りを別の言語バリエーションに含めます。
また、物事の一貫性を保つために、US-Englishを使用する必要があります（他の人がすでにここで述べているように）。私はアメリカ英語を母国語としていますが、ドイツ語とスウェーデン語の両方のソフトウェア会社とソフトウェアプロジェクトを行っており、どちらの場合も、チームメートがコードでドイツ語またはスウェーデン語のテキストを使用するように誘惑することがあります。変数名またはメソッド名の場合もあります。私はそれらの言語を話すことはできますが、それは実際には目障りで、プロジェクトに新しい非スピーカーを連れてくるのを難しくしています。
ほとんどのヨーロッパのソフトウェア会社（少なくとも私が使用した会社）は同じように動作します-コードが英語のままである理由は、別のプログラマーが参加してもコードがより国際的にフレンドリーになるからです。ただし、内部のドキュメントは通常、母国語で作成される傾向があります。
とは言っても、ここでの違いは英語の2つの異なる方言についてであり、同じソースコードファイルで2つのまったく異なる言語を見るほど極端ではありません。ですから、APIは英語（米国）のままにしておきますが、コメントの方が適切であればGB（英語）にします。
私はあなたの言語の他のライブラリがどのようにそれらの慣習を選択し、それに従うかを見てみようと思います。
プログラミング言語とその組み込みAPIの設計者は選択を行い、ユーザーが国際的であるかどうかにかかわらず、この選択と一致するスペルを使用することに慣れています。あなたは別の言語の話者ではなく、プログラミング言語のユーザーを対象としています。奇妙なことに、組み込みのAPIから外国語でかなりの数の単語を学習しており、アメリカ英語とイギリス英語の違いに気付かないかもしれません。池の側面を入れ替えて混乱させないでください。
私は主に.NET言語を使用しており、.NET Frameworkは米国英語のスペルを使用しています。このプラットフォームでは、米国英語を使用します。私はGB英語で標準化されている言語を知りませんが、あなたの言語が標準化している場合は、その言語と一貫性を保つようにしてください。
まず、私はアメリカにいます。私の現在のプロジェクトでは、常に「色」ですが、スペルを選択できないように見える単語は「灰色」対「灰色」です。
実際にはかなり面倒です。
識別子名の言語の選択は、オーディエンスとは関係なく、フレームワークまたはAPIが開発された元の言語とすべて関係があります。
私はあまり言語を知りませんが、アメリカ英語以外を使用する単一の言語を考えることはできません。
スペルが異なるために微妙なバグが発生する危険性は、非常に大きいです。
関数オーバーライドは、簡単に疑似オーバーロードになる可能性があります。
スペルの違いにより、設定ファイルが無効になる可能性があります。
en-USとen-GBの両方を使用して、同じ概念オブジェクトが複数のクラスを使用して定義されている状況が発生する可能性があります。
したがって、コードの一部が純粋に内部で使用される場合でも、外部で使用される場合でも、使用されるスペリングは常にプラットフォーム/フレームワーク/コンパイラ/ APIの元の言語と一致する必要があります。
あなたはあなたの聴衆を考慮する必要があります。誰がコードを使用するのか、そして彼らが何を期待するのか？
私はカナダと米国の両方にオフィスを持つ会社で働いています。米国で使用されているものに対してカナダと米国のスペルでドキュメントとコードを作成する場合、カナダのスペル（イギリス英語に非常に類似）を使用します。
国境を越えるものもありますが、スペルの違いが問題になることはほとんどありません。アメリカン英語とイギリス英語のスペルが異なることにアメリカ人が気付いていない場合、実際に興味深い対話を生成できます。彼らはそれで大丈夫なこともあれば、「正しい」スペルに変更することを主張することもあります。これは日付形式にも影響します（カナダではdd / mm / yyyy、米国ではmm / dd / yyyy）
行き詰まりがある場合、カナダの人々は両方のバリエーションに精通しているため、通常は米国のスペルを使用します。
英国英語よりも米国を選択した主な理由は、英国の聴衆が米国のスペルに直面したときに、それが米国のアプリケーションであることを認識している（またはそうであると想定）のに対し、英国のスペルに直面した米国の聴衆は、ねえ、それは間違っている..それは色ではなく色だ」
しかし、他の人が言ったように、標準化します。選んで、それに固執する。
私はこれらの人々の1人です。セットアップファイルなどでアメリカ英語を使用するように強いられるたびに心拍数と血圧が上昇します。これは、ソフトウェアがイギリス英語のオプションを提供しないためです。私:)
しかし、これに関する私の個人的な意見は、両方のスペルを提供し、それらにsetColor（）とsetColour（）を与え、そのうちの1つにコードを記述し、2番目のスペルにパラメーターを渡すことです。
このようにして、両方のグループを幸せに保ち、インテリセンスが少し長くなることを認めますが、少なくとも人々は「間違った」言語を使用することに不満を言うことはできません。
数百年を振り返ってみると、多くの人が考えているように、この変化は米国とはまったく関係がないことがわかります。変化はヨーロッパの影響、特にフランス人の影響によるものです。その前は、英語の「色」は実際には「色」と綴られていました。
中国の子供たちの半分は英語の前ヨーロッパの影響と米国の英語の理解を学んでいるが、残りの半分は現在のように英語としてそれを取り入れているので、標準化を試みることは無駄だ。
言語が問題だと思われる場合は、600gの台湾Kgを検討してください。彼らがそれをどのように管理したかはまだわかりませんが、航空機の燃料補給担当者として雇用されていないことを願っています！
私はすべてのプログラミングに常に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を使うことができました。多分そのような些細な目的のためにやり過ぎかもしれませんが、ちょっと、それが重要であると思われるなら、なぜでしょうか！:)