
做電子量表開發的朋友不知道有沒有遇到過這種情況:辛辛苦苦把量表翻譯成英文、日文、德文,結果用戶切換語言時,要么界面亂成一團,要么某些問題還是顯示原文,甚至直接報錯。這事兒說大不大說小不小,但確實挺讓人頭疼的。
我自己在工作中也沒少跟多語言切換打交道,從最初的簡單粗暴替換文本,到后來慢慢摸索出一套相對靠譜的方案,這個過程踩了不少坑。今天就結合實際經驗,聊聊電子量表翻譯后多語言顯示切換這件事兒,希望能給有類似困擾的朋友一點參考。
很多人覺得,多語言切換不就是把中文換成英文嗎?能有多復雜?但實際做起來就會發現,這事兒遠比想象的要麻煩。
首先是文本長度的問題。中文通常比較簡潔,比如"您最近一周感到焦慮嗎",翻譯成英文可能變成"During the past week, how often have you felt anxious",長度直接翻倍都不止。如果是德語或者俄語,那更長。這就會導致按鈕被撐爆、換行亂掉、截斷顯示等問題。我見過最夸張的是某個量表的問題選項,從中文的"從不"到俄語硬是變成了"Dятел, котοрый κοрит в лесу"這樣一長串,原本設計好的兩行布局完全失效。
然后是布局適配的問題。英語從左往右讀,阿拉伯語和希伯來語卻要從右往左讀,這就不只是文字替換的事了,整個界面的排版邏輯都要調整。量表的問題序號、選項的圓點或者方框、提交按鈕的位置,都需要跟著語言方向走。有段時間我們有個項目要支持阿拉伯語,最初只是簡單替換了文字,結果用戶反饋說"感覺在照鏡子",特別不習慣。
還有就是動態內容的問題。電子量表里經常會有根據用戶回答動態生成的內容,比如量表分數解讀、個性化建議等等。這些內容本身就不是固定的,翻譯之后還要考慮語法變位、復數形式、數字格式等等。比如分數顯示,中文說"您的得分是85分",英文要說"Your score is 85 points",如果得分是1分還得說"Your score is 1 point"。這些細節如果沒處理好,就會顯得特別不專業。

這應該算是最基礎的方案了。簡單來說,就是把界面顯示的所有文本都從代碼里抽離出來,放到單獨的資源文件里。中文一套,英文一套,日文一套,每種語言對應一個文件。程序根據用戶的語言設置去加載對應的文件,顯示的時候直接從文件里取文本。
這種方案的好處是簡單直觀,維護起來也方便。翻譯人員只需要修改資源文件就行,不用碰代碼。而且新增語言也很容易,加一個新文件就完事了。但缺點也很明顯,就是前面提到的長度問題和布局適配問題沒法很好地解決。另外,如果量表里有大量動態生成的內容,資源文件方案處理起來會比較吃力。
在實際應用中,資源文件通常會按模塊來組織。一個大的電子量表系統可能包含幾十個甚至上百個量表,每個量表又有題目、說明、分數解讀等等不同類型的文本。把這些全部塞進少數幾個文件里會很難維護,所以一般會按量表ID或者頁面模塊來拆分文件。這樣找起來方便,翻譯的時候也能按模塊批量處理。
鍵值對存儲可以看作是資源文件方案的升級版。核心思路是用一個唯一的"鍵"來標識每一段需要翻譯的文本,然后用一個"值"來存儲對應語言的實際內容。程序顯示的時候,只需要根據當前語言找到對應的鍵值對,取出值來顯示就行。
舉個例子,鍵"question_1_title"在中文環境下對應"您最近一周的情緒如何",在英文環境下對應"How have you been feeling over the past week"。不管用戶選什么語言,系統都是去查"question_1_title"這個鍵,只是取出來的值不一樣。
這種方案現在用得很多,因為實現起來靈活,數據也容易管理。很多公司會把鍵值對存在數據庫或者專業的翻譯管理系統里,這樣翻譯工作就可以和開發工作分開進行。翻譯人員通過管理后臺添加或修改翻譯內容,開發人員只需要在代碼里引用相應的鍵就行??得逶谔峁?a href="http://www.hljmxtx.com/">醫學翻譯服務的時候,就經常使用這種鍵值對的方式來管理量表翻譯內容,確保每一道題目、每一個選項都有唯一的標識,方便后續的技術對接。
有個細節需要注意,就是鍵的命名規范。最好能有一種統一且有規律的命名方式,比如"量表ID_題目編號_內容類型"這樣的結構。時間長了項目大了,鍵可能成百上千個,如果沒有好的命名規則,到后來根本沒法維護。

