这个我尝试详细介绍一下目前的想法。
问题一：官方文档层次结构复杂，不好关联
这个可以通过一个 Post Meta 字段，在每篇文档中指定该文档所关联的翻译项目，同时可以按文档目录拼接命名来避免项目名重复的问题，比如说：开发文档_REST-API_介绍
问题二：翻译的运作的机制
这个设想中就和应用市场的插件、主题自述文件的翻译是一样的。
目前开发了一个全局的 i18n 库，WordPress 官方的 i18n 库是以 mo 文件为索引目标的，但是 litepress.cn 中的这个 i18n 库是以翻译平台中的项目为索引目标。
也就是说可以在整个平台的任意地方调用翻译平台的翻译数据，我举个例子：
比如一篇文档来说，他有一个段落：hello word。这个时候在代码上可以写：i18n::translate( '翻译平台的项目名', 'hello word' );，这时候 i18n 库就会自动去翻译平台在这个项目下搜 hello word 的译文再返回回来。
了解了这个机制后后面应该就清晰明了了。我们只需要在文档输出时给原文加一个过滤器，把每个段落的原文都去调用 i18n 库查以下译文，之后把存在译文的段落替换掉原文输出。
也就是说，其实不存在“通过 GlotPress 翻译好以后将同步到我们平台的文档中”这个概念，因为翻译是实时调用的，文档平台中存储的始终只有英文原文，翻译只存在于翻译平台中。
问题三：翻译采集的流程
大概是这样的：机器采集后将原文入文档平台，之后文档平台会通过异步队列将创建翻译项目的请求提交给翻译平台（其中包含了项目名、原文数据等），翻译平台收到请求后就创建项目，而因为创建请求是文档平台提起 ，所以文档平台就可以通过自己掌握的数据，按前面说的使用一个 Post Meta 字段来与翻译平台的这个项目联动了。
效果
设想中，这一套机制，可以实现按块更新、文档中点击翻译、翻译效果实时预览。
按块更新
这是说的，当官方文档的原文存在更新时，我们只需要把新的原文无脑的入文档平台即可，这时候文档平台再去翻译平台请求更新新的原文，对于没变过的段落，翻译平台会自动跳过，对于变过的字段翻译平台会自动采用新的（这就是一般的导入原文操作，不需要特别开发）。这个时候对于文档平台来说，它在输出时那些没更新过的段落，依然可以从翻译平台调取到翻译数据，而更新过的则没有了。
这一切呈现给译者的就是：哪个段落更新了，哪个段落的译文就消失了，需要重新在文档上点击翻译，不过仅仅是翻译这个段落，不需要像传统方式那样重译整篇文章。
文档中点击翻译
因为翻译是由 GlotPress 管理的，所以只需要提供一个外部 API,让用户可以通过 API 贡献翻译即可（已经有了，是wordpress.com 开发的）。也就说，虽然翻译是在 GlotPress 中的，但是译者可以在文档中点击某个段落，唤起一个窗口，这个窗口会自动通过 API 与翻译平台联动。
此时在从译者的角度看，他就是在文档上直接点击某个段落贡献翻译了，可以在完全参考上下文的基础上给出最佳翻译。
翻译效果实时预览
这个的实现其实就是依赖于前面说的翻译调用机制（通过 litepress.cn 的 i18n 的模块而不是把译文直接写在文档里）。
对于普通用户，文档平台会为他们调用“当前”翻译。
对于译者，则会调用“当前”翻译+机器生成的模糊的翻译+由这个译者提交的“等待”翻译。
此时站在译者角度看，他就是随时贡献随时可以查看效果了，同时也可以参照机器生成的模糊翻译。
当然，我们面临的始终不是一个译者，而可能是多个人合作一个项目，这个时候这一套机制的优势就能体现出来了：我们可以在前端为每个译者输出他自己的翻译的同时在 GlotPress 上从多个译者提交的翻译版本中选出最优的设置为 “当前”翻译，以交付给普通用户。
结尾
其实我觉得这一些机制，比较好的体现了我之前一直说的“成体系”，这样可以很好的进行多模块联动以提供意想不到的效果，这一些基础设施奠定了我们与其他尝试做“中国社区”、“中国市场”的人的不同，他们只是搭建了一个网站，而不是一个成体系的平台，所谓的画皮不画骨。
当然这里只是举了其中一个应用例子，还有我们之前探讨的翻译贡献自动得优惠券这应该也是一个多模块联动的应用例子。
此外，这个规划是很早之前想的，不是一定不变的“确定方案”，所以有觉得不妥的地方可以再探讨。