10 個常見的翻譯錯誤（以及如何避免）

一句翻譯錯誤的標語讓 HSBC 損失 1,000 萬美元。一個日期格式的程式錯誤摧毀了價值 5 萬美元的工廠設備。一次 Facebook 的自動翻譯害一名男子遭到逮捕。翻譯錯誤不只是尷尬——它們會把事情搞砸。以下是 10 個值得留意的具體錯誤，附上真實案例與幾秒鐘就能套用的修正方法。

1. 逐字翻譯慣用語

慣用語很少能經得起直譯。這些詞在語境中是一個意思，拆開來看卻是完全不同的意思——然而這依然是所有語言組合中最常見的翻譯錯誤。

❌ “It’s raining cats and dogs” → 「下貓下狗」（中文字面意思：「貓和狗正在落下」）

✅ 「傾盆大雨」（中文：「盆子倒出來的大雨」）/ “Il pleut des cordes”（法語：「下著繩子」）/ “Es regnet in Strömen”（德語：「下著水流」）

❌ “Break a leg” → 「رجل اكسر」（阿拉伯語：字面意思為「打斷一條腿」）

✅ 「بالتوفيق」（阿拉伯語：「祝好運」）/ «Ни пуха ни пера!»（俄語：「既無絨毛也無羽毛」——等同於「祝你好運」）

❌ Coors 啤酒「Turn it loose」→ 西班牙語中相當於「腹瀉」

✅ 一句經過目標市場母語人士測試的本地化標語

❌「To have other cats to whip」（法語：«avoir d’autres chats à fouetter»）→ 直譯成英文後毫無意義

✅ “To have other fish to fry”——英文中對應的慣用語

如何避免： 當你遇到慣用語時，問自己：「目標語言中是否存在意思相同的完全對應說法？」如果答案是否定的——而幾乎總是如此——就去找當地的對等說法，而不是逐字翻譯。

2. 忽略正式程度與語域

英文對所有人都用 “you”。大多數其他語言並非如此。用錯稱謂形式，輕則有點尷尬，重則明顯冒犯人——在商業、法律和面向客戶的情境中尤其如此。

❌ 日語：客服情境使用 あなた（anata）。字面上是「你」，但在服務情境中顯得疏遠且輕蔑。

✅ お客様（okyakusama，「貴客」）或客戶姓名 + 様（-sama）

❌ 法語：在商務電子郵件中使用 “Tu” 而非 “Vous”。對不熟的人使用非正式稱呼很冒昧。

✅ 對於沒有明確非正式關係的人一律用 “Vous”。預設使用正式形式。

❌ 義大利語：稱呼客戶時用 “Tu” 而非 “Lei”。義大利語用第三人稱陰性的 “Lei” 作為正式稱謂。

✅ 商務與正式情境使用 “Lei” + 第三人稱動詞形式

❌ 韓語：在商務電子郵件中使用 반말（banmal，非正式語）而非 존댓말（jondaenmal，敬語）。

✅ 除非關係明顯隨性，否則預設使用最高敬語等級（합니다 / 합니까 形式）

如何避免： 對任何你要翻譯成的語言，學習兩件事：稱謂的正式／非正式區分，以及目標受眾期待哪種語域。有疑問時就選正式——稍微過於禮貌總比不小心失禮來得安全。在日語、韓語和泰語中，敬語系統特別複雜，單靠機器翻譯無法正確處理。

3. 日期與數字格式混淆

只有美國和少數屬地使用 MM/DD/YYYY。世界其他地方使用 DD/MM/YYYY 或 YYYY-MM-DD。搞錯這點不只是看起來不專業——它會損壞資料。

❌ 在給歐洲受眾的合約中寫 03/06/2026。作者意指 3 月 6 日（DD/MM）。讀者卻看成 6 月 3 日（MM/DD）。

✅ “6 March 2026” 或 “March 6, 2026”——在各區域都不會產生歧義

❌ 在德文文件中寫 1,500.75。德語會交換逗號和小數點：1.500,75。巴西葡萄牙語也是如此：1.500,75。瑞士法語和義大利語使用撇號：1’500.75。

✅ 1.500,75（德語／葡萄牙語）、1 500,75（法語），或使用能辨識地區設定的格式

❌ 假設所有受眾都使用格里曆。沙烏地阿拉伯的官方文件使用伊斯蘭曆。泰國使用佛曆（年份 +543）。日本使用年號（令和 8 年 = 2026）。

✅ 確認你的受眾在標示日期時使用哪種曆法

