这篇论文就像是在调查一个巨大的、全球性的“开源软件集市”（比如 GitHub），看看在这个集市里，大家除了说英语，是不是开始越来越多地用中文、韩语、俄语等自己的母语来交流了。
以前，这个集市有个不成文的规矩：“在这里，必须说英语，没人听得懂你的家乡话。” 就像在一家只有英语菜单的餐厅，如果你点菜时用法语，服务员可能会一脸茫然，甚至直接拒绝服务。
但这篇研究通过“数数”和“分析”，发现情况正在发生巨大的变化。以下是用通俗的大白话和生动的比喻为你解读的核心发现：
1. 集市正在变得“五颜六色” (多语言化趋势)
- 过去： 就像整个集市只有英语一种声音。
- 现在： 越来越多的开发者开始用母语说话。研究分析了从 2015 年到 2025 年的91.4 亿条消息（包括提问、评论、代码讨论）。
- 发现： 非英语的内容从 2015 年的约 4% 涨到了 2025 年的 11% 以上。特别是韩语、中文和俄语，增长得最快。
- 比喻： 想象一下，以前这个集市里 95% 的人在说英语，现在每 10 个人里就有 1 个在说韩语或中文。这不仅仅是大家“闲聊”变了，连代码里的注释（给程序员看的说明书）和字符串（程序里显示的提示语）也开始出现母语了。
2. 谁在说？说什么？ (主要语言分布)
- 主力军： 中文、韩语、日语、俄语和越南语是增长最快的“方言”。
- 特别现象： 韩语的爆发式增长最惊人（增长了 1700% 多！）。这就像是一个原本只有几个人的小摊位，突然因为政府支持和社区热情，变成了人声鼎沸的大市场。
- 代码里的“硬骨头”： 虽然大家在“聊天”和“写说明书”时开始用母语，但在写代码的核心部分（比如给变量起名字、给函数命名），大家还是习惯用英语。
- 比喻： 就像你在家里做饭，跟家人聊天可以用方言（注释），但菜谱上的专业术语（变量名）还是得写英文，因为全世界的厨师都认得英文，而且很多厨房工具（编译器）只认英文。
3. “语言摩擦”：当不同语言的人相遇 (冲突与协调)
- 冲突现场： 虽然大家开始说母语了，但冲突也随之而来。研究发现了很多这样的场景：
- 有人用中文提问，被回复：“请写英语，我们看不懂。”
- 也有人用俄语提问，被要求：“请用英语或俄语。”
- 甚至在一些非英语主导的项目里，大家也会互相要求：“请写中文/韩语，别用英语。”
- 比喻： 这就像在一个国际会议上，有人坚持要大家说英语，而另一个小组则坚持说中文。有时候，这种坚持是为了效率（怕大家听不懂），有时候则是一种“领地意识”（这是我的地盘，按我的规矩来）。
- 有趣的反转： 有些维护者很开明，他们会说：“没关系，你说俄语，我用翻译软件看。”这种包容性让讨论继续了下去。
4. 说母语会有“代价”吗？ (可见度与参与度)
这是论文最扎心但也最现实的一个发现：说母语，可能会让你的项目“更不受欢迎”。
- 英语项目 = 流量密码： 英语主导的项目，收到的星星（Star，代表点赞和关注）、贡献者（Contributor）和评论都最多。
- 母语项目 = 默默无闻： 非英语的项目，即使代码写得很好，收到的关注也最少。
- 比喻： 想象两个卖同样好喝咖啡的摊位。一个摊位挂着“英语菜单”，路人（全球开发者）一眼就能看懂，人山人海；另一个摊位挂着“中文菜单”，虽然咖啡更好喝，但只有懂中文的人能看懂，路人匆匆走过，根本不知道这里有好咖啡。
- 结论： 语言选择成了一种“双刃剑”。用母语能更好地服务本地社区，但会牺牲全球可见度，导致项目更难获得外部贡献。
5. 一个反直觉的发现：谁解决问题更快？
- 通常认为： 英语项目人多，应该解决问题更快。
- 实际发现： 英语主导的项目解决问题反而最慢，而非英语项目解决问题最快。
- 原因： 英语项目太大了，人多嘴杂，协调起来像指挥一支庞大的交响乐团，容易乱；而非英语项目通常是小而美的社区，大家关系紧密，像一个小家庭，有问题喊一声立马就解决了。
总结：未来的路怎么走？
这篇论文告诉我们，开源世界正在从“英语独大”走向“多语言共存”。
- 好消息： 世界变得更包容了，更多人能用母语参与创造。
- 坏消息： 语言障碍依然存在，说母语的项目容易被“边缘化”，大家之间还会因为“该说什么语言”而吵架。
- 未来的希望： 就像现在的AI 翻译工具（如 GitHub Copilot）越来越聪明，未来它们可能成为“万能翻译官”，让说中文的人能轻松看懂英文代码，让说英文的人也能理解中文的注释。
一句话总结：
开源世界正在从“英语一家独大”变成“百家争鸣”，虽然大家开始说自己的家乡话了，但要想让全世界都听见你的声音，可能还得学会在“母语”和“英语”之间找到平衡，或者期待 AI 来帮我们打破这堵语言墙。
论文技术总结：《“在这里写英语，没人听得懂你的语言”：开源仓库中非英语趋势研究》
1. 研究背景与问题 (Problem)
开源软件（OSS）生态系统长期以来由英语主导，被视为代码、文档和开发者互动的通用语言（Lingua Franca）。然而，随着全球参与度的提升以及 Unicode 等标准对非拉丁脚本支持的完善，开源社区正逐渐走向多语言化。
尽管已有研究指出语言障碍是新手参与开源的主要障碍之一，但现有文献存在以下关键缺口：
- 缺乏大规模纵向数据：以往研究多基于小样本或定性分析，缺乏对代码、文档和讨论中非英语内容随时间演变的量化分析。
- 忽视代码层面的多语言性：现有研究多关注讨论区，鲜有深入分析代码本身（如注释、字符串字面量、标识符）中的非英语使用情况。
- 多语言协作的影响不明：非英语内容的增加是否促进了包容性，还是引发了协作摩擦？多语言项目是否面临可见性和参与度下降的问题？
本研究旨在回答以下核心问题：开源软件的开发（包括沟通、代码和文档）是否正在变得更加多语言化？这种趋势如何演变，又对协作产生了何种影响？
2. 方法论 (Methodology)
本研究采用大规模实证分析，结合定量统计与定性分析，涵盖了从 2015 年 1 月至 2025 年 5 月的数据。
2.1 数据集
- 沟通数据：来自 GHArchive，包含约 91.4 亿条 GitHub 消息（Issue、Pull Request、评论、Review 等），涉及 4.76 亿个仓库和 7800 万开发者。
- 代码数据：通过 GitHub REST API 采样了 62,500 个 仓库的代码补丁（Patches），覆盖五种主流编程语言（JavaScript, Python, Java, TypeScript, C#）。
- 时间跨度：2015 年至 2025 年（10 年）。
2.2 技术流程
- 语言检测与分类：
- 沟通数据：使用
Lingua 库（v2.1.1）进行语言识别。设定严格的置信度阈值（0.9）以过滤短文本和代码混合导致的误判。
- 代码数据：由于代码片段通常较短且混合，
Lingua 表现不佳。研究改用 Google Cloud Translation API 进行语言检测，同样设定 0.9 的置信度阈值。
- 过滤：排除了低置信度结果，并针对代码元素（标识符、字面量等）去除了编程语言关键字（如
int, float）。
- 代码解析：
- 使用
tree-sitter 解析器提取代码中的特定元素：标识符（Identifiers）、函数/类名、字符串字面量（Literals）和注释（Comments）。
- 采样策略：每月随机抽取 385 个包含新文件的补丁，以确保语法上下文完整。
- 统计分析：
- 使用非参数检验（Kruskal-Wallis H 检验和 Mann-Whitney U 检验）来比较不同语言类别（英语主导、非英语主导、混合语言）在参与度、可见性等方面的差异，以处理数据的偏态分布。
- 定性分析：
- 人工审查包含语言强制指令（如“请写英语”）的 Issue，分析语言摩擦的具体情境。
3. 主要贡献 (Key Contributions)
- 首个大规模纵向研究：首次对开源软件中多语言化趋势进行了长达 10 年、涵盖 90 多亿条消息和 6 万多个代码样本的量化分析。
- 全维度视角：不仅分析了开发者讨论（Issue/PR），还深入分析了代码本身（注释、字符串、标识符）和文档（README）中的语言使用情况。
- 揭示“语言张力”与“可见性权衡”：实证证明了多语言化虽然提升了包容性，但也导致了非英语项目在可见性（Stars）、参与度（Contributors）和讨论量上的显著劣势，同时揭示了社区内部关于语言规范的持续摩擦。
- 发现 AI 的影响：观察到 2022 年后多语言内容的激增与大型语言模型（LLM）的普及高度相关。
4. 关键研究结果 (Key Results)
RQ1 & RQ2: 沟通层面的多语言化
- 显著增长：非英语内容在 Issue 和 PR 中的比例从 2015 年的 4.2% 上升至 2025 年的 11.3%（相对增长 164%）。
- 主要语言：韩语增长最快（从 0.3% 增至 5.2%，增长 1706%），其次是中文（1.6% 增至 3.4%）、日语、俄语和越南语。
- 异常事件：2020 年 12 月曾出现中文垃圾信息（WeChat 推广）导致的峰值，表明攻击者也在利用多语言环境。
RQ3 & RQ4: 代码层面的多语言化
- 分布不均：
- 注释和字符串字面量：多语言化程度最高。非英语注释比例从 3.6% 升至 11.9%，字符串从 3.2% 升至 9.6%。
- 标识符和函数名：几乎仍由英语主导（<0.3%），受限于编程语言规范（如 Unicode 支持历史）和输入效率。
- 语言差异：Java 和 Python 的非英语内容增长最显著，这与其在全球教育和企业中的广泛使用有关；C# 和 TypeScript 增长较慢。
- 驱动因素：2022 年后，GitHub Copilot 等 LLM 工具的普及显著推动了非英语注释和文档的生成。
RQ5: 语言摩擦与协调
- 语言强制：研究发现大量“请写英语”或“请写中文/韩文”的评论。语言规范 enforcement 不仅存在于英语主导项目，也存在于非英语主导项目中。
- 混合模式：许多项目采用“文档本地化 + 代码英语化”的混合模式，但在讨论中常出现语言切换或翻译工具的使用。
RQ6: 多语言对参与度的影响（权衡）
- 可见性与参与度下降：
- Stars（可见性）：英语主导项目获得的 Stars 显著多于非英语项目（中位数：36 vs 2）。
- Contributors（协作）：英语主导项目随着规模增长吸引更多贡献者，而非英语项目贡献者数量增长缓慢。
- Comments（讨论）：大型项目中，英语主导项目的讨论量远超其他类别。
- 响应速度悖论：
- 非英语项目 Issue 解决时间最快（中位数 3.39 天）。
- 英语主导项目 解决时间最慢（中位数 7.17 天）。
- 原因推测：英语项目规模大、Issue 数量多、全球协作协调成本高；非英语项目通常规模较小、社区更紧密。
5. 研究意义与启示 (Significance)
- 对开源生态的重新认知：开源社区正从单一的英语霸权向多语言生态转变，这种转变在代码注释和文档中尤为明显，但在核心代码结构上英语仍占主导。
- 包容性与可见性的权衡：虽然使用母语能降低参与门槛，促进本地化社区发展，但会导致项目在 GitHub 全球平台上可见度降低，难以吸引外部贡献者和资金。开发者需在“服务本地社区”与“全球影响力”之间做出权衡。
- 工具与基础设施的缺口：现有的开发工具（IDE、Linting、Bot）大多基于英语设计，难以处理多语言代码和文档。未来需要开发支持多语言翻译、本地化错误提示和跨语言协作的工具。
- AI 的双刃剑效应：AI 工具降低了多语言创作的门槛，但也可能加剧语言摩擦（如生成大量非英语 Issue 增加维护者负担）。社区需要制定更清晰的多语言协作指南。
- 研究范式的转变：未来的软件工程研究不能仅依赖英语数据，必须纳入多语言视角，以避免对全球开发者行为的误判（例如，基于英语数据训练的毒性检测模型可能无法识别其他语言中的排斥行为）。
总结：该研究揭示了开源软件正在经历深刻的多语言化转型。虽然这一趋势增强了包容性，但也带来了协作效率、可见性和社区规范方面的新挑战。开源社区需要适应这一变化，通过改进工具和制定包容性策略，平衡语言多样性与全球协作效率。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。