2021年7月第四周周报

[孙锡源]

上周大量时间花费在增加Cravatar的稳定性，以及项目宣传的工作上。开发工作占用的时间比例有所减少。

简要介绍一下上周的具体开发进度：

一、我们完成了翻译记忆库从Pontoon到Elasticsearch的迁移工作，目前正在重新跑爬虫。这里得吐槽下因为Elasticsearch官方总是引入破坏性的更改，导致网上的第三方文档几乎没法看，只能多方参照才勉强完成了开发工作。

二、应用市场已经支持了按翻译后的中文进行产品检索，同时得益于Elasticsearch的特性，我们可以同时使用标题、简介及详情进行搜素，同时可以为三者分配不同的权重。至此翻译平台与应用市场的联动工作应该已经全部完成了，未来我们就可以基于此提供一个100%纯中文的WP应用市场，同时支持类似百度搜索这样的中文语义化搜索。

三、用于在线更新LitePress测试版版本的插件已经上线：https://litepress.cn/plugins/lp-plugins/litepress-beta

本周计划

目前翻译平台还差机器翻译填充，这个特性好像是从大上个周就开始尝试排期，结果一直也没实际安排出时间搞。本周希望可以了结这个需求。

同时发现翻译平台还缺词汇表，以及类似WordPress的插件目录这样的源代码浏览工具，方便译者定位上下文语境：https://plugins.trac.wordpress.org/

另外就是完成wp-china.org上的翻译平台到litepress.cn的迁移工作了，在翻译平台迁移后wp-china.org域名会被直接301。

本周将注重解决以上四个问题，如果有余力的话会回到应用市场的开发工作。

#21160

[smile32]

这个源代码是不是在建立项目的时候填写了原文件URL就可以实现了？

#21161

[孙锡源]

差不多就是你说的这样。

不过现在问题是原文件的URL从哪搞？所以，我们主要需要解决的就是建立一个类似https://plugins.trac.wordpress.org/这样的本地化平台，可以浏览WordPress.org的SVN上托管的所有源码。

#21163

[smile32]

词汇表可以从 WordPress.org 导入，正好可以提供一下意见，到时候改动一下。另外如果机器翻译填充插件能读取词汇表中的条目并套用就差不多完美了。

#21162

[孙锡源]

词汇表是打算从wordpress.org导的，不过昨天的尝试中发现导出的csv文件因为某种原因无法导入，这个问题待查。

机器翻译读取词汇表在技术上是没问题的，但是在钱上有问题……因为术语库（也就是咱们说的词汇表）是谷歌付费翻译才支持的特性，如果调用谷歌付费翻译的话全翻译一遍差不多要大几千美刀。

#21164

[smile32]

回复 @ 孙锡源：从记忆库读取翻译并填充应该是在机器翻译的之前进行的，如果存在词汇表的话这里再加一道批量替换词汇的流程不知道是否可行？

#21167

[孙锡源]

回复 @ smile32：这个在我目前的认知范围里是不可行的。

比如说：

You are a handsome boy

机器翻译/记忆库匹配出的结果是：

你是个英俊的男孩

词汇表中的记录：

handsome => 帅气

这个时候词汇表的匹配要如何进行？

如果我们对原文匹配的话，那么原文就成了：

You are a 帅气 boy

这个时候我们就无法拿这个原文去匹配记忆库或者是进行机器翻译了。

而如果我们对译文匹配的话，因为译文中缺失了英文单词与译文语句的对照关系，所以无法获取handsome这个单词在译文中对应的是哪一个词汇，也就无法进行替换了。

这个替换的过程只能在谷歌的AI引擎中进行。

 

#21168

[孙锡源]

回复 @ smile32：想了想，有一种方案是可以实现使用词汇表替换的。

但比较局限，只能是类似plugin、theme这样的名词。

比如说以下句子：

This is a great plugin, I recommend everyone to install it

译文：

这是一个非常棒的插入，我推荐大家安装它

---

我们可以在原文提交翻译前对原文进行如下替换：

This is a great <code>#007</code>, I recommend everyone to install it

其中#007是自动生成的一个编号，用来标记这个待匹配术语表的单词将来在译文中的位置，而code标签则是为了防止谷歌对其翻译。

机器翻译后：

这是一个非常棒的<code>#007</code>，我推荐大家安装它

现在我们就可以使用根据使用术语表中plugin对应的译文来替换整个<code>#007</code>了

处理后的译文：

这是一个非常棒的插件，我推荐大家安装它

---

这个方案理论上是可行的，但是对术语表要求比较严格，因为只能包含词性为名词的词汇。如果替换了动词、形容词，则可能会破坏语义。

#21176

[smile32]

回复 @ 孙锡源：这个方案不错，顺便也可以对词汇表进行修正、完善。

