2021年9月第一周周报

论坛首页 论坛 项目发展 2021年9月第一周周报

标签: 

正在查看 0 条回复
  • 作者
    帖子
    • #21560
      孙锡源
      管理员
        @ibadboy
        楼主
        坏蛋的博客
        ibadboy.net

        上周主要完成了以下开发工作

        1、Cravatar 已经支持自动头像审核

        之前是打算完全人工审核的,结果图片的规模超出预期了……目前的总数大概在10万规模,人工审核已经不现实了。所以对接了腾讯云的数据万象服务,两天时间筛出来21张违规图,里面有漏半个屁股的,也有手指遮三点的,还有用毛爷爷当头像的……目前是违规图自动审核自动拦截,一张图在第一次请求的时候会触发异步审核,如果存在违规的话10分钟内就会返回违禁提示了:

        2、ICP 备案工作已经全部完成

        目前两个域名的 ICP 备案已经都切换到了企业主体上,公安备案暂时不打算做了,经营性备案目前正在办理中。

        3、第三方项目入驻流程进一步优化

        目前项目管理员可以直接上传插件、主题安装包到后端,平台会自动从中提取语言包。同时导入原文时也支持了设置版本号

        4、翻译平台翻译导入逻辑优化

        之前导入翻译的时候是会覆盖老翻译的,这个特性十分讨厌,目前已经更正为只增量更新,以及覆盖等待中、警告和模糊的翻译。

        5、翻译平台已支持从 wordpress.org 增量同步翻译

        也就是说,从今以后 wordpress.org 有的 litepress.cn 有,wordpress.org 没有的 litepress.cn 也有。litepress.cn 将等于是 wordpress.org 的超集。

        6、翻译平台支持用户主动从 wordpress.org 同步翻译

        这个特性主要是防止爬虫自动更新不及时的情况,这样用户可以手动使翻译的原文一直保持在最新。

        文档模块布局的新思考

        今天和 WordPress 大学的站长倡萌讨论了一上午,对目前文档平台的规划做了相当多的补充。

        简要概述一下,就是文档平台总体上是分三个模块来做。

        其一是目前规划中的对 WordPress 官方文档的翻译,作为补充的是对类似 Woo 和 BBpress 这类常用插件的官方文档也纳入翻译的范畴,而底层的翻译逻辑依然是按这篇文档介绍的来:https://litepress.cn/forums/topic/20156

        其二是增加一个使用类教程聚合模块,提供一批预设分类,站长可以投递自己的文章,之后平台就能提供一个文章的索引目录,用户浏览文章会被导入到站长自己的网站中。

        其三是为开发教程的作者提供一个付费的系列教程发布平台。

        这里只是对新的文档平台简要概述,至于为什么这样规划,以及这样规划所产生的意义,详细谈的话可以单独成一篇文章了,而且目前其实想法还不太成熟,后续思考的全面了会专门出一篇文章阐述。

        本周计划

        今天上午的谈话确定了一个基本的原则,就是翻译平台在短期内重要性是大过应用市场的,应该先集中精力将其完善好。虽然最终的决定是一致的,但是给出这个决定的观点是存在分歧的。

        在我的想法中之所以翻译平台短期内重要是因为我觉得国内 wp 社区和应用市场做不起来的原因是他们缺少所谓的“底蕴”以及没有自己的积累和体系,就只是一个商城或者社区论坛而已,用户和开发者为什么要选择?这个和立一个牌坊就期望用户蜂拥而至是一样的。所以在设想中应该厚积而薄发,先由外围设施入手,这些将作为铺垫,不断的培养用户和开发者对这一系列平台的使用习惯,以及接受和认可度,比如 Cravatar 就是第一个尝试,而翻译平台将很快是第二个。这些最终都是围绕着去推应用市场而进行的,因为我认为基于应用市场的用户换量计划是这个项目能铺开的唯一手段,这一点刚好和倡萌的想法冲突了。倡萌的想法是应用市场暂时不重要,阻碍生态发展的主要因素在于翻译缺失,所以翻译平台是很重要的,而项目的铺开则应该依靠内容积累,这一块也就是通过前面提到的文档平台来实现,应该着力于翻译平台和文档平台的建设和发展,通过不断产出内容来增加活跃度和用户基数。

        也就是说,虽然我们都认可翻译平台优先级高于应用市场,但是一方的观点是应用市场很重要,但想要成功就必须先做好外围,另一方的观点是应用市场在一段时间内在整个规划中起不到实质作用,所以不重要,理所当然的优先级要靠后。

        虽然核心出发点不同,但是在短期内的规划路线却是一致的,那么按这个路线先执行,在执行过程中再逐渐磨合底层的观点,应该是可行的。

        上周关于机器翻译填充的谷歌翻译封锁 ip 的问题,探索出了一个解决方案,就是模拟 Google 网页翻译的机制,生成一个 token 字符串,这样就可以破解限制了,实际测试一分钟请求 500 次也没被封。另外就是群友给提了一个方案:可以把多个原文合并到一个请求中提交翻译,进一步加大效率以及减少请求数。这个方案技术论证过也是可行的。此外倡萌给关于自动调用记忆库中的建议来填充翻译的想法提了一个补充方案,就是可以通过判断某一译文被采纳的频率来判断这个译文是否是准确译文,这样就可以取代掉之前规划的人工编辑了,一下让这个方案可以尽快实施了。

        不过机器翻译在上周实在没时间搞了,又得拖一个周到本周解决这个问题。

        除了前面叙述的机器翻译相关的内容外,还规划基于 Loco Translate 二开一个翻译插件,对接 litepress.cn 平台,这样可以实时翻译实时预览。再加上可以共享 litepresss.cn 的翻译记忆库以及机器翻译填充,可以算是一个加强版的 poedit pro 了。

    正在查看 0 条回复
    • 哎呀,回复话题必需登录。