以英文撰寫，自動翻譯觸及更多讀者

公開寫作是學習一個主題的較好方法之一，而其影響範圍通常止步於單一語言的邊界。你花一個晚上用英文寫了一篇文章，而一位用韓文或日文思考的讀者永遠找不到它。解決方法不是手動再寫四篇文章。而是撰寫一份原始文件，並讓一個管線來翻譯和發布剩下的內容，如此一來，你只需維護單一檔案，就能讓同樣的想法觸及更廣大的受眾。這篇文章是關於這個設定如何運作、它對你的寫作有何要求，以及何時不值得這麼麻煩。

為何公開寫作值得付出努力

第一個回報是為你自己。為了發表一篇解釋，你必須將整件事一次性地在腦中掌握並加以整理。當這個想法只存在於你的筆記中時，你所忽略的漏洞，在你試圖寫下第三段時就會變得顯而易見。教導的行為會暴露出你實際上並不理解的部分。你最終會學習這個主題兩次，一次是在私底下學得不好，一次是在公開場合學得透徹。

第二個回報是為了那些遇到你剛解決的那個確切問題的讀者。大多數的技術搜尋，都是某人在晚上 11 點卡關時，尋找那個描述他們錯誤的頁面。一篇關於你實際部署的修復、簡短而誠實的文章，對那個人來說，比一篇精美的概述更有價值，因為它符合他們問題的樣貌。

第三個回報是修正。當你在公開場合寫錯了東西，懂得更多的人往往會告訴你。這讓人不舒服，但很有價值。私人筆記永遠不會錯，因為沒有人會讀它。一篇公開的筆記會受到那些沒有與你相同盲點的人的壓力測試。

這三種回報的上限，取決於有多少人能讀到這些文字。這個上限就是這篇文章接下來要討論的問題。

一份原文，多方讀者

這個想法很簡單。你用一種語言（此處為英文）寫作，並將該檔案視為你唯一擁有的東西。儲存檔案後的一切都是機器的任務：解析 Markdown、將其翻譯成你支援的其他語言，並將每個翻譯版本以其專屬的 URL 發佈為獨立頁面。你完全不必碰觸翻譯版本。當你想修改一個句子時，你在英文原文中修改，下一次執行時就會重新翻譯並重新發佈。

本部落格正是以此方式運作。一篇文章就是一個英文 Markdown 檔案。在 push 時，一個擷取步驟會將其翻譯成韓文、日文、簡體中文和繁體中文，然後將各個版本作為獨立頁面提供。我寫的一個檔案，產出了五種語言的頁面。這個倍數效應相當顯著。如果你的英文文章觸及了一定規模的讀者，另外四種語言版本各自也能觸及相當規模的讀者，而額外花費的寫作時間趨近於零。

之所以值得將此流程自動化而非手動進行，是因為手動翻譯經不起編輯修改。當你第一次修正英文版本中的一個錯字時，四個手動翻譯的版本就開始失步，而要讓一份動態文件的五個版本保持同步，是沒有人會持續去做的工作。一個從單一原文重新生成所有翻譯的管線，從根本上消除了這種失步問題。真相來源只有一個，而翻譯版本則是衍生出來的產物，就像編譯後的輸出一樣。

撰寫易於機器翻譯的內容

自動翻譯的品質取決於所提供的句子。一個模型可以乾淨俐落地翻譯一個簡單、直接的句子，但會搞砸一個巧妙的句子。因此，為翻譯流程而寫作，意味著要採用一種無論如何都算是好的寫作方式。

規則是移除任何需要讀者已經用英語思考才能理解的內容。成語、雙關語、文化笑話和一長串的代名詞，翻譯效果都很差，因為模型必須猜測字面之外的含義。使用具體名詞的清晰、重點前置的句子，翻譯效果很好，因為需要猜測的地方更少。

一個關於成語問題的具體例子：

Before: We finally moved the needle on cold starts.
After:  We reduced cold start time.

「修改前」那行會迫使模型在呈現含義之前先解碼一個隱喻，而四種翻譯版本對於該隱喻的含義會產生分歧。「修改後」那行只有一種含義，每次都會以相同的方式翻譯。你會失去一點個人風格，但同時在四種語言中獲得正確性。對於一篇技術文章來說，這是一筆划算的交易。

程式碼和技術術語需要特別留意。你會希望產品名稱、API 識別碼和保留字能夠保持原樣，而不是被翻譯成本地的近似詞。一個好的流程會保護圍欄式程式碼區塊和行內程式碼不被翻譯，並會保留一份應維持英語的術語詞彙表。如果你寫了 goroutine，並期望它在每種語言中都保持為 goroutine，那麼詞彙表就是強制執行這項規則的工具。如果沒有詞彙表，一個「善意」的模型會很樂意地將關鍵字本地化，從而破壞其原意。

