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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上面就是我的一些流程，有興趣或者有疑問，歡迎交流。