助力中国开源出海：英文技术文档工程师的培养与发展

今年 9 月中旬有幸参加了 tcworld 技术传播大会，本文基于我会上关于《助力中国开源出海：英文技术文档工程师的培养与发展》议题的分享而整理，内容有 70% 左右相同，本文主要增加了一些细节的说明。

在云原生浪潮大爆发的互联网时代，一个个来自中国的开源项目不断涌现。除了打造优质的产品外，中国开源项目如何更好地接轨国际是每个项目都需要思考的问题。技术内容作为开源项目中重要的一环，需要语言技能过硬、技术知识专业的文档工程师直接进行英文技术内容的输出，包括撰写与审核英文文档、输出英文技术博客与案例、录制英文视频教程，以及组织社区本地化贡献等。本主题将围绕英文技术文档工程师的招聘、培养与职业生涯发展这三个方面进行阐述。

虽然本文主要针对开源项目，其实很多地方也适用于闭源产品。

关于我

目前就职于开源项目 Apache Pulsar 的商业化公司 StreamNative，主要负责英文技术内容的策划。之前也曾在外企担任过本地化项目的 Gatekeeper，开源项目的文档负责人，为多个 SaaS、CCaaS 和 PaaS 产品撰写并审核过英文文档。我是语言专业出身，对 K8s 等开源技术尤为感兴趣。

痛点

中国人作为英文的技术文档工程师主要存在以下两个问题：

1. 中文的技术文档工程师难以满足内容出海的语言要求，无法以地道的英文向全球用户介绍产品。

2. 英文的技术文档工程师往往缺乏相关的技术背景知识，在输出英文文档时可能仅仅是润色语言，难以从技术的角度为用户提供专业的内容。

于是，有的项目不得不首先输出中文内容，然后由英文文档工程师进行翻译。这种做法有几个明显的弊端：

1. 专业技术内容很难准确翻译。翻译的本质是要在理解原文内容的基础上用地道的译出语进行表达，说白了就是“先把意思搞清楚，再把人话说明白”。我见过很多英文语言优秀的人在做汉到英技术翻译时英文写得不清不楚，主要是没把中文原文读懂，所以只能直意，导致翻译腔严重甚至英文本身就有误。要知道，开源项目的一些技术，例如 Docker 与 K8s 等容器技术、MySQL 和 Redis 等数据库、Kafka 和 Pulsar 等消息流中间件、Grafana 和 Prometheus 等可观测性工具，以及其他各种云原生技术绝非一朝一夕能轻易弄懂，其中任何一个领域在不理解内容的情况下想要翻译清楚难度非常大。

2. 降低了开源内容的传播效率。开源项目所面对的是全球用户，英文作为国际化语言就目前来说其地位难以撼动。优先输出英文内容，让全球用户都能第一时间掌握产品的相关信息至关重要。英文内容产出后，可以号召社区的贡献者们进行不同语种的本地化，这种英文到多语种的模式才是全球性开源项目正常的语言转换顺序，而非在中间先加一道中转英的步骤。

3. 并非适用于所有的内容类型。内容本身是个非常宽泛的概念，可以包括文档、博客、案例分析和白皮书等语言文本类内容，也可以包括音频、视频和播客等媒体内容（例如，你会在 Apple 的一些 iTunes 相关的文档中看到“Content Provider”的用法，指的就是这些内容的提供商）。仅从文字类的本地化来说，对文档和博客的翻译或许还能接受。然而，中文的案例分析直译成英文往往不合适，主要是因为中英案例分析的写法有着不少差别。

可以看出，中国的开源项目想要出海，需要语言和技术两方面都过关的英文文档工程师，优先产出地道且专业的英文内容。

本文统称“文档工程师”，但实际叫法有很多，也并非只写文档。

招聘

了解了以上几个痛点后，接下来我结合自身的经验从招聘的角度谈一谈我们所能采取的措施，即如何才能筛选出符合要求的人才或者至少是有潜力达到开源项目内容要求的人才。

每个公司的招聘流程不同，但基本上我们可以分成前期的简历筛选和后面的三个正式流程：

1. 简历筛选。优先寻找有相关工作经验的候选人，例如曾在开源项目担任过英文文档工程师的人才。针对应届毕业生，如果有相关实习经历可以优先考虑。如果是一张白纸，培养周期可能比较长，需要结合公司的实际情况来考虑成本等问题。

