翻譯在哪裡？

在解釋了地球上有一大部分人 [不會說英文]](“2020-06-12-80-percent.md”)，接著 解釋如何為 Fedora 發行版貢獻心力，讓我們來看看一個軟體的翻譯在哪裡。

翻譯是程式碼不可分割的一部分

翻譯檔案是執行程式所需的原始碼的組成部分。 包含翻譯的檔案格式因開發團隊使用的工具而異。 要了解主要的檔案格式，Weblate 翻譯平台支援的格式清單 是很有趣的。 一般而言，Gettext 格式最廣泛用於編譯/桌面軟體，而 Json 格式則用於網路軟體。 每種檔案都有其優缺點，這就是軟體國際化的範疇，通常縮寫為 i18n。

對翻譯工作的影響

由於翻譯是原始碼的一部份，翻譯人員必須準時交稿，以確保當前版本的每一項變更都能翻譯出來。 最輕微的改動，即使是一個字母或字元的改動，都意味著每一個翻譯都必須經過檢查，以確定改動是否會影響句子的意思或結構，而改動對翻譯人員來說是昂貴的。

更常見的情況是，開發人員在進行變更時不知道如何調整譯文，這也是意料之中的事。 因此，必須有緊密跟進專案開發的翻譯人員，才能反應迅速，避免新版本的專案在送達使用者時，在已經有部分翻譯的軟體中間以英文顯示字串。

這就是問題變得複雜的地方：自由軟體專案至少有數以千計，甚至數以十萬計。 有成千上萬的語言，那麼我們在每一種語言都有足夠的翻譯員來跟上所有這些專案嗎？ 當然不能。

整合翻譯流程

讓我們來看看幾個專案的範例，看看軟體開發與翻譯流程之間的互動是如何組織的。

可翻譯……但古老！

Jitsi Meet 是線上視訊會議軟體。在它的原始碼中，一個 lang 資料夾內包含每個語言的 json 檔案。

每個翻譯都必須提交整合，既複雜又費時。

幾分鐘之後，我發現了一個極端案例，這個請求已經等待了超過 8 個月。 然而，在此期間，包含軟體中要翻譯的字串的檔案 已經變更了 19 次，而且已經有 8 個版本出版！

在 readme 和 contribution guide 中都沒有如何翻譯的資訊。

使用者多的語言社群可能會因為貢獻者的數量而花費所需的時間（即使如此……），所有其他的語言社群都會被遺漏，軟體只會提供已被過度代表的語言的更新翻譯。 要追蹤變更，您可能需要訂閱 github 專案。

這種工作方式的效率有待商榷。 雖然我們可以讚賞為了讓軟體能夠被翻譯所做的努力，但我對於沒有考慮到這類貢獻感到遺憾。 我並未與 Jitsi Meet 團隊進行任何討論，因為並非一直如此，過去也曾使用過翻譯平台。

很清楚…但對 GNOME 來說非常特別

GNOME 專案使用類似的版本，但著重於翻譯團隊的需求。 若要將翻譯結果傳送至最終軟體，必須使用 git。 然而，有一個工具可以提供給翻譯者，讓他們可以清楚知道需要翻譯的內容，並進行合作。 更重要的是，在 GNOME 生態系統中，有一長串的軟體應用程式遵循著相同的新版本節奏與相同的工作流程。 因此，這個過程是不完美且手動的，但我們使用的工具大大降低了貢獻者的管理成本。

有效…但對 Mozilla 非常特別

Mozilla 專案認為翻譯是其活動的重要部分。 如果您想貢獻一份心力，請造訪 Pontoon 翻譯平台（專案分為 翻譯小組）。

要知道什麼是可翻譯的很容易，要找到回答問題的聯絡人也很容易。

這是一個龐大的專案，您可能會覺得很難理解翻譯平台與軟體發行之間的階段，但這是問題嗎？ 它運作得很好，軟體的發行日期是已知的，優先順序也是確定的。 因為所有的工具都是 Mozilla 專案特有的，所以你會失去一點時間來建立團隊和審核流程，但總體來說還是相當有效的。

自動化與通用化，解放現代性

可以提供專門用於翻譯活動的工具，使訂閱在發生變更時可以取出、多位使用者可以一起工作，以及偵測異常。

此外，終極獎勵是與軟體原始碼自動同步。

一個很好的例子：Weblate 翻譯平台樹立了一個榜樣，所有的東西都是連接和自動化的。 翻譯的變更很多，影響翻譯的變更很容易找到。

許多專案都使用 Weblate，因此無論您的情況如何，Weblate 都是您應該做的選擇。 在翻譯平台的生態系統中，Weblate 已經像 git 一樣，成為管理軟體開發原始碼的明顯而有效的工具。

如果您的專案提供這個平台，那麼您就提供了語言貢獻的槓桿，透過培養與這個大型社群的關係，您就很有機會讓工具翻譯成許多語言。

總結

專案的技術層面與翻譯之間的聯繫對翻譯過程的效率至關重要。

各種充滿有趣功能和自動化的工具讓每個人的生活更輕鬆。

開發團隊必須充分利用這一優勢，使軟體包含越來越多的翻譯，支援越來越多的語言。

但如果專案沒有製作任何新版本，該怎麼辦？ 如何補償休眠的專案？ 這將是未來文章的主題。