11

我在不同国家从事不同的项目，并表示有时代码会变得国际化，比如

设置LargeurEtHauteur ()                            (对于 SetWidthAndHeight, fr )
Dim _ListaDeObiete as List(Of Object)   (对于 _ObjectList, ro )
internal void Sohranenie User ov ()             (对于 SaveUsers, ru )
等等。

碰巧在使用拉丁字母的国家，这种混合更为明显，因为不需要音译。

不仅如此，编程“行话”通常受到项目规范语言的启发。在某些情况下，“项目语言”中的术语具有在英语中不可“翻译”的含义。

还有一些项目仅适用于法国团队，例如使用法语单词（例如，Personne、Vehicule、Projet 等）。

在这种情况下，我个人在规范中添加了一个“字典”，它解释了所有业务对象名称，并且只有这些对象用于其他（法语）语言。

说：

Collectif - ensemble des Personnes ;

所有操作（获取、设置、更新、修改、加载等）都是英文的。

现在可以在代码中使用“强”名称： Add Personne To Collectif。

  • 您对“国际化”的态度是什么？

PS。
我很高兴 VisualStudio 在 .NET 中使用名为“btnAdd É lève ”或“кпкСтоп”的按钮编译和运行项目...

4

8 回答 8

14

我个人的做法是编程社区中的许多人（但不是全部）都共享源代码应该是英文的，如果可能的话，所有的开发工具也应该是英文的。

最重要的原因是能够与世界分享您的问题和解决方案（就像我们现在在 StackOverflow 中所做的一样），而不必每次都翻译类名、错误消息、路径和其他工件。

它还有助于保持一致性，因为大多数库都是用英语编写的，并且具有混合两种语言的元素名称并不能真正帮助任何人，除了当像Add这样的动词并不总是被翻译时，它会成为内部冲突的持续焦点。

英文代码还可以更轻松地将外国人添加到项目中，而不必担心理解和误解（尤其是在密切相关的语言之间，如西班牙语和葡萄牙语，它们有很多错误的同源词）

关于这个主题的一个很好的链接：http: //www.codinghorror.com/blog/2009/03/the-ugly-american-programmer.html

（如果有人想知道，我是南美人，英语不是我的主要语言）

于 2010-06-25T17:49:24.950 回答
5

即使团队中的每个人都能说一口流利的英语（这不是必然的），他们也不一定知道所有商业术语的对应英语。

我认为这是一个项目特定的决定允许什么，但我通常会容忍并在某些情况下鼓励使用当地语言的业务术语（例如实体名称），而不是技术术语（即不是 Largeur/Hauteur 而不是 Width/Height） .

例如在法国的金融界，每个人都知道 OPCVM 和 FCP 是什么意思——如果你尝试英文翻译，你可能会比允许混合语言得到更多的误解。

于 2010-06-25T18:00:35.477 回答
2

我目前对挪威语有同样的问题。我想这取决于你在项目中的位置、可用时间和软件的作用。

就我而言，我决定将所有术语保留在我正在使用的挪威语的现有协议和库中，因为我可以合理地预期几代管理人员已经习惯了这些，并且因为库依赖于协议。在一个国际项目的库包装器中，我已经按字面翻译了每个方法名称，并添加了该方法的英文文档。

代码的注释和文档是英文的。

如果从头开始设计软件，我会尝试为所有方法名称甚至业务术语找到英文术语（如果合理的话。我几乎想不出一个找不到术语的例子。），以保持它的“可移植性”。

于 2010-06-25T17:54:16.370 回答
2

如果您编写的代码有一天可能会在国际上使用，请用英语编写。如有疑问，请用英文写，如果可以的话，甚至是评论（尽管我想你可以用你工作场所的语言添加一些评论）。

不幸的是，它并不特定于编码。英语不是我的母语，但我已经能够阅读许多技术论文并与来自世界各地的人们一起参加国际会议。如果每个人都用各自的母语发表文章，这些合作根本就行不通。

如果您想不惜一切代价捍卫自己的语言，这可能会令人难过，但您必须对此保持现实。我想英语的优势在于达到基本水平相对简单：名字没有性别，没有变位，没有大小写。

于 2010-06-25T18:04:27.793 回答
2

通常，涉及语言概念的代码应该与编程语言使用相同的母语（即英语 - 因为字符串都是英语单词）。

在本地语言中使用变量和域概念是可以的（但不是很好），但您绝对不希望将 List、Object、Decimal 等翻译成导致程序员在协调两种语言方面更多工作的术语。尽管如此，我还是会强烈游说限制非常常见的域概念，如 Collection、Membership、Person、User，以及可能不太常见的域概念，如 Invoice、Receipt，在可能的情况下限制为英语。

这就像用 VB 编写一半的课程，用 C# 编写一半的课程一样——你的大脑必须做出认知转变。虽然这对于混合应用程序（Web 上的 JavaScript 和后端的 C#）有好处，因为它可以帮助您保持运行的内容清晰，但它不适合一般编程。

此外，一切都使用英语可以使领域和语言单词更好地协同工作。

总是有例外。在某些情况下，无论如何您都会使用本地词 - 该词最好地描述了域。例如，在我们的（英语）代码库中，对于某些概念，我们引用了墨西哥西班牙语术语，这些术语仅与在墨西哥运行我们软件的人相关。但是，通常情况下，日语术语是用语音/罗马字拼写的 - 非日语很难发音象形图;-)。

于 2010-06-25T18:05:10.213 回答
1

我想我会把这样的代码库称为“糟糕”而不是“国际化”，但我一直听到的一般规则是，如果你认为说你语言的人以外的人可能会接触到代码，用英语做。

于 2010-06-25T17:52:47.170 回答
1

我认为好的设计指南是使用英文名称和仅使用英文注释编写代码（当然，如果您的团队有能力这样做，但在国际团队的情况下，英语似乎是自然的选择，因为它是最流行的语言，特别是在 IT 领域）。

对这种指导方针的一个很好的解释是，大多数编程语言中的关键字都取自英文，因此使用英文名称编写代码可以提供更一致的外观，并且由于这一点，您的代码更容易阅读。

另一个原因是大多数编译器只能将 ascii 字符作为类、方法等的名称处理，因此当您决定使用包含非 ascii 字符的字母表时，您可能会以一些奇怪的名称结尾。

我想到的第三个原因是在网站上分享你的代码，比如 SO。今天我用一段代码打开了一个帖子，其中类有西班牙名字。我很难猜出这门课的目的是什么（即使有时没有必要，当你阅读代码并理解所有使用过的单词时会很好:)）。

综上所述，我认为代码的国际化并不是一个好主意。您可以想象编程语言中的关键字（例如 class、try、while）也可以本地化，并且您可能还可以想象那时的生活会多么艰难......

于 2010-06-25T18:26:07.013 回答
0

为了保持一致，我会让代码与（编程）语言相同（人类）语言。也就是说，如果编程语言使用英文关键字（如for、switch、public等），则将其余代码保留为英文。如果您使用的编译器可以识别（比如说）关键字的斯瓦希里语翻译，那么将其余代码保留在斯瓦希里语中。

许多 API 都有标准化的命名方案，无论（人类）语言如何，都会根据需要翻译随附的文档（而不是源代码）。

无论您选择哪种（人类）语言，都选择一种并坚持下去。我更愿意尝试用德语浏览源代码，而不是德语和英语混合的代码。

于 2010-06-25T18:09:52.390 回答