2. 第一轮：基本情况了解。与一般岗位的面试类似，HR 来负责。

3. 第二轮：语言水平测试。方式多种多样，例如翻译与审核测试、文档与博客（案例分析也可）测试等。测试时应选择与该开源项目相关的内容。如果是文档与博客测试，在给素材时注意提供基本的内容说明就行，可以是某个功能的文字说明草稿、场景或视频讲解，甚至可以只提供一个标题或话题，然后让候选人自己去写，具体可根据其过去的经验进行相应的修改。有经验的候选人会自己去网上寻找各种材料放到最终的测试结果中，资料的查找和搜集本身也是文档工程师非常重要的能力。

   需要注意的是，文档与博客类测试结果的提交方式也可以多种多样。考虑到技术语言与格式的特殊性，管理者们需要知道我们很难用 WORD 完美地呈现出标准的技术内容，特别是文章中包含代码或命令行就更是如此。如果候选人能通过开源项目普遍使用的工具（例如 Markdown 和 Git）来提交测试结果，也能侧面说明 TA 的文档工具能力。举个例子，我在面试当前这份工作时，面试官给了我一个题目写英文技术博客，但没说提交时用什么格式。最后我利用 Hugo 搭建了临时个人博客并托管在 GitHub 上，再通过 Markdown 写好博客上传。这样面试官和公司内部的其他人在查看作业时只需要点一个链接即可，非常方便，同时也能呈现出符合技术语言的标准格式。如果对候选人英文口语有要求的，也可以让 TA 以英文视频教程的形式提交作业。

4. 第三轮：本地化、文档与开源技术理解的考察。能到这一轮的候选人说明至少语言功底基本过关，需要进一步考察相关知识的理解，并进行 Red Flag Check（例如，是否有意愿学习相关的技术知识），对口语有要求的可以用英文在这一步沟通。后文我会对这几点做详细解释，这里不过多赘述。

打造专业的团队

文档工程师通过面试进入公司后，要面对的需求往往不只是单纯地写文档，特别是处于早期的开源项目更是如此。这里我主要从本地化和文档两个方面来说明。

本地化

上文我曾提过，为了让全球用户都能及时获得产品的相关信息，我们应该先输出英文内容，但这并不意味着文档工程师不能做中英的互译。开源项目本身也会号召社区的小伙伴们进行文档或博客的翻译贡献（这里主要是英译中），但水平参差不齐，这就需要文档工程师起到带头作用对内容的翻译质量进行把关。此外，中文社区所贡献的优秀博客或案例，也需要文档工程师们转化成对应的英文内容，贡献到全球社区。

就本地化而言，我个人认为有三个方面至关重要（这里我们先不谈中英语言水平），在上文招聘的第三轮可以就以下这三个方面考察候选人对本地化的理解。

准确性

这个很好理解，就是对原文内容的把握是否准确。要提高准确性，除了语言水平外更重要的是对技术背景知识的理解，这个与我后文在“文档”部分提到的“专业性”类似。在理解原文的意思上去翻译，就可以真正做到“写作”而非单纯地翻译，最直接的好处就是能说人话，避免翻译腔。

标准化

和文档类似，技术语言有自己的风格。我们需要一套规范（风格指南）来统一产品文档的文风和表达（无论是直接翻译还是写作），其他还包括图片、标点、格式和使用的工具等。在开源的环境下，本地化的风格指南应该尽量简单，门槛设得适中，公开后方便社区用户参考进行文档翻译贡献。

本地化思维

这个思维可以说是本地化和翻译的区别之一，也是可以进一步提升本地化质量的地方，更是让我们能仔细去思考对语言态度的地方。简单来说就是因地制宜去思考什么语言才是用户预期的结果，下文我会用一个例子来说明（本地化本身包括很多内容，由于篇幅原因这里我不详细解释技术内容的本地化，之后会单独就这个话题在其他的文章中阐述。由于前两点我相信很多人都能想到，这里我主要想谈一下第三点）。

做软件行业的朋友应该会在产品（特别是有图形化 UI 的产品）文档中经常碰到一个词：Click。请问这个词该怎么翻译？我的看法是这样的：

1. Windows 系统上这个词的翻译是“单击”，例如 Windows 的相关文档。