如何避免： 內部以 ISO 8601（YYYY-MM-DD）儲存日期。顯示時使用讀者預期的格式。對於任何翻譯文件，明確標示：「本文件中的日期使用 DD/MM/YYYY 格式。」花 5 秒加上這句話，能省下好幾天的困惑。

4. 假朋友：當詞語對你說謊

假朋友（false friend）是指兩種語言中看起來相同或幾乎相同，意思卻截然不同的詞。它們特別危險，因為會製造一種「正確」的假象——譯者看到熟悉的詞，就不會停下來查證。

英文詞彙	假朋友	語言	實際意思
embarrassed	embarazada	西班牙語	懷孕
actually	attualmente	義大利語	目前
gift	Gift	德語	毒藥
sensible	sensibile	義大利語	敏感
eventually	eventualmente	葡萄牙語	可能／也許
library	librairie	法語	書店
demand	talep etmek	土耳其語	請求（而非「要求」）
pain	pain	法語	麵包
magazine	магазин (magazin)	俄語	商店
brave	braaf	荷蘭語	乖巧
location	location	法語	租賃
pretender	pretender	葡萄牙語	打算

Parker Pens 為此付出了慘痛代價：他們的英文標語承諾這支筆「won’t leak in your pocket and embarrass you」（不會在你口袋裡漏墨讓你尷尬）。西班牙文譯本把 embarazar 誤認為 “embarrass”，結果變成「不會在你口袋裡漏墨讓你懷孕」。假朋友只是語言帶給我們驚喜的眾多方式之一——我們的令人驚訝的語言冷知識合集介紹了更多會讓譯者栽跟斗的語言怪癖。

如何避免： 為你處理的每種語言組合維護一份已知假朋友的詞彙表。用「請勿翻譯」的警告標記它們。當你在目標語言中看到看似熟悉的詞，停下來查證——正是這種相似性讓它變得危險。

5. 盲目信任機器翻譯

機器翻譯已有長足進步——但仍會犯下人類不會犯的類型錯誤。2025 年 7 月，Meta 的自動翻譯根據一位印度邦首席部長為他人寫的哀悼貼文，誤報這位仍在世的部長「逝世」。他的辦公室稱這項工具「危險」，並要求暫停其卡納達語功能。

其他真實案例：

❌ 阿拉伯語 → 希伯來語（Facebook，2017 年）： 一名巴勒斯坦男子發的「早安」被自動翻譯成「攻擊他們」。以色列警方在錯誤被發現前就逮捕了他。

✅ 人類譯者知道 صباح الخير 的意思是「早安」，別無其他。

❌ 印地語 → 英語（Uber，2025 年）： 「Mother Dairy ke samne hun」（我在 Mother Dairy 前面，Mother Dairy 是印度知名品牌）變成「我正面臨被謀殺的威脅」。

✅ 譯者需要認出「Mother Dairy」是品牌名稱，而不是可翻譯的詞。

❌ 英語 → 法語（蒙特婁交通局，2025 年）： 公車路線圖上的「Bishop Street」被 AI 翻譯成「Beeshop」。

✅ 專有名詞不翻譯。人類不會嘗試這麼做。

如何避免： 機器翻譯是草稿，不是成品。對於任何面向客戶、法律、醫療或涉及安全的內容：務必由人工審閱輸出結果。不同工具也有不同的盲點——我們的 OpenL 與 Google Translate 比較 顯示了特定工具容易出錯的地方。規則很簡單：如果錯誤的後果只是尷尬，你可以冒險；如果後果是法律責任或人身傷害，就不行。

6. 文字膨脹與版面破壞

不同語言佔用的空間不同。把英文翻譯成德文時，文字會膨脹約 25–40%。義大利語和葡萄牙語：15–30%。法語和西班牙語：15–25%。即使是文字精簡的語言也有意想不到之處——俄語西里爾字母詞彙平均比對應的英文詞更長，荷蘭語複合詞的長度則可與德語匹敵。較短的 UI 字串膨脹得更誇張——英文中不到 10 個字元的按鈕標籤，翻成德文可能變成三倍長。

❌ 一個寬 80px 的「Submit」按鈕。德語「Absenden」會超出。義大利語「Invia」放得下，但俄語「Отправить」不行。土耳其語「Gönder」撐破版面。

✅ 按鈕設計要預留 30% 以上的膨脹空間，或使用能隨內容增長的彈性版面

