[孙锡源 楼主坏蛋的博客]

Cravatar头像

Cravatar上线已经整整18天了，是时候对数据进行一下梳理了。

目前使用Cravatar的网站数量已达1000个，日均请求量180万，每天为18万访客提供头像服务。

不过需要特别说明一下，上面的数据中请求量和访客量存在水分，因为请求量最大的那个网站仅它自己一天就是120万……比它后面1000个小伙伴加起来还多一倍。

作为对比，老版的WP-China-Yes节点（gravatar.wp-china-yes.net）目前每天请求量仍有250万之多，访客数量也有27万。具体的接入站点数量因为百度云加速不提供日志下载功能，所以无从统计（Cravatar的CDN由又拍云提供，所以可以访问到具体日志）。

目前总计一下，我们每天平均响应来自45万访客的430万次头像请求，每天消耗的流量大概在20G。

现阶段最大的挑战除了保障服务稳定性外还有就是如何让老版用户尽快升级到Cravatar，毕竟直接反代Gravatar还是有法律风险的，推Cravatar就是为了替换老节点以消除风险。

除了统计报告外，Cravatar过去一周也进行了一些改进。

之前很多人反映头像无法刷新，这个问题和又拍云的工程师对接了整整一个周，最后查出的结果是Cravatar的源站在返回头像时未返回文件最后修改时间，而又拍云在资源按URL规则刷新后会先给源站发送一个预请求，只有资源被更新过才会触发后续的资源拉取和正式刷新操作。该问题当前已修复。

Cravatar已支持返回头像提供者字段，这个功能主要是用于调试，当你使用Cravatar头像时可以在Header中发现一个名为avatar-from的字段，这个字段可能的值有三个：cravatar、gravatar、qq，其代表的意思就是当前头像是由谁提供的。

其次是所有默认头像的原始图片以及QQ头像的清晰度增加了四倍（100px->400px），当初设置为100px主要是考虑头像一般都是很小一只，100px足够了，结果后来有人反馈说自己的业务使用了高清大图输出，结果被糊了一脸……

最后，以Cravatar LOGO为主题的默认图参考Gravatar重新设计（因为CDN缓存的缘故，全国生效最长需要7天），如下：

翻译平台

过去一周原本是想把目前存量的翻译记忆库好好整理编辑一下的，结果发现这份工作实在是太枯燥了，磨蹭了两天也才搞了3000条左右，给我的感觉就好像要死了一样，实在是枯燥到难以附加的地步。而且我自己不愿意做，考虑到己所不欲勿施于人的原则，老李头和老赵头也同样抵触这份工作。

目前考虑可能在未来将以机器翻译为主，记忆库审核的工作后面考虑看看如果资金充裕的话外包出去给专人做吧，只有经过审核的通用性翻译才会被应用到机器翻译流程中。

翻译平台当前已经支持普通用户导入翻译（仅可导入状态为等待中的翻译）：

术语库已经就绪：

https://litepress.cn/translate/languages/zh-cn/default/glossary/

不过还需要在翻译平台的界面上为此开辟一个显眼的入口。

当前术语库是完全从wordpress.org搬的，为了适应litepress.cn的机翻引擎，本周会对其重新编辑。

记忆库的架构目前更改为使用MySQL存储，但数据同步到ES上用于索引。之所以这样改是因为ES作为一个NoSQL不支持复杂查询，所以对记忆库的编辑工作直接在ES上做的话真的是折磨死人，所以就在MySQL上存储以及编辑，最后同步到ES上来检索，这样集各家之所长。

翻译平台目前已经支持对译文自动格式化：对常用名词纠正大小写，比如说google纠正为Google，以及在中文中嵌入的英文和数字两次增加空格。

具体的格式化规范参考的是：

https://github.com/mzlogin/chinese-copywriting-guidelines/blob/Simplified/README.md

目前已经在整个仓库上应用了这套规范，同时译者提交翻译时也会自动触发格式化规则。

LitePress发行版

