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