Mozilla VPN用戶端成功推出：德國與法國的在地化之旅

Teh 更新時間 2025年2月13日

连续6年不跑路的安全速度最适合国人VPN

免费试用了解更多

引言

2023年4月28日，Mozilla成功在德國和法國推出VPN用戶端。自2020年以來，這款VPN用戶端已在多個國家（如美國、英國、加拿大、紐西蘭、新加坡和馬來西亞）上線，但用戶介面之前僅支援英語。本文將詳細介紹Mozilla生態系內該產品在地化的過程與步驟。

專案開始

在2020年10月，參與專案的小團隊向我提出請求：我們計劃使用Qt對現有的VPN用戶端進行全面重寫，並使用一個程式碼庫支援所有平台，並希望實現在地化。我們該如何進行？

首先，我要強調團隊儘早溝通的重要性。這使我們能夠了解現有的局限性，解釋我們可以現實地支持的內容，並設定明確的期望。在流程後期面臨緊迫的截止日期時，被逼入困境絕對不是件愉快的事。

初步本地化設置

這個專案無疑是一個有趣的挑戰，因為我們之前沒有Qt的經驗，並且需要確保專案能夠在我們的內部翻譯管理系統（TMS）Pontoon中得到支援。

初步研究顯示，Qt本地使用XML格式（TS檔案），但這需要編寫解析器和序列化器來支援Pontoon。幸運的是，Qt也支援從更常見的標準XLIFF匯入和匯出。

接下來的步驟通常是決定內容結構：我們想要TMS直接在主程式碼庫中寫入，還是希望使用一個專門的外部函式庫進行在地化？在這種情況下，我們選擇了後者，考慮到當時主程式碼庫仍然是私有的。

一旦確定了格式和庫結構，下一步是對現有內容進行全面審查： - 檢查每個字串的本地化問題。 - 在內容模糊或有變數在執行時間替換的地方新增註解。 - 檢查en-US內容的一致性，以防內容沒有經過我們非常能幹的內容團隊的審查或創建。

值得注意的是，這個過程在很大程度上依賴指定給專案的在地化專案經理，因為團隊中有不同的技能組合。例如，我採取了非常實用的方法，通常直接寫補丁來修復小問題，例如缺少註釋（這通常有助於減少修復所需的時間）。

在我的情況下，這是一種理想的方法： - 審查後，在Pontoon中將項目設定為私有項目（僅限管理員存取）。 - 實際將項目翻譯成義大利文。這使我能夠驗證Pontoon中的所有設定是否正確，更重要的是，它使我能夠識別我在初步審查中可能遺漏的問題。當你只是查看內容時，你的大腦運作方式與實際嘗試翻譯時是截然不同的，真是令人驚訝。 - 測試產品的在地化建置。透過這種方式，我可以驗證我們是否能夠使用TMS的輸出，建構系統是否按預期工作，並且沒有錯誤（如硬編碼內容、在不同上下文中重複使用的字串等）。

整個過程通常需要至少幾週的時間，具體取決於同時進行的其他項目數量。

擴展與自動化

我非常喜歡在處理重複任務時進行自動化，並且在這個專案中我學到了很多關於GitHub Actions的知識。幸運的是，這些知識在後來的多個專案中也得到了幫助。

我注意到的第一件事是，我經常對來源（en-US）字串的兩個問題進行評論：排版問題（直引號、三個點而不是省略號）、缺少字串變數的註解。因此，我編寫了一個非常基礎的linter，在開發人員在拉取請求中新增字串時自動執行。

自動化的主要內容位於l10n庫： - 每天運行的自動化提取程式碼庫中的字串，並建立一個PR將其暴露給所有語言。 - 一個基本的linter檢查本地化內容中的問題，尤其是缺少變數。這種情況比應有的更常見，主要是因為佔位符格式與本地化者習慣的格式不同，並且可能會出現翻譯記憶匹配——來自不同文件格式的已翻譯字串。

更新自動化尤為有趣。提取新的en-US字串相對容易，得益於Qt命令列工具，儘管需要一些工作來清理生成的XLIFF（例如，將本地化註釋從extracomment移動到note）。

在新增語言環境的過程中，我們迅速意識到，僅更新參考檔案（en-US）是不夠的，因為Pontoon期望每個在地化的XLIFF都包含所有來源訊息，即使未翻譯。

歷史上，其他雙語檔案格式（如.po（GetText）和.lang檔案）也是如此，但這並不一定適用於XLIFF檔案。特別是，這兩種格式都有自己的工具來將新字串從模板合併到其他語言環境中，但XLIFF並沒有這樣的工具，它是一個在完全不同工具間使用的交換格式。

此時，我需要自動化來解決兩個獨立的問題： - 在更新en-US時，將新字串新增至所有本地化檔案。 - 捕捉意外的字串變更。如果字串在沒有新ID的情況下更改，Pontoon不會觸發任何操作（現有翻譯將保留，本地化者不會意識到更改）。因此，我們需要確保這些變更得到妥善管理。

以下是來源XLIFF檔案中字串的樣子： ```xml
服務條款

```

更新腳本的主要步驟如下： - 它以en-US XLIFF檔案為模板。 - 它讀取每個本地化文件，保存現有翻譯。這些翻譯儲存在字典中，鍵是透過檔案元素的original屬性、trans-unit中的字串ID和實際來源字串的雜湊產生的。 - 然後，將翻譯注入en-US模板並儲存，覆蓋現有的在地化檔案。使用en-US檔案作為範本確保檔案包含所有字串。使用原始文字的雜湊作為ID的一部分將移除翻譯，如果來源字串發生變化（在遍歷en-US檔案時產生的ID將沒有匹配的翻譯）。