說實話，我剛接觸本地化翻譯那會兒，對"字符串"這個概念是模糊的。總覺得不就是把英文翻成中文嘛，能有多復(fù)雜？后來發(fā)現(xiàn)，事情完全不是我想的那樣。軟件里的字符串跟Word文檔里的文字根本不是一回事，它有自己的脾氣，有自己的規(guī)則，也有自己的陷阱。
今天我想用比較接地氣的方式聊聊，軟件本地化翻譯到底是怎么處理字符串的。這里會用一些康茂峰在實踐中積累的經(jīng)驗，盡量把那些技術(shù)性的東西講得通俗易懂。
簡單說，字符串就是軟件界面里那些會被翻譯的文字。但它遠不止是"顯示在屏幕上的字"這么簡單。
舉個很常見的例子。你打開一個軟件，界面上有個按鈕寫著"OK"。這個詞看起來夠簡單了吧？但如果我告訴你，這個"OK"在不同的語境下可能需要翻譯成完全不同的詞，你會怎么想？
有些情況下，"OK"就是確認(rèn)的意思，翻譯成"確定"或者"好"就行。但有些情況下，"OK"可能是一個狀態(tài)標(biāo)識，比如"設(shè)置已保存，狀態(tài)為OK"，這時候它可能需要翻譯成"正常"或者"成功"。還有更極端的情況，這個"OK"根本不需要翻譯，保持英文就行。
這就是軟件字符串的詭異之處。同樣的字串，在不同的上下文里可能有完全不同的處理方式。所以本地化翻譯的第一步，往往不是拿起鍵盤就翻，而是先把字符串的來龍去脈搞清楚。
軟件開發(fā)的時候，程序員寫代碼會把界面上要顯示的文字單獨存放在資源文件里，而不是硬編碼在程序邏輯中。這種做法的好處是，修改界面文字不需要改動程序代碼，翻譯的時候也只需要處理這些專門的資源文件。
常見的資源文件格式有很多，比如Windows系統(tǒng)常用的RESX和RC文件，Java程序用的PROPERTIES文件，網(wǎng)頁應(yīng)用常見的JSON和XML文件，還有蘋果系統(tǒng)用的STRINGS文件。每種格式都有自己的特點，提取工具也各不相同。
提取字符串這個環(huán)節(jié)看似簡單，實際上坑很多。有些字符串是可見的，用戶能直接看到；有些則是隱藏的，只有在特定操作后才會顯現(xiàn)。提示信息、錯誤消息、菜單項、按鈕標(biāo)簽、幫助文檔，這些都屬于需要翻譯的內(nèi)容，但它們的格式和位置可能完全不同。
更有意思的是，同一個字符串可能在代碼里被引用好多次。這時候如果翻譯不統(tǒng)一，就會出現(xiàn)界面混亂的問題。比如一個程序把"Cancel"在界面上顯示為"取消"，在某個下拉菜單里卻顯示為"放棄"，用戶肯定會覺得這個軟件做得太糙了。
如果說普通的字符串是本地化的入門關(guān)卡，那含有變量和占位符的字符串就是進階挑戰(zhàn)。這東西有多煩人呢？
讓我舉個例子。軟件開發(fā)中經(jīng)常會有這樣的提示信息："您有%d條新消息"。這里的%d是一個占位符，實際運行時會替換成具體的數(shù)字，比如"您有5條新消息"。如果只翻譯字面意思，翻成"你有條新消息"，那到時候顯示出來就會是"您有5條新消息"，少了個量詞，語法都錯了。
更復(fù)雜的情況是多個變量共存。比如"來自%s的消息：%s"，這里有兩個%s，第一個是發(fā)送者名字，第二個是消息內(nèi)容。翻譯的時候不僅要考慮兩個變量各自的位置，還要考慮它們之間的標(biāo)點和分隔方式。
不同的編程語言對變量的標(biāo)記方式也不一樣。有的用%d表示整數(shù)，有的用%s表示字符串，有的用%f表示浮點數(shù)。還有用花括號的，比如{0}、{1}，或者用命名占位符的寫法{name}、{count}。翻譯人員需要了解這些不同的寫法，才能在翻譯時正確處理每個占位符的位置。
這里有個關(guān)鍵原則：占位符的位置可以調(diào)整，但占位符本身絕對不能刪改或移動。舉個反例，如果原字符串是"Show {0} of {1} results"，有人翻成了"顯示{1}條結(jié)果中的第{0}條"，雖然讀起來好像也通順，但程序運行時會出錯，因為變量替換的順序變了。
英語的復(fù)數(shù)規(guī)則相對簡單，大多數(shù)詞加s或es就行。所以英文軟件里經(jīng)常能看到類似"1 file(s)"這樣的寫法，通過括號里的s來兼顧單數(shù)和復(fù)數(shù)。但這種方法在翻譯時會遇到問題，因為不是所有語言都這么處理復(fù)數(shù)的。
俄語有三種復(fù)數(shù)形式，分別對應(yīng)不同的數(shù)字區(qū)間。阿拉伯語的復(fù)數(shù)形式更多，高達六種。波蘭語的復(fù)數(shù)形式則取決于數(shù)字的最后幾位數(shù)字，而不僅僅是數(shù)字本身。這意味著同一個詞，根據(jù)數(shù)字的不同，可能需要完全不同的翻譯。
有些語言根本沒有復(fù)數(shù)概念，或者復(fù)數(shù)形式和單數(shù)完全一樣。遇到這種情況，翻譯時就需要根據(jù)目標(biāo)語言的語法規(guī)則來調(diào)整，而不是機械地把原文的復(fù)數(shù)形式翻譯過去。
好的本地化工具會提供專門的復(fù)數(shù)形式編輯界面，讓翻譯人員可以為同一條字符串提供多個翻譯版本，每個版本對應(yīng)不同的數(shù)字規(guī)則。但這就要求翻譯人員不僅要懂源語言和目標(biāo)語言，還要了解目標(biāo)語言の數(shù)詞變化規(guī)則。
本地化翻譯最痛苦的事情之一，就是拿到一條字符串，卻完全不知道它會用在哪里。
我舉個例子。假設(shè)有這么一條字符串："Drive"。這個詞在技術(shù)文檔里可能指的是硬盤分區(qū)，在汽車相關(guān)的軟件里可能指的是駕駛行為，在游戲里可能指的是關(guān)卡或賽道。如果沒有任何上下文，翻譯人員只能靠猜，猜對了皆大歡喜，猜錯了就等著被測試人員報bug吧。
康茂峰的本地化團隊在處理這類情況時，通常會建立一套上下文收集機制。翻譯開始前，會和開發(fā)團隊溝通，獲取界面截圖、用途說明、使用場景等信息。有些比較規(guī)范的項目，還會在資源文件里用注釋的方式標(biāo)注每個字符串的用途。
但現(xiàn)實總是比理想骨感。很多項目的字符串注釋要么不完整，要么干脆沒有。這時候有經(jīng)驗的翻譯人員會怎么做？他們會去分析字符串所在的代碼模塊、關(guān)聯(lián)的變量名稱、所在的界面位置，從這些信息里反向推斷可能的含義。
如果推斷不出來怎么辦？最好的辦法是標(biāo)注為"待確認(rèn)"，等項目負(fù)責(zé)人提供更多信息再處理。硬著頭皮隨便翻一個，雖然可能省了一時的事，但后續(xù)返工的成本往往會更高。
除了文字內(nèi)容，軟件界面里還有大量需要格式化的數(shù)據(jù)，比如數(shù)字、日期、時間、貨幣。這些東西看起來是"數(shù)"，實際上是"文"，同樣需要翻譯處理。
先說日期格式。美國人習(xí)慣月/日/年，比如10/31/2024代表2024年10月31日。但歐洲很多國家用的是日/月/年，同一個日期就會寫成31/10/2024。如果軟件界面直接顯示"10/31"，美國人理解為10月31日，歐洲人則會認(rèn)為是10月31日這個日期有問題，因為他們的月份不可能到31。
貨幣格式的差異也很有意思。美國用美元符號$放在數(shù)字前面，歐洲用歐元符號€有的放在前面有的放在后面，日本用円或者￥但通常不加符號。千分位的分隔符也不同，美國用逗號，歐洲用句號。2,000在英語里是兩千，在德語里則是二點零，也就是二。
這些格式化內(nèi)容有些是在翻譯階段處理，有些則需要在程序代碼里處理。本地化翻譯人員需要了解目標(biāo)地區(qū)的習(xí)慣寫法，確保顯示出來的格式符合當(dāng)?shù)赜脩舻恼J(rèn)知。
軟件字符串處理還有一個容易被人忽視的領(lǐng)域，就是字符編碼。看起來都是字，但其實背后的存儲方式各不相同。
英語國家用ASCII編碼就足夠了，但中文、日文、韓文這些需要CJK字符集的語言，必須用Unicode編碼才能正確顯示。如果源語言的編碼和目標(biāo)語言的編碼不匹配，就會出現(xiàn)亂碼，翻譯內(nèi)容完全不可讀。
更麻煩的是有些語言有特殊的字符變體。比如德語的?，既可以寫成單個字符?，也可以寫成ss。土耳其語有帶點和不帶點的i。俄語的某些字母在不同詞形下會有不同的形狀。這些細節(jié)如果處理不當(dāng)，輕則顯示不美觀，重則影響文本搜索和排序功能。
另外，字符串的長度限制也常常是個問題。英文翻譯成中文后，字符長度通常會縮短30%到50%，這一般是好事。但反過來，如果從中文翻譯成某些使用拉丁字母的語言，文字可能會變長。原來按鈕上剛好能顯示的文字，翻譯后可能就超出一截，顯示不完整。
很多人以為翻譯完就是把譯文交給客戶就完事了。但在專業(yè)的本地化流程里，翻譯只是其中一個環(huán)節(jié)，后面還有一系列的測試和驗證工作。
功能測試是最基本的檢查。要在目標(biāo)語言的操作系統(tǒng)上運行軟件，查看所有界面元素是否正確顯示，文字是否完整，有沒有任何亂碼或截斷。特別要關(guān)注那些動態(tài)生成的字符串，比如用戶操作后彈出的提示信息，這些往往是問題高發(fā)區(qū)。
語言測試則是檢查譯文本身的準(zhǔn)確性和自然度。翻譯是否準(zhǔn)確傳達了原文含義？是否符合目標(biāo)語言的習(xí)慣表達？有沒有生硬或者不通順的地方？界面上的文字和其他地方是否保持一致的譯法？
技術(shù)測試則關(guān)注字符串在實際運行中的表現(xiàn)。變量占位符是否正確替換？復(fù)數(shù)形式是否根據(jù)實際數(shù)字顯示正確的版本？日期和數(shù)字的格式是否符合當(dāng)?shù)亓?xí)慣？這些都需要在真實的使用場景中驗證。
康茂峰的項目流程通常會安排多輪測試，每輪測試后修復(fù)發(fā)現(xiàn)的問題，直到所有測試項都通過。這個過程可能會持續(xù)好幾輪，但確保最終交付的產(chǎn)品質(zhì)量是有保障的。
說了這么多流程和挑戰(zhàn)，最后聊聊支撐這些工作的工具。
p>翻譯記憶工具是本地化的標(biāo)配。它能記住之前翻譯過的句子和短語，遇到相似的句子時自動給出參考譯文。這樣不僅提高了效率，還保證了同一術(shù)語在不同地方的譯文一致性。術(shù)語管理工具則負(fù)責(zé)管理項目的專業(yè)詞匯表。遇到新術(shù)語時，系統(tǒng)會自動檢查是否在術(shù)語庫中有標(biāo)準(zhǔn)譯法，如果有就采用，沒有就新增或者標(biāo)注待確認(rèn)。這樣一來，整個項目的術(shù)語翻譯都會保持統(tǒng)一。
質(zhì)量檢查工具則可以在翻譯完成后自動掃描，發(fā)現(xiàn)常見的錯誤。比如漏譯、譯文過長、標(biāo)點符號使用不當(dāng)、變量占位符丟失或位置錯誤等等。這些工具雖然不能替代人工審校，但能 catch 到很多低級錯誤，提高整體質(zhì)量。
軟件本地化翻譯的字符串處理，說到底就是一場跨語言、跨技術(shù)、跨文化的協(xié)調(diào)工作。它既需要對語言的敏感，也需要對技術(shù)的理解；既要有追根究底的精神，也要有處理繁瑣細節(jié)的耐心。
好的本地化不是簡單地把一種文字換成另一種，而是讓軟件在另一種語言環(huán)境里用起來，就像本來就是為那個語言和那個文化設(shè)計的一樣。這背后涉及到的字符串處理工作，看似不起眼，實則是其中非常關(guān)鍵的一環(huán)。
如果你正在做或者準(zhǔn)備做軟件本地化，希望這篇文章能幫你少走一些彎路。有些坑，只有踩過才知道疼；而有些經(jīng)驗，聽別人講一句，可能就能省下好幾天返工的時間。