老赵头赶着七夕节发布了5.8.0.1 RC1，详细见：

https://litepress.cn/forums/topic/20211

本周计划

整理了下，目前翻译平台还有如下工作需要做：

• 记忆库编辑整理（暂时搁置，重启时间暂无计划，如果有人志愿帮忙的话可以开放编辑权限）
• 翻译自动打包与推送（新版LitePress API重构时做）
• 术语库编辑整理（本周计划）
• 机翻填充调优和测试（本周计划）
• 在用户主页开辟一个Tab用来显示他参与的翻译项目（本周计划）
• 第三方应用托管流程优化（本周计划）

以上本周计划的部分搞完，翻译平台应该就可以告一段落了。

#21396

[smile32 参与者]

我觉得术语表应该需要以这个为基础重新整理一下 https://wp-info.org/p/glossaries.csv 这里面条目比较全

#21398

[孙锡源 楼主坏蛋的博客]

我在WordPress.org的支持文档中翻到了这一篇官方建议的术语表列表：

https://wordpress.org/support/article/glossary/

按上面说的，术语表存在的意义在于让不了解WordPress的人能正确的使用 WordPress专有的术语 进行翻译，而不是对通用词汇提供翻译指北以实现类似《英汉词典》这种大而全的词汇对照。

而上面的文档中列出的也就是如前所述的“WordPress专有术语”。

wp-info.org上的术语表中存在很多类似“administrator”这种几乎只对应唯一翻译的词汇，以及类似“approval”这种在不同地方存在不同译文的词汇，这样的话我感觉整体范围太宽泛了，变成了前面说的《英汉词典》而有悖术语表的初衷。

如果是想通过术语表让翻译保持一致的话，我在想是不是也要提供一个翻译一致性检查工具，由这个工具来确保翻译一致，而不是通过术语表。

#21399

[smile32 参与者]

回复 @ 孙锡源：翻译一致性检查工具我觉得能做的话就做出来吧，可以对一些字词或句子的翻译进行查找还是很有必要的，方便参考，如果有些字词出现的频率比较高而又在术语表中找不到也可以用上

#21402

[孙锡源 楼主坏蛋的博客]

你如果感觉这个w.org的术语列表可以的话我开发一个自动同步工具，从w.org上抓取这个列表填充到翻译平台的术语表中，后面也随着w.org上的更新而增量更新

#21400

[smile32 参与者]

回复 @ 孙锡源：我是准备打算用 wp-info 把 wp.org 的术语表重新整理一遍的，然后按照情况去除掉一些条目，然后把以前术语表的一部分条目保留下来（仅限整理后的数与表不包含的条目，即整理之前手动添加上的条目）

#21401

[孙锡源 楼主坏蛋的博客]

回复 @ smile32：按道理讲术语表属于是技多不压身的东西，对于人类翻译的话条目理应是越多越好。

我前面表达的观点主要是从机器翻译填充和成本投入的角度出发的，因为举个例子，如果一个句子比如说10个单词，其中有3个都命中术语表被替换成代码的话谷歌就翻译不出来了。

同时，对于我们来讲，整理数据这种枯燥的工作只能是我自己做，毕竟己所不欲勿施于人。但是我的时间老实说也蛮紧张的，所以说没法在这上面投入太大精力。目前计划术语表整理的规模大概在200条，今天下午实践看，精校20条+收集整理资料的时间大概是一个小时，200条大概是两天全天的工作量，但是老实说这种枯燥的工作我很难满效率搞两天，所以总时间大概延长一倍。。

总结一下就是综合以下三个方面的考量，我现阶段希望建立一个较小的术语表：

1. 利于机器翻译
2. 较小的成本投入
3. 大而全的术语表似乎并非必要

其实对机器翻译的影响应该可以通过技术方案规避（比如说限制下机器只读取某些术语），最主要的问题还是成本投入。

如果你愿意整理的话我不介意白嫖一份（大笑。

当然我整理的你也可以导出使用。

