为了规范 MDN 上的术语、用语及规范，在此建立一个供编者、译者参考的术语表和翻译规范。如需查阅其他 Web 开发术语，请参见词汇表（有待翻译）。
| 原文 | 译文 | 注释 |
| Creative Commons License | 知识共享许可协议 | 有些空间不足等原因可能简称CC协议 |
| best practices | 最佳实践 | 最佳实践，是一个管理学概念，认为存在某种技术、方法、过程、活动或机制可以使生产或管理实践的结果达到最优，并减少出错的可能性。（参考 维基百科） |
| Mozilla Demo Studio | Mozilla 演示室 | |
| Demo | 演示 | 如果会产生歧义或需特别注明，可以译为“演示（Demo）” |
| Kuma | Kuma | 这里特指用于 MDN 的 wiki （维基知识库）软件系统本身，不译 |
| Mozilla | Mozilla | 指 Mozilla 基金会时，不译 |
| 谋智 | 特指谋智网络（Mozilla 中国全资子公司）时 | |
| Firefox | Firefox | 虽然“谋智网络”网页等处翻译为火狐，但软件目前仍显示为 Firefox，且 MDN 访者皆可了解，故暂不译。 |
| Add-on|Addons | 附加组件 |
扩展、插件、外观（主题）的总称 |
| Extension | 扩展 |
本体 .xpi |
| Plug-in|Plugin | 插件 |
本体 DLL |
| Appearance | 外观 |
原称为主题（Theme），后某个版本开始在附加组件管理器中已改为外观。 |
| Web | Web |
准确的翻译的话，应该对应中文的“网络”，然而感觉太容易有歧义了。不如不译。 |
| World Wide Web | 万维网 |
虽然说这样翻译最好，但翻译后可能有些人不懂（还真有这样的），所以可以引注万维网的具体释义：一个由许多互相链接的超文本组成的系统，通过互联网访问。 |
|
|
这里列出了一些在翻译工作中经常会遇到的一些问题，并给出一些参考意见和建议。
MDN 是开放性的，每个人都可根据自己的兴趣和能力为其做出贡献。而无论你做出的贡献是大是小，都有可能会让很多的人从中受益，所以请不要吝惜自己的才华。
但是，开放并不代表毫无约束和规范。MDN 中有几篇与风格和规范有关的文章可供参考（本文即为其中之一）。我们建议你认真阅读并尽量遵守，这会使你的文章与其他人保持一致，而一致的风格会让读者阅读起来更加轻松和惬意。
本规范主要给你在翻译 MDN 上的英文文章时提供参考。其中的内容绝大部分都不是强制的（强调一下，MDN 是开放性的，我们更关注内容本身的价值，其次才是样式和风格），但是如果每个人都能注意这些并遵守，必然会让 MDN 变得更加美好。因此，何乐而不为呢？
另外还有几篇与此有关的文章。如果你正准备为 MDN 添加一篇新的文章，可以参考 MDN Web 文档写作规范，这篇文章是从英文翻译过来的，其中的部分内容并不适合中文写作，但这并不妨碍你从中受益。而如果你对 MDN 编辑器（就是在 MDN 中撰写或编辑文章时使用的在线所见即所得编辑器）还不熟悉，可以参考这里的说明。
最后，感谢你能够耐心阅读本文。Let‘s get started.
技术文档的翻译不比文学作品的翻译，因为一般来说，技术类文章都是采用直述方式来撰写的，因此翻译相对简单，即使是完全的直译也不会导致读者无法理解的问题。
但是由于中英文的语法、表述习惯、以及思维方式上的差异等诸多客观因素，如果只是机械化地对原文的每一句话进行直译，仍然可能会影响翻译质量。因此就我个人的经验来看，在翻译的时候把握原文的意思，然后适当采用意译的方式来翻译，是一种比较好的技术类文章的翻译实践。
一般来说，我们拿到一篇英文文章，在翻译的时候都会采用边阅读边翻译的方式，也就是逐句翻译。这种方式有点类似于计算机处理指令。优点是简单直观，比较流程化；而缺点则是容易导致翻译较为生硬，并且容易产生理解偏差甚至错误。
翻译生硬是因为当你把注意力集中在某条句子上面时，就容易被其英文表达方式所影响，从而由逐句翻译变为逐词翻译，翻译出来的中文经常带有明显的“翻译腔”（想了解什么是翻译腔？）。
容易产生理解偏差和理解错误，是因为逐句翻译时容易忽略它们与上下文中其他内容之间的联系，从而导致对原文的意思把握不够全面，有时候就会产生理解上的偏差，甚至是完全曲解原文的意思。
对于不是专业从事翻译工作的人来说（我想大多数志愿者应该都不是专业的翻译人员），很难避免逐句翻译的习惯，但是我们在这里给出几点建议，可以帮助你提高翻译质量。
我们鼓励你在翻译之前先将英文版的原文通读一遍，至少应该通读一下当前准备翻译的小节，这样可以减少对原文的理解偏差。
写作文的时候，老师会强调修改的必要性；写代码的时候，我们也会强调重构的好处。翻译也是一样，不要想着一次成功，想要一遍就得到高质量的成果是很难的。我们可以先采用逐句翻译的方式，得到译文的第一稿，然后再通过重构去修正和优化它。重构可能会重复好几轮最终才能得到一篇高质量的的译文。
不要担心过程繁琐或重构会占用你太多时间。记住，宁缺毋滥，不准确甚至错误的翻译只会误导他人，而我们的理想是给他人带来帮助。
可能有些人会有这样的误解：我必须把英文原文中的每一句话都翻译出来，不能遗漏，只有这样才是准确的翻译。
这种观念是错误的。首先，由于英文和中文在表述习惯上的差异，有些句子在英文中比较自然，但如果直接翻译为中文就会显得有些啰嗦。此时我们可以选择将其精简一下，把冗余的部分去掉。不要担心丢掉了这些内容之后会让译文不准确，必要的删减只会让译文更加简洁，阅读起来也更加流畅。
比如英文中经常会见到“he/she”、“and/or”这样的表达方式。看起来比较严谨，但是在中文中并没有类似的习惯，因此简单将其翻译为“他”、“和”（也可以是“或”）即可。如果非要追求“准确”而将其翻译为“他/她”、“和/或”反而有画蛇添足之感（并且翻译腔也比较浓）。
表述习惯上的差异还包括语序、句式、时态、词性等，关于中英文两种语言在表述习惯上的差异，可以参考下面的小节。
其次，英文原文也不一定是 100% 正确的。MDN 上的英文文档虽然质量很高，但它也是由人维护的，是人就会有疏忽和犯错的时候，因此我们所翻译的原文并不一定是完全正确的。而作为翻译者，我们不应该只满足于翻译活动本身，还应该在翻译过程中勇于发现和改正原文的错误之处。
这一点并不是一条具体的规范，因为我不会、也无法解释如何才能做到“准确表述原文的原意”。将这一点列在这里主要是为了强调我们应该努力提高翻译的准确性。
我们要对翻译的每一句话负责。如果你的翻译中有错误，就可能会让读者产生误解，而这比不给他们提供译文更糟糕（没有译文时，读者可以阅读英文原文，或去其他地方查找相关资料）。注意，这里所说的错误特指严重的概念性错误或原则性错误，而不是由于疏忽而导致的排版错误、打字错误等小的失误。
下面这个例子是我之前翻译过的一篇文章里面的一段内容。原文是这样的：
The term "global objects" (or standard built-in objects) here is not to be confused with the global object. Here, global objects refer to objects in the global scope. The global object itself can be accessed using thethisoperator in the global scope (but only if ECMAScript 5 strict mode is not used; in that case it returnsundefined). In fact, the global scope consists of the properties of the global object, including inherited properties, if any.
这段话中有两个微妙的词“global objects”和“global object”，一个是复数一个是单数。但我们知道，中文的名词并没有单复数的变化，因此直译过来都是“全局对象”，然而原文却恰恰需要对两者的不同进行解释，但是同一个名词怎么会有两种不同的解释呢？如何在中文中表达原文的意思呢？
我们先来看之前的翻译，它采用的是直译，即将两个词都翻译为”全局对象“（将这个作为反例列在这里并没有贬低或指责的意思，仅仅是想通过这个例子让大家理解本小节所要表达的意思）：
“全局对象（global objects）”（或标准的内置对象）与全局对象（global object）不同。 这里的全局对象（global objects）指的是全局作用域中的对象。而全局对象（global object）本身可以……实际上，全局作用域由全局对象（global object）的属性组成，包括 继承属性（如果有的话）。
”全局对象与全局对象不同“，显然会让读者犯糊涂。虽然译者在两个”全局对象“后面加上了它们的英文名称，但是收效甚微，读者仍然会被这段话搞晕，因为它们的英文名称也是很相似的。因此，这里必然不能采用直译的方式，而应该选择符合原文意思，但是中文名称又有明显不同的名词来翻译。下面是我对这段译文的重新翻译：
标准内置对象也称为全局对象（global objects）。注意这里的全局对象指的是具有全局作用域
的“一组”对象，而全局对象这个词还有一层意思，用来指代当前环境中的顶层对象，该对象在……
事实上，全局作用域就是由顶层对象的属性组成的，包括继承而来的属性（如果有的话）。
我选择把第二个全局对象（即单数形式的 global object）翻译为”顶层对象“，这样就把两个全局对象从中文名称上区别开了。同时，我还对整段译文进行了较大的调整，因为如果仅仅是将“global object”替换为“顶层对象”仍然不是很好，可能会让读者感到困扰。请将上面的译文与下面的这段对比一下：
“全局对象”（或标准的内置对象）与顶层对象不同。这里的全局对象指的是全局作用域中的对象。 而顶层对象本身可以……实际上，全局作用域由顶层对象的属性组成，包括继承属性（如果有的话）。
一个读者在初次读到这段话的时候，可能会产生以下疑问：
所以，追求意思准确的同时还要尽量让中文表述更合理、自然。
由于思维方式、表述习惯、语言语法/句法等方面的差异，同样的意思，中文和英文在表述形式上经常会有差异。而我们在翻译的时候应当注意并尽量抹平这种差异，以符合中文读者的阅读习惯。这可以有效提高你的翻译质量。
下面是我所想到的一些中文和英文在表述习惯上的差异。欢迎补充。
英文强调格式严谨，一个句子里面主语谓语通常是必须有的，但中文则注重表意，只要意思表达清楚就行。对于这样的句子，多数时候我们都不需要把其中的主语翻译出来。
All arguments passed to the function are treated as the names of the identifiers of the parameters in the function to be created, in the order in which they are passed.
这句话中的“they”就是一个不太重要的主语（虽然是在从句中），翻译时去掉也不会有什么影响：
传递给函数的所有参数都会以函数的参数列表中的标识符名称来对待，并以它们传递时的顺序来匹配。
英语中有很多万能动词：do、make / take、get、have 等，遇到这些万能动词的时候最好留意一下，尽量将其替换成其原本所要指代的动作。
可能是受英文的影响，中文中也越来越多地出现了一些万能动词，比如“作为”、“进行”等。个人认为这是一种不好的现象，应该尽量避免滥用这些词。
英语中经常喜欢用被动句式来表达一种被动关系。但其实在中文里面我们一般只有在需要强调物和人之间存在被动关系的时候才会使用被动句式，其他时候一般不会刻意使用被动句式。如果将文章中出现的每个被动句式都翻译成“被……”可能会让译文看起来略显生硬且翻译腔浓重。因此应该仅在必要的时候才采用被动句式来翻译，其他时候直接忽略原文中的被动关系即可。
这种情况在英文中很常见，随便找一下就能找到不少。比如：
Strings are useful for holding data that can be represented in text form.
如果直接翻译，可能会翻译成：
字符串在用来保存那些可以被表示成文本形式的数据时很有用。
这样翻译虽然也能正确表达原文的意思，但是中文在这种情况下一般不会刻意使用被动句式，所以完全可以去掉“被”字：
字符串在用来保存那些可以表示成文本形式的数据时很有用。
其实这句话还可以进一步简化：
字符串在保存文本数据时很有用。
原文最后的整个从句仅仅用来说明“data”是“文本数据”而已，“can be represented in”和最后的“form"都是次要的，在中文里面完全可以省略。你甚至可以将这句话翻译成下面这样：
字符串可以用来保存文本数据。
完全不会影响读者的理解！
和被动句式一样，英文中也经常使用将来句式来表达这是一个可能发生的动作或者将来会发生的动作。然而，同被动句式一样，翻译的时候我们通常都不需要将其翻译成“将……”。
这种情况同样有很多，随便举一例：
很多人会把这句话翻译成：
尽管可以使用方括号的方式来访问字符，但是试图删除或为其赋值将不会成功。
这样翻译会带有明显的翻译腔，实际上并不需要把原文中的“will”翻译出来，直接忽略即可：
尽管可以使用方括号的方式来访问字符，但是试图删除或为其赋值是无法成功的。
英文中的名词有单复数变化，在遇到复数名词的时候，我们一般都知道并不需要刻意把这种复数翻译出来。但是还有一种情况我们却往往会忽略，那就是单数可数名词前面有“a”或“an”的时候，我们经常会翻译成“一个……”。实际上，多数时候并不需要加上这个数量词。
比如下面这个例子：
It's possible to use String as a more reliable toString() alternative, as it ...
当然，你可以按照原样来翻译，将“a”翻译为“一种”或“一个”：
将 String 函数作为 toString() 方法的一种更可靠的替代是可行的，因为它……
虽然看起来没什么问题，但是这里的“一种”、“一个”是完全多余的，去掉之后不但不会影响翻译效果，而且还会显得更加简洁。其实这个翻译还犯了一个前面所说过的万能动词的问题，“作为”在这里并不是太好，另外把“possible”翻译为“可行”、“可能”也不是很好，因为“possible”在这里只是用来说明“可以”这么做。
总之，这个翻译的翻译腔还是浓了点，仍然有改进的空间：
可以用 String 函数代替 toString() 方法，并且这样更可靠一些，因为它……
英文中经常会使用”when“来表示一种状态，或某种条件，而在中文里面我们不会经常用“当……的时候”这种表述方式来表达这种状态和条件。所以不要一遇到“when”、“while”，就把它翻译成“当……的时候”，应该先判断一下这里的“when”和“while”确实是用来表示时间，还是仅仅用来表示状态或条件。
看下面这个例子：
这里的“when”所表示的就是一种条件，所以最好不要将其翻译为“当内存是共享的时候”。下面是我的翻译：
多个共享内存的线程能够同时读写同一位置上的数据。
英语有一个比较死板的规则，一个句子中包含了主谓宾的时候，就应该用句号把这个句子结束掉，然后再另起一句。但是中文却没有这种限制，因此在翻译的时候，我们不要总是把英语的句号当做一个句子的结束，有时候把逻辑关系比较强的几句英文合并为一句中文会更好。
这一节介绍了一些在页面排版、样式、风格等方面可能会遇到的一些问题，并给出指导建议。
首先，这是一个见仁见智的问题，不同的人可能有不同的喜好。这里建议你加上空格（因为我喜欢 :-p），当然你完全可以按照自己的喜好来。
但是，请在同一篇文章中保持风格统一。如果你正在编辑别人之前翻译过的文章，也请尽量与文章原有风格保持一致（或者如果你不嫌麻烦，可以将整篇文章全部改成你喜欢的风格）。整齐划一的风格会使阅读时如沐春风，从而有利于读者从你的文章中获益。
请在译文中使用中文标点。在中文中夹杂着英文标点是很不严谨的做法，并且不利于读者的阅读体验。
这里所说的标点不包括代码中的标点。但如果选择翻译代码中的注释，则注释中的标点也应该一并翻译为中文。
这里不再强调一般的标点对应关系，仅列举几种特殊情况：
MDN 上的很多文章都具有类似的结构，比如很多文章都包含“Specifications”和“Browser compatibility”两个小节。为了保证文章间的统一性，常见小节的标题翻译应尽量保持一致。下面就给出一些文章中常见的小节及其推荐翻译方法。此表欢迎补充。
| 英文标题 | 推荐翻译方法 | 不推荐翻译方法 | 示例 |
|---|---|---|---|
| Examples | 示例 | 例子、举例 | Array 中的示例一节 |
| Specifications | 规范 | 标准、规范文档 | Array 中的规范一节 |
| Browser compatibility | 浏览器兼容性 | 浏览器的兼容性、浏览器兼容 | Array 中的浏览器兼容性一节 |
| See also | 相关链接 | 参考、参见、更多内容 | Array 中的相关链接一节 |
| Obsolete | 已过时 | 已废弃、作废、淘汰 | <a> 标签的已过时一节 |
| Syntax | 语法 | 句法 | Array 中的语法一节 |
| Description | 描述 | 说明 | Array 中的描述一节 |
| Properties | 属性 | 属性列表 | Array 中的属性一节 |
| Methods | 方法 | 方法列表 | Array 中的方法一节 |
| …… instances | ……实例 | ……对象、……实例化 | Array 中的数组实例一节 |
| Attributes | 属性 | <a> 标签的属性一节 |
展开缩写时使用中文括号，括号中首先给出缩写的完整英文表达，后面跟着逗号和中文翻译。例如：
HTML（超文本标记语言，HyperText Markup Language）
HTML（超文本标记语言——HyperText Markup Language）
HTML (HyperText Markup Language，超文本标记语言) （注：使用了英文括号）
有时候，我们会在翻译过程中面临某个单词或某段内容是译还是不译、哪种翻译方法更好的选择。本小节总结了翻译中的一些常见问题，并给出一些意见和建议，供参考。
没有人会乐意阅读复杂和很长的句子。但是有时候由于所要表达的内容本身的逻辑复杂性，而导致无法进一步压缩句子的长度和复杂度。但是这时候我们可以通过调整顺序和拆分句子来降低它的理解难度。
对于非严谨的地方，一般用“你”即可，这样亲切些，没必要冷冰冰的。当然必要的时候（一般是警告的地方，如“您即将从演示室移除xxx”）可以使用“您”来称呼。
MDN 上面的很多文章中都包含示例代码。一般来说，你可以将这些代码及注释原封不动地复制过来，并不需要刻意去翻译。示例代码不同于正式工作中所写的代码，示例代码主要是说明概念和用法，因此通常会设计的很简单，并且主要的解释都已经在前面的文章内容里面了，注释大多数时候只是起到辅助说明的作用，所以多数时候，即使读者完全不看注释也不妨碍他们对示例的理解。
但是有几种情况还是建议最好能对其中的注释做一下翻译。
在这种情况下，确保读者已完全理解了注释就是相当必要的了，否则可能会影响对整个示例的理解。因此这种情况最好能对这部分注释做一下翻译。
比如下面是摘自 JavaScript Array 对象中的例子。该示例涉及到正则表达式的应用，而对于初学者来说，他可能还不太了解什么是正则表达式，以及这段代码的结果是什么，这会使他产生迷惑（而且原文中本段代码后面还配有一个详细解释了代码执行结果的表格，如果读者无法理解这段代码，他很可能也看不懂那个表格中的内容）。
// Match one d followed by one or more b's followed by one d
// Remember matched b's and the following d
// Ignore case
var myRe = /d(b+)(d)/i;
var myArray = myRe.exec('cdbBdbsbz');所以我选择对其进行翻译：
// 匹配1个 d 后面紧跟着至少1个 b，再后面又跟着1个 d 的子串，
// 并且需要记住子串中匹配到的 b 和最后的 d （通过正则表达式中的分组），
// 同时在匹配时忽略大小写
myRe = /d(b+)(d)/i;
myArray = myRe.exec("cdbBdbsbz");有些示例是对原文的补充说明，而不是单纯的演示和举例。这时候，示例和注释相当于是原文的一部分，因此这种情况下最好能将注释翻译出来。
这一点不太容易解释，并且我个人觉得还存在争议，列在这里供参考。
有些注释中使用了一些我们平时的惯用语，而这些惯用语我们已经习惯了中文化的表达，对英文并不熟悉。这种情况下，可以适当对其进行翻译。
一个常见的例子，我们经常会在示例中使用打印语句来打印信息，以此说明程序的运行结果。这种时候，英文文档中经常会用“// print 100”或”// log 100“来对打印语句做注释。如果我们将其翻译为”// 打印 100“可能看起来会更加亲切一些。
页面底部的标签大部分情况下并不需要翻译。
slug 就是网页地址后面的那一串，用来标识每一篇文章。如果你正面临是否需要翻译 slug 的选择，请选择 No！保留 slug 为英文可以保证链接的可读性，也可以避免翻错的情况（这个一旦确定好像就不能修改了）。
翻译一篇文章可能无法一次完成，尤其是比较长的文章。幸好 MDN 的编辑器可以将进度自动保存在你的本地电脑中，在你不小心关闭了浏览器，或者不小心点击了一个链接而离开了当前页面的时候，自动保存的内容会在你重新打开编辑页面的时候自动恢复，从而避免丢失之前的劳动成果。
但是，请不要百分百依赖编辑器的自动保存功能，偶尔它也有失效的时候，而一旦发生就可能会造成严重后果。
如果因为文章内容较多而导致翻译时间很长，可以在取得阶段性成果之后先将内容提交，并在提交时勾选“版本备注” -> “本地化标志” -> "本地化进行中 - 还没完全翻译呢"，这样提交后用户看到的页面上会显示“翻译正在进行中”的提示信息。
最后，如果你在翻译过程中存在一些拿不准的地方，或者自我感觉译文中可能存在错误或需要改进的地方，那么你可以在提交时勾选“版本备注” -> “需要复核吗？”中的“技术复核”或“文法复核”选项。这样其他志愿者就可以看到并帮助你复核译文。
这一小节列出了翻译过程中可能会遇到的其他一些问题。
除非中文版 UI 控件的翻译有明显错误，否则控件名称（如操作步骤中描述的窗口、菜单、按钮等）都应尽量参照所描述版本或最新版 Firefox 中的翻译，以保证可对应。
若最新版 Firefox 的 UI 仍有错误的翻译或你有改善建议，请到 mozest 本地化板块反馈或邮件通知简体中文本地化成员。
英文版文章中可能会包含引用 MDN 中其他文章的绝对链接，此时要注意将链接修改为中文版的 URL。
修改方法很简单，一般是把其中的 en-US 改为 zh-CN 即可。比如下面是 JavaScript 文档中对全局对象的介绍，分别对应英文版和中文版：
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects
https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects
本规范还有很多不完善的地方，如果你有什么好的意见和建议，欢迎编辑本页面，当然也可以到MDNzh论坛来讨论。