参与者列表 Search 感谢 2020 ~ 2023.4 所有关注过 LitePress 的用户 此版已存档，详情参见 《推广名单》 《“ 参与者列表” 》 有 2,005 条评论 文派叶子 🍃 2021.07.06 WP-China-Yes 的头像替换函数存在以下 BUG： 可能由于其他插件、主题已经接管头像的原因导致无法替换 有的插件、主题使用 get_gravatar_url() 函数自行拼接头像，这种情况下无法替换 为此我已经更了一个小版本修复此问题，见附件。 或者直接把以下函数加入主题的 functiongs.php 里： if ( ! function_exists( 'wcy_get_avatar_url' ) ) { /** * 替换 Gravatar 头像的访问域名 * * @param string $url * * @return string */ function wcy_get_avatar_url( $url ) { return preg_replace( '/(([w|-]+.)+)?[w|-]+.w+/', 'gravatar.wp-china-yes.net', $url ); } } add_filter( 'um_user_avatar_url_filter', 'wcy_get_avatar_url', 9999 ); add_filter( 'bp_gravatar_url', 'wcy_get_avatar_url', 9999 ); add_filter( 'get_avatar_url', 'wcy_get_avatar_url', 9999 ); suiyilight 2021.07.06 非常感谢您的帮助，因为我曾经对页面的父页面进行修改，所以完全禁用确实会导致网站出现 404，我在您提供的资料中发现了 strict_redirect_guess_404_permalink add_filter( 'strict_redirect_guess_404_permalink', '__return_true' ); 将其设置为完全匹配更符合我的想法，不会出现驴唇不对马嘴的猜想，并且在修改父页面时也可进行跳转 最后再次感谢您的帮助 suiyilight 2021.07.05 我问下有多个相同开头的，跳转到哪个页面是怎么确定的 可以人为干涉吗 suiyilight 2021.07.05 就是比如输入/l 会跳转到/link 因为现在网站上别名 l 开头的很多，能不能禁用掉，返回 404 文派叶子 🍃 2021.07.05 指的是哪里的自动补全？这句话没主语，着实不知道指的啥 文派叶子 🍃 2021.07.05 没太看明白你的意思 sexloli 2021.07.05 感谢解答 文派叶子 🍃 2021.07.05 把上图中的重定向域名改为重定向路径即可 5323 2021.07.05 谢谢回复，在请教下 如果反过来呢~ litepress.cn/plugins 自动跳转到 plugins.itepress.cn 访问 谢谢~ 文派叶子 🍃 2021.07.05 以宝塔面板为例： 文派叶子 🍃 2021.07.05 WordPress 的路由机制决定了你不可能通过 Nginx 的 URL 重写来实现这个目的 （WordPress 会获取重写前的路径并与自身的固定链接规则尝试匹配，所以无论你如何重写 URL，WordPress 获取的都是你重写前的地址） 。在 WEB 层唯一能实现的可能是通过在反代时设置回源规则。 所以现在这个问题有两套方案： 通过更改 WordPress 与站点地图相关的固定连接规则并增加对站点 URL 输出时的过滤机制来实现更改站点地图路径的目的 通过使用第三方插件的站点地图功能实现更改地图路径的目的 方案一我翻了一下 WordPress 源码，想实现很复杂，不是几行代码就能搞定的，所以没有再深入研究。 方案二可以参考这些插件：https://litepress.cn/plugins/google-sitemap-generator 文派叶子 🍃 2021.07.05 这个逻辑，好像就是目前的翻译记忆库机制吧——机器翻译时先检查记忆库中是否存在已翻译过的语句，存在则调用并标记已通过，当然其中的逻辑还包括昨晚讨论的对存在多个译文的情况的处理，这里先对此不赘述。 总之，对需求拆解归类下，你说的这个似乎就是翻译记忆库吧？术语表我觉得应该是颗粒度为单词或词组的一个对照表，而不应该是整条句子。 smile 2021.07.05 我的想法是：因为有很多主题的大部分字符串都是通用的，应该在翻译过程中把这些字符串一点一点的整理积累起来到一个 po 文件中，到时候有新的主题要翻译就可以先把它们导进去，GlotPress 会忽略掉在该主题中不存在的字符串，然后为了确保翻译准确性，导入的字符串应该先设为 Waiting，然后手动批准。 文派叶子 🍃 2021.07.05 术语表可以有，对于不是计算机专业的普通用户来讲，很多计算机专业词汇的翻译和日常用语不一样，还是需要有术语表纠正的。 比如 Cookie 、 Bug 日常翻译为饼干和虫，但计算机中一般直接引用英文。再比如 Memory 日常翻译为记忆，但计算机中通常为内存。 如果有术语表的话，就能让这些普通用户更方便的参与翻译贡献了。 smile 2021.07.05 我目前有打算整理一份主题的术语表，到时候要翻译哪个主题直接导入可以节省不少时间 文派叶子 🍃 2021.07.04 对记忆库编辑应该可行手：工指定下机翻的时候优先选择哪个词条，同时也可以将太离谱的直接删掉。 smile 2021.07.04 所以我觉得出现这样的情况标记为模糊比较好，但是也要尽量减少这种情况的发生，比如说主题的很多字符串都是重复使用的，所以不需要二次翻译，就可以直接套用翻译记忆库中的建议，而如果有个别译者不习惯看翻译记忆库或者直接导入了其他来源的译文就会出现两个甚至更多的译文，到这里又有一个新问题了：这样是否要对翻译记忆库进行编辑以保留一组质量最好的翻译？ 文派叶子 🍃 2021.07.04 想了想，刚说的那个规则会只对机翻引擎生效。给译者展现的翻译建议依然会同时显示多个结果，因为对于人工翻译来说，我觉得翻译建议更多是一种参考，有更多的翻译结果就可以提供更多的对比的机会。就好像我个人看技术文档习惯把官方文档结合第三方博客的放在一起看，互相对照。 文派叶子 🍃 2021.07.04 限制只对两个及以下单词的条目生效似乎可解决这个问题。因为在长句子中存在上下文，很难会出现某个单词释义不同的情况。 smile 2021.07.04 在 WordPress.org 上翻译主题的时候这个问题就特别的明显了：例如 「It looks like nothing was found at this location. Maybe try the search below?」 这类的句子就会出现至少两个 100% 的结果 文派叶子 🍃 2021.07.04 似乎还存在一个情况：在长句子中，因为译者习惯不同而产生不同的翻译。 似乎应该限制一下这个 「存在多个翻译结果则标记为模糊」 的功能只对两个及以下单词的条目生效。 文派叶子 🍃 2021.07.04 你说这个我想起来，这个记忆库还存在不足。 目前是不可能出现匹配到 1 个以上 100% 的翻译的情况的，记忆库在入库时会进行数据去重，具体逻辑是： 所有字符串转小写-> 去除首位两端空格-> 生成 md5 校验码-> 入库 （数据库中以 md5 值为唯一主键，出现冲突的情况会直接替换现有值） 。 所以每个原文 （包括仅大小写不同的） 都只会记录一次以及其唯一的翻译结果。 但，看你刚提出的这个疑问，我想起来：比如说 post 这个词，有的插件翻译为帖子，有的翻译为提交，这种情况下记忆库就会出问题，还是应该把这种有多个结果的词标记为 「模糊」 而不是 「已通过」 。 这个问题我列到第三期开发计划里处理一下。 smile 2021.07.04 如果在记忆库中找到一个以上 100% 的翻译该如何处理？是标记为模糊吗？ 文派叶子 🍃 2021.07.04 另外，详细说一下，之所以不在采集时就把已翻译字符串直接标记，是因为记忆库是全局生效的，也就是说 A 项目不止会匹配来自 w.org 的 A 项目的翻译，还会匹配到 B 项目、 C 项目的翻译。为了程序架构设计上的 「解耦」，所以就把翻译匹配的工作统一放到机翻引擎里，而采集程序则只负责数据录入工作。 文派叶子 🍃 2021.07.04 是我没表述清楚。 机翻引擎启动之后会自动在翻译时去记忆库中尝试匹配原文，如果 100% 匹配上的话就直接调用记忆库结果并设置为 「已通过」，只有记忆库匹配不上的才会由机器翻译并被标记为 「模糊的」 。 所以，从 wordpress.org 上采集的翻译直接把原文和翻译结果分别入库，这样机器翻译的时候会自动做正确处理。 最近一年的实际观察结果来看，通常一个项目大概有 30% 的字符串可以直接匹配上翻译记忆库。 smile 2021.07.04 已翻译的部分入记忆库 已翻译的部分不应该是直接添加并批准吗？难道还要手动叫准一遍？ linn 2021.07.04 发网址地址看看 yunqikan 2021.07.04 报错如下 文派叶子 🍃 2021.07.03 总结一下就是 Cavalcade 为 WordPress 添加了真正的任务队列支持，类似于 Laravel 的 Horizon 。之后就可以放心的使用 WordPress 的 Cron 运行大批量的计划任务了，并且可及时触发。 sexloli 2021.07.03 厉害了，直接触及到我的知识盲区 ←较旧评论 1 … 16 17 18 19 20 … 67 较新评论→
《“ 参与者列表” 》 有 2,005 条评论
WP-China-Yes 的头像替换函数存在以下 BUG：
为此我已经更了一个小版本修复此问题，见附件。
或者直接把以下函数加入主题的 functiongs.php 里：
if ( ! function_exists( 'wcy_get_avatar_url' ) ) { /** * 替换 Gravatar 头像的访问域名 * * @param string $url * * @return string */ function wcy_get_avatar_url( $url ) { return preg_replace( '/(([w|-]+.)+)?[w|-]+.w+/', 'gravatar.wp-china-yes.net', $url ); } } add_filter( 'um_user_avatar_url_filter', 'wcy_get_avatar_url', 9999 ); add_filter( 'bp_gravatar_url', 'wcy_get_avatar_url', 9999 ); add_filter( 'get_avatar_url', 'wcy_get_avatar_url', 9999 );非常感谢您的帮助，因为我曾经对页面的父页面进行修改，所以完全禁用确实会导致网站出现 404，我在您提供的资料中发现了 strict_redirect_guess_404_permalink
将其设置为完全匹配更符合我的想法，不会出现驴唇不对马嘴的猜想，并且在修改父页面时也可进行跳转
最后再次感谢您的帮助
我问下有多个相同开头的，跳转到哪个页面是怎么确定的
可以人为干涉吗
就是比如输入/l 会跳转到/link
因为现在网站上别名 l 开头的很多，能不能禁用掉，返回 404
指的是哪里的自动补全？这句话没主语，着实不知道指的啥
没太看明白你的意思
感谢解答
把上图中的重定向域名改为重定向路径即可
谢谢回复，在请教下 如果反过来呢~
litepress.cn/plugins 自动跳转到 plugins.itepress.cn 访问
谢谢~
以宝塔面板为例：
WordPress 的路由机制决定了你不可能通过 Nginx 的 URL 重写来实现这个目的 （WordPress 会获取重写前的路径并与自身的固定链接规则尝试匹配，所以无论你如何重写 URL，WordPress 获取的都是你重写前的地址） 。在 WEB 层唯一能实现的可能是通过在反代时设置回源规则。
所以现在这个问题有两套方案：
方案一我翻了一下 WordPress 源码，想实现很复杂，不是几行代码就能搞定的，所以没有再深入研究。
方案二可以参考这些插件：https://litepress.cn/plugins/google-sitemap-generator
这个逻辑，好像就是目前的翻译记忆库机制吧——机器翻译时先检查记忆库中是否存在已翻译过的语句，存在则调用并标记已通过，当然其中的逻辑还包括昨晚讨论的对存在多个译文的情况的处理，这里先对此不赘述。
总之，对需求拆解归类下，你说的这个似乎就是翻译记忆库吧？术语表我觉得应该是颗粒度为单词或词组的一个对照表，而不应该是整条句子。
我的想法是：因为有很多主题的大部分字符串都是通用的，应该在翻译过程中把这些字符串一点一点的整理积累起来到一个 po 文件中，到时候有新的主题要翻译就可以先把它们导进去，GlotPress 会忽略掉在该主题中不存在的字符串，然后为了确保翻译准确性，导入的字符串应该先设为 Waiting，然后手动批准。
术语表可以有，对于不是计算机专业的普通用户来讲，很多计算机专业词汇的翻译和日常用语不一样，还是需要有术语表纠正的。
比如 Cookie 、 Bug 日常翻译为饼干和虫，但计算机中一般直接引用英文。再比如 Memory 日常翻译为记忆，但计算机中通常为内存。
如果有术语表的话，就能让这些普通用户更方便的参与翻译贡献了。
我目前有打算整理一份主题的术语表，到时候要翻译哪个主题直接导入可以节省不少时间
对记忆库编辑应该可行手：工指定下机翻的时候优先选择哪个词条，同时也可以将太离谱的直接删掉。
所以我觉得出现这样的情况标记为模糊比较好，但是也要尽量减少这种情况的发生，比如说主题的很多字符串都是重复使用的，所以不需要二次翻译，就可以直接套用翻译记忆库中的建议，而如果有个别译者不习惯看翻译记忆库或者直接导入了其他来源的译文就会出现两个甚至更多的译文，到这里又有一个新问题了：这样是否要对翻译记忆库进行编辑以保留一组质量最好的翻译？
想了想，刚说的那个规则会只对机翻引擎生效。给译者展现的翻译建议依然会同时显示多个结果，因为对于人工翻译来说，我觉得翻译建议更多是一种参考，有更多的翻译结果就可以提供更多的对比的机会。就好像我个人看技术文档习惯把官方文档结合第三方博客的放在一起看，互相对照。
限制只对两个及以下单词的条目生效似乎可解决这个问题。因为在长句子中存在上下文，很难会出现某个单词释义不同的情况。
在 WordPress.org 上翻译主题的时候这个问题就特别的明显了：例如 「It looks like nothing was found at this location. Maybe try the search below?」 这类的句子就会出现至少两个 100% 的结果
似乎还存在一个情况：在长句子中，因为译者习惯不同而产生不同的翻译。
似乎应该限制一下这个 「存在多个翻译结果则标记为模糊」 的功能只对两个及以下单词的条目生效。
你说这个我想起来，这个记忆库还存在不足。
目前是不可能出现匹配到 1 个以上 100% 的翻译的情况的，记忆库在入库时会进行数据去重，具体逻辑是：
所有字符串转小写-> 去除首位两端空格-> 生成 md5 校验码-> 入库 （数据库中以 md5 值为唯一主键，出现冲突的情况会直接替换现有值） 。
所以每个原文 （包括仅大小写不同的） 都只会记录一次以及其唯一的翻译结果。
但，看你刚提出的这个疑问，我想起来：比如说
post这个词，有的插件翻译为帖子，有的翻译为提交，这种情况下记忆库就会出问题，还是应该把这种有多个结果的词标记为 「模糊」 而不是 「已通过」 。这个问题我列到第三期开发计划里处理一下。
如果在记忆库中找到一个以上 100% 的翻译该如何处理？是标记为模糊吗？
另外，详细说一下，之所以不在采集时就把已翻译字符串直接标记，是因为记忆库是全局生效的，也就是说 A 项目不止会匹配来自 w.org 的 A 项目的翻译，还会匹配到 B 项目、 C 项目的翻译。为了程序架构设计上的 「解耦」，所以就把翻译匹配的工作统一放到机翻引擎里，而采集程序则只负责数据录入工作。
是我没表述清楚。
机翻引擎启动之后会自动在翻译时去记忆库中尝试匹配原文，如果 100% 匹配上的话就直接调用记忆库结果并设置为 「已通过」，只有记忆库匹配不上的才会由机器翻译并被标记为 「模糊的」 。
所以，从 wordpress.org 上采集的翻译直接把原文和翻译结果分别入库，这样机器翻译的时候会自动做正确处理。
最近一年的实际观察结果来看，通常一个项目大概有 30% 的字符串可以直接匹配上翻译记忆库。
已翻译的部分不应该是直接添加并批准吗？难道还要手动叫准一遍？
发网址地址看看
报错如下
总结一下就是 Cavalcade 为 WordPress 添加了真正的任务队列支持，类似于 Laravel 的 Horizon 。之后就可以放心的使用 WordPress 的 Cron 运行大批量的计划任务了，并且可及时触发。
厉害了，直接触及到我的知识盲区