2. Mac 系统上这个词的翻译是“点按”，例如 Apple 的相关文档。

3. 如果不涉及系统，从语言中立性的角度考虑，最好翻译成“点击”，例如 Google 的相关文档。

以下是 Apple 文档中关于这个词的翻译，可以看出在指定了系统语境的情况下，这个词的翻译完全不同。

有的朋友可能会质疑开源产品的文档本地化是否要达到这种准确度？诚然，我们看到的很多开源文档的翻译质量其实都不尽如人意。就我本人来说，我是个非常喜欢语言的人，如果能尽量提升准确度我并不认为这有什么问题。其次，很多开源产品会商业化，需要提供商业化的中文文档，此时往往需要文档工程师去做本地化工作。由于是付费用户，保证高质量的文档翻译不应该存在任何的异议。

文档

从技术语言的角度来说，写好文档和做好本地化有很多相通的地方，毕竟本地化的输出语言本身也是文档。然而，直接撰写文档的要求会更高，文档工程师们需要自己去规划文章的结构，确定到底要写什么。同样，这里我们先不谈语言水平，我个人认为以下三点对文档来说最为重要：

专业性

专业性考察文档工程师对所写内容的技术背景知识是否了解。显然，如果你写的内容不专业，甚至有技术上的错误，又怎么能指望读者用你的文档去解决问题？这里说的技术背景知识不仅涉及到你自己的产品，其他竞品甚至整个相关的行业知识你都需要一定的了解。对于非技术专业（例如语言专业）的朋友来说，这点最为棘手。关于如何学习技术知识需要专门的文章去说明，不过在后文我会简单说明一下该如何培养英文文档工程师去学习技术。

实用性

写文档时我会问我自己，用户最想知道的是什么。说实话这个问题不好回答，毕竟每个人的理解能力不同。但我们应该尽可能地保证内容的实用性，总体上来说要兼顾概念解释和操作说明，前者不要说废话，后者不要少步骤。概念说明比较好理解，就是阐述这个东西是什么，但是太啰嗦反而会让别人没有看下去的想法。操作说明也就是步骤演示，这里的一个大忌是不指明一些关键的环境配置，或觉得某个地方很简单不用说明。例如，有的文档初稿可能由其他同事提供，TA 操作的时候能够跑通，你操作的时候就跑不通。后来发现可能是 TA 一开始开发环境中装了个什么东西，又或者要配置某个东西然后 TA 觉得和这篇文档本身无关所以没写，而且认为用户应该知道这个怎么弄所以不需要写。这种问题其实比比皆是，如果你的步骤跑不通，文档的意义又是什么？

标准化

和本地化类似，技术语言有自己的风格。我们需要一套规范来统一产品文档的文风和表达，其他还包括图片、标点、格式和使用的工具等。大型企业都有自己的风格指南，如果你的文档团队刚刚建立，可以参考其他公司已有的风格指南去制定自己的一套规则。这里列几个常用的给大家参考（第 4 个严格来说不是风格指南，但会告诉你 Apple 生态里面很多的操作或 UI 的英文称呼，强推）：

1. Apple Style Guide https://support.apple.com/guide/applestyleguide/welcome/web

2. Google Developer Documentation Style Guide https://developers.google.com/style

3. Microsoft Style Guide https://learn.microsoft.com/en-us/style-guide/welcome/

4. Human Interface Guidelines https://developer.apple.com/design/human-interface-guidelines/guidelines/overview/

培养计划

新人进入公司后，我们最好能为其制定全面的培养计划（Ramp-up Plan）。如果按照小白的标准来培养，可以分为以下这几个阶段一步步入手。如果是有一定经验的人，可以根据这个人的实际水平跳过以下的某些部分。

风格指南和工具

风格指南上文我已经说过，可以自己制定或参考大厂然后让新人学习，这里不再赘述。至于工具，开源领域的文档工程师要掌握的工具其实并不复杂。很多向仓库提交文档的人并非专业的文档工程师，他们用的往往就是最基本的 Markdown 工具（例如 Visual Studio Code）。这里简单列几个：

