上一周大部分時間都花在了折騰谷歌小語種上，利用近一周的時間，總算是將這塊內容折騰明白了。所以這篇文章就簡單總結一下，我在做小語種翻譯過程中涉及到的一些流程與思路。

首先要說明兩個問題，其一是為什么不用自動化翻譯的問題，其二是為什么不用相關翻譯軟件API的問題。

第一，自動化翻譯出來的質量不高，會導致后續不斷掉收錄，甚至可能會拉低全站質量。所以思來想去，干脆放棄了類似于谷歌翻譯這樣的功能，轉而使用OpenAI訓練身份設定，將對應詞條轉述為對應小語種版本。

第二，不使用API主要還是因為性價比的問題。像DeepL API這種質量還不錯的方案，開通會員版后，25美金只能翻譯一百萬字符，基本就是30個頁面左右。

而我的網站目前就有一千三百多個頁面，使用這種方案的話真的有點扛不住。即便去買免費版的DeepL API，每個月也需要花費近千元了。

當然，這周也陸陸續續試了一些朋友的推薦（比如有朋友推薦的Deeplx方案），總結起來就是「好貨不便宜，便宜無好貨」。所以，最后也就決定直接使用OpenAI訓練身份設定來翻譯詞條了。

整體方案確定了，下一步要做的就是執行細則。目前我的做法是，手工整理頁面詞條信息，然后交由OpenAI轉述成對應小語種，然后利用工具將英語版本與小語種版本的詞條一一對應起來，存儲到表格中。

這個過程，最基本也是最重要的要求，就是英語與小語種的詞條對應順序不能錯，否則就亂套了，好在這塊我直接寫了一個Python腳本協助處理，直接將「人」這個不確定因素剔除出去。

到這一步，基本不費什么人工，唯一需要手動操作的地方，就是手動去整理頁面的詞條。我簡單統計了一下，平均整理一個頁面耗時在一分鐘左右，還能接受。且目前我的OpenAI都是使用的第三方工具提供的，也沒花錢。

下一步就需要將這一個一個小語種的詞條，填充到小語種的頁面中去了，可能這也是整個流程比較讓人頭痛的一點。

目前，我網站小語種插件使用的是TranslatePress開發版，支持自定義頁面編輯。假如使用人工一條一條去處理的話，可能猴年馬月都干不完。

所以我就嘗試著去找一些翻譯詞條批量上傳的工具，試了幾個效果都不理想。所以這也是我最煩TranslatePress的一個點，為什么不提供一個翻譯詞條批量上傳的功能（有這個功能能省事不少）。

可能人家出于商業變現的考量，閹割了這個需求。那干脆我就只能自己動手寫了，主要也就是兩個方案。一是寫專門的上傳插件，去對接TranslatePress數據庫，從根上解決問題。二是寫RPA自動執行腳本（或者自動化流程），直接將「人工」從詞條更新這個環節抽離出去。

焦慮了一個上午，最后決定還是采用RPA方案。畢竟節省時間，節省成本，因為我真的沒有時間去深入了解TranslatePress的表結構設計。

上圖便是昨天下午寫出來的自動化流程，200多行代碼，整體上寫出來不難。比較耗時間的就是測試、微調，好在這個部分工作今天也做完了。簡單試驗了十幾個頁面，效果還不錯，畢竟這種「復制粘貼」的工作，我是真的不愿做。