❌ 一個文字框排得很緊的 PDF——荷蘭語「Sollicitatieformulier」（17 個字元）取代英文「Job Application」（15 個字元），但德語「Bewerbungsformular」（19 個字元）卻溢出頁面。

✅ 定稿前檢查所有目標語言的版面。在原始設計中留下空白

如何避免： 在 UI 設計上，德語是你的壓力測試語言——如果德語放得下，大概所有語言都放得下。文件方面，翻譯後一定要做一次版面檢查。如果你翻譯的是 PDF，版面破壞尤其常見——我們的不破壞格式翻譯 PDF 指南涵蓋了跨語言保留設計的工具與工作流程。W3C 建議從英文翻譯成歐洲語言時，至少預留 30–40% 的膨脹空間。

7. 術語不一致

在同一份文件中把同一個術語翻成三種不同說法，會侵蝕信任並造成混淆——在法律、技術和醫療內容中尤其如此。

❌ 在一份英文法律合約中：第 1 頁寫「Service Agreement」，第 5 頁寫「Services Contract」，第 8 頁寫「Terms of Engagement」。三者指的都是同一份文件。讀者納悶：這是三件不同的事嗎？

✅ 為每個概念選定一個術語，並在整份文件及其譯文中貫徹到底

❌ 日語醫療翻譯（NIH，2025 年）：「患者」在一個段落譯為 “patient”，下一段卻譯為 “case”——讓人無法確定文中是否指同一個人

✅ 為領域專用術語建立詞彙表，並在整個專案中確實遵守

如何避免： 開始翻譯專案前，先為 10–20 個最重要的術語及其核准譯法建立一份小型詞彙表。把它分享給所有參與這份文件的人。翻譯記憶工具（多數專業翻譯平台如 OpenL 都內建）能自動化這個流程——它們會記住你如何翻譯某個術語，並在整份文件中一致地重複套用。

8. 翻譯不該翻譯的名稱

專有名詞——人名、品牌、地名、產品名——幾乎從不翻譯。但機器翻譯工具不知道這一點，甚至人類譯者有時也會過度修正。

❌ 西班牙語 → 英語（墨西哥觀光網站）： 「Tulum」變成「Jumpsuit」，「Acolman」變成「I Blame」，「Progreso」變成「Progress」。

✅ 地名不翻譯。它們保持原本的形式。

❌ 英語 → 中文： 「Palo Alto」→「高木頭」（“tall wood”）。它是一座城市，不是木材行。

✅ 「Palo Alto（加州一城市）」——名稱保留 + 選用的括號說明

❌ 俄語 → 英語： 「Василий」→「Cornflower」（василёк 意思是矢車菊）。這是人名——Vasily。

✅ 「Vasily」——音譯，不要意譯

如何避免： 在翻譯檢查清單中加一條規則：「專有名詞、品牌名稱、產品名稱和地名不翻譯。」如果機器翻譯工具動到了名稱，立刻標記。這是機器總是出錯、而人類不會的領域之一。

9. 文化盲點

翻譯發生在文化之間，而不只是語言之間。如果忽略受眾的文化背景，再精準的翻譯也可能失敗。

❌ 以白色作為婚禮色彩，目標是華人或印度受眾。在許多東亞文化中，白色 = 喪事；紅色 = 婚禮。在西非部分地區，紅色 = 哀悼。

✅ 定案視覺 + 文字組合前，先研究目標文化的色彩象徵

❌ 某遊戲公司針對中東玩家的齋戒月活動中，角色帶著食物和啤酒。齋戒月是禁食的節日。

✅ 如果要引用某個文化或宗教活動，請教來自該文化的人

❌ 對中東和西非受眾的訊息中使用豎起大拇指的 emoji——這個手勢在那些地區大致等同於豎中指。

✅ 跨文化溝通時，文字比 emoji 安全。如果要用 emoji，先確認它在目標文化中的含義。

如何避免： 對於任何進入新市場的活動或文件，問一個問題：「審核流程中有當地人嗎？」如果沒有，就加一個。與撤回並重做一場失敗的活動相比，請母語人士花 15 分鐘審閱的成本等於零。

10. 字元編碼：「Krüger」變成「Kr?ger」

這是本清單中最不引人注目的錯誤——卻也是最常見的之一。當帶重音字母（é、ü、ñ、ç、ø）、CJK 字元或西里爾文字以錯誤的編碼儲存或傳輸時，就會變成亂碼。技術術語稱為 mojibake。

❌ 德語：「Krüger」→「Kr?ger」（或「Kr�ger」——取代字元字符）

