程式翻譯與文化引介 — 論譯法風格，兼談 breadcrumb、permission、lint 等譯詞

當一位譯者在考量某個詞彙的翻譯時，必須一併考量原作者本身的文化背景，以及自身語言的文化背景，如此才能得出好的、如實呈現的翻譯。

信實傳遞原文化背景，並以自身語言貼切表達（思果提出的信達貼守則）

以 Weblate 為例，翻譯編輯器除了一般模式外，還有一個提供譯者心識狀態更專注於翻譯的 Zen mode；另外，翻譯專案下也提供一個 Insight 項目向內觀看專案下的大略樣貌，像是翻譯的歷史、活動、統計數據資料等。

如果譯者稍微瞭解近期佛教發展的動態，以及美國嬉皮文化引領的新世紀風潮，甚至到後來心理學浪潮，如心流、正念冥想、超覺靜坐等技巧，便知道作者可能有過相關體驗而特意採用（賈伯斯學禪亦是曾浸在這個文化背景中），Zen、Insight 都是內觀禪修很常見到的英語用字。

因此，這裡的 Zen mode 將之譯為「禪譯模式」（帶有禪意的心流翻譯模式），Insight 直接對應為「內觀」（往內觀看專案的內在樣貌）。Zen 與 Insight 這些皆是作者選擇採用的譬喻詞，而不說 Mind-flow mode、In-project stats。

說穿了，今日若有譯者認為 Zen 此處不該譯成禪譯、Insight 不該譯成內觀，打算依照自身理解與此處作用去描述它，例如改說是「連續模式」(Continuous mode)， 或「概觀」(Overview)、「數據統計」(Stats) 諸如此類，等同指明他不懂相關的文化背景脈絡，亦不打算深入瞭解原作者心思，只想以自身見解自行解釋。

 

一旦完全丟失了原作者採用該詞語想表達出的旨意，這樣一來就不是譯介，而是譯者主觀詮釋的個人改作。

========

磅蛋糕，出自嘉義的「自由が丘」小店

再來曾見到網友討論 breadcrumb 的翻譯，抨擊不應該直譯為「麵包屑」云云。

 

其實，如果譯者慧根夠，就會知道作者採用此字眼的典故出自耳熟能詳的童話故事——糖果屋。糖果屋的故事在臺灣同樣廣受歡迎，幾乎眾所皆知。讀者多半看見這個字眼後，稍微動點腦筋就會想到糖果屋，心中立刻會有相應的概念浮現出來，這也就原作者採用這個字眼的用意。

在這個案例中，甚至可以說兩個語言間的文化脈絡是互通的。

更換原文意思概念，以操作導向或個人解讀來表達（作用理解式轉意改寫）

若另外譯為諸如「網址導覽指引」之類的詞語，無異畫蛇添足，反而無法給予讀者從直譯詞語理解其暗示資訊，在秒懂時發出「啊哈」一聲 (Aha! moment) 的會心一笑。

這種譯法讓讀者又隔了一層紗，搞不懂原文 breadcrumb 的語意脈絡，甚至第一次看到英文資訊時，還要自行重新理解一遍。

 

當翻譯失去文化引介的作用之後，本質上就不算是如實「翻譯」了，而另屬於「改作」範疇。

 

像「網址導覽指引」這種翻譯風格，是譯者以實際操作介面，或其所理解的個人解析，另行轉意（非轉譯）的「作用理解式」改寫。

這其實也相當常見，方便台灣讀者在去脈絡的情境下，直接跳過文化引介的門檻，以翻譯詞直接理解介面中該詞語的「實際作用」為何。

 

========

作用理解式轉意改寫（不等義/失義，譯者主觀詮釋，另行改寫 Adaption）

例如設定 Permission 的介面，很常被翻譯成「權限」，但實際上 Permission 是指得到許可的取用權利，是設定賦予使用者什麼權利的意思。而得以行使權利，中文稱為「權能」。

這裡的「權限」是「權利限制」，類似速限、速度限制，在中文語境下，是指預先全部都加上限制，有需要時再特別為其開通需要的權利（語境用途：取用權遮罩，Permission mask）。

 

之所以用權限，是譯者為了讓讀者方便知道，這裡是在「設定使用權利相關限制」的地方，跳過 Permission 允許、賦予權利的本意，改成方便讀者理解「權利限制設定」的「權限」(Restriction of rights)。

 

如果譯者在翻譯前，還不知道 Permission 當初這是譯者自行「理解作用」而翻譯成權限，就直接套用，會造成重大的中文詞語錯亂問題。在中文語言的文字本意下，權限是指「特定或受限的權力範圍」。

 

結果譯者誤將「Permission denied」譯成「沒有權限」（和沒有速限同個概念，實際應改正為「沒有權能」），而沒有權限的話，不就是沒有任何限制、權力沒有範圍了嗎？

那使用者都可以為所欲為了，意義完全相反啊！那可是系統管理員的意思啊！真要用權限（權力可行使的特定範圍）一詞，應改為「沒有對應權限」、「未取得適當權限」或「超出權限範圍」等。

 

再回過頭來看，這裡的原文是指「取用遭拒」，即「沒有取用權」的意思呢⋯⋯

 

這種跨越作者原意，丟失原脈絡的「作用理解式」轉意改寫風格必須相當謹慎，而且譯者應當先寫在內部翻譯溝通管道裡，讓所有其他譯者都知道，也方便後面的參與者知悉，才不會模糊翻譯直上。

 

直到今日都還能見到微軟、Google 僱用的專業翻譯社，仍陸續翻譯出「沒有權限」這種超譯 Permission 原義的翻譯事件。這種不良對應翻譯已經遍布其幾乎旗下所有作品，積非成是，覆水難收了⋯⋯

譯者對詞語的不小心，讓全民逐漸把英文的 Permission 誤理解為「權限」(實際意思本該是 Getting permitted rights，卻對應成 Restricted extent of the authority) ，交相混淆；所以譯者不可不慎啊！務必謹慎對待「作用理解式」翻譯風格，如果有類似翻譯風格的條目為模糊翻譯，請查證原文意義。

 

註：中文的權限，除了受限制的權利外，還有另一個意思：是指政府機關或國家權力，在受到限制下其影響力所及的特定範圍，如國家、政府機關、公民團體等的權限。該詞對應法律、政治、治理領域用語的 Authority，由日文用詞権限而來，類似中文的「職權」，是文化交流後的影響。

 

然而，將 Permission 譯作意為權限（職權）的 Authority，仍是一種脫離原文脈絡的轉意改寫，不信實、不貼切；而且正規的中文語法下也只會說其權限到哪裡、或是超出其權限範圍、沒有對應權限，至於「沒有權限」等翻譯，在此情境下依然是中文表達不當。

 

=======

 

中文套件一詞的翻譯濫用，也是作用理解式轉意改寫的著名案例。

 

就譯者不知道要怎麼翻譯時，想說這種在原軟體上，再加裝一些新功能的概念，就像為車子安裝不同套件升級吧！所以 Extension 擴充套件、Addon 附加套件、Package 套件、Office Suite 辦公套件、Distribution 散布套件⋯⋯這一系列轉意改為套件的翻譯全部出爐，實在也是讓人哭笑不得。

 

========

原文中約定俗成的用語應採直譯 (類同形式對等翻譯 formal equivalent)

至於前面文章曾討論過的 bug、patch 等，這都是有典故的，請見這篇。因為有典故，後來約定俗成，就變成英文的「成語」，用 bug 借代為程式碼中的錯誤，用 patch 借代為程式碼的修正，並且廣為流傳，成了大家都知道的日常用詞，普及進入大眾文化中。

 

在這類案例中，唯有將 bug 和 patch 翻譯為臭蟲（煩人的蟲）和補丁（或修補檔），才能如實反映出原文語言中的背景文化，並且將這個文化像是搭橋一般介紹到譯者的語言文化中。若轉意改為「程式碼錯誤」(Code error)、「程式碼修正」(Code fix)，雖然也能讓讀者瞭解，但譯文卻丟失了原文中背後的文化脈絡菁華，只剩糟粕。

 

甚至，讓譯者語言文化衍生出新的、無法解釋的問題：為何程式碼錯誤的圖案是都是用蟲子？為什麼程式碼修正的圖案會是用貼布？

這時就不適合再以譯者所理解的作用，跨越脈絡去轉意改寫。只有將 bug 和 patch，或是 virus、worm 等這類相當普及的原文譬喻借代詞，如實直接對應翻譯，才能將原文世界中的普及用語文化，引入譯者的語言文化中。

 

好奇臭蟲和補丁為何的讀者，自會去探查原因，進而瞭解這些約定俗成用語的「通俗」典故，達成譯者應該做的文化橋接目標。

 

譯者必須意識到，所謂翻譯，除了翻譯本身外，由於翻譯對象領域多半是自身語言文化中尚缺乏、未成熟、正在擴展的新版圖，所以還負有打造自身語言新領域文化的責任在。

 

========

專業的晦澀黑話不翻譯，或採作用理解式轉意改寫

再來聊另一個例子 Lint，起源自 lint，指「衣物上掉下來的毛絮、線頭」。
 

linter 程式的誕生，就是原作者的譬喻加借代，指稱「清除洗衣機或烘衣機裡面設計用來收集這些毛絮團塊的裝置 (有一個 lint trap 收集槽）」。所以最早在 Unix 中出現時，設計師以 lint 來命名這個程式。

 

在中文語言裡，毛絮也無法當作動詞用，如果譯者只講「毛絮」，或甚至「收集毛絮」都會讓人不知所云。這個詞是高度專業的資訊領域用語，俗稱「行話」或「黑話」，相較於通俗常見的 bug 或 patch 等，反而只有程式設計專業才會見到，門檻極高。所以，僅有極少數人可能查得到 lint 或 linter 的命名起源歷史，更別說是翻譯成毛絮後，這些專業人士會有多少人能讀懂了。

 

此時兩方文化沒有共同脈絡，用詞甚至過於冷僻，而直譯詞也脫離中文語法，無法順利橋接。因此，lint 我一般維持程式原名 lint（全部小寫），就當它是專用的程式名稱。

 

在這種極端情況下，便極為不適合直譯。真要翻譯，就必須採用作用理解式轉意改寫。lint 如果是當作動詞用的話，則可以說他是梳理；linter 則可稱為「梳理器」。

 

譯者要注意的是，「lint 在此的作用是梳理，但梳理並不是 lint 的翻譯」，只是從作用來理解這個字背後的意義，並依此轉意改為梳理來稱呼它。

========

每個翻譯都是譯者的創作

總結來說，如果譯者無法盡可能表達出原作者所想表達的，那麼比起翻譯，更像是用自己的話說一次，有時候是作用理解式轉意改寫，也可以說是「超譯」。是故，不同的譯者會有不同的翻譯，而不同的翻譯都可視為不同的「創作」。根據譯者自身程度而定，貼近原作的緊密度就會有所差異。

信達貼

而好翻譯的評判標準呢？就是用原語言和文化的眼光，去看翻譯是否貼切。去想像作者今天如果同時間也能流暢地講國語、寫中文，那麼同樣的句子他會怎麼說？以這樣的脈絡去思考，才能改善譯作貼合原作語言、文化的程度。

 

不過有時候也還需要考慮，如果真的這樣翻譯，讀者是不是有機會看得懂？例如上面討論的 lint 案例，毛絮和梳理，而在中文裡的毛絮，是不可能作為動詞用的。權衡之下，還是必須採用作用理解式轉意改寫。

 

又如果各種翻譯風格都可以，到底要用哪種才最會適合呢？這也是翻譯最困難的地方。

當地本位風格翻譯（意譯，類同功能對等翻譯 functional equivalent）

最後，還有一種資訊領域翻譯極少用的風格，稱為「當地本位風格譯法」。就是作者今天如果突然不會自己的語言，也不懂自己的文化了，卻說得一口好國語、寫得一手好作文，還懂各種當地人的風俗文化，那麼同樣的句子他會怎麼說？

這種譯法風格，不須考慮文化引介、也不須以原作者創作時的背景脈絡表達。

 

翻譯出來的成品，就會很像是一個台灣人寫的，非常道地的地方性程式一樣。有一些很想與在地文化接軌的軟體程式，則可能會以這種語氣與說法來翻譯。這其實也更偏向於改作，而非照實翻譯。

翻譯原文出自於他語，轉換時基於語言特性無法完全對等，以及兩地文化差異的緣故，只能盡可能對應、貼近，故程式翻譯一定會有翻譯味存在。在程式翻譯領域中，實務作業上以譯完原文意義，並貼切表達為主；較少花費時間心力雕琢成純母語風格，更何況乎這類譯文風格會大受譯者的語文造詣、主觀詮釋影響。

若要如此執行，則必須整套程式都採同樣風格，專案越大越多人參與越難控管，不同譯者間的語文表達方式都有差異，最後必須有一人再次以其主觀統一，重複勞動。即便完成了，也會和系統中的他家程式語感有所落差。除非是整套系統都能控管，以及業主要求，否則一般不會採用這種翻譯風格。

 
以上為個人對翻譯風格與文化引介的看法，謹供有心於精進資訊領域或程式翻譯的譯者參考。