1. Git/GitHub。用 Git 提交文档至 GitHub 是最基本的操作，属于开源领域的必备技能。从我之前带过的人来说，如果要让小白学会整个这套流程，最好的方式是录制视频，视频可以包含帐号设置、克隆分支到本地、创建分支、本地创建 Markdown 文件（顺便演示 Markdown 简单语法和添加图片的方式、路径等）以及 Commit 到上游仓库等一系列操作，整套流程录制下来不会超过半小时。小白一开始最容易出错的地方是提交或克隆失败（多半和梯子有关）以及提交时的分支切换搞错（老用 Master 分支去提交）。有的人可能会说可以写文档来说明，不用录视频，这种方法对于部分人可以，还有一部分人（尤其是新手）就是看不懂。为了确保所有人肯定能把这个流程走通，我还是推荐录制视频，视频可以多次复用给后面新来的同事看。如果确实不想录制或写文档，也可以去网上找相关的文字或视频教程。等新人熟悉一段时间后，可以根据自己公司流程的需要再教一些别的知识，包括合并多个 Commit 和 Cherry Pick 等。

2. Markdown 和 HTML 基本语法。可以去网上找相关的教程，记几个常用的命令即可。HTML 的一些语法可以方便补足 Markdown 的一些短板。

3. Linux 基本命令。虽然文档工程师不是专业技术人员，但现在众多的开源项目都可运行在 Linux 上，甚至是 Docker 和 K8s 容器环境。后面这两个自然一开始不用掌握，但基本的 Linux 操作还是需要学会。可以整理一个清单，或者去网上搜索相关教程发给新人学习。如果新人需要练习 Linux 环境上的基本操作而一开始又不能给 TA 一个专门的机器，可以去 katacoda 这个网注册，上面的环境可以免费使用。

4. 其他相关的工具，例如 CAT 工具或公司内部专门的写作工具。这一部分主要看公司自己的规定和要求。有的人可能会问是否需要学习 DITA？我的看法是，对于标准化、结构化写作来说 DITA 确实很重要，但很多开源公司的文档规模没那么大，根本不需要到使用 DITA 的程度。换个角度说，难道你想让所有社区贡献者都用 DITA 工具来写文档才能贡献吗？显然不现实。

翻译

掌握工具后，新人可以从翻译开始做起，同时也要一步步学习公司产品。中国人做英文的文档工程师要确保自己所用的技术术语正确，而做翻译可以慢慢帮助新人积累有关的双语词汇，也可以让 TA 学习相关的知识。能翻译的内容主要包括文档（中英互译），博客也能翻，但质量不会太好（可以试试将博客英翻中）。另外不建议翻译案例，因为中英案例分析的写法不同，着重点不一样（后面还会详细解释）。新人在学习的同时一定要手动实操部署应用，我的建议是在前一到两个月，要让这个新人自己会参照已有文档成功搭建环境，并能够使用一些基本功能。

英文文档

从上一步到这一步的时间因人而异，有的人可能一个月就行，有的人可能三个月都写不了。由于如何写文档牵扯到众多因素，包括文档来源、大纲、流程、风格、团队合作与沟通以及更新等，需要专门的文章去说明，我这里简单说一下给培养新人的意见：模块化、模板化、场景化、术语化以及简单化。说白了，一开始需要做的就是让新人照葫芦画瓢，多看竞品和大厂的英文文档（仅参考，千万别直接照抄），不要搞太复杂，也别让这个人写太难的东西。以下两个材料给大家参考：

1. Google 免费的文档工程师培训教程（英文）：https://developers.google.com/tech-writing
2. Udemy 上的技术写作教程（有免费章节，看完整需要付费。这个课程我有买，所有内容我都看了，纯针对技术写作小白。有一定基础的可以选其中不懂的看）：https://www.udemy.com/course/start-your-career-as-user-assistance-developer/

英文技术博客

从上一步到这一步可能又是比较长的时间，半年甚至更久都有可能。严格来说这里又可以细分为两个阶段：中到英的 Transcreation 和原创英文技术博客。

Transcreation

简单来说就是把中文博客转化成英文的同时，英文还需要加上一些再创造的内容，包括结构的调整等，注意这个概念和第二步说的翻译有本质区别。在之前那个阶段翻译博客只是让新人能够学习，但是到这个阶段文档工程师（可能称呼已经变了，但是这里我姑且仍这么叫）对产品已经有了一定的了解，应该具备一定的写作能力来说明一个概念是什么以及为什么会这样等。那么，为什么会需要在英文中对博客进行再创造？这又是个很大的话题，简单来说是因为很多人在写博客时只是按自己的理解，很多地方缺胳膊少腿，没有详细解释甚至连相关内容的参考链接也没有。这就需要文档工程师在 Transcreation 的时候帮忙补足。同时，这也和中英这两种语言的本质有关，即意合与形合，我会在其他的文章中去解释，这里不再赘述。

