翻譯與文化引介，兼談 breadcumb、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) 諸如此類，等同指明他不懂相關的文化背景脈絡，亦不打算深入瞭解原作者心思，只想以自身見解自行解釋。

 

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

========

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

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

 

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

 

在這個案例中，甚至可以說兩個語言間的文化脈絡是互通的，若另外譯為諸如「網址導覽指引」之類的詞語，無異畫蛇添足，反而無法給予讀者從直譯詞語理解其暗示資訊，在秒懂時發出「啊哈」一聲 (Aha! moment) 的會心一笑。這種譯法讓讀者又隔了一層紗，搞不懂原文 breadcumb 的語意脈絡，甚至第一次看到英文資訊時，還要自行重新理解一遍。

 

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

 

像「網址導覽指引」這種翻譯風格，是譯者以實際操作介面，或其所理解的個人解析，另行轉意（非轉譯）的「作用理解式」譯法。這其實也相當常見，方便台灣讀者在去脈絡的情境下，直接跳過文化引介的門檻，以翻譯詞直接理解介面中該詞語的「實際作用」為何。

 

========

 

例如設定 Permission 的介面，很常被翻譯成「權限」，但實際上 Permission 是指得到許可的取用權利，是設定賦予使用者什麼權利的意思。而得以行使權利，中文稱為「權能」。「權限」是「權利限制」，類似速限、速度限制，在中文語境下，是指預先全部都加上限制，有需要時再特別為其開通需要的權利。

 

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

 

如果譯者在翻譯前，還不知道 Permission 當初這是「譯者自行理解作用」而翻譯成權限，就直接套用，會造成重大的中文詞語錯亂問題。在中文語言的文字本意下，要解開權限，使用者才會得到權利。

 

結果譯者誤將「Permission denied」譯成「沒有權限」（和沒有速限同個概念，實際應改正為「沒有權能」），而沒有權限的話，不就是沒有任何權利限制嗎？使用者都可以為所欲為了，意義完全相反啊！那可是系統管理員的意思啊！

 

在這裡原文意思是「取用遭拒」即「沒有權利」的意思⋯⋯還有「Remove permission」譯成「解除權限」（和解除速限同個概念）也是同樣翻譯錯亂，對應至中文則應是「撤銷權利」、「解除權能」。

 

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

 

直到今日都還能見到微軟、Google 僱用的專業翻譯社，仍陸續翻譯出「沒有權限」和「解除權限」這種不懂中文詞原意的重大翻譯錯誤事件。這種翻譯錯誤已經遍布其幾乎旗下所有作品，積非成是，騎虎難下，覆水難收了⋯⋯

 

譯者對詞語的不小心，塑造了全民逐漸把中文「權限」(Restriction of rights) 一詞當作「職權」(Authority) 來用的新時代，所以譯者不可不慎啊！務必謹慎對待「作用理解式」翻譯風格，如果有類似翻譯風格的條目為模糊翻譯，請查證原文意義。

 

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

 

即便如此，將 Permission 譯作權限/職權 Authority，仍是一種脫離原文脈絡的轉意式翻譯，不信實、不貼切；而且正規的中文語法下也只會說其權限到哪裡、或是超出其權限範圍，沒有權限、取消權限等翻譯，在此情境下依然是中文表達不當。

 

=======

 

中文套件一詞的翻譯濫用，也是作用理解式轉意風格的著名案例。就譯者不知道要怎麼翻譯時，想說這種在原軟體上，再加裝一些新功能的概念，就像為車子安裝不同套件升級吧！所以 Extension 延伸套件、Addon 附加套件、Plugin 插入套件、Package 套件、Office Suite 辦公套件⋯⋯這一系列轉意為套件的翻譯全部出爐，實在也是讓人哭笑不得。

 

========

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

 

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

 

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

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

 

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

 

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

 

========

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

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

 

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

 

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

 

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

 

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

========

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

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

 

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

 

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

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

 

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

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