✅ 「Krüger」——一律以 UTF-8 儲存與傳輸

❌ 日語：「翻訳」（「翻譯」）→ 電子郵件主旨列中變成「�|��」

✅ 「翻訳」——檢查電子郵件用戶端和 CMS 平台的編碼設定

❌ 俄語：「Россия」→ 當 Windows-1251 被當成 ISO-8859-1 讀取時變成「Ðîññèÿ」

✅ 一律使用 UTF-8。它能處理所有文字系統：拉丁字母、西里爾字母、CJK、阿拉伯字母、泰文——全都在同一種編碼中。

如何避免： 一律使用 UTF-8——它是現代標準，能處理現今使用的所有文字系統。在傳送或上傳譯文前，快速目視檢查：特殊字元看起來正確嗎？從 Excel 匯出時，在「另存新檔」對話方塊中明確選擇「CSV UTF-8」。有疑問時，用純文字編輯器開啟檔案——如果重音字元在那裡是壞的，那它在哪裡都是壞的。

快速參考：10 秒送出前檢查清單

在傳送、發布或列印譯文之前，先問完這四個問題：

1. 慣用語： 有任何詞語被逐字翻譯嗎？→ 換成當地的對等說法。
2. 正式程度： 語域適合受眾和情境嗎？→ 不確定時預設使用正式形式。
3. 日期： 日期格式是讀者預期的嗎？→ 明確標示格式。
4. 名稱： 有任何專有名詞被「翻譯」了嗎？→ 還原成原文。

十秒鐘。四個問題。它不會抓到所有錯誤，但能抓到那些會上新聞的錯誤。

FAQ

ChatGPT / Claude 會自動修正這些錯誤嗎？

不一定可靠。LLM 在慣用語處理和語域方面比舊式機器翻譯更好，但仍會犯假朋友錯誤、仍會誤譯名稱，也仍缺乏文化判斷力。它們不知道「Mother Dairy」是品牌名稱——它們只看到兩個詞，然後翻譯它們。請把 LLM 的輸出視為和任何其他機器翻譯一樣：一份需要人工審閱的優秀草稿。

在避免這些錯誤方面，免費工具和付費專業翻譯有何不同？

免費工具產出的是未經修飾的翻譯。專業譯者（以及像 OpenL 這樣的專業級平台）額外提供：術語管理以防不一致、格式保留以防版面破壞，以及情境意識以捕捉慣用語和假朋友。差距在錯誤 #1–5（慣用語、語域、假朋友和文化細微差異）上最大。在錯誤 #10（編碼——兩端的好工具都能妥善處理 UTF-8）上差距較小。

哪個錯誤最花錢？

錯誤 #5（盲目信任機器輸出）一直造成最昂貴的失敗。HSBC 的 1,000 萬美元品牌重塑、價值 5 萬美元的工廠設備毀損，以及 Meta 的政治人物死亡事件，全都可追溯到在未經人工審閱的情況下發布機器翻譯。解決方法——在內容上線前由人工閱讀輸出——只需幾分鐘，卻能省下數百萬美元。

Sources

• PMC/NIH: Errors in Japanese–English AI-assisted translation (2025) — taxonomy of AI translation failure types in medical texts
• STAR Translation: When Translation Goes Wrong — real-world mistranslation case studies including medical, branding, and signage
• POEditor: 6 Famous Mistranslations in Localization — HSBC, Pepsi, KFC, and other brand case studies
• Meta apologizes after auto-translation mistakenly announces Indian state chief minister’s death (CNN, July 2025) — Meta auto-translation falsely declaring a living politician dead
• Uber auto-translation: “Mother Dairy” becomes “threat of murder” (Livemint, 2025) — Hindi-to-English auto-translation blunder
• Montreal Transit: AI labels Bishop Street bus stop as “Beeshop” (CTV News, 2025) — AI signage translation failure
• Goethe-Institut: Oh Heavenly Berry — false friend stories from German learners — collection of false friend errors including “Himbeere” (raspberry) → “Himmelbeere” (heaven berry)
• W3C: Text Size in Translation — authoritative reference on text expansion rates across languages
• SandVox: Text Expansion in Localization — expansion rates by language with short-string amplification data
• Lingoda: False Friends in Languages — comprehensive false friend tables across major language pairs
• Ulatus: Lessons from Marketing Localization Failures — brand localization case studies and cultural blind spots
• Forbes: Why Global Brands Fail When They Communicate Locally (Feb 2026) — strategic perspective on localization failures