原创

写英文技术博客有多种方法和策略。为了简化给这一阶段文档工程师的培养意见，写的时候可以从以下几点入手：

1. 概念/产品介绍以及产品对比。需要对某个功能或产品以及其竞争有一定的了解，深入、全方位的了解更加。写的时候注意概念解释清晰，告诉读者该产品能解决什么问题，应用场景是什么，以及优劣势等。可灵活使用架构图与对比图。

2. 功能实操与实用技巧。对某个功能的操作步骤进行详细说明，也可以是某个产品的使用技巧或最佳实践。这种类型新手写的话上手成本比较低，因为可以从现有的文档进行转化，语言的规范性和正式性相比于文档也可以低一些。可灵活使用流程图，同时忌文档风。

3. 技术观点与行业评论。有一定技术基础，对产品的某个部分，或对某一特定领域的当前趋势、状况与发展有比较独特或深入的见解。写的时候注意多方查询行业观点，避免低级错误、技术漏洞，可与研发同事协作合著。

对于社区人数较少（特别是在海外的知名度较低），初创的开源项目来说，采取前两种方式写博客时可采用一种“诱导”的方式来为自己的产品取得一定的关注度。举例来说，可以先介绍业内已经存在的某个产品在解决某个问题（或某个操作）时需要怎么做，然后在文章快结束时说虽然我们可以用这个产品做这些操作完成这项任务，但现在有另外一个产品是 XXX（也就是你自己的产品），可以使用更简单的方法完成同样的任务。此时不要详细介绍，只用简单说明，然后放相关的链接即可。之所以这么做是因为如果一开始就告诉读者你自己的产品怎么用，别人可能没有概念，甚至看到标题就不会看你的文章，我们需要用某种方式先把读者引入进来。

开源博客内容的策略有很多种方法。以选题来说，可根据博客最终的指标进行分析，形成选题->写作->市场/运营->分析->选题的良性闭环。在这点上我的意见是：紧跟业界时下风潮，及时回应用户需求。以形式来说，可做成系列甚至白皮书等。成体系地讲，我们需要开源博客层面的全局策略，覆盖选题、撰写、审核、发布、页面呈现、市场、运营、SEO、可观测指标分析、社区贡献等多方面，覆盖每个阶段的用户群体。作为文档工程师，这个人或许不用去主管每一环，但实际操作的时候会发现 TA 对于推动整个流程的前进至关重要，特别是一些初创的开源项目，在人手不够的情况下，这些环节 TA 可能必须一把抓😂。以后我会在单独的文章中说明我们每一步该具体如何去做，这里先让大家有个宏观的概念。从培养的角度上来说，我认为让文档工程师涉及其中的多个环节也不是坏事，最终会发现这可以促进写作的流程，同时也有助于拓宽职业发展。

之后我会在 SegmentFault 举办的中国开发者生态峰会上谈开源内容的策略如何规划（主要是博客和案例），感兴趣的朋友可以到时候关注。

英文案例分析

从技术博客再进阶一步便是案例分析，但其实由于人手原因，很多文档工程师在上一步时也已经在做案例分析。这么做问题并不大，但最好要先注意英文案例分析的具体写法。从培养的角度上说，我建议先让文档工程师去参考一下同类竞品的案例分析怎么写，同时学习大厂（Google Cloud、Azure 和 AWS）的写法。

在说明写法之前，先看一下案例分析是什么。细分的话其实应该分为 Case Study 和 Customer Success Story 这两种。后者有些偏商务，前者更偏技术，但是你会发现很多公司分得没有这么细，可能会统称 Case Study。以下是我参考了各大厂和一些开源公司的 Case Study，同时综合我自己写英文 Case Study 总结的一些经验和建议：

1. 我们写 Case Study 的基础材料可包括用户的 Meetup 分享视频、用户的采访材料、现有的技术博客等。

