MDN 网页文档本地化策略更新

在我们的上一篇文章——MDN 网页文档演变!即将推出的新平台概述——中,我们讨论了将于 12 月 14 日推出的全新 MDN 网页文档平台的多个方面。在这篇文章中,我们将更详细地探讨其中一个方面——我们如何处理未来的本地化工作。我们将讨论自上次文章发表以来我们的想法如何改变,并详细说明我们更新后的行动方案。

更新后的行动方案

基于社区提供的宝贵反馈,我们进行了进一步的调查,确定了一个更强大、更清晰的未来方向。

首先,我们希望将注意力集中在全新平台发布之前的相关工作,并确保整个系统能够顺利运行。这意味着在发布后,我们仍计划在所有现有语言环境中显示翻译,但它们最初将被冻结——只读,不可编辑。

我们曾经考虑将自动翻译作为主要前进方向。一个关键问题是,自动翻译成欧洲语言被认为是可以接受的解决方案,但自动翻译成CJK 语言远非理想选择——它们与英语和欧洲语言的结构截然不同,而且许多欧洲人能够阅读足够的英语,在需要时可以回退到英语文档,而一些 CJK 社区并不普遍使用英语,因此没有这种便利。

我们与许多人交流后发现,自动翻译在他们的语言中是不可接受的。自动翻译不仅质量低下,而且许多 MDN 网页文档社区都围绕着翻译文档展开。如果手动翻译消失,这些充满活力且高度参与的社区可能会消失——这绝对是我们想要避免的!

因此,我们将重点放在有限的手动翻译作为我们的主要前进方向,目标是在新平台发布后尽快解冻一些关键语言环境。

有限的手动翻译

我们已经进行了严格的测试,看起来在主构建过程中构建翻译后的内容是可行的。我们将语言环境分为两层,以确定哪些将被解冻,哪些将保持锁定状态。

  • 第一层语言环境将被解冻,并可通过拉取请求进行手动编辑。这些语言环境需要至少有一位代表担任社区负责人。社区成员将负责监控本地化页面,更新关键内容的翻译(一旦英文版本发生变化),审查编辑等。社区负责人还将负责就该语言环境做出决策,并充当社区和 MDN 工作人员团队之间的联络人。
  • 第二层语言环境将被冻结,不接受拉取请求,因为它们没有社区来维护。

我们首先将解冻的第一层语言环境是:

  • 简体中文 (zh-CN)
  • 繁体中文 (zh-TW)
  • 法语 (fr)
  • 日语 (ja)

如果您希望解冻第二层语言环境,那么您需要向我们提交提案,其中包括一个积极的团队愿意承担与该语言环境相关的工作的证据。如果是这样,那么我们可以将该语言环境提升至第一层,您可以开始工作。

我们将监控第一层语言环境的活动。如果第一层语言环境没有被其社区维护,我们将在一定时限后将其降级到第二层,并再次冻结。

我们认为这个新系统是一个合理的妥协方案——为社区提供了一条路径,只要有兴趣,就可以继续参与 MDN 翻译工作,同时也能确保语言环境维护的可行性,并防止内容进一步过时。由于大多数语言环境都没有得到维护,更改没有得到有效审查,这些语言环境的读者经常在使用他们喜欢的语言环境或英语之间感到困惑,他们的体验因此受到影响。

审查流程

审查流程非常简单。

  • 每个第一层语言环境的内容将保存在其单独的代码库中。
  • 当对该代码库进行拉取请求时,本地化社区将被标记以进行审查。
  • 当内容被审查后,将标记 MDN 管理员合并更改。我们应该能够建立一个系统,使其自动发生。
  • 还将有一些用户提交的内容错误在 https://github.com/mdn/sprints/issues 以及每个语言环境代码库的错误跟踪器中进行提交。在进行分类后,"sprints" 中的问题将被分配给相关的本地化团队进行修复,但相关的本地化团队负责对他们自己的代码库提交的问题进行分类和解决。

机器翻译与手动翻译并存

我们之前讨论过机器翻译在增强新本地化流程中的潜在作用。我们仍然对此抱有希望,但我们希望将初始系统保持简单,以使其可实现。2021 年第一季度的下一步将是开始研究如何最有效地利用机器翻译。一旦取得更多进展,我们将在第一季度中旬再次更新您。

关于 Chris Mills

Chris Mills 是 Mozilla 的高级技术作家,他编写有关开放 Web 应用程序、HTML/CSS/JavaScript、A11y、WebAssembly 等等的文档和演示文稿。他热爱用 Web 技术进行各种尝试,并偶尔在会议和大学进行技术演讲。他曾在 Opera 和 W3C 工作,并喜欢演奏重金属鼓和喝好酒。他和他的爱人以及三个可爱的子女住在英国曼彻斯特附近。

Chris Mills 的更多文章……


