代码“国际化”
我在不同国家从事不同的项目，并指出有时代码会国际化，例如
设置LargeurEtHauteur() （对于 SetWidthAndHeight，fr）
将 _ListaDeObiecte 调暗为列表（对象） （对于_ObjectList，ro）
内部无效 SohranenieUserov() （对于SaveUsers，ru)
等等
在使用拉丁字母的国家，这种混合更为明显，因为不需要音译。
不仅如此，编程“术语”通常是受到项目规范语言的启发。在某些情况下，“项目语言”中的术语的含义在英语中是不可“翻译”的。
也有一些项目仅适用于法国团队，使用法语单词（例如人员、车辆、项目等）。
在这种情况下，我亲自在规范中添加一个“字典”来解释所有业务对象名称，并且只有这些对象以其他（法语）语言使用。
说：
Collectif - ensemble des Personnes；
所有操作（获取、设置、更新、修改、加载等）都是英文的。
现在可以在代码中使用“强”名称： 添加人员到Collectif。
- 您的“国际化”之路是什么？
<子> PS.
我很有趣的是，VisualStudio 使用名为“btnAddÉlève”或“кпкСтоп”的按钮在 .NET 中编译和运行项目...
I worked on different projects in different countries and remarked that sometimes the code became internationalized, like
SetLargeurEtHauteur() (for SetWidthAndHeight, fr)
Dim _ListaDeObiecte as List(Of Object) (for _ObjectList, ro)
internal void SohranenieUserov() (for SaveUsers, ru)
etc.
It happens that in countries with Latin alphabet this mix is more pronounced, because there is no need of transliteration.
More than that, often the programming "jargon" is inspired by the project specifications language. There are cases that terms in "project language" have a meaning that is not "translatable" in English.
There are also projects on which works only, say a French team, uses French words (say, Personne, Vehicule, Projet etc).
In that cases I personally add in specifications a "Dictionary" that explains all business object names and only these objects are used in other (French) language.
Say:
Collectif - ensemble des Personnes;
All the actions(Get, Set, Update, Modify, Load, etc) are in English.
Now that "strong" names could be used in code:
AddPersonneToCollectif.
- What is your approach to "internationalization"?
PS.
I was amused that VisualStudio compiles and runs projects in .NET with buttons named à la "btnAddÉlève" or "кпкСтоп"...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我个人的做法是，源代码应该是英文的，并且在可能的情况下，所有开发工具也应该是英文的，这是编程社区中许多人（但不是所有人）所认同的。
最重要的原因是能够与世界分享您的问题和解决方案（就像我们现在在 StackOverflow 中所做的那样），而无需翻译类名、错误消息、路径和其他内容每次都有文物。
它还有助于一致性，因为大多数库都是用英语编写的，并且混合两种语言的元素名称对任何人都没有真正的帮助，除了当像 Add 这样的动词不存在时，它会成为内部冲突的持续焦点。总是被翻译。
英语代码还可以更轻松地将外国人添加到项目中，而不必担心理解和误解（尤其在密切相关的语言之间，例如西班牙语和葡萄牙语，它们有很多错误的同源词）
对此有一个很好的链接主题： http://www.codinghorror.com/blog /2009/03/the-ugly-american-programmer.html
（如果有人想知道，我是南美人，英语不是我的主要语言）
My personal approach, which is shared by many but not all in the programming community, is that source code should be in English and, if possible, all the development tools should be in English too.
The most important reason for this is being able to share your problems and solutions with the world (like we are doing now in StackOverflow, no less) without having to translate class names, error messages, paths and other artifacts every time.
It also helps consistency, because most libraries are written in English and having element names that mix two languages doesn't really help anyone, besides being a constant focus of internal conflicts when a verb like Add isn't always traslated.
English code also makes it easier to add foreign people to a project without worrying about comprehension and misunderstandings (especially between closely related languages, like Spanish and Portuguese, which have lots of false cognates)
A good link on this subject: http://www.codinghorror.com/blog/2009/03/the-ugly-american-programmer.html
(In case anyone wonders, I'm south-american and English is not my primary language)
即使团队中的每个人都能说一口流利的英语（这并不是必然的），他们也不一定知道所有商业术语的英语对应词。
我认为这是一个特定于项目的决定允许什么，但我通常会容忍并在某些情况下鼓励使用本地语言的业务术语（例如实体名称），但不是技术术语（即不是 Largeur/Hauteur 而不是宽度/高度） 。
例如，在法国的金融界，每个人都知道 OPCVM 和 FCP 的含义 - 如果您尝试英语翻译，您最终可能会比允许混合语言产生更多的误解。
Even if everyone on the team is a good English speaker (which is not a given), they may not necessarily know the English equivalent of all the business terminology.
I think it's a project-specific decision what to allow, but I would generally tolerate and in some cases encourage business terms (e.g. entity names) in the local language, but not technical terms (i.e. not Largeur/Hauteur instead of Width/Height).
For example in the financial world in France, everyone knows what is meant by OPCVM and FCP - if you attempt English translations you might end up with more misunderstandings than you do by allowing mixed languages.
我目前对挪威语也有同样的问题。我想这取决于你在项目中的职位、可用时间和软件的作用。
就我而言，我决定将所有术语保留在我正在使用的挪威语中使用的现有协议和库中，因为我可以合理地预期几代行政人员已经习惯了这些术语，并且由于该库依赖于该协议。在国际项目的库包装中，我按字面意思翻译了每个方法名称，并添加了该方法的英语文档。
代码的注释和文档都是英文的。
如果从头开始设计一个软件，我会尝试为所有方法名称甚至业务术语找到英文术语（如果合理的话。我几乎想不出找不到术语的例子。），以保持它的“可移植性”。
I have the same issue with Norwegian currently. I guess it depends on your position in the project, the available time and the role of the software.
In my case, I have decided to keep all terms in an existing protocol and library I am working with in Norwegian, as I can reasonably expect that generations of administrative workers have gotten used to these, and since the library depends on the protocol. In a library wrapper for an international project, I have translated each method name literally, and added an English language documentation of the method.
Comments and documentation on the code are in English.
If designing a software from scratch, I would try to find English terms for all method names and even business terms (if reasonable. I can hardly think of an example where no term can be found though.), to keep it "portable".
如果您正在编写有一天可能会在国际上使用的代码，请用英语编写。如果有疑问，请用英语写，如果可以的话甚至可以添加注释（尽管我认为您可以用您工作场所的语言添加一些注释）。
不幸的是，它并不特定于编码。英语不是我的母语，但我已经能够阅读大量技术论文并与来自世界各地的人们一起参加国际会议。如果每个人都用各自的母语发表文章，这些合作根本行不通。
如果您想不惜一切代价捍卫自己的语言，这可能会令人难过，但您必须面对现实。我认为英语的优点是相对简单，可以达到基本水平：名字没有性别，没有词形变化，没有格。
If you're writing code that you may be used internationally one day, write it in English. In doubt, write it in English, even comments if you can (although I suppose you can add a few comments in the language of your workplace).
It's not specific to coding unfortunately. English isn't my native language, but I've been able to read a number of technical papers and participate to international conferences with people from all over the world. These collaborations simply wouldn't work if everyone published in their respective native languages.
It may be sad if you feel like defending your language at all cost, but you have to be realistic about it. I suppose English has the advantage to be relatively simple for achieving a basic level: no genders for names, no conjugations, no cases.
一般来说，引用语言概念的代码应该与编程语言使用相同的母语（即英语——for、while、string都是英语单词）。
使用本地语言提供变量和域概念是可以的（但不是很好），但您绝对不希望将列表、对象、小数等翻译成导致程序员在协调两种语言方面付出更多工作的术语。即便如此，我仍强烈游说将非常常见的领域概念（例如集合、成员资格、人员、用户）以及可能不太常见的领域概念（例如发票、收据）限制为英语（如果可能）。
这就像一半的课程用 VB 编写，一半的课程用 C# 编写一样 - 你的大脑必须做出认知转变。虽然这对于混合应用程序（Web 上的 JavaScript 和后端的 C#）很有用，因为它可以帮助您保持运行内容的清晰，但它不适合一般编程。
此外，一切都使用英语可以使领域和语言单词更好地协同工作。
总有例外。在某些情况下，您无论如何都会使用本地单词 - 该单词最能描述该领域。例如，在我们的（英语）代码库中，我们引用了墨西哥西班牙语术语来表示某些概念，这些概念仅与在墨西哥运行我们软件的人相关。通常，日语术语是按语音/罗马字拼写的 - 对于非日本人来说很难发音象形文字;-)。
Generally code referring to language concepts should be in the same mother language as the programming language (i.e. English - for, while, string are all English words).
It's OK (but not great) to have variables and domain concepts in a local language, but you definitely don't want to be translating List, Object, Decimal, etc. into terms which cause programmers more work in reconciling two languages. Even still, I would strongly lobby to restrict very common domain concepts like Collection, Membership, Person, User and possibly less common domain concepts like Invoice, Receipt to English where this is possible.
It would be like coding half your classes in VB and half in C# - your brain has to make a cognitive shift. While this is good for hybrid apps (JavaScript on the web and C# on the backend) because it helps you keep what's running where clear, it isn't good for a general programming.
In addition, using English for everything makes the domain and language words work together better.
There are always exceptions. There are certain cases where you would use a native word anyway - where the word describes the domain best. For instance, in our (English) code base, we had references to Mexican Spanish terms for certain concepts which were only relevant for people running our software in Mexico. Typically, Japanese terms were spelled out phonetically/Romaji, though - it was difficult for non-Japanese to be able to pronounce the pictograms ;-).
我想我会称这样的代码库为“糟糕”而不是“国际化”，但我一直听到的一般规则是，如果你认为除了说你的语言的人之外的其他人可能会接触到代码，用英语做。
I think I'd call a code base like that "abysmal" rather than "internationalized", but the general rule I've always heard is that if you ever think that someone other than one who speaks your language might ever touch the code, do it in english.
我认为好的设计指南是使用英文名称和英文注释来编写代码（当然，如果你的团队有能力做到这一点，但如果是国际团队，英语似乎是自然的选择，因为它是一种最流行的语言，特别是在 IT 世界中）。
对这种指导方针的一个很好的解释是，大多数编程语言中的关键字都取自英语，因此使用英文名称编写代码可以提供更一致的外观多亏了这一点，您最终得到的代码更容易阅读。
另一个原因是大多数编译器只能处理 ascii 字符作为类、方法等的名称。因此，当您决定使用某种包含非 ascii 字符的字母表的语言时，您可能会以一些奇怪的名称结尾 。
我想到的第三个原因是像这样在网站上分享您的代码。今天我开了一篇文章，里面有一段代码，其中的类有西班牙语名称。我很难猜测这个类的目的是什么（即使有时没有必要，当你阅读代码并理解所有使用的单词时，这是很好的:)）。
综上所述，我认为代码国际化不是一个好主意。您可以想象编程语言中的关键字（例如 class、try、while）也可以本地化，也许您也可以想象那时的生活有多么艰难......
I think that good design guideline is to write code with use of English names and with english comments only (of course if your team is capable to do this, but in case of international team English seems to be natural choose, since it's a most popular language, expecially in IT world).
Good explanation of such guidline is that keywords in most of programming languages are taken from English so writing your code using English names gives more consistent look and thanks to this you end with code that is easier to read.
Another reason is that most of compilers can handle only ascii characters as names of classes, methods, etc. so probably you will end with some strange names when you decide to use some language with alphabet containing non ascii chars.
Third reason that came to my mind is sharing your code on site like SO. Today I opened a post with a piece of code where classes had Spanish names. It was hard for me to guess what was the purpose of this class (even if sometimes is not necessary it is good when you read code and understand all used words:)).
To sum up I think that internationalization of code is not a good idea. You can imagine that keywords in programming languages (e.g. class, try, while) could also be localized and probably you can imagine also how hard life could be then...
为了保持一致，我将使代码使用与（编程）语言相同的（人类）语言。也就是说，如果编程语言使用英语关键字（例如
for、switch、public等），则将其余代码保留为英语。如果您使用的编译器可以识别（例如）关键字的斯瓦希里语翻译，则将其余代码保留为斯瓦希里语。许多 API 都有标准化的命名方案，无论（人类）语言如何，都遵循这些方案，并且随附的文档根据需要进行翻译（而不是源代码）。
无论您选择哪种（人类）语言，请选择一种并坚持使用。我宁愿尝试费力地阅读德语源代码，也不愿阅读德语和英语混合的代码。
To keep things consistent, I would make the code the same (human) language as the (programming) language. That is, if the programming language uses English keywords (like
for,switch,public, etc) then keep the rest of the code in English. If you are using a compiler that recognizes (say) the Swahili translations of keywords, then keep the rest of the code in Swahili.Many APIs have standardized naming schemes that are followed regardless of (human) language, and the accompanying documentation is translated as needed (instead of the source code).
No matter what (human) language you choose, pick one and stick with it. I'd much rather try to wade through source code in German than code that was a mix of German and English.