2. 中文也有 Case Study 和 Customer Success Story，中文的 Case Study 很多人喜欢在里面讲技术很深的内容（甚至包括解决代码层面的 BUG），但是英文我看这么做的比较少。英文 Case Study 或 Customer Success Story 的大致结构是：公司/背景介绍->当前挑战->工具选型->实际落地->使用细节/结果->未来计划，中间穿插关键人物证言。这个是我总结的一个模式，但并非不这么写就是错的。我见过有外国公司的 Case Study 非常简单，只包括背景、解决方案和结果，我这里列的是个相对完整的写法。

3. 非要给英文的技术博客、Case Study 和 Customer Success Story 分个类的话，我的看法是技术内容不超过 10% 的可写成 Customer Success Story，10%-50% 的可写成 Case Study，50% 以上的按照技术博客去写。前两个可采用第三人称，加用户/顾客证言的方法，博客则可直接采用第一人称。需要注意的是，这个分类以及人称写法只是我参考各大厂（Google Cloud、Azure 和 AWS）做法后的一个建议，你如果认为你的写法没有问题，符合你公司的做法，可以继续这么干。

4. 我上面的百分比分类法主要的依据是这三类材料要达到的目的不同。Customer Success Story 更注重让用户去夸你的产品，多说好话，说明你的产品如何让用户成功，好鼓动其他公司，但要适当说一点技术内容让别人知道这个用户用的是什么功能，达到了什么效果，解决了什么问题。Case Study 也有这个目的，但更注重用户用了什么，以及是怎么用的，要凸显对用户这个 Case 的“Study”，同时也需要适当添加用户的证言。但是，英文的 Case Study 不用讲太多（甚至别讲）用户使用你产品时是怎么解决 BUG 的，或是 Workaround 的方法。比较深的技术问题适合在技术博客去讨论，我也并不认为在同一篇文章中让用户一边夸你，同时又说你的产品有某个问题是个好的写法。

写好案例分析是个比较长的学习过程，如果你的公司里面有 Customer Success Manager，写完了之后可以让 TA 看看非技术的部分，TA 应该会给出更专业的意见。

关于案例分析如何写是个很复杂的事，我和国外的朋友沟通过发现很多人自己也不太清楚。所以，我认为不拘泥于上述形式也可以，只要能达到我们的目的就行。但从培养文档工程师的角度说，如果 TA 不知道如何下手案例分析，可以参考我上面的建议。另外，这里再和大家分享我和两位大佬请教的经验。

1. 我很庆幸在上一份工作中碰到了一位曾经来自微软的大佬，他是微软上世纪在中国本地招的第二号员工，曾担任过 Windows 和 Office 的产品经理，自己也曾开过多家公司。他这个人最大的特点是喜欢创新，做任何事不走寻常路。他看到我写的英文文档后告诉我，虽然文档写得可以，但是没什么创新性。我当时想不出需要风格指南规定的技术文档该如何创新，他说可以试着在某些技术类文章中讲讲故事，因为读者归根结底也是人，喜欢看故事。我认为确实有道理，我平常看老外写的技术文章有的人会在里面讲段子，这种时候我看到往往会觉得挺有意思。

2. 在这份工作中，我有幸能向开源内容领域的一位前辈坤姐请教，她曾是 PingCAP 的国际化负责人。我给坤姐描述了我设想英文 Case Study 的一种写法，这里我以 K8s 来举例：某个夜黑风高的夜晚，某运维在家里接到了公司的电话，说公司的 K8s 集群因为某种原因崩溃了，需要 TA 去公司机房解决问题；TA 只好驱车 20 公里来到公司，结果夜晚因为大楼要省电电梯不开，TA 又爬楼 10 层，在机房倒腾了半天，终于解决了某问题；此时 TA 想，如果能存在一个好的 K8s 运维工具该多好。这是开篇，接下来就可以介绍 TA 所在的公司是如何选择你的产品来解决问题的。目前我看了很多篇英文的 Case Study，但是没有这么写的。坤姐告诉我中文其实也有这么写的文章，但是英文她之前没这么做过，不过如果真的这么写要有个前提，即用户真的深受其害。如果用户真的被某个问题困扰很严重，同时也愿意提供素材，我认为这种开头的英文文章会更容易吸引读者。

这里只是为大家提供一些思路，具体的案例分析写法其实有很多可以延伸去讲，以后我再详细说明。

英文视频教程