告知讀者此為機器翻譯

機器翻譯雖好，但非完美。若假裝完美，讀者一遇到不通順的句子，便會對您失去信任。誠實的做法是在頁面上說明這一點。

每個翻譯版本都應附上簡短而顯眼的註記，說明其為自動翻譯，並附上返回原始英文版本的連結。這有兩個作用。首先，它設定了正確的期望，讓奇怪的措辭被理解為已知的限制，而非草率的結果。其次，它為雙語讀者提供了一個解決之道：當翻譯的句子不清楚時，他們可以打開原文，查看您的確切意思。原文才是權威，而您正在告訴讀者權威的出處。

這種透明度也能保護您自己。如果翻譯在某個技術細節上出現了細微的錯誤，標示清楚的原文就是您所言內容的記錄。您並非聲稱機器逐字逐句地代表您發言，而是聲明英文原文屬於您，而翻譯版本是盡力搭建的溝通橋樑。

走向多語言的成本

這一切都不是免費的，而誠實的提案版本會附上帳單。

第一項成本是翻譯品質的控管。純文字內容的翻譯效果很好。充滿程式碼、表格和精確術語的文章，是模型最可能出現偏差的地方：重寫標題、將關鍵字在地化，或悄悄地漏掉一行。你需要為此設置防護機制，這意味著要保護程式碼、維護詞彙表，並設置一個驗證步驟，以便在發布前拒絕或還原不良的翻譯。建置並維持這套機制的運作，需要投入實質心力。

第二項成本是多語言的 SEO。一篇文章的五種語言版本，意味著有五個 URL，搜尋引擎必須能理解這些是不同語言的相同內容，而非重複內容或貧乏頁面。這就是 hreflang 註釋、正確的標準化處理，以及確保每種語言都有足夠的實際內容，讓分類頁面值得被索引。如果做錯了，你最終可能會與自己競爭，或導致整組頁面被降權。這種複雜性會隨著語言數量的增加而擴大，而且不會消失。

第三項成本是流程本身。你正在用靜態檔案的簡單性，換取一個能夠解析、翻譯、驗證和發布的系統。必須有人負責這個系統。當翻譯任務在凌晨兩點失敗時，這也成了你部落格的一部分。單一來源的原則是一項實質的收穫，但你為此付出的代價是，將來源轉換成頁面所需的一切操作層面。

總而言之，這些成本意味著，只有當跨語言的觸及範圍對你來說確實有那麼高的價值時，多語言的設置才算值回票價。

當一種語言就足夠時

當您的讀者已經共享同一種語言時，請跳過所有這些內容。如果您為團隊、在地社群或英語閱讀能力良好的市場撰寫文章，翻譯成另外四種語言會增加成本，但幾乎不會帶來新的讀者。這個流程是額外的開銷，因為另一端並沒有受眾。

當您的文章生命週期短暫時，也請跳過翻譯。版本說明、狀態更新和具時效性的公告只會被閱讀一次，然後就過時了。翻譯的回報會隨著一篇長青文章的生命週期而複利增長，這類文章多年來會不斷地在搜尋中被找到。對於下週就無關緊要的內容來說，翻譯幾乎沒有任何效益。

並且，及早跳過它。如果您只發表了三篇文章，並且還在尋找自己的風格，請先不要建立翻譯流程。先用一種語言寫作，直到您擁有一系列真正有人閱讀的作品，然後在觸及範圍成為實際限制而非假設性限制時，再增加語言。有效的順序是：第一，寫作；第二，受眾；第三，翻譯。在擁有讀者之前就建立這套機制，是在優化一個仍然是零的數字。

粗略的測試方法是：將您對一篇文章終身讀者數量的最佳猜測，乘以其中無法閱讀您來源語言的讀者人數。如果這個數字很大，而且您的文章能長時間保持關聯性，那麼這個流程就值得。如果數字很小，就用一種語言寫作，並將省下的心力用來寫更多文章。

值得保持的習慣

在工具的表象之下，真正重要的事情從未改變。你透過解釋來學習一個主題，並藉由公開發表解釋而非將其私藏來幫助他人。自動翻譯並不能取代這個習慣。它只是敞開了大門，讓你原本只為一種語言寫的文章，能悄然觸及另外四種語言的讀者。

它所要求的紀律——簡潔的句子、一次一個想法、具體的詞彙、定義清晰的術語——正是能讓使用相同語言的讀者清楚理解你文章的紀律。無論如何，你本來就應該那樣寫。翻譯流程只是提高了不這麼做的代價，而當你這麼做時，則能讓更廣大的群體受益。