#21403

[smile32 参与者]

我想了想：litepress.cn 的术语表是用于对机器翻译的错误词汇进行纠正的，所以应只需包含机器翻译会出错的术语，这样条目也不会太多，也顺便减少了你说的替换过多而无法翻译的情况，这样可能就需要对术语表进行适当的增减了。

#21409

[孙锡源 楼主坏蛋的博客]

现在这个阶段讲的话我觉得就是你说的这样。

更深层次阐述一下，这个和我本人一直奉行的发展策略有关。

我觉得我唯一成功的方式是通过一个优势点去撬动其他点，在不断的资源整合中变得强大。这个策略适用于我在做的几乎所有的事情。

往大的方面举例子，就好像我从12岁就开始自学编程，对计算机的了解和编程知识就是我作为一个社会底层人士在前期积累中的一个优势点。在日后的日子里我不断通过这个优势点去撬动其他资源，比如说老师们更愿意和我保持朋友关系，而不仅仅是上完课就走的塑料师生关系，原因就在于我有一技之长，虽然作为一个学生在地位上无法和他们相提并论，但是我可以和他们形成优势互补，他们自己做项目或者帮别人做项目或多或少都要咨询我。

往小的方面说，比如WP-China-Yes这个项目刚起步的时候，很多人说“我们早就想到了，只是碍于成本没做”。但是我一直在说的是只要有用户使用，我就可以靠用户资源这个优势点去拉动赞助来填平成本，我觉得日后的事实证明我是对的。

整个逻辑就好像是手摇式拖拉机的启动过程，单凭发动机自己虽然力量存在，但是找不到做功的着力点（类比一下，就好像现实世界中我的老师这一力量存在，赞助我的商家这一力量也是现实存在的，他们只是对我或我在做的事来讲找不到或者说不想找到做工的着力点），而我要做的就是去用摇把摇一下（创造优势点），给发动机一个初始的力，有了这个初始的力后发动机的各个机件就会不断的加入到工作循环，直到所有机件都被带动起来之后，甚至我不摇它它也会凭借发动机做工而运转下去。

前面还只是拿我个人发展举例子，如果代入WordPress生态发展上来讲：

我觉得WordPress生态是根上烂了，也就是我在发展计划里说的是，强制GPL及不支持国内的小程序体系。前者阻碍生态原始积累，后者把WP锁死在PC端。

所以说做这件事第一步就是刮骨疗毒重新打一套新的地基（新的LitePress发行版与liitepress.cn），之后也就是融入我前面讲的通过优势点不断整合资源的思想。

比如通过China Yes的存量用户与开发者交换流量的方式要求开发者入驻，越多的开发者入驻后筹码和能力就会越大。

再比如通过完善的翻译和其他优势以及适当的引导，撬动用户主动参与翻译过程。这就是咱们本次讨论的话题，我觉得通过机器翻译填充起来的100%汉化的仓库或许是打出与w.org差异以撬动用户在新体系下贡献翻译的点，我需要做的就是集中力量加大这一优势点，以让更多人参与进来，由大家一起完善资源，而不是尽善尽美地都自己去做，这样老实说也不大现实，就好像我作为一个穷人不可能仅凭自己完成所有积累然后实现最终理想。

通过以优势点不断撬动资源的方式，在不久的将来，很大一部分的开发者、译者、普通用户将会参与到这个新体系中，待到时局一变（w.org被墙或再来一次429），届时就是彻底实现整个计划的时刻了。

之后目标就会从内部统一转换为向外扩张，理想状态下WordPress将渗透入中小企业应用场景的方方面面，而不止于建站系统。

改变世界或许太远了，先从改变行业开始吧！

#21412

[孙锡源 楼主坏蛋的博客]

刚整理术语表的时候突然想起来，中文翻译的时候是不是可以忽略掉单复数了。这样术语表里只记录单数，然后程序匹配的时候单数和复数都去匹配这条术语？不知道这样会不会产生一些翻译错误。

#21413