最近，一位朋友跟我聊到現在的遊戲翻譯工具。
只要框選螢幕上的一塊區域，工具就會讀取裡面出現的文字，再把翻譯結果顯示在半透明視窗中。雖然會有一些延遲，但如果翻譯階段使用LLM，就不只是機械式換字，而是能根據上下文做更自然的意譯。
我的第一個反應很單純：
「等等，現在已經到了不用等官方在地化或翻譯補丁，也能直接玩外語遊戲的程度了嗎？」
結果查著查著，話題完全從遊戲上脫軌。
OCR負責看螢幕。
翻譯模型負責理解意思。
Overlay負責把結果重新疊回原本畫面。
這個結構根本不只適用於遊戲。
如果已經有一套能產出12種高品質語言版本的多語文章系統，那為什麼不把這12種語言繼續保留為高品質核心，再用本地翻譯模型，只把熱門文章薄薄地撒到更多長尾語言？如此一來，幾乎不必增加LLM或雲端API的消耗。
明明只是從遊戲字幕開始聊。
最後卻變成全球內容分發架構會議。
1. 即時遊戲翻譯，其實就是四個零件
把即時翻譯Overlay當成魔法看，真的很厲害。
拆開後反而更有趣。
基本流程只有四步：
- 擷取遊戲畫面的指定區域。
- 用OCR把圖片中的文字轉成文本。
- 用翻譯引擎、NMT或LLM轉成目標語言。
- 把譯文以半透明Overlay重新顯示在遊戲畫面上。
公開的Windows工具已經有這種架構。OverlayTranslate會對畫面區域做OCR，再把譯文覆蓋到原本位置。SubLens則持續監看遊戲畫面的指定區域，偵測到新文字後翻譯，再顯示到透明Overlay。[1][2]
以前是「截圖→開翻譯網站→貼上→閱讀→切回遊戲」。
現在更像「告訴翻譯員要盯哪裡，然後讓他一直坐在遊戲旁邊」。
人類終於開始在沒有在地化的RPG旁邊召喚常駐口譯員。
2. Google Lens很好用，但它不是遊戲常駐翻譯Overlay本身
Google Lens可以辨識照片或相機畫面中的物件與文字，也能選取並翻譯圖片中的文字。[3]
Google翻譯也支援圖片翻譯。PC可以上傳圖片並翻譯其中的文字，手機則可透過相機進行翻譯。Google自己也提醒，小字、模糊文字和裝飾字體都可能降低準確度。[4]
所以Lens很像整個系統的「眼睛」。
但朋友描述的遊戲翻譯工具再往前一步。
Lens比較像「請讀這張圖」。
遊戲Overlay則是「請一直盯著這個區域，只要有新台詞就自動處理」。
差別不只是翻譯品質。
持續擷取、差異偵測、快取、視窗焦點判斷、把字幕重新畫回正確位置，這些不起眼的周邊工程才真正決定使用體驗。
AI負責搶版面。
管線工程負責讓你順利破關。
3. 「Google翻譯不是LLM吧？」到了2026年已經不能一句話講完
如果想到的是以前的Google翻譯，把它和ChatGPT這類系統分開理解，大致沒有錯。
Google翻譯長期以專門的神經機器翻譯為核心。
但2025年12月，Google宣布把Gemini的翻譯能力導入Google Translate的文字翻譯，特別強化俚語、慣用語和高度依賴上下文的表達。[5]
2026年2月，Google又利用Gemini的多語能力，加入更多譯法建議與語氣、語意說明。[6]
語音方面，Google之後公布Gemini 3.5 Live Translate，可在70多種語言提供接近即時的語音對語音翻譯。[7]
因此在2026年，如果一句話說「Google翻譯不是LLM」，已經太粗糙。
反過來說「每一次Google翻譯都直接丟進一個通用Gemini聊天模型」也同樣過度簡化。
Google公開的是Gemini能力已整合到Translate，而不是完整內部路由架構。
更精確的說法是：邊界正在變模糊。
4. 免費的Google翻譯和自動化API不是同一件事
看到這裡，很容易冒出一句：
「那文章全部丟免費Google翻譯不就好了？」
很誘人。
但一般使用者使用Google翻譯不按字元計費，不代表程式可以透過官方API無限免費自動翻譯。
Google Cloud Translation的NMT目前提供每月前50萬字元的免費額度，超過後的標準價格是每100萬字元20美元。[8]
假設一篇文章有5,000字元。
翻譯成50種語言，就是25萬字元。
兩篇就是50萬。
如果一個月把10篇熱門文章翻成50種語言，會到250萬字元。扣掉免費部分後，剩下200萬字元依標準價約40美元。
很便宜。
但不是零。
Google Cloud的Translation LLM另外還有輸入與輸出費用。[8]
如果「不能有持續API費」是硬條件，比起無限增加雲端翻譯，更乾淨的方案是另外建立本地翻譯通道。
5. 真正適合零API費用路線的，是本地翻譯模型
這時，本地翻譯模型就登場了。
Google公開的MADLAD-400-3B-MT在Hugging Face上標示支援419種語言，採Apache 2.0授權。[9]
如果在自己的機器上運行，就不會每次翻譯都產生API費用。
當然，這不代表真實成本字面上等於零。
它會用CPU或GPU。
會用電。
會花時間。
但擴張模式不同了：不再是多翻一個字就多付一點雲端費用。
最重要的注意事項是，不要把「支援419種語言」理解成「419種語言全部都有人類翻譯品質」。
低資源語言的品質差異可能很大。
所以本地翻譯不該取代高品質12語言，而應該成為以前因成本無法測試的語言之實驗層。
6. 這時話題從遊戲跳到文章工廠——高品質12語言不要動
如果一套多語文章系統已經用LLM產出12種高品質語言版本，就沒有必要為了省錢把它們降級成廉價機器翻譯。
那12種語言就是母艦。
假設核心包含日文、英文、韓文、簡體中文、繁體中文、西班牙文、巴西葡萄牙文、印尼文、泰文、越南文、法文和德文。
如果這些版本已經完成脈絡整理、自然意譯、標題與小標調整、品質檢查，那它們不只是12份翻譯。
它們是12種已經整理過語意的中間表示。
製作追加語言時，也不必永遠從日文直接翻。
對某些目標語言，英文版、西班牙文版或印尼文版可能是更好的中介來源。
但翻譯鏈越長，誤差也可能累積。
因此不能只憑「語言很接近」就決定父語言，而應該以小型基準測試比較多個來源，確認數字、專有名詞、否定、限定語和整體語意保留程度，再為每種目標語言固定最穩定路線。
7. 不做「所有文章×所有語言」。熱門度就是過濾器
這是整個設計最划算的部分。
即使有5,000篇文章，也不用把5,000篇全部翻成100種語言。
先處理熱門文章就好。
例如依最近30天PV：
- 前10名：增加50種語言
- 第11到50名：增加20種語言
- 其他：只保留高品質12語言
也可以更簡單：每天取前20篇文章，只翻譯尚不存在的「文章×語言」組合。
一旦建立，翻譯就會留下成為資產。
於是每天從熱門內容開始，世界地圖慢慢被填滿。
這不是「第一天就在全世界蓋完整基地」。
而是「先派幾乎免費的偵察兵出去，有反應的地方再派主力」。
更聰明。
也更省錢。
8. 把語言分成三層，讓真實需求決定品質投資
新增語言可以分三層。
Core：目前的高品質12語言。LLM在地化、嚴格QC、全文章覆蓋。
Growth：已開始產生真實流量的新增語言。仍以本地翻譯為基礎，但增加文章數量。
Experimental：需求未知的長尾語言。只翻熱門文章，初期也可以限制搜尋索引。
之後依訪問、閱讀完成度、下一篇點擊、回訪等指標升級。
Experimental沒人讀，就保持原樣。
波蘭文有流量，就升到Growth。
土耳其文持續成長，而且讀者行為也好，就成為Core候選。
如此便不必在會議室裡猜「下一個會紅的是哪種語言？」
翻譯本身就是市場調查。
9. 想維持免費結構，就先建立不依賴LLM的QC
如果每個新增翻譯都再丟給ChatGPT問「這個對不對？」，免費翻譯策略很快就不免費了。
第一層QC應該由程式碼完成。
能自動檢查的項目其實很多：
- 數字、百分比、貨幣、日期是否保留
- URL是否改變
- 小標數量是否異常減少
- Markdown或HTML結構是否損壞
- 標題與description是否為空
- 是否殘留大量來源語言
- 是否明顯偏離目標語言的文字系統
- 是否疑似遺失否定
- 專有名詞是否異常變形
- 輸出長度是否相對原文明顯過短或過長
必要時還可以用本地模型逆向翻回英文等中介語言，只把語意偏差很大的項目標記出來。
這不是完美的品質評估。
但對防止壞翻譯被大規模發布非常有用。
昂貴的LLM應該當異常案件複檢員，而不是全量流水線檢查員。
10. 比「100種語言」更重要的是，不要製造100堆垃圾
最後還有一個坑。
多做很多語言頁面，不代表搜尋流量會按同樣倍數成長。
Google Search Central建議不同語言版本使用不同URL，並透過hreflang等方式標示對應關係；同時頁面的內容與導覽都應清楚呈現單一語言。[10]
另一方面，Google也把以操弄搜尋排名為主要目的、透過自動轉換或翻譯大量建立低價值頁面的行為列為scaled content abuse的例子。[11]
所以Experimental頁面一產生，不需要立刻全部送進搜尋索引。
可以先noindex。
先看品質與需求。
只有通過品質閘門的語言再進index。
讀者必須真的能閱讀。
不能只翻文章正文，介面也要對應。
語言URL與hreflang要正確。
語意不能壞掉。
原始文章本身也必須有價值。
做到這些，語言數量才是資產，而不是垃圾倍增器。
整件事一開始，只是朋友聊到遊戲翻譯。
「現在可以讀螢幕上的文字，用LLM翻得比較自然，再透過半透明視窗疊回去。」
接著查Google Lens，查Google翻譯與LLM之間正在改變的界線，再查API價格，最後跑到本地翻譯模型。
最後得到的設計很簡單：
高品質12語言維持原樣。
只把熱門文章透過本地翻譯低成本擴散到更多語言。
真正產生需求的語言，再升級到更高品質層。
一開始只是在遊戲畫面上疊一層翻譯字幕。
最後卻變成在整個文章系統上，一層一層疊加全世界的語言。
技術轉用，大概就是從這種合理的離題開始。
參考資料（11筆）
- OverlayTranslate — Windows overlay translation tool using OCR and multiple translation engines github.com
- SubLens — real-time OCR-powered game dialog translator with continuous scan and transparent overlay github.com
- Google Search Help — Google Lens can select text and translate supported text through Google Translate support.google.com
- Google Translate Help — image translation on desktop and mobile; Google notes lower accuracy for small, unclear, or stylized text support.google.com
- Google, 2025-12-12 — Bringing state-of-the-art Gemini translation capabilities to Google Translate blog.google
- Google, 2026-02-26 — AI-powered context and translation alternatives in Google Translate using Gemini capabilities blog.google
- Google, 2026-06-09 — Gemini 3.5 Live Translate, near-real-time speech-to-speech translation in more than 70 languages blog.google
- Google Cloud Translation pricing — NMT first 500,000 characters per month covered by free credit, then standard per-character pricing; Translation LLM priced separately cloud.google.com
- Google MADLAD-400-3B-MT on Hugging Face — 419 languages listed, Apache 2.0 huggingface.co
- Google Search Central — Managing multi-regional and multilingual sites; separate URLs and hreflang guidance developers.google.com
- Google Search Central — Spam policies; scaled content abuse includes low-value pages generated through automated transformations such as translating when created primarily to manipulate rankings developers.google.com