8 条评论

  1. Janet Swisher

    很高兴听到您找到了一种方法来支持活跃的本地化社区,同时将非活跃语言环境的维护负担降到最低。

    2020 年 12 月 8 日 下午 10:22

    1. Chris Mills

      感谢 Janet,很高兴收到您的来信!

      2020 年 12 月 9 日 上午 08:18

  2. Eric Shepherd

    虽然我很高兴已经找到了一种方法来为本地化提供良好的支持,但我仍然对当前贡献工作流程中用户友好方面的损失感到失望。我绝对同意拥有一个贡献-审查-发布模型是提高 MDN 内容整体质量以及贡献者与工作人员之间沟通的关键。

    但正如大多数与我共事过一段时间的人都知道,我非常相信文档内容的所见即所得编辑方法。看到 MDN 抛弃了其当前设计中的这个关键功能,我感到很沮丧。显然,在我还在职的时候,我经常会表达我对这个问题的担忧。我还非常惊讶地发现有多少人更喜欢手动编辑 HTML,而不是使用一个不错的 WYWIWYG 编辑器。

    也许问题在于现有编辑器体验中的怪癖和缺陷,其中许多是由目前 HTML 规范对编辑的支持不足造成的。无论如何,一旦你了解了这些问题,你通常可以很容易地避免它们。

    也许我现在不在职是最好的(尽管我真的想念它)。如果采用编辑源代码的方法,至少会使我完成任何事情所花费的时间增加一倍,而且还会让我完全崩溃。我会讨厌它。我可以说,我对继续贡献的任何机会——即使是微不足道的贡献——都已彻底消亡。☹️

    2020 年 12 月 8 日 下午 10:52

    1. Chris Mills

      很高兴收到你的来信,Sheppy,我们也想念你!你一直都非常明确地表达了你对这个问题的感受 ;-)

      值得注意的是,我们打算在发布后根据收到的反馈,将 Yari 工具集添加到其中。还需要注意的是,基于 GitHub 的工作流程使得它很容易将其插入到您想要的任何工作流程/工具集中。我相信除了你之外,还有更多人重视所见即所得的方法,我相信会为这些贡献者找到一个解决方案。

      2020 年 12 月 9 日 上午 08:21

  3. Daniele Mte90 Scasciafratte

    说实话,我反对自动本地化,即使是针对欧洲语言,例如我的母语意大利语。

    根据我们的经验(也是作为开发者),这种情况非常糟糕,因为这意味着技术术语会被本地化(并非所有语言都拥有相应的术语,而是使用英文版本),同时在 Firefox 或 Chrome 等软件中以某种方式本地化的术语在文档中却使用了不同的术语(指代相同的特性),这会给用户造成很大的困惑。

    这样一来,志愿者就会花费时间来修正自动本地化结果。WordPress 社区以前也遇到过这个问题,并因为种种问题在几个月后就移除了自动本地化功能,而清理这些问题花费了好几年时间,因为一些问题依然存在。

    大型公司不使用机器自动本地化内容而采用人工本地化的原因也是一样,因为自动本地化会导致错误,损害项目品牌形象。

    2020年12月9日 05:36

    1. Chris Mills

      嗨,Daniele!

      在理想情况下,我们不会使用机器翻译。我理解它们并不完美。但所提出的方案是折衷方案,既允许活跃的语言区域继续保持手动维护(如果有兴趣的话),又避免保留过多的过时、无人维护的翻译。我们没有足够的资源来妥善维护所有这些语言区域,没有社区团队的帮助是不行的。

      我们打算使用一个术语词汇表(在 Firefox 团队内部维护),并与自动翻译系统配合使用,确保技术术语要么根本不翻译,要么翻译一致,视情况而定。这样做的目的是减少这种混乱。

      2020年12月9日 08:17

  4. Jean-Baptiste

    如果您的机器翻译机制是通用的,那么每个人都可以使用它,因此每个人都可以为其做出贡献。

    假设内容遵循以下步骤:

    1. 人工管理的英文仓库
    2. 机器管理的翻译模板仓库
    3. 人工管理的翻译仓库(通过翻译平台)
    4. 机器完成的翻译仓库
    5. 发布仓库

    机器翻译只在步骤 3 和 4 之间进行,人工会进行正常的翻译流程来修正错误。因此,这个修正过程是通用的(特定之处在于如何方便地访问要翻译的字符串)。

    因此,机器翻译是通用的,任何人都可以向其添加内容,或者根据语言测试不同的引擎。

    在现有的翻译记忆库中,我们有例如 amagama 项目正在做的事情:https://github.com/translate/amagama-updater/

    或者我用 Fedora 内容做的事情 https://jibecfed.fedorapeople.org/partage/fedora-localization-statistics/f32/language/fr/

    或者世界各地的不同 Weblate:https://weblate.org/fr/news/archive/weblate-even-more-open-now/

    或者 Ubuntu langpacks:https://launchpad.net/~ubuntu-langpack/+maintained-packages

    我可以帮助完成这项工作,希望:
    * 任何免费项目都可以根据自己的需要查询翻译引擎(尽管可能需要事先授权)
    * 每种语言都有存在的权利,即使 Mozilla 会专注于自己的语言清单。

    现实场景

    * 我们能填补 Fedora 翻译的空白吗?
    * 我们能填补 LibreOffice 翻译的空白吗?
    * 等等……

    2020年12月12日 03:41

  5. Harvey Liu

    好久没访问 MDN 了,真的很惊讶整个网站都迁移到 Github 了。(我本来想评论 10 月的文章,但那里的评论功能关闭了。)
    就像许多其他人已经建议的那样,WYWIWYG 编辑器比当前每个人都在 Github 上提交 PR 的解决方案要好得多。其他网站,比如维基百科,对用户编辑有更好的管理方式。
    我个人也觉得编辑历史很重要。从某种程度上来说,我能看到这种技术的演变过程,以及它如何与历史上的其他技术联系在一起。
    用户个人资料的活动也随着“解耦”而消失,现在个人资料仅仅是一个描述。我曾经设想 MDN 社区可以发展成一个像 StackOverflow 这样的论坛。

    2020年12月18日 13:54

本文的评论功能已关闭。