我们致力于为所有人提供一个友好、安全和欢迎的环境，无论其年龄、体型、残疾、种族、性别特征、性别认同和表达、经验水平、教育、社会经济地位、国籍、个人外表、种族、宗教、性认同和取向或其他此类特征如何。
语言是思想和表述的有力工具，因此可以突出、强调或模糊世界的某些特征。语言——在其使用和结构中——可能会影响我们对世界的看法，有时会对某些人造成不利影响。因此，已经提出了不同的语言策略来促进更具包容性的语言形式，呼应对所有人更加平等对待的需求。
因此，本包容性语言指南旨在帮助我们采用更具包容性的沟通方式。尽管本指南并未详尽涵盖所有与非包容性语言相关的问题，但它涵盖了我们目前意识到的最重要问题。
对 Scala 核心项目及其文档（包括本网站）的贡献应遵循本指南。
非性别语言
应避免使用他、他、他的、男人和男人。尽管这些术语旨在指任何性别（男性、女性、其他、未知或无关紧要），但它们暗示主体是男性，因此排除了所有其他性别。相反，使用单数他们，就像简·奥斯汀等著名作家已经使用的那样。
单数他们用法的示例
当开发人员想要为项目做出贡献时，他们会打开一个拉取请求。
尽管他们指的是一个人，但我们用复数形式对动词进行变位。这类似于某些语言中代词的礼貌形式，例如德语中的“Sie”或法语中的“vous”。
在可能的情况下，避免使用指代特定性别的（组合）词，而改用性别中立的替代词。例如
- 男人或女人->人
- 董事长->主席
单词简单、容易、快速和琐碎
对你来说容易的事情对其他人来说可能不容易。其他单词也适用，如快速或简单。在使用肯定或最高级形式时，尝试从句子中消除这个词，因为通常可以在没有它的情况下传达相同的含义。
肯定形式的示例
然后你可以使用
run命令简单地执行程序。
可以替换为
然后你可以使用
run命令执行程序。
而不改变句子的含义。
最高级形式的示例
foobar 方法是我们库的最佳入门方法。
可以替换为
我们在此展示如何使用 foobar 方法开始使用我们的库。
但是，在相关时可以使用这些形容词和副词的比较级形式。
比较形式示例
foobar 方法比 baz 方法更容易上手。
类似地，单词 just 通常是多余的，可以删除它而不改变含义。
示例
你可以将这些设置添加到你的构建中。
可以替换为
你可以将这些设置添加到你的构建中。
当然，每种情况都不同，并且可能存在使用“简单单词”仍然是最佳做法的情况。在这种情况下，应该在考虑上述因素后，慎重决定是否使用它们。
特定的加载单词
有些单词可能带有贬义内涵和/或具有明显的压迫性起源。尽可能避免使用这些单词，而代之以中立的替代词。目前，不建议将以下用于常见计算机科学概念的单词。此列表既不全面也不确定，并且可能随着时间的推移而演变。
- 黑名单/白名单
虽然这些单词的词源与种族主义无关，但它们的使用表明黑色与某种形式的邪恶或排斥之间存在关联，而白色与某种形式的善良或包容之间存在关联。尽可能选择替代方案。已经提出了几种替代方案，但没有一种能成为“唯一”的方案。我们建议使用 拒绝列表/允许列表 或 排除列表/包含列表 对，因为它们足够通用，可以替换大多数 黑名单/白名单 的用法。 - 主/从
切勿使用 从。切勿将 主 与 从 结合使用。根据具体架构，请使用以下替代方案之一：控制器/工作器、主/从、领导者/跟随者 等。如有疑问，如果你无法选择，主/从 始终是一个不错的选择。
当与 老师、专家、指南 或 参考 的含义一起使用时，单词 主 并没有被特别禁止。例如，术语 艺术硕士 是可以接受的。
注意：存在一个更广泛的运动，即使用main代替master作为默认 git 分支，由 GitHub 和 git 项目本身领导，我们也鼓励人们遵循这一运动。 - 健全性检查
优先使用 置信度检查。 - 隔离
计算机科学概念，如 接口隔离原则 和 隔离网络，将隔离视为可取的，而不是有害的。优先使用替代方案，如 关注点分离 和 分段网络。 - 大师
虽然 大师 最初指的是一位受人尊敬的精神领袖，但它也指教派的领袖。两者都是精神性质的，并且模棱两可。如果可能，请使用更准确的术语，例如 老师 或 专家。
可以在 https://github.com/dialpad/inclusive-language 找到包含解释和参考的优质来源。
请记住，你的特定应用程序域可能包含其自己的特定于域的负载词。我们鼓励你研究适用于你的域的包容性语言指南。
你可能希望使用 In Solidarity 等自动化软件来引导贡献者远离负载词。
轻蔑语
轻蔑语与委婉语相反，如果你不习惯它们，它们可能会令人不安。示例包括英语表达“扣动扳机”（执行决定）和“咬紧牙关”（忍受困难）。相反，优先使用直接含义。
向后兼容性
有时，我们有现有的代码、API 或命令不遵循上述建议。通常建议执行重命名来解决此问题，但不能以牺牲向后兼容性（特别是库的向后二进制兼容性）为代价。如果可能，应保留已弃用的别名。
有时，无法通过重命名来保持向后兼容性；例如，对于旨在被用户定义的子类覆盖的方法。在这些情况下，我们建议保留旧名称，但在文档中（例如，在 Scaladoc 注释中）记录它们被命名为它们是出于历史原因和为了保持兼容性，以及它们的预期名称应该是什么。
另请参见
- 我们的 行为准则。