#21180

[孙锡源]

另外问一下，你的头像是自己删了还是遇到BUG了？

#21165

[smile32]

回复 @ 孙锡源：我更新了邮箱地址，这个邮箱地址是注册了Gravatar的

#21166

[孙锡源]

词汇表无法导入的原因是wordpress.org上简体中文的代号是zh-cn，而litepress.cn上是zh，语言代码对不上。手工编辑一下csv文件可以了

#21262

[smile32]

回复 @ 孙锡源：建立项目的时候不是应该选择zh-CN吗？

#21264

[孙锡源]

回复 @ smile32：是的，后来发现是我傻逼了，应该是zh-cn的，要不然将来想扩展成兼容一些港澳的翻译都很难，所以在系统里改了。

#21265

[smile32]

另外我发现翻译平台使用的 glotpress 3.0.0-alpha.2版本是缺少一部分翻译的，应该考虑切换版本或者是补充翻译。

#21266

[孙锡源]

GlotPress的翻译昨天已经处理了，目前翻译率100%。

另外，我发现wordpress.org上的存量翻译似乎质量堪忧。

这里是翻译待审核列表：https://litepress.cn/trans-waiting-list

可以发现机器检查出了超过800个存在翻译警告的项目（大多数是因为缺或多了html标签、标点符号对不上、缺或多了换行符）。

而且还有大量的繁体和copy的英文原文，在考虑要不要对这些翻译统一删除。

#21267

[smile32]

回复 @ 孙锡源：插件 Readme 的更新日志部分优先级为 low，一般是不翻译的

#21268

[孙锡源]

回复 @ smile32：如果是统一使用机器翻译预填充的话应该就可以不用管优先级了吧。谷歌翻译目前翻译长段文本基本可靠，也就是说readme部分差不多可以完全依赖谷歌翻译，只是插件主体部分需要人工校准调整。

我今天稍晚的时候出机器翻译填充的测试版，允许托管第三方插件、主体测试。到时候看看具体效果。先测试一段时间机器填充稳定后再应用到整个仓库上。

#21269

[smile32]

回复 @ 孙锡源：我觉得插件的更新日志翻译校准不好把握，因为更新日志字符串非常的多，而且也没有多少人会去把插件更新日志都全部浏览一遍，还有一些插件会在版本升级之后把上一版本的更新日志移到其他地方去了，这样相当于之前的翻译又失效了。

比如说这个插件

https://litepress.cn/plugins/jetpack

#21271

[孙锡源]

回复 @ smile32：更新日志那个照这么说的话可以直接在机器翻译填充阶段就全调用英文原文填充上了？然后记忆库入库那里我过滤一下，纯英文的不再录入记忆库

话说你觉得允许第三方托管的话项目是直接把他们的项目放到现有的插件、主题父目录下， 还有单独建一个“第三方”父目录来统一存放？

是不是还要给每个用户的会员中心加一个他所管理的/创建的翻译项目列表。又或者是给翻译项目加一个收藏功能，收藏后这个项目就出现在他会员中心的列表里，方便将来进入。

#21272

[smile32]

回复 @ 孙锡源：我觉得，如果不麻烦的话还是为第三方的插件或主题建立一个单独的目录进行分类比较好，当然这只是我自己的想法。另外如果技术上可行的话，这个页面应该需要扩展/修改一下，因为默认只会显示最近参与和校对的项目，应该在此基础上增加两个页面，分别显示自己收藏、编辑的项目，请求建立新项目的用户自己就是编辑者，另外这些页面要支持分页。

#21274

[smile32]

收藏功能对于指贡献翻译而没有编辑权限的用户是很有用的，他们可以把自己经常参与的项目收藏起来，另外考虑到有些用户参与翻译之后忘记收藏项目，我前面说的第1个页面应该保留。

#21275

[孙锡源]

这样在会员资料卡片上开个tab，展示一下翻译相关的工作情况，应该不错吧？

然后我在想，这个收藏功能是否有必要。因为只要他参与了项目的翻译，这个项目就会出现在上述的列表中（只要参与了即可，无需有编辑权限），而如果他只是使用的话，那么理论上他可以通过china yes插件或者litepress发行版自动收到翻译推送，他也无需通过收藏的方式关注项目的翻译进度。

#21278

[smile32]

回复 @ 孙锡源：可以的。
这样的话我觉得收藏功能也可以先不考虑，看看之后的参与情况如何在说。

#21281

[孙锡源]

另外昨天说的第三方托管开放测试的事情要鸽了，实际测试看因为记忆库的词条整理工作还没做，匹配出的翻译质量相当的低。见：https://litepress.cn/translate/projects/others/codestar-framework/body/zh-cn/default/

#21279