我想大多数编程代码都是用英语编写的。但我很好奇人们如何处理这里的命名问题。许多编程是在某些业务领域内完成的，通常对某些程序、项目使用完善的术语。
例如，我来自丹麦，我经常使用的东西有一个叫做“indblikskode”的术语，可以翻译成“洞察代码”。那么，我是否在 C# 代码中使用“string indblikskode = ...”行来处理与此相关的一些 Web 服务？还是我尝试使用翻译，例如“insightcode”？我所从事的业务在其语言中甚至不一致，例如使用术语“organisatorisk enhed”（组织单位），但经常使用缩写“OU”，这显然是英语的缩写。
其他人如何处理这个命名问题，同时保持一致和理智（从代码中的简单变量名称到数据库表，再到服务器名称）？
重复：
我只能为自己说话，但在命名类和变量时，我总是将术语翻译成英文，这也是我们不成文的最佳编码实践之一。你永远不知道什么时候你可能需要将开发工作交给更便宜的国外劳动力或城里的专家外籍顾问。
类和函数的非英语命名的问题是，你总是会以 macaronic pidgin 结尾。关键字是英文的，命名约定（例如 getter/setter）也是英文的，设计模式的标准名称也是如此。
你最终会得到类似的东西：
OrganisatoriskEnhedFactory::getInstance()->getIndblikskode();
在瑞士（德国方面，即苏黎世）工作并在德国生活了一段时间，我可以告诉你，我还没有看到代码不是英文的环境。当然，该应用程序很可能是德语（但许多专业环境都是说英语的），但代码（我见过）几乎都是英语。
很难用其他语言编写代码。一方面，API（几乎）都是英文的。例如，Java 使用 JavaBeans 命名，因此无论如何您都必须使用 set 和 get，而“getGeburtstag”只是与“getDateOfBirth”没有完全相同的环。
其他国家可能会有所不同，因为这是我在日耳曼国家的经验。
我们通常使用既定的英语术语（我们的业务领域通常有英语术语），但如果我找不到合适的术语，我也可以使用芬兰语。哎呀，即使我们在代码中的注释也是混合语言的......
当然，明智的做法很大程度上取决于源代码是否会在建筑物外使用。在一个小商店里，这没什么大不了的。
我在奥地利的一家公司工作（所以我们说的是德语），我们正在用英语编程（变量名、域对象、GUI）。让它有点麻烦，因为你必须找到英文翻译，你必须在发布程序之前翻译 GUI。我不确定所有的名字是否真的正确。
相比之下，在我工作的前公司，我的程序是严格用德语编写的。这非常好（尽管德语单词往往比英语单词长）。几年后，该公司想在美国使用相同的程序，所以说英语的程序员不得不使用相同的代码库。在这之后，一切都变得非常不一致-变量，数据库字段..两种语言（说英语的团队成员不会说德语）。
我的经验是，在应用程序的早期（当你用英文编写程序时，你不得不这样做）处理国际化比较容易，因为本地化一个 10000 LOC 的应用程序并没有什么好玩的。用另一种语言写作的优势在于，您可以立即看到哪些是本地化的，哪些不是本地化的——尽管您必须考虑到这一点。
对于无法翻译的词：我们还没有体验过 - 尽管找到“社区内交付”的英文短语（这是欧盟的事情）是一些工作。但如果发生这种情况，我很确定我们会使用德语单词。
我在德国生活和工作，但只写英文代码。它使事情变得更容易。如果您想提出问题或发布有关您的工作的教程，您可以在网上发布您的代码。
此外，代码对我来说看起来更“专业”。
在这里查看我的问题和答案。
基本上它取决于您的组织和应用程序。如果您的公司、开发人员和客户都说相同的母语，并且您希望它保持这种状态，那么让每个人都成为兼职翻译将适得其反。纯粹假设的未来优势会导致相当大的生产力损失。雅尼。
如果它是一家大型国际公司，或者如果有具体的国际扩张计划或在海外完成一些工作，那当然是另一回事了。
我现在也在德国生活和工作，除了一些旧的德语评论外，我们主要使用英语。我认为非英语评论通常是非常糟糕的主意，因为您必须花时间尝试理解它（并正确理解）。虽然德语和英语都不是我的母语，但用非英语编写的代码似乎很奇怪。
你永远不会知道第二天谁会处理你的代码。所以你应该使用通用的 IT 语言。
PS 由于我不喜欢在我的开发环境中使用非英语语言，当我拒绝我的电脑安装德文 Windows、德文 Office 和德文 Visual Studio 时，我让当地管理员非常生气。我花了好几个小时才下载英文版。
虽然我认为安装一个语言包或只是为了学习术语而安装相同软件的不同副本是一件好事。法语的 SQL Management Studio 让我非常兴奋，就像我尝试将 Skype 切换到西班牙语时一样。