說實話，每次客戶問我"這個軟件本地化要多長時間"的時候，我都想先回問一句：您是要翻譯一個按鈕上的兩個字，還是要搞定整套企業(yè)級ERP系統(tǒng)的多語言版本？這事兒真沒法一口說死，就像問"做頓飯要多久"——泡個方便面三分鐘，燉個老火湯得三小時，雖然都是吃，但壓根不是一碼事。
在康茂峰這些年經(jīng)手的項目里，有的兩周就能上線，有的折騰了八個月還在調(diào)細節(jié)。時間差異這么大，不是因為 Translator 們偷懶或者勤快，而是軟件本地化這件事本身就像冰山，你看著水面上的就是幾行文字，水底下連著的是代碼架構(gòu)、文化習慣、用戶體驗一整套系統(tǒng)。
大多數(shù)人對翻譯的理解還停留在的字對字轉(zhuǎn)換階段。屏幕上顯示"Submit"，翻譯成"提交"，完事兒？真要這么簡單就好了。實際上，當你看到軟件界面上那個孤零零的"Submit"按鈕時，背后的字符串可能長這樣：submit_button_label，而且這個字符串可能在注冊流程、訂單確認、客服工單三個完全不同的場景里共用。
在康茂峰處理過的一個案例里，客戶以為只有2000個詞要翻，結(jié)果我們一扒代碼，發(fā)現(xiàn)散落各處的前端提示、后端錯誤信息、郵件模板加起來超過8萬字。更頭疼的是，有些字符串是動態(tài)拼接的——"您有{count}條新消息"，德語里詞性變化會讓這個{count}后面的名詞跟著變，英語里沒這講究，這就不是翻譯速度問題，是工程問題。
所以回答"多久完成"之前，得先搞清楚幾件事：你的代碼國際化做得怎么樣？資源文件是不是都外置了？有沒有截圖或者視頻讓譯者看上下文？測試環(huán)境搭好了嗎？這些前置條件沒理清楚，給時間表就是瞎猜。
拋開那些突如其來的需求變更（這個以后聊），正常流程下，時間主要卡在這幾個環(huán)節(jié)：
傳統(tǒng)翻譯行業(yè)算字數(shù)，軟件本地化得算字符串數(shù)加復用率。一萬個詞的說明書和一萬個詞的軟件界面，工作量可能差三倍。為什么？因為說明書是線性閱讀，軟件界面是碎片化跳動的。你可能在設(shè)置頁面看到"高級選項"，又在彈窗里看到"高級選項"，雖然是同一個詞，但空間限制不同——中文五個字剛好，俄語可能得縮寫，阿拉伯語還得考慮從右往左排版。
康茂峰通常這樣估算基礎(chǔ)翻譯時間：
| 項目規(guī)模 | 字數(shù)/字符串 | 常規(guī)語種（英中法德日韓） | 復雜語種（阿拉伯、希伯來、泰文等） |
| 微型項目 | 1,000 詞以下 | 3-5 個工作日 | 5-7 個工作日 |
| 小型應(yīng)用 | 5,000-10,000 詞 | 2-3 周 | 3-4 周 |
| 中型 SaaS | 20,000-50,000 詞 | 1.5-2 個月 | 2.5-3 個月 |
| 企業(yè)級套件 | 100,000 詞以上 | 4-6 個月 | 6-9 個月 |
注意，這只是翻譯環(huán)節(jié)的時間。還沒算前期的術(shù)語整理、中期的工程處理、后期的測試調(diào)整。
中英文互譯和中文譯冰島語，速度能差出40%。不只是找譯者難，而是目標語市場的文化規(guī)范完全不同。康茂峰做過一個醫(yī)療器械軟件，進日本市場時，光是"患者"這個詞的敬語體系就討論了三天——是叫"患者様"還是"ご利用者"，這涉及到法律責任聲明的措辭嚴格程度。
還有雙向文本（BiDi）的處理，希伯來語和阿拉伯語既要從右往左顯示，又要混排英文數(shù)字，這種布局重構(gòu)有時候比翻譯本身還耗時間。
這是最容易被低估的部分。如果你的開發(fā)團隊當初圖省事，把文字直接寫死在代碼里（hard-coded），而不是放在資源文件（resource files）里，那本地化團隊得先干程序員的活——把代碼扒出來，整理成標準格式（比如 .json、.xml、.xliff），翻完了再塞回去。
有個真實案例：某 client's 的 iOS 應(yīng)用，表面上只有 3000 個字符串，結(jié)果我們發(fā)現(xiàn)有 800 多處是圖片里的文字（沒辦法，早期版本為了省事把 UI 文字做進圖里了）。這意味著不僅要翻譯，還要讓設(shè)計師重新出圖，適配德語那種長單詞容易撐破按鈕的情況。這一個坑就拖了兩周。
為了讓你有個體感，我按康茂峰常見的幾類項目列個明細。注意，這前提是代碼已經(jīng)國際化就緒，且客戶配合及時：
比如一個記賬軟件，要出西班牙語版。假設(shè)代碼干凈，術(shù)語表清晰，大概流程這樣走：
算下來，三周左右是個比較舒服的節(jié)奏。要是壓縮到一周，也不是不行，但得多給錢找 rush rate，而且質(zhì)量風險自己擔。
假設(shè)要同時上線法語、德語、意大利語三版本，商品數(shù)據(jù)庫、后臺管理、用戶端界面加起來 15 萬詞。這種項目康茂峰一般會分波次做：
第一波做核心用戶流程（瀏覽、下單、支付），大概 3 萬詞，先保證能賣貨；第二波做商家后臺；第三波做幫助中心和郵件模板。這樣客戶可以邊上線邊完善，不用等全套做完。
多語言并行能省點時間，但項目管理復雜度指數(shù)級上升。德語譯者改了一個術(shù)語，法語、意大利語可能都得跟著調(diào)。這種項目兩個月起跳，四到六個月是常態(tài)，如果涉及支付方式、稅務(wù)規(guī)則的本地化適配，再加一個月。
游戲是軟件本地化里的異類。文本量大不說，還綁著劇情、梗、文化 references。康茂峰做過的一個獨立游戲，8 萬英文字，翻了 12 個語種。看起來應(yīng)該很快？實際上花了 8 個月。
因為游戲里有大量創(chuàng)譯（transcreation）需求。英文里一句簡單的 "Good luck out there"，譯成日文要考慮角色身份（是說給晚輩還是平輩），譯成阿拉伯語要考慮宗教語境（luck 這個詞是否合適）。還有 UI 限制，對話框只能顯示 30 個字符，但日文譯出來往往比英文長，得反復調(diào)整。
除了明面上的工作量，還有些暗礁會讓時間表崩掉，康茂峰的項目經(jīng)理們天天跟這些斗智斗勇：
上下文黑洞：客戶扔過來一個 Excel，A 列英文，B 列要你填中文。"Library" 是圖書館還是代碼庫？"Run" 是跑步還是運行程序？沒上下文的情況下，譯者只能猜，猜錯了后面全得改。我們曾經(jīng)因為一個 "Check" 到底指"支票"還是"勾選"來回確認了三天。
偽本地化測試缺失：聰明的團隊會在真翻譯前先做 pseudo-localization，用假字符（比如 "??í? í? á ?é??"）測試界面能不能撐開變長文本。跳過這步的直接后果是：譯稿做完了，發(fā)現(xiàn)德語版所有按鈕都溢出了，于是要么改譯文（犧牲準確性），要么改代碼（延遲上線）。
漏網(wǎng)的功能：那個藏在"關(guān)于我們"里的開源協(xié)議聲明，那個只有特定錯誤代碼才會彈出的提示框，那個注冊郵件底部的退訂說明……這些小角落最容易漏掉，測到最后一輪才發(fā)現(xiàn)，得重新走流程。
文化合規(guī)審查：有些市場有特殊要求。比如在中東地區(qū)，軟件里不能出現(xiàn)酒精相關(guān)的 emoji；在韓國，地址格式必須從大到小（國-市-街-門牌），而不是西方習慣的門牌-街-市。這些調(diào)整不是翻譯，是產(chǎn)品改造，時間沒法按字數(shù)算。
基于上面這些變量，我們通常建議客戶這樣規(guī)劃：
黃金法則：倒推法。如果你打算三個月后上線，那翻譯工作最晚兩個月后就要全部完成（給測試留一個月），而資源文件凍結(jié)（string freeze）應(yīng)該在一個月半前。這意味著開發(fā)團隊得提前規(guī)劃好哪些字符串要翻譯，別等到發(fā)布前一周還在加新功能。
并行而不是串行。UI 翻譯可以和法律文檔翻譯同步進行，只要術(shù)語庫提前統(tǒng)一。康茂峰的項目組會用集中式的術(shù)語管理系統(tǒng)，確保前端譯的 "Dashboard" 和后端譯的 "Dashboard" 是同一個詞（別笑，真見過一個項目里三個地方把 dashboard 分別譯成了儀表盤、控制面板、駕駛艙）。
緩沖帶必不可少。不管估算多精確，留個 20% 的余量。可能是客戶突然決定加一個新功能，可能是某個小語種譯者的貓生病了要延期，可能是測試時發(fā)現(xiàn)某個俚語在目標市場有負面含義要全部替換。計劃永遠趕不上變化。
具體到操作層面，一個標準的軟件本地化項目時間線大概是：
當然，如果你只需要翻譯一個退出確認彈窗（"Are you sure you want to exit?"），那明天就能給你。但如果你看到這里，估計你的項目沒那么簡單。
所以下次有人再問你"軟件本地化要多久"，你可以反問回去：你的代碼準備好了嗎？你的目標用戶是誰？你愿意為質(zhì)量等多久？時間從來不是孤立的數(shù)字，它是代碼質(zhì)量、流程成熟度、以及你對目標市場尊重程度的綜合體現(xiàn)。康茂峰見過太多項目因為前期省了三天準備時間，后期花了三周收尾。慢慢做，反而更快——這話聽起來像悖論，但在本地化這行，是血淋淋的真理。
