- 该话题包含 22个回复，4 人参与，最后由
更新于 1年、 10月前 。
-
帖子
-
-
LitePress翻译平台一共迭代了两次，第一次也就是https://wp-china.org上的协同翻译平台，那时老实说我在WordPress方面的开发经验并不足，所以做了很多破坏性更改（未使用钩子直接修改第三方软件包源码），因而一定程度上埋下了一些隐患，并使其变为了“孤版”。
第二期是LitePress.cn开发阶段，对翻译平台的UI进行了优化，当时并未改进任何功能。
最近因为应用市场除插件端外的开发以及平台性能优化的工作差不多告一段落，所以翻译平台的迁移工作提上了日程，但经过一年的运营发现整体架构方案还是有很多不足，于是索性趁着迁移的功夫对其进行一次重构：
- 因为我们开发了本地化的api.wordpress.org的缘故，所以现在有能力彻底解决“无Tag插件包被缓存”的问题，同时也有能力及时监控插件、主题包的更新，于是在第三期的翻译平台中，其待翻译插件、主题包的发现和推送服务将由之前的一个用Python写成的独立脚本迁移到一个与api.litepress.cn的爬虫服务联动的WordPress插件上。
- 翻译平台将支持对插件和主题的描述信息进行翻译
- 消息队列服务由HTQ迁移到由WP-Cli定时触发的WordPress Corn服务上，当初选择HTQ主要原因是WordPress Corn的触发很不稳定，经常有漏掉任务的情况
- 翻译平台将支持按使用人数对项目排序，这样可以集中精力到少数使用人数较多的项目上
- 翻译平台增加积分机制以及贡献者铭牌标识
- 翻译平台将对未来的文档翻译提供预支持
得益于以往的积累，技术方案差不多已经成熟了，只需要按部就班的开发，所以整体工作预计可以在5个工作日内完成，可以在这个GitHub看板关注我们的进度：https://github.com/litepress/litepress.cn/projects/2
-
去年5月份就说要为https://github.com/wearerequired/traduttore项目（一个自动从Git仓库提取翻译到GlotPress的开源项目）添加对Gitea的支持，结果拖到现在，哈哈哈。当时其实我已经开发好了，只是太懒得写单元测试，没提交合并请求，这次一起搞下吧！
-
突然发现我宛如一个智障。
之前翻译平台的翻译提取流程是这样的：
包更新检测服务检测包更新情况->存在更新则下载并解析其是否是英文以及是否支持多语言->是英文且多语言则推送给自建git->自建git接受到push请求后发送web hook给Traduttore插件提供的API接口->Traduttore插件从git拉取程序代码并提取翻译->检查translate.wordpress.org是否存在翻译，存在则导入记忆库->调用机器翻译流程
以上流程完全可以简化为：
包更新检测服务检测包更新情况->存在更新则直接去translate.wordpress.org下载翻译好的po文件，不存在就说明是不支持多语言，然后原文入库，已翻译的部分入记忆库->调用机器翻译流程
世界刹那间清净了
-
emmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm 牛
-
-
因为一些事情，自建Gravatar头像托管的优先级被提到了所有工作之前，所以翻译平台的开发暂时封存。
以下的目前收集的关于翻译平台一些有用信息：
使用Cavalcade项目增强WordPress的Cron：https://github.com/humanmade/Cavalcade
-
加油加油，同时注意劳逸结合👏
-
-
是我没表述清楚。
机翻引擎启动之后会自动在翻译时去记忆库中尝试匹配原文，如果100%匹配上的话就直接调用记忆库结果并设置为“已通过”，只有记忆库匹配不上的才会由机器翻译并被标记为“模糊的”。
所以，从wordpress.org上采集的翻译直接把原文和翻译结果分别入库，这样机器翻译的时候会自动做正确处理。
最近一年的实际观察结果来看，通常一个项目大概有30%的字符串可以直接匹配上翻译记忆库。
-
另外，详细说一下，之所以不在采集时就把已翻译字符串直接标记，是因为记忆库是全局生效的，也就是说A项目不止会匹配来自w.org的A项目的翻译，还会匹配到B项目、C项目的翻译。为了程序架构设计上的“解耦”，所以就把翻译匹配的工作统一放到机翻引擎里，而采集程序则只负责数据录入工作。
-
-
-
你说这个我想起来，这个记忆库还存在不足。
目前是不可能出现匹配到1个以上100%的翻译的情况的，记忆库在入库时会进行数据去重，具体逻辑是：
所有字符串转小写->去除首位两端空格->生成md5校验码->入库（数据库中以md5值为唯一主键，出现冲突的情况会直接替换现有值）。
所以每个原文（包括仅大小写不同的）都只会记录一次以及其唯一的翻译结果。
但，看你刚提出的这个疑问，我想起来：比如说
post这个词，有的插件翻译为帖子，有的翻译为提交，这种情况下记忆库就会出问题，还是应该把这种有多个结果的词标记为“模糊”而不是“已通过”。这个问题我列到第三期开发计划里处理一下。
-
似乎还存在一个情况：在长句子中，因为译者习惯不同而产生不同的翻译。
似乎应该限制一下这个“存在多个翻译结果则标记为模糊”的功能只对两个及以下单词的条目生效。
-
-
在 WordPress.org 上翻译主题的时候这个问题就特别的明显了：例如“It looks like nothing was found at this location. Maybe try the search below?”这类的句子就会出现至少两个 100% 的结果
-
限制只对两个及以下单词的条目生效似乎可解决这个问题。因为在长句子中存在上下文，很难会出现某个单词释义不同的情况。
-
想了想，刚说的那个规则会只对机翻引擎生效。给译者展现的翻译建议依然会同时显示多个结果，因为对于人工翻译来说，我觉得翻译建议更多是一种参考，有更多的翻译结果就可以提供更多的对比的机会。就好像我个人看技术文档习惯把官方文档结合第三方博客的放在一起看，互相对照。
-
-
所以我觉得出现这样的情况标记为模糊比较好，但是也要尽量减少这种情况的发生，比如说主题的很多字符串都是重复使用的，所以不需要二次翻译，就可以直接套用翻译记忆库中的建议，而如果有个别译者不习惯看翻译记忆库或者直接导入了其他来源的译文就会出现两个甚至更多的译文，到这里又有一个新问题了：这样是否要对翻译记忆库进行编辑以保留一组质量最好的翻译？
-
对记忆库编辑应该可行手：工指定下机翻的时候优先选择哪个词条，同时也可以将太离谱的直接删掉。
-
对记忆库人为编辑还是很重要的，今天偶然间发现记忆库里甚至还有繁体……后面可以在数据库里筛选出所有包含多条翻译的记忆内容，然后指定机器翻译时固定调用哪条的同时删除掉不合适的翻译结果。
-
-
-
术语表可以有，对于不是计算机专业的普通用户来讲，很多计算机专业词汇的翻译和日常用语不一样，还是需要有术语表纠正的。
比如Cookie、Bug日常翻译为饼干和虫，但计算机中一般直接引用英文。再比如Memory日常翻译为记忆，但计算机中通常为内存。
如果有术语表的话，就能让这些普通用户更方便的参与翻译贡献了。
-
-
我的想法是：因为有很多主题的大部分字符串都是通用的，应该在翻译过程中把这些字符串一点一点的整理积累起来到一个 po 文件中，到时候有新的主题要翻译就可以先把它们导进去，GlotPress 会忽略掉在该主题中不存在的字符串，然后为了确保翻译准确性，导入的字符串应该先设为 Waiting，然后手动批准。
-
这个逻辑，好像就是目前的翻译记忆库机制吧——机器翻译时先检查记忆库中是否存在已翻译过的语句，存在则调用并标记已通过，当然其中的逻辑还包括昨晚讨论的对存在多个译文的情况的处理，这里先对此不赘述。
总之，对需求拆解归类下，你说的这个似乎就是翻译记忆库吧？术语表我觉得应该是颗粒度为单词或词组的一个对照表，而不应该是整条句子。
-
新翻译平台的爬虫数据抓取工作完全完成了，统计了一下：
- 共460万原词条
- 共235万唯一原文
- 共36万已翻译词条
- 共13万唯一翻译
以上统计信息得出来的结论：
- 目前总的已翻译率为7.8%
- 目前原文重复率为48%
- 目前中文翻译的重复率为63%
类似你说的这种整理一个po文件，每个项目导一遍这种预填充的方式可以节省这48%的工作量。不过13万条已翻译语句导入的话估计直接就504超时了。
-
-
- 哎呀，回复话题必需登录。