再进阶一步，英文文档工程师也可以录制相关的视频教程。录制的内容可以根据文档或博客去改编成视频材料，当然由于是英文视频，这对文档工程师的口语能力有一定要求。不过，开源讲究开放贡献，全世界的朋友们都会发相关的视频，就算英文口语不是那么利索也不用担心。不过，如果是让商业化用户看的视频教程则要格外注意。

有的公司会有专门的 Training 部门去负责。以我上家公司举例，我的文档写好后国外的 Training 同事会安排对部分文档内容录制视频，他们会提前写好稿子让我审核，没问题了再去录制。感兴趣的朋友可以私底下找我聊，我可以给大家介绍一下具体的做法和方式（包括使用 Lightboard 等），这里不再赘述。

除了视频之外，播客是开源中常用的内容形式，但这块文档工程师一般参与的比较少。感兴趣的朋友可以去和自己开源社区的经理去了解，他们在这一块的经验会更丰富。

从业余到专业

这部分最后给大家总结一下英文文档工程师的几个发展阶段：

1. 翻译：翻译文档、博客以及其他材料（例如社区新闻等）。

2. 文档工程师：写文档、英文博客、录制英文视频，可能还要负责其他英文材料的准备。

3. 文档/本地化负责人：到这个阶段基本上算是某种内容形式的专家，可能还负责培养一些新人。

我在上文介绍本地化和文档时都提到了我认为各自比较重要的三个方面，当时我提到的前提是我们不考虑语言问题。综合来讲，我认为中国人要做好英文的文档工程师最重要的是两点：中英语言水平以及技术背景知识，缺一不可。

从职业发展的角度说，文档工程师发展的方向有很多，以下是一些可能从事的工作：

1. 中英本地化；

2. 中英文档；

3. 中英博客与案例分析。你甚至可以成为自由撰稿人，多投稿国外 DZone、Medium、InfoQ 等渠道，经常在 Linkedin 等平台上混脸熟，可能会有人来问你要不要给他们写稿；

4. 视频教程录制（这里指的 Training 方向）；

5. 开源布道（内容本身也是布道的一种形式）；

6. 社区运营（与技术内容关联很强）。

这里仅列出其中部分，其中只要你想，任何工作都有可能。无论是哪个发展方向，都要做的一件事就是学习，无论是语言还是技术（如果是文档工程师）。先不谈语言，技术知识该怎么学习？简单讲就是要从基础的砖块搭建起来，然后一步步往更深的内容学习。举个例子，下面这段是 Apache Pulsar 的解释：

Apache Pulsar 是 Apache 软件基金会顶级项目，是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体，采用计算与存储分离架构设计，支持多租户、持久化存储、多机房跨区域数据复制，具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性。

请问小白看的懂吗？每个中国字都认识，但还是不知道 Apache Pulsar 有什么用，主要原因是里面单个的基础砖块不懂。要搞懂这些，要先搞清楚其中的“云原生”、“分布式”等关键字的意思到底是什么。每个大致清楚之后，再结合实操才能弄懂。这是个很漫长的过程，但基础知识不牢固肯定很难学会。之后我会去单独的文章中详细解释。

有的人可能会问，要学的东西有很多，该如何坚持？我经常拿孔子的一句话来激励自己：知之者不如好之者，好之者不如乐之者。真正喜欢的话你并不会认为学某个东西是负担。我经常和我朋友说，虽然我工作日在“上班”，但写文章是我的爱好。这么一来，你可以理解为我其实都在拓展自己的兴趣，而且还有💰拿，更重要的是每天都能变得更好，学得更多，这么好的事为啥不干？

总结

如果能看到这里先感谢大家愿意花时间阅读。我因为人生第一份工作的原因（曾教过 70 岁老爷爷如何使用某技术软件），所以讲话比较啰嗦。看过我写的文档的人应该知道我很怕别人看不懂，所以有时候说太多，这也是我想努力克服的毛病。

中国有很多优秀的开源产品，但很遗憾的是我们缺乏优秀的英文技术文档工程师把这些产品真正传递给全球的用户，但愿这篇文章能给大家提供一些实用的建议和参考。后面，我也想以这篇文章为契机，结合我实际的工作经验去一篇篇补足开源内容的各种策略（特别是英文内容），形成一套实用的方法论或玩法手册，帮助咱们中国人自己的开源项目顺利出海。