如果我们有API，并且我们是英国的开发人员，并且具有很高的国际受众群体，那么API应该是

setColour()

或者

setColor()

(以一个字为例)。

英国工程师通常对自己的"正确"拼写颇为防御，但可以说美国拼写在国际市场上更为"标准"。

我想问题是重要的吗？其他地区的开发人员是否在拼写GB拼写方面挣扎，还是通常很清楚这是什么意思？

都应该是美式英语吗？

解决方案

我倾向于使用美式英语，因为这已成为其他API的规范。以英语程序员的身份讲，例如，使用"颜色"没有任何问题。

取决于我们看到大多数客户的位置。我个人更喜欢在我的私人代码中使用English-GB(例如，颜色)，但是我去Color查阅外部发布的应用程序/ API /代码！

我用非美国英语的API遇到麻烦。只是因为拼写不同。我知道单词的意思，但是不同的拼写使我感到震惊。

我熟悉的大多数库和框架都使用美国拼写。当然，我是美国人，所以...美国英语是我的母语。

我得到了另一个示例：序列化和序列化。 :)

就个人而言，我认为这并不重要。我从事的项目使用的是英式英语拼写国家，而他们使用的是英国拼写。它仍然是英语，由于Intellisense，它并没有多大关系。

尽管我通常对正确的拼写非常着迷，但作为英国开发人员，我总是会选择美国的"颜色"拼写。在我遇到的所有编程语言中，都是这样，因此，为了保持一致性，使用"颜色"很有意义。

假设这是Java或者CAPI，考虑到IDE中自动完成功能的普遍性，这可能并不重要。如果这是一种动态语言，或者不是现代IDE的惯用语言，那么我会使用美国的拼写。我当然是美国人，因此显然有偏见，但似乎我从非英语国家的开发人员那里看到的大多数代码都使用美国拼写作为其变量名等。

大多数开发文档(就像MSDN一样)都使用美式英语。

因此，如果我们要面向国际受众，那么最好还是留在主流并在API中使用美式英语。

我不是母语人士。在写作中，我总是尝试使用en-gb。但是，在编程中，出于与我不使用德语或者法语作为标识符的大致相同的原因，我总是使用" en-us"而不是英式英语。

作为加拿大人，我一直都遇到这种情况。
对我来说，键入"颜色"非常困难，因为我的肌肉记忆力一直持续到" u"。

但是，我倾向于采用库的语言。 Java具有Color类，因此我使用color。

通常，我会很喜欢GB拼写，但是我认为如果代码一致，那么代码的读取效果会更好，我发现：

Color lineColor = Color.Red;

看起来比：

Color lineColour = Color.Red;

我想最终这并不重要。

如果可能，我会尝试寻找替代词。我将让-ize幻灯片。对于颜色，我可能会使用色相，墨水，前景/背景...

如果不是这样，作为英国人，我会使用en-GB，因为我对自己的国家和血统有一些自豪感。

但是，如果要成为更大项目(尤其是国际项目)的一部分，则我会保持整个项目的一致性，而其中的一小部分是一种语言的变化，其余的是另一种语言的变化。

我是其中之一，每次我被迫在设置文件等中使用美式英语时，心率和血压都会升高，原因是该软件未提供用于英式英语的选项，但这仅仅是我 ：)

我个人对此的看法是提供两种拼写，给它们提供setColor()和setColour()，在其中一种代码中编写代码，让第二种将参数传递通过。

这样，我们就可以让两个小组都开心，因为智力会更长一些，但是至少人们不能使用"错误的"语言来抱怨我们。

我会选择当前的标准，然后选择美国英语拼写。 HTML和CSS是公认的带有" color"拼写的标准，其次，如果我们正在使用.NET之类的框架，则很可能已经在不同的名称空间中使用了color。

不得不处理两个拼写的精神税将阻碍而不是帮助开发人员。

Label myLabel.color = setColour();

如果我们所有的程序员都是英国人，请使用en-gb。如果代码将被英国以外的程序员看到，那么en-us将是一个更好的选择。

一点，我们依靠翻译服务将我们的文档复制为其他语言。我们发现，使用en-us作为来源时，我们可以获得更好的翻译。

我还不得不站在美式英语的一边，只是要保持一致(就像其他人已经在这里指出的那样)。尽管我是说英语的美国人，但我曾与德国和瑞典的软件公司一起完成过软件项目，在这两种情况下，这种诱惑有时都会打击我的队友在代码中使用德语或者瑞典语文字-通常是在做评论，但有时也用于变量或者方法名称。即使我会说这些语言，也确实让我感到震颤，这使得在项目中引入新的非母语人士变得更加困难。

大多数欧洲软件公司(至少与我合作过的公司)的行为方式相同-代码保留英语，仅仅是因为如果其他程序员加入，这会使代码对国际更友好。但是，内部文档通常倾向于以母语完成。

就是说，这里的区别是关于英语的两种不同的方言，这并不像在同一源代码文件中看到两种完全不同的语言那样极端。因此，我想说的是，请将该API保留为美国英语，但如果更适合评论，请保留为GB英语。

我想说一下我们所用语言中的其他库如何选择并遵循它们的约定。

编程语言及其内置的API的设计者做出了选择，无论用户是否是国际用户，他们都习惯于查看与该选择一致的拼写。我们不是针对使用其他语言的用户，而是针对编程语言的用户。奇怪的是，他们已经从内置的API中学习了很多外语单词，并且他们可能不知道美式英语和英式英语之间的区别。不要通过切换池塘的侧面来混淆它们。

我主要使用.NET语言，而.NET Framework使用美国英语拼写。在这个平台上，我会坚持使用美国英语。我不知道有任何以GB英语为标准的语言，但是如果我们已经做到了，那么请务必与该语言保持一致。

我同意"去美国"演出团。我自己在编写电子邮件等时更喜欢en-GB，但是美国英语几乎是所有编程领域的标准。

作为一名英语程序员，我在软件开发人员中使用en-US。在几乎所有其他API中，美式英语都占主导地位，以至于坚持一种拼写和消除歧义要容易得多。寻找一种方法，只是发现拼写本地化导致拼写被一个字母打断，这是浪费时间。

即使在世界范围内都使用英式英语，但我还是建议我们使用美式英语，就像其他人所说的那样，在市场上占主导地位。

我们需要考虑听众。谁将使用该代码，他们期望看到什么？

我在一家在加拿大和美国都设有办事处的公司工作。在加拿大制作文档和代码时，我们使用加拿大的拼写(非常类似于英式英语)，而在美国，则使用美国的拼写。

有些东西是跨界的，但是拼写上的差异很少成为问题。当美国人不知道加拿大英语和英国英语的拼写不同时，它会引起一些有趣的对话。有时他们会接受，有时他们坚持将其更改为"正确"的拼写。这也会影响日期格式(加拿大的dd / mm / yyyy和美国的mm / dd / yyyy)

如果出现僵局，我们通常会采用美国的拼写，因为加拿大人都熟悉这两种变体。

我听说选择美国而不是英国英语的主要原因是，当英国观众面对美国拼写时，意识到它是美国的应用程序(或者假设是这样)，而面对英国拼写的美国观众则认为"。"。嘿，那是错误的。

但是就像其他人所说的那样，标准化。选择并坚持下去。

对于我来说，不用考虑英语就自然而然地就可以用英国英语工作了。但是，如果我们正在开发内部程序，那并不重要。如果我们要创建将公开使用的API，并且受众是国际用户，那么为什么不同时实现这两个呢？

我更喜欢美国英语。

绝对是美国英语。

首先，我在美国。在我当前的项目中，它始终是"颜色"，但是，我们似乎无法为其选择拼写的单词是"灰色"与"灰色"。

实际上变得很烦人。