做醫(yī)學(xué)翻譯這些年，我發(fā)現(xiàn)一個特別有意思的現(xiàn)象：很多譯員把精力都放在術(shù)語準確性、表達專業(yè)性上了，結(jié)果翻譯出來的文本拿到電子量表系統(tǒng)里一放，根本放不進去。要么被截斷，要么字號小得讓人眼瞎，最后用戶填個問卷跟解謎似的。這事兒說大不大，說小不小，但確實挺影響使用體驗的。
我自己在工作中也遇到過不少這種情況。后來跟做產(chǎn)品開發(fā)的朋友聊多了，慢慢摸索出一些門道。今天就想著把這些經(jīng)驗整理一下，跟大家聊聊電子量表翻譯到底該怎么應(yīng)對顯示界面空間受限這個實際問題。
咱們先來拆解一下這個問題。電子量表跟傳統(tǒng)紙質(zhì)問卷不一樣，它必須在有限的屏幕空間里呈現(xiàn)所有內(nèi)容。手機屏幕就那么點地方，還要放下問題文字、選項、確認按鈕，翻譯過來的文本稍微長一點就打架。
舉個真實的例子。有個PHQ-9量表，原版英文問題"Do you have little interest or pleasure in doing things"翻譯成中文是"您做事時提不起興趣或沒有樂趣"，英文單詞數(shù)是9個，中文字符數(shù)卻達到了16個。這還是在中文相對精簡的情況下，要是翻譯成德語或者阿拉伯語，那個長度簡直沒法看。更要命的是，電子量表系統(tǒng)通常都有嚴格的字符數(shù)限制，超了部分直接被砍掉，用戶根本看不到完整的問題。
不同語言之間的字符長度差異大得驚人。我做了個小統(tǒng)計，把幾個常用的醫(yī)學(xué)評估量表做了個對比，大家感受一下：
| 量表名稱 | 英文版本平均字符數(shù) | 中文版本平均字符數(shù) | 德語版本平均字符數(shù) |
| GAD-7（廣泛性焦慮量表） | 約45字符 | 約28字符 | 約55字符 |
| PHQ-9（抑郁篩查量表） | 約60字符 | 約38字符 | 約72字符 |
| ISI（失眠嚴重程度指數(shù)） | 約55字符 | 約35字符 | 約68字符 |
從這個表格能看出來，同樣的內(nèi)容翻譯成不同語言，占用的空間可能相差一倍以上。英文翻譯成德語長了將近30%，中文卻能壓縮40%左右。這不是說中文有多高級，而是語言結(jié)構(gòu)本身就存在差異。
更麻煩的是，有些語言是從右向左書寫的，比如阿拉伯語和希伯來語。這時候不光是長度問題，連界面布局都要翻轉(zhuǎn)。有些系統(tǒng)在這方面支持不好，翻譯好的文本放進去會出現(xiàn)顯示錯亂。
說實話，很多電子量表在設(shè)計的時候根本沒考慮多語言適配。開發(fā)團隊可能都是母語者，覺得英文原版看起來剛剛好，界面布局也合理。結(jié)果翻譯成其他語言后，要么文字超框，要么選項按鈕被擠到下一行，整個界面變得七零八落。
我接觸過一些客戶，他們的產(chǎn)品在英語國家用得好好的，擴展到德國市場就收到大量投訴，說界面太擁擠、看不清楚。問題出在哪里？就是當初設(shè)計界面的時候沒有預(yù)留足夠的冗余空間，翻譯過來的文本一長就原形畢露。
還有一種情況是，量表翻譯和界面開發(fā)是兩個獨立團隊負責的。翻譯團隊按照原文忠實轉(zhuǎn)譯，力求專業(yè)準確；開發(fā)團隊對著設(shè)計稿做界面，按英文版本預(yù)留字符數(shù)。兩個團隊缺乏溝通，最后拼在一起才發(fā)現(xiàn)問題。這種情況其實挺常見的，責任也不在誰，只是流程上缺了那么一環(huán)。
既然問題擺在這里，總得想辦法解決。這些年我們在項目里積累了一些經(jīng)驗，雖然不敢說是標準答案，但確實幫不少客戶解決了實際問題。
這是最直接的思路。與其翻譯完了再去精簡，不如在翻譯的時候就控制好篇幅。我們在做醫(yī)學(xué)量表翻譯時，會在保證語義準確的前提下，盡量選用簡潔的表達方式。
比如說，"在過去的兩個星期內(nèi)，您有多少時候受到以下問題的困擾"這句話，完全可以精簡為"過去兩周，您有多少時候"。核心意思沒變，但字符數(shù)減少了將近一半。當然，這種精簡必須建立在充分理解原意的基礎(chǔ)上，不是隨便砍詞。
對于一些約定俗成的表達，我們也會采用醫(yī)學(xué)領(lǐng)域的標準簡化說法。像"感到情緒低落或沮喪"在臨床語境下簡化為"情緒低落"也是可以接受的，只要不影響量表的信度和效度。
醫(yī)學(xué)量表雖然種類繁多，但很多概念是相通的。"疲勞"在十幾個量表里都可能出現(xiàn)，"睡眠困難"也是反復(fù)出現(xiàn)的高頻詞。我們會為每個項目建立專門的術(shù)語庫，記錄經(jīng)過驗證的標準譯法和推薦表達。
這樣做有兩個好處。第一是保證同一個概念在不同量表里翻譯一致，用戶不會因為表述差異產(chǎn)生困惑。第二是提高效率，譯員不用每次都糾結(jié)怎么表達，直接調(diào)取庫里的標準說法，省下來的時間可以花在難點內(nèi)容上。
這可能是我最推薦的一個做法。在正式翻譯之前，先拿幾個有代表性的問題做小規(guī)模測試。翻譯完成后，按照目標語言的字符數(shù)上限在模擬界面上跑一遍，看看實際效果。
很多問題在這個階段就能暴露出來。比如某個問題翻譯成德語后超了30個字符，要么界面要重新調(diào)整，要么翻譯要做二次精簡。這種早期發(fā)現(xiàn)比上線后被用戶吐槽強多了。
我們一般會準備幾種不同屏幕尺寸的模擬器，手機、平板、桌面都跑一遍。畢竟用戶可能在各種設(shè)備上使用，不能只考慮一種情況。
翻譯做得再好，如果界面不支持也是白搭。所以技術(shù)層面的配合同樣重要。
現(xiàn)在的電子量表系統(tǒng)大多采用響應(yīng)式設(shè)計，同一套代碼適配不同屏幕尺寸。但響應(yīng)式不是萬能的，它解決的是布局問題，不是空間問題。文字該多長還是多長，不會因為屏幕變小就自動縮短。
更好的做法是針對不同語言版本做針對性的界面優(yōu)化。比如中文版本可以用稍小的字號，因為中文信息密度高；德語版本則需要預(yù)留更寬的文本框，或者采用兩行顯示問題的方案。這種差異化處理比一刀切的響應(yīng)式設(shè)計更有效。
有些先進的電子量表系統(tǒng)支持根據(jù)文本長度自動調(diào)整字號。問題短時就用大字號，問題長時就用小字號，確保文字始終在框內(nèi)。這個技術(shù)實現(xiàn)起來有一定難度，但用戶體驗確實好。
需要注意的是，自動調(diào)字號要有下限，不能無限制縮小下去。否則字小得看不清，反而影響使用。一般我們會設(shè)置一個最小值，比如12像素，達不到這個標準就觸發(fā)其他優(yōu)化措施，比如換行顯示或者顯示省略號加展開按鈕。
如果一個問題實在無法精簡，試試分步展示。把一個復(fù)雜問題拆成幾步，每步只呈現(xiàn)一部分內(nèi)容，用戶一步步往下填。這種設(shè)計在移動端特別常見，效果也不錯。
折疊設(shè)計則是把一些輔助說明或者詳細選項默認隱藏，用戶需要時再點擊展開。比如選項的詳細解釋可以做成折疊面板，主界面只保留核心問題和簡短選項，用戶有疑問就自己點開看。
說了這么多方法，最后想聊幾點實操層面的建議。這些是我們在項目里踩過坑之后總結(jié)出來的，算是一點點心得。
首先是預(yù)留充足的測試時間。很多客戶覺得翻譯就是文字轉(zhuǎn)換的事，給幾天時間就能搞定。但實際上，從翻譯完成到系統(tǒng)上線，中間需要預(yù)留時間做各種測試。字符顯示有沒有問題、界面布局有沒有錯亂、不同設(shè)備上效果怎么樣，這些都是需要實際跑一遍才知道的。我們一般建議預(yù)留總工期的20%到30%給測試和調(diào)整。
其次是找有醫(yī)學(xué)背景的譯員來做這件事。普通譯員可能很難把握醫(yī)學(xué)量表的微妙之處，翻譯出來的文本要么太口語化不夠?qū)I(yè)，要么太學(xué)術(shù)化患者看不懂。而且有醫(yī)學(xué)背景的譯員更容易理解量表的設(shè)計意圖，在做簡化或者調(diào)整時能守住底線，不會為了省空間而犧牲準確性。
第三是建立清晰的反饋機制。電子量表上線后，用戶的反饋很重要。哪些問題表述不清楚、哪些選項太占空間，這些信息收集回來可以指導(dǎo)后續(xù)優(yōu)化。我們會建議客戶在量表里加一個可選的反饋入口，哪怕只是簡單的"這個問題您能看清嗎"也能收集到有價值的信息。
電子量表的翻譯工作看似只是語言轉(zhuǎn)換，其實涉及用戶體驗、界面設(shè)計、技術(shù)實現(xiàn)等多個維度。空間受限這個問題看著不大，解決起來卻需要各個環(huán)節(jié)配合好。
我個人覺得，最好的辦法是從項目一開始就把它當回事。不要等到翻譯完了、界面做完了才發(fā)現(xiàn)問題，那時候改起來成本就高了。在規(guī)劃階段就把多語言適配考慮進去，預(yù)留好測試和調(diào)整的時間，最終效果往往會好很多。
醫(yī)學(xué)量表的最終目的是準確評估患者的狀況，如果因為顯示問題導(dǎo)致患者看不懂、填不對，那量表就失去了它的價值。從這個角度看，認真對待空間受限這個問題，不只是為了界面美觀，更是為了保證量表的臨床有效性。
