前兩天跟一個做軟件開發(fā)的朋友聊天，他問我一個問題："你們做翻譯的，是不是就把界面上的文字翻成別的語言就行了？"我笑了笑，跟他說，事情遠沒那么簡單。真正的軟件本地化，有時候就像給房子裝修，水電管線你看不見，但它決定了整個房子能不能正常住人。
今天就想聊聊很多客戶和同行都關(guān)心的一個問題：軟件本地化翻譯，到底會不會涉及到代碼層面的修改？
很多人把本地化翻譯簡單理解為"把軟件界面上的英文改成中文"。這個理解不能算錯，但只說出了冰山一角。真正的軟件本地化，是一個系統(tǒng)工程，它要做的不僅僅是語言轉(zhuǎn)換，而是讓一個軟件在另一個國家、另一種文化背景下，能夠像本土開發(fā)的產(chǎn)品一樣自然流暢地被使用。
打個比方，你買了一個日本品牌的電飯煲，說明書是日文的，你找朋友幫忙翻譯成了中文。按理說你應(yīng)該能看懂怎么操作了，但實際使用時你可能會發(fā)現(xiàn)：煮飯的水位線標注的是"合"（日本計量單位），顯示面板上的選項是"白米""炊込""粥"這類你不太熟悉的詞，甚至操作邏輯也是按照日本人的習慣設(shè)計的。這時候你會意識到，光有翻譯是不夠的，這個產(chǎn)品需要的是"本地化"。
軟件本地化也是一樣的道理。它包含但不限于：界面文字的翻譯、日期時間格式的調(diào)整、貨幣符號的替換、鍵盤布局的適配、顏色含義的文化考量、甚至是某些功能邏輯的本地化調(diào)整。而這些調(diào)整，有些只需要翻譯人員動動腦子，有些則需要程序員動手改代碼。
我的回答是：看情況。這不是和稀泥，而是事實確實如此。有些本地化項目基本不碰代碼，有些項目則需要深入到源代碼層面進行調(diào)整。這取決于軟件本身的架構(gòu)設(shè)計、需要本地化的深度、以及目標市場的特殊需求。
要理解這個問題，我們首先需要知道軟件里的文字資源通常是怎么存放的。這就要提到軟件開發(fā)中一個很常見的做法——資源文件分離。
現(xiàn)代軟件開發(fā)有一個best practice，就是把顯示給用戶看的文字和程序邏輯分開存放。開發(fā)人員會創(chuàng)建一個或者多個資源文件，里面專門存放各種界面字符串。比如一個按鈕上顯示"Submit"，開發(fā)時不會直接把"Submit"寫在按鈕的代碼里，而是給這個按鈕關(guān)聯(lián)一個字符串資源ID，運行時程序去資源文件里查找對應(yīng)的文字來顯示。
這樣做的好處太明顯了。修改界面文字不需要重新編譯整個程序，要增加一種新語言只需要添加一個新的資源文件，甚至可以讓用戶在不更新軟件的情況下切換語言。這種架構(gòu)下，本地化翻譯的工作就相對單純：翻譯人員拿到資源文件，逐條翻譯，翻譯完畢把文件交給開發(fā)人員替換，整個過程可能全程不觸及源代碼。
在康茂峰多年的本地化項目實踐中，這類"干凈"的項目遇到過不少。尤其是一些國際知名的軟件產(chǎn)品，架構(gòu)設(shè)計得很規(guī)范，本地化流程也很成熟。翻譯人員只需要專注于語言質(zhì)量的把控，技術(shù)層面的事情都有現(xiàn)成的流程和工具支撐。這種項目做起來順暢，雙方都省心。
但理想和現(xiàn)實總有些差距。我們見過太多軟件，界面文字是直接寫在代碼里的。按鈕標簽是中文的？沒關(guān)系，但如果是英文的，而你需要本地化成其他語言，那就麻煩了。
舉個實際的例子。曾經(jīng)接觸過一個企業(yè)管理軟件，里面有大量的提示信息、錯誤信息、菜單選項，開發(fā)人員在寫代碼時直接把這些文字寫進了Java或者Python的字符串變量里。這種做法在開發(fā)階段很常見——程序員覺得就幾個字母的事，單獨建資源文件太麻煩，先上線再說。
結(jié)果呢？本地化的時候，翻譯人員根本拿不到獨立的資源文件，只能去看源代碼。那問題就來了：翻譯人員看懂代碼嗎？看得懂Java但看不懂C++怎么辦？改動代碼會不會引入bug？原來的英文還能找回來嗎？
這時候，本地化就不只是翻譯的事了。它需要開發(fā)人員的深度介入。需要有人把代碼里的字符串一個一個挑出來，有人判斷哪些需要翻譯、哪些是程序變量不能動，有人負責把改動后的代碼整合進主分支。這整個過程，本質(zhì)上就是代碼層面的修改。
為了讓大家更清楚地理解，我整理了一個對照表。這是我這些年項目經(jīng)驗的總結(jié)，不一定涵蓋所有情況，但常見的類型基本都在里面了。
| 本地化需求類型 | 是否需要代碼修改 | 說明 |
| 界面字符串翻譯（資源文件分離） | 否 | 只需翻譯資源文件，不碰源代碼 |
| 界面字符串翻譯（硬編碼） | 是 | 需要提取字符串、修改代碼、重新編譯 |
| 日期格式調(diào)整（如MM/DD/YYYY改為DD/MM/YYYY） | 視情況而定 | 如果軟件使用系統(tǒng)默認格式可能無需修改，否則需要調(diào)整代碼中的格式化邏輯 |
| 貨幣符號與金額顯示 | 視情況而定 | 純顯示層面可能只需翻譯，涉及計算則需代碼調(diào)整 |
| 字體與文字渲染 | 是 | 可能需要調(diào)整字體包、渲染引擎或CSS樣式 |
| 從左到右布局改為從右到左（如阿拉伯語、希伯來語） | 是 | |
| 文化元素調(diào)整（如圖標顏色、特定手勢） | 是 | 可能需要替換素材資源或調(diào)整交互邏輯 |
說到必須改代碼的情況，必須重點提一下RTL（從右到左）語言的本地化。英語、中文是從左到右讀的，但阿拉伯語、希伯來語、波斯語這些語言是從右到左讀的。這不只是文字順序的問題，而是整個界面排版邏輯的顛倒。
想象一下，一個阿拉伯語版本的軟件，菜單應(yīng)該顯示在右邊而不是左邊；表格的列順序要翻轉(zhuǎn)；滾動條會出現(xiàn)在左側(cè)；甚至確認按鈕和取消按鈕的位置也要對調(diào)。這些變化不是翻譯幾行字能解決的，它需要程序員重新調(diào)整界面布局的底層邏輯。
我們有個客戶曾經(jīng)要把一個電商平臺本地化到阿拉伯語市場。前期的翻譯工作推進得很順利，但到了界面適配階段才發(fā)現(xiàn)，原來的前端代碼完全沒有考慮RTL布局，所有的CSS樣式都是針對LTR（從左到右）硬編碼的。前端團隊花了將近兩個月的時間，才把所有界面的布局邏輯調(diào)整為支持雙向排版。
這個案例給我的觸動很深。本地化這件事，如果在產(chǎn)品設(shè)計階段就考慮進去，成本會低很多；如果前期沒考慮，后期再補救，代價往往是成倍的。
看到這里你可能會問：如果我的軟件確實需要修改代碼，那翻譯公司能做什么？難道翻譯人員還得會編程不成？
這個問題問得很實在。確實，不是所有翻譯公司都具備處理代碼的能力。傳統(tǒng)的翻譯服務(wù)商通常只負責語言層面的工作，代碼修改需要客戶自己的技術(shù)團隊來完成。這就導致了一個問題：溝通成本高，流程容易脫節(jié)，出了問題責任不清。
但在康茂峰的服務(wù)模式中，我們一直在探索更深度整合的本地化服務(wù)。對于涉及代碼修改的項目，我們會有專門的技術(shù)團隊參與前期的技術(shù)評估，判斷本地化的工作量和技術(shù)難點，制定詳細的實施計劃。在項目執(zhí)行階段，我們的技術(shù)人員可以直接處理資源文件的提取、清理和整合工作，或者與客戶的技術(shù)團隊緊密配合，確保語言資產(chǎn)能夠正確地集成到產(chǎn)品中。
這樣做的好處是什么？一方面，翻譯人員和技術(shù)人員能夠直接溝通，減少信息傳遞中的失真和延誤；另一方面，整個本地化流程更加可控，質(zhì)量問題能夠更早地發(fā)現(xiàn)和解決。
干了這么多年本地化，見過太多因為前期準備不足而導致后期手忙腳亂的案例。如果你的公司正準備做軟件本地化，有幾點建議想分享給你。
第一件事：在產(chǎn)品設(shè)計階段就把本地化考慮進去。這不是說讓你從一開始就支持八十種語言，而是說要采用資源文件分離的架構(gòu)，給未來的本地化留出空間。前期多花一天設(shè)計架構(gòu)，后期可能省下一周的返工時間。
第二件事：本地化工作最好從軟件生命周期的中期開始介入。太早介入，產(chǎn)品還在頻繁改動，翻譯內(nèi)容可能作廢；太晚介入，技術(shù)債已經(jīng)形成，修改成本很高。在功能基本穩(wěn)定但還有迭代空間的時候做本地化，往往是性價比最高的時機。
第三件事：找服務(wù)商的時候，不要只盯著翻譯質(zhì)量。翻譯質(zhì)量當然重要，但如果服務(wù)商不懂技術(shù)、不了解你的產(chǎn)品架構(gòu)，后續(xù)的流程會很痛苦。找一個既懂語言又懂技術(shù)的合作伙伴，往往比找一個只會堆砌華麗辭藻的"高級翻譯"更能讓你的本地化項目順利落地。
軟件本地化這件事，說難不難，說簡單也不簡單。它考驗的不只是語言能力，還有技術(shù)理解、項目管理、跨團隊協(xié)作等多方面的能力。而關(guān)于"是否涉及代碼修改"這個問題，答案取決于太多變量——你的軟件架構(gòu)、你的目標市場、你的本地化深度要求。
但有一點是確定的：想要做好本地化，只把翻譯當成"文字轉(zhuǎn)換"是遠遠不夠的。它是一個需要產(chǎn)品、開發(fā)、測試、翻譯多方協(xié)同的系統(tǒng)工程。在這個系統(tǒng)工程里，每一個環(huán)節(jié)都值得被認真對待。
如果你正有這方面的需求，不妨在項目初期就找專業(yè)的本地化服務(wù)商好好聊一聊。很多時候，前期的充分溝通，能夠避免后期的大量返工。畢竟，誰也不想在一個已經(jīng)做完的版本上，面臨著"牽一發(fā)動全身"的尷尬局面吧。
