我們做的是一套「上傳一張孩子的照片，就寫出並畫出一本繪本」的產品，內容要以十種語言交付。做到第三種語言的時候，我們踩到一個到今天都還覺得值得寫下來的坑：翻譯把每一個字都換對了，整段話卻是錯的。

錯在哪裡？錯在那段話的論證，是建立在一個只有部分讀者活在其中的行事曆上。

一、一段「翻譯得完全正確」的錯誤文案

原本的英文文案裡有這樣一個場景：聖誕節早晨，孩子在樹下拆開一本以自己為主角的書。

這是一句很好用的話。它同時交代了三件事：什麼時候送、送給誰、拆開的那一刻是什麼感覺。它是整段文案的錨——後面所有的句子都靠它站著。

然後我們把它交給翻譯流程。俄語版出來了，每個詞都對：ёлка 是樹，подарок 是禮物，Рождество 是聖誕節。語法沒問題，語感也不差。

問題是：對大多數俄語讀者來說，孩子拆禮物的那一刻不在聖誕節。 那是 12 月 31 日跨年夜，是 Новый год，禮物是 Дед Мороз 送的。而東正教的聖誕節在 1 月 7 日，性質也不是「拆禮物的早晨」。

我們寫的那句話，在俄語版裡變成了一個「發生在錯誤日期的正確場景」。沒有任何一個翻譯環節會報錯，因為每個詞都翻對了。

二、為什麼翻譯層結構性地看不見這種錯

再看幾個我們實際撞到的：

• 西班牙：傳統上孩子收禮物的日子是 1 月 6 日的 Reyes Magos（主顯節／三王節）。你把「聖誕節早晨」翻成 la mañana de Navidad 沒有錯，但它不是那個「拆禮物的早晨」。
• 阿根廷、智利：聖誕節在夏天。原文裡的雪、壁爐、暖飲、窗外結霜——整組意象在南半球是反的。我們原本還很得意地在插圖 prompt 裡寫了「窗外飄雪」。
• 巴西：真正的「日常復位」那一天不是一月，是二月的 volta às aulas（開學）。長假結束、制服穿回去、作息重新開始，那才是家長會想「該給孩子準備點什麼」的時刻。
• 阿拉伯語：多數讀者根本不過聖誕節。錨點要換成 العيد——而且 Eid 是跟著伊斯蘭曆走的，它在西曆上每年往前移，不存在「固定日期」這回事。

把這四個放在一起看，共同點就浮出來了：出錯的從來不是詞彙層，是論證層。

而幾乎所有主流的 i18n 工具鏈——gettext、ICU message format、一包一包的 JSON 語系檔——處理的單位都是「字串」。它的心智模型是：一句話 → 對應的另一句話。這個模型很好用，也正因為好用，它讓一件事變得隱形：

有些句子之所以成立，靠的不是它的字，而是讀者腦子裡的一張行事曆。

字串目錄裡看不到行事曆。語系檔裡也沒有一欄叫「這個地區的孩子什麼時候收禮物」。所以這類錯誤不會出現在任何 diff 裡，不會有測試變紅，只會在真正的讀者眼前，安靜地讀起來怪怪的。

三、把「翻譯」換成「換論證」

我們最後的處理方式是：那篇內容，我們針對不同語系重寫了整段論證，而不是翻譯它。

具體來說，我們先把原本藏在散文裡的東西挖出來，變成明確的欄位。原本那句話拆開之後長這樣：

• 時間錨點：孩子收到禮物的那一天是哪一天
• 季節錨點：那一天當地是什麼季節（決定雪、外套、日照、戶外還是室內）
• 儀式錨點：禮物由誰帶來、在什麼場合打開
• 語氣錨點：那個場合是安靜的、喧鬧的、宗教性的，還是純粹家庭式的

這四個欄位一旦被寫成資料，「同一篇內容的十個版本」就不再是十份翻譯，而是同一套骨架、十組不同的填充。俄語版填 12/31 與 Дед Мороз，西語版填 1/6 與 Reyes Magos，巴西版填二月與開學，阿拉伯語版填 العيد 與一個浮動的日期。

值得說清楚的是代價：這比翻譯貴。 貴在你得先承認「我這段話的說服力是建立在什麼上面」，而這件事只能人來做一次。但它是一次性的——骨架抽出來之後，新增一個語系就是填一組欄位，而不是重寫一次全部。

四、讓機器能判定：把「不可能出現的詞」寫成表

抽欄位解決了「怎麼寫對」，但不解決「怎麼知道自己沒寫錯」。內容出錯最麻煩的地方在於，錯的東西看起來完全正常。人工複查在語言變多之後也不可靠——不是不用心，是你不可能對十種語言都有那個直覺。

所以我們的做法是：盡量把文化判斷，翻譯成機器可以判定的邊界。

例如把「這個語系的行事曆」寫成一張表，然後讓檢查程式去掃產出的文案：如果阿拉伯語版本裡出現了聖誕節的詞彙，或者南半球語系的版本裡出現了「雪」，就直接讓那個產出不通過。這種檢查很笨，但它抓得到的，恰恰是人最容易放過的那一類錯。

我們在日語上做過同一件事，形狀一模一樣。日語版要控制漢字難度，一開始我們在 prompt 裡寫「請使用適合這個年齡的漢字」——結果六歲的故事裡出現了「真鍮」「鳳凰」。程度詞約束不住產出。 後來我們改成直接引用文部科學省的「學年別漢字配當表」，把某個年級能用的字寫成一張明確的字表，超綱的字一律判不通過。同一個問題，從「請你注意一點」變成「這個字在不在表裡」，才真的被關住。

這裡有個一般性的教訓，跟語言沒關係：

凡是你只能用形容詞描述的約束（適度、控えめに、符合當地習慣），對機器來說都等於沒有約束。 你得把它降級成一個可以查表的問題，它才會被執行。

順帶一提，這類檢查器本身也會騙人。我們寫過一個跨語言的檢查程式，結果分佈漂亮得可疑——後來發現是 JavaScript 的 \b（word boundary）只認 ASCII，遇到中日韓和阿拉伯文根本不成立，整個檢查一直在空跑。檢查結果整齊到不像話的時候，先懷疑檢查器，不要先相信它。

五、什麼時候不值得做

老實說，不是所有內容都需要走到這一步。

如果你的文案是功能說明、操作步驟、錯誤訊息，字串層的翻譯就夠了——這些句子的說服力不依賴讀者的生活經驗。真正需要「換論證」的，是那些靠場景打動人的內容：行銷文案、故事、節慶溝通、任何一句「想像一下那個畫面」開頭的話。

判斷方法很簡單，一個問題就夠：

這句話如果讀者所在的地方沒有這個節日／這個季節／這個習慣，它還成立嗎？

不成立的那些句子，就是你的錨點。它們數量通常不多，但它們決定了整段內容在別的地方讀起來像不像人話。

六、我們在做的東西

上面所有的例子都來自我們自己的產品。我們做的是 Lumora：家長上傳一張孩子的照片，AI 會寫出並畫出一本以這個孩子為主角的繪本，而我們花最多力氣的地方，就是讓每一頁的孩子樣貌保持一致。

十種語言的故事都是以該語言原生寫作，不是先寫英文再翻譯——這篇文章講的整套做法，就是為了讓這件事真的成立。第一本免費，不需要信用卡。繁體中文版在這裡：https://lumora.kids/zh-hant

如果你也在做多語系的內容，希望上面那四個錨點欄位對你有用。至少，別再讓南半球的孩子在聖誕節早晨看窗外飄雪了。