如果你的電子量表項目比較大,需要支持很多種語言,那專業的國際化框架就很有必要了。i18n(internationalization的縮寫,因為i和n之間有18個字母)相關的庫和框架現在有很多,比如i18next、gettext、ICU等等。這些框架功能都很完善,不僅能處理文本替換,還能處理復數形式、變量插值、日期格式、貨幣格式等等復雜情況。
以復數形式為例,中文里"1個問題"和"5個問題"都可以用"個問題"來表達,但英文就必須說"1 item"和"5 items"。國際化框架一般都會提供復數規則的定義,不同語言的復數規則還不一樣。英語有單數復數兩種形式,阿拉伯語有六種形式,俄語則根據數字的最后幾位數來決定用哪種形式??蚣芾锇堰@些規則都寫好了,開發者只需要按規范調用接口就行。
變量插值也很實用。量表的分數解讀經常需要把分數嵌入到句子里面,比如"您的得分為{score}分,高于{percent}%的用戶"。通過變量插值,系統會自動把實際的分數和百分比填進去,翻譯人員只需要翻譯句子模板就行,不用擔心變量位置的問題。
電子量表的翻譯工作通常不是開發人員自己做的,而是交給專業翻譯或者本地化團隊。這時候怎么保證翻譯質量和效率,就成了一個重要問題。
最理想的情況是有一套完善的對接流程。翻譯團隊通過專門的平臺或者文件格式來提交翻譯內容,這些內容可以直接被技術系統使用,不需要再手動復制粘貼。這個過程中,保持鍵的穩定非常重要。如果鍵變了,之前做的翻譯就可能對不上,甚至導致程序出錯。所以最好是在開發初期就把鍵的命名規則定下來,后續盡量避免修改。
另外,翻譯內容的更新也是個大問題。量表上線后難免會有修改,可能某道題目的表述要調整,可能新增了某個選項,可能分數計算邏輯變了需要調整解讀文本。每次修改都要同步更新所有語言的翻譯,如果沒有好的流程,就會出現不同語言版本內容不一致的情況。
前面提到了文本長度差異的問題,這事兒沒有辦法完全避免,但可以通過一些方法來緩解。首先是界面布局要預留足夠的空間,不能把每個區域都設計得剛剛好。標題區、選項區、按鈕區都要有一定的彈性,能容納比預期更長的文本。
其次是容器的高度要能自適應。固定高度在單語言下可能沒問題,多語言環境下就很容易出問題。最好是用自動高度,讓容器根據內容自動調整。如果某些區域實在需要固定高度,那也要設定一個最大值,超出部分用省略號或者其他方式處理,不要直接截斷或者溢出。
測試環節絕對不能省。每一套語言、每一種布局都要覆蓋到。特別是那些字符特別長的語言,比如德語、俄語、阿拉伯語,還有字符特別短的,比如日語。不同屏幕尺寸也要測,手機、平板、電腦端的表現可能都不一樣。有條件的話,最好找目標語言的母語者幫忙看一下,有些問題只有本地人才能發現。
這個問題看似基礎,但現實中真是沒少讓人栽跟頭。UTF-8編碼是必須的,這個應該已經是共識了。但光有編碼還不夠,還要考慮字體的問題。同一個字符在不同字體下的顯示寬度可能差別很大,界面布局也會因此受到影響。
更麻煩的是一些特殊字符和生僻字。醫學量表里經常會出現專業術語,這些術語在某些語言下可能需要用特殊的Unicode字符來表示。如果字體不支持,這些字符就會顯示成方框或者問號。用戶看不懂還好,要是被誤解了那就麻煩了。所以一定要確保所選的字體能覆蓋目標語言的所有字符,必要的時候可能需要為不同語言配置不同的字體。
記得之前做過一個國際合作的精神健康評估項目,要同時支持中文、英文、日文、韓文、阿拉伯文和西班牙文六種語言。一開始我們用了資源文件方案,覺得應該夠用了。結果到了測試階段,發現阿拉伯語的界面完全是反的,用戶操作起來非常別扭。
緊急整改之后,我們引入了RTL(從右往左)布局支持。技術實現上,主要是把CSS的direction屬性和text-align屬性根據語言來動態設置。阿拉伯語和希伯來語用RTL,其他語言用LTR。為了避免每個地方都手動設置,我們把語言設置和全局樣式綁定在一起,只要切換語言,整個頁面的方向性就自動調整過來。
這個項目還教會了我一件事:不同語言的日期格式真的差很多。同樣是"2024年3月15日",英文是"March 15, 2024",日文是"2024年3月15日",阿拉伯文又要從右往左寫。數字也有區別,阿拉伯語用的是東阿拉伯數字,而波斯語雖然也用阿拉伯字母,但數字又是另一套體系。這些細節如果沒處理好,用戶會覺得很奇怪,覺得這個產品不夠專業。
多語言支持不是一次性做完就完事了,而是需要持續投入的工作。用戶的反饋要收集,翻譯的更新要做,界面的問題要修。最好是有專門的機制來跟蹤這些問題,不要讓它們淹沒在日常的工作里。
翻譯質量的監控也很重要。時間長了,量表可能會有調整,新版本發布了,但某些語言的翻譯沒有及時跟上。這時候用戶切到那個語言,看到的就可能是過時甚至錯誤的內容。康茂峰在長期服務醫學量表翻譯項目的過程中就發現,建立一套翻譯與版本同步的管理機制非常關鍵,這樣才能確保各語言版本始終保持一致。
對了,用戶體驗方面也可以多想想。比如能不能讓用戶自己選擇偏好的語言,而不是只能按系統的區域設置?能不能記住用戶的語言選擇,下次打開直接就用上次選的?能不能提供語言切換的入口,讓用戶隨時可以換?這些看似是小事,但做好了能大大提升用戶的滿意度。
總之,電子量表的多語言切換問題說復雜也復雜,說簡單也簡單。關鍵是前期要把架構設計好,流程理清楚,后面實施的時候才能少踩坑。當然,實踐中總會遇到各種各樣的具體問題,遇到一個解決一個,慢慢積累經驗就好了。
