參與者列表 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 運行大批量的計劃任務了，並且可及時觸發。
厲害了，直接觸及到我的知識盲區