台灣自由軟體社群正體中文程式翻譯風格指引，以 GIMP 為例
各個專業領域有不同的術語，同一個字詞在不同的領域下，也可能有不同的稱呼，或是不同的意義，所以在處理專業領域的程式時，需要謹守一些準則與心法，才能將翻譯處理得好。
基本守則
當譯者在考量某個詞彙或整體語句的翻譯時，必須一併考量原作者創作時的文化背景（例如程式用詞背後的情境脈絡、作者可能的文化涵養），以及譯者自身語言的文化背景（本土文化下的情境脈絡、自身的語文造詣和內在涵養），然後試圖在兩者之間比擬對應（試圖以本土語言與文化貼近原作），如此才能得出好讀的、如實呈現的翻譯。
術語翻譯訂立
以 GIMP 這套影像處理領域的專業程式來說，想要翻譯得好，就需要瞭解常見、已知的影像處理專業術語作為參考資料。
這些用語可以從台灣人撰寫的網頁資料，或是出版的專業書籍取得，並作為譯詞參考。
若社群已有現成的出版書籍，可作為術語用詞對照。像是專業的辦公生產力領域下，如 LibreOffice 套裝程式為例，則有《LibreOffice 排版設計》一書能參考。
術語的譯詞訂立方法如下：
理解
對於那些找不到對應中文資料的詞語，則可以先瞭解詞語的使用情境，例如查詢 Wikipedia 維基百科、Merriam-Webster、Oxford Learner's Dictionaries 英英字典，或是程式提供的文件說明網頁、新版本的 Release Note（此為重中之重的要點）等，以及查詢得到的英文討論資料等。以資料為據，先弄懂詞語的用途、原理、概念。
拿 GIMP 舉例，最重要的參考資料是 GIMP Documentation，即 2.10 版的使用手冊。每當不清楚詞語意義時，必先查找文件以瞭解對應情境。
接著我們來看 Dodge 和 Burn 這一組用語作案例探討，在 GIMP Documentation 中是「The Dodge or Burn tool uses the current brush to lighten or darken the colors in your image. 」
另外，Dodge / Burn 的圖示是一根遮擋光線的棒子，類似視力檢查的遮擋棒，如上圖。
在搜尋引擎中輸入「Dodge Burn Wikipedia」，可以在維基百科中得知，原來這是相片印刷用暗房處理技巧用語，是負片投影轉正程序，並附圖解說 Burn 以加強曝光，來達到變更暗（相紙照到更多光，顯影越多顯得越暗）；Dodge 以遮蔽曝光，來達到變更亮的效果（相紙照到較少光，顯影越少顯得越亮）。
 |
| By きたし - Own work, CC BY-SA 2.5 |
貼近
接著揣想用中文要怎麼說比較好，在這個發想過程中，可以參考劍橋英漢字典，或是教育部重編國語辭典等，以及網路有的資料（如樂詞網等），來逼近出適當的中文詞語。如果找不到適當的對應詞語，則進入發想創造。
譯者要注意的是，既有的常見翻譯很有可能是不良翻譯。請先理解原文與概念，再試著用自己的語言說，只有在想不到詞彙能比擬後，才去找已有的中文資料，並將微軟系統譯詞、蘋果系統譯詞、各軟體公司譯詞、樂詞網搜集之譯詞作為最後一道參考。當參考這些資料後，都覺得無法表達出原作的意義，就進入自己發想階段。
此處以 Dodge 和 Burn 這一組用語為例，在輸入「Dodge Burn 暗房」關鍵字後，搜尋引擎可以找到「躲避和燒錄」（2012）以及「數位銀鹽攝影術 一場逆向行駛的暗房之旅」 （2022）兩篇比較有用的文章，讓我們參考其用語。
至於輸入「Dodge Burn Photoshop」搜尋，則可以知道該主流軟體採用「Dodge 加亮」和「Burn 加深」為改寫。
前者去情境脈絡直譯為 Dodge 躲避和 Burn 燒錄，後者改寫為加光、減光，而既有的主流軟體則改為加亮、加深。此三者未能表達出功能圖示所表達遮蔽與曝光關聯的概念，皆不貼切，所以進入發想創造。
發想
台灣主流風格新譯詞的發想步驟為：
- 先瞭解該英文單字的泛化模糊概念整體
- 定下詞眼為骨幹
- 添補他字為肉以全該情境下之意義
並套用台灣社群譯法：「只有譬喻式的英文詞（類似中文修辭的借代法）會跨情境直譯；至於其他所有模糊泛用的英文詞，皆會區別英文詞的不同情境，來對應翻譯成不同的中文詞」。
以 Dodge 為例，其英文本意所著重的意象，在於「閃躲」，是要「躲避光線，來達成變亮」，並且圖示同時也在表達遮蔽與曝光的概念，其詞眼必須用到「遮」。因此 Dodge 的譯詞，需同時表達這兩個概念，「遮」、「亮」，即「遮亮」。
以 Burn 為例，其英文本意所著重的意象，在於「曝燒」，是要「曝露光線，來達成變暗、變深」，並且圖示同時也在表達遮蔽與曝光的概念，其詞眼必須用到「曝」。因此 Burn 的譯詞，需同時表達這兩個概念，「曝」、「深」，即「曝深」。而這裡之所以用深而不用暗，是為了與 Photoshop 使用的詞語更加相容。
譯詞識讀要求
另外，根據 Accessibility 的近用性原則，通常翻譯的識讀性目標，應以國中程度為主。
例如 Regular expression，一般譯為「正則表達式」，然而由於中文的「正則」過於冷僻、僵硬，令一般教育下的人們難以理解，識讀性門檻過高。
這裡的「Regular」，代表的是 Regularity 規律性，在數學中也被譯為「正則性」，指根據發現的某種「常規」來表示，故今日建議翻譯成「常規表達式」。
常見翻譯風格
在處理大型程式翻譯時，除了譯詞的統一外，還需要依循共同的翻譯風格。這裡所說的翻譯風格，指的是翻譯的譯法，即直譯、意譯、音譯、音意皆譯等，這些翻譯時所本的概念。純粹音譯因為無法讓讀者直接瞭解意義，故在現代程式翻譯中已不再使用。
在程式翻譯時，通常有以下幾種作法：
一、 直譯
類同翻譯學中的「形式對等翻譯」(Formal equivalent)，直接將原文的文化和語言脈絡移植過來。
以程式翻譯為例，像是將 Menu 在無論任何情境下，皆譯為「菜單」，就是一種去情境脈絡的不對等直譯法；而譯為「選單」，則是情境對應下的對等直譯法。
二、意譯
類同翻譯學中的「功能對等翻譯」(Functional equivalent)，在理解原文的文化和語言脈絡之後，改用自己的語言文化來描述類似的意象與概念。
以程式翻譯為例，像是將協助使用者操作程式、得知程式相關資訊的 Help，翻譯為「說明」，就是一種從幫助概念中抽出說明意象的的中文式換句話說。
而這種意譯相當注重語境，必須精確對應，但只能專項專用，無法通用、汎用到不同情境。一旦丟失情境，意譯很容易變成脫譯或錯譯。
三、改寫
又稱為「作用理解式翻譯」，即根據譯者自身的實際程式操作經驗與理解為基礎，忽略原文的語言和背景脈絡，重新發想個方便讀者理解的自創內容，來替換直譯下或意譯下使用者仍難以理解，或譯者難以翻譯的內容。
在網頁領域中有個 Breadcrumb 詞彙，直譯為「麵包屑」，文化背景出自大眾普遍熟知的格林童話「糖果屋」，用來譬喻這個功能會指出網頁在整個網站階層中的位置，協助使用者有效瞭解及探索網站，就像沿途丟下的麵包屑一樣，能指引使用者。
而使用者可以從導覽標記記錄的最後一個導覽標記開始，依網站階層往上瀏覽，一個階層一個階層往回探索。
在這個案例下，直譯為「麵包屑」是合宜的作法，無論是原文文化背景脈絡，或是台灣的常民文化背景脈絡，大多能理解這個譬喻。
若想要改寫，譯者會以實際操作介面，或其所理解的個人解析，來主觀詮釋、介紹這個概念。
Breadcrumb 常見改寫為「網址導覽標記」，是直接略過原文不管，跳過文化引介的門檻，以翻譯詞直接讓使用者理解介面中該詞語的「實際作用」為何，方便讀者能在去文化脈絡的情境下知道它的「實際作用」，而不用先知道糖果屋的故事。
根據作者主觀詮釋改寫的譯法，最常見缺陷是譯者容易有盲點，或是詞語重複對應，造成未來譯詞碰撞的可能。
像是軟體管理程式中的 Package，早期常見譯為「套件」（現多譯為「軟體包」），是譯者改用擴充套件的概念來表達 Package 能擴充各種新功能。
然而 Package 原意的重點在於和 Repository 相對，是物流封裝包裹遞送的觀念，在這個翻譯中卻完全不見。甚至造成和 Extension 擴充套件（真正意義上的套件）、Suite 套裝軟體（成套的軟體套件）⋯⋯等詞語碰撞，譯者必須另外再發想不同的詞語來避開。
亦即，「套件」一詞在中文語境和文化脈絡下雖然是合理的改稱，但並不是 Package 合適的對等翻譯。
另外，在早期多工作業系統中，Process 常見譯為「行程」（現多譯為「程序」或「處理程序」），便是改用行程安排的概念來表達 Process 的意義。而今日手機普遍，真正意義上的行程 (Event) 安排程式（如行事曆）已大行其道，就會造成溝通上的歧異。
這類譯法，是以既有的文化脈絡描述外來新知，並推知其意義的階段。這就像中國剛開始西化的時候，也習慣用傳統思維解讀外來的洋學。
一旦學術發展到一定程度後，就不必再用過去本土有限的詞彙與概念，推理外國的語言文化，而會開始走向直接以新學治新學，並往上發展開支散葉的階段。
四、直譯加改寫
回到 Breadcrumb 的案例來看，譯者亦可以選擇直譯加改寫的合譯法，像是採取「麵包屑導覽」這樣的翻譯風格。
另外再以 git 命令的 plumbing、porcelain 類別為例，前者直譯為管道工作，後者為瓷器，是一組代表管道與馬桶（或洗臉盆）的譬喻，即做工黑手之於傻瓜使用者。而這些詞語，對於英文母語者的一般常民也是苦手，仍是少數專業人士才能懂的譬喻。
如果以中文直接表達管道、瓷器相當難解，因為中文與英語的最大差別在於：相對於英語的詞語是模糊泛化概念，中文則是情境限定指稱，所以英語讀者看到不會覺得奇怪，而中文讀者卻會覺得自己讀不到限定的情境脈絡，所以多半認為一定是譯者在亂翻譯⋯⋯
因此，這類情況也可以採取直譯加改寫的合譯法，如 plumbing 髒手水管、porcelain 友善瓷盆，這樣處理。
五、維持原文不翻譯
當詞語極為專業，像是 mipmap，其中「MIP」來自於拉丁語 multum in parvo 的首字母，意思是「放置很多東西的小空間」，是為了加快算繪速度並減少鋸齒的可能，而將貼圖處理成一系列已預先計算、最佳化過的圖片所組成的檔案。這樣的貼圖就稱為 mipmap。
此時兩方文化沒有共同脈絡，用詞甚至過於冷僻，而直譯成「多物小空間貼圖」也過於冗長，無法順利橋接。因此，mipmap 一般維持原名 mipmap（全部小寫），就當它是專用的英文術語名稱。
在這種極端情況下，便極為不適合直譯。真要翻譯，就必須採用作用理解式轉意改寫。也許根據其設計目的，可以說是「速成貼圖」。
譯者要注意的是，「mip 在此的作用與目的是速成，但速成並不是 mip 的翻譯」，我們只是從作用來理解 mip 這個字背後的概念，並依此轉意改為速成來稱呼它。
程式翻譯風格指引
原文出自於他語，翻譯在轉換時基於語言特性無法完全對等，以及兩地文化差異的緣故，譯者只能盡可能對應、貼近，故程式翻譯一定會有翻譯味存在。
在程式翻譯領域中，實務作業上以譯完原文意義，並貼切表達為主。
以情境限定對等直譯為基本原則（類同形式對等翻譯 Formal equivalent）
當原文的背景文化與詞語，在台灣本地的情境脈絡下能比擬、互通時，則直譯。在此提醒譯者，我們必須注意到，直譯法是有情境限定的。
一般而言，台灣社群主流翻譯風格下，只有譬喻式的英文詞（類似中文修辭的借代法）會跨情境直譯；而至於其他所有模糊泛用的英文詞，皆會區別英文詞的不同情境，來對應翻譯成不同的中文詞。
舉例而言，如 Menu 沒有菜，非餐廳情境，不會是菜單；Render 沒有水墨，不會是渲染；Script 沒有演員，就不會是腳本。像菜單、渲染、腳本等這些中文詞語，原先都已經是情境限定才會使用的特化詞語。「菜單」是餐廳用語、「渲染」是水墨畫用語，「腳本」是戲劇類用語。
譯者多會先抓到能表達概念的詞眼，接著在這之上延伸來補完情境。
努力在譯詞中補完直譯所缺失的情境概念，是台灣本土翻譯與中國式翻譯之間最明顯的差別。中國式翻譯則極少顧及情境。
像是菜單，台灣社群風格譯法會改說是「選單」；渲染，會說是「算繪」；腳本，會說是「命令稿」等，我們會依據情境與作用來調整對應用語，是與原文語境對等的譯法。
譯者應盡量避免取用過去已限定情境的特化中文詞，不將其重新定義成新的資訊領域中文詞用法，而是再發想、創造出資訊領域專用的新譯詞來表達。
跨情境類比借代詞即直譯
那麽有的人會問，像 Virus 病毒、Worm 蠕蟲、Bug 臭蟲⋯⋯等，這些呢？ 這些詞語不都是已經限定情境用在生物領域了嗎？譯者是不是該另外補完資訊領域下的情境？
像這類英文詞彙，在英文原文中都是一種跨情境類比的譬喻借代，即以其原領域的意義，直接挪用到資訊領域借代使用，擴增原詞彙的使用情境。
例如病毒，取其自我複製與破壞宿主機能的特性，類推挪用至資訊領域。台灣式翻譯也循同樣邏輯，這一類詞彙便不用翻譯成新的對應詞，可重複採用原先有的中文詞，再擴增其新的資訊領域意義。
這與前者「重新定義已經限定情境特化的中文詞」不同，而是同理類推挪用，擴增出新的資訊領域意義。
有的人會說，像是將 Menu 譯為菜單時，菜色就是選項們；將 Render 譯為渲染時，水墨就是電腦畫面中的色彩呈現；將 Script 譯為腳本時，演員就是變數們，這些也都是一種中文語境下的同理類推啊！但，真的是這樣嗎？
英語模糊泛用 vs 中文限定特化
請注意，這是因為英文語言中，詞語特性常有「模糊泛用」的情況（一詞多義，泛指）。
例如，凡有列表清單可選擇的，皆可以類推說是 Menu（原意著重於「列為表單」）；凡有藝術性轉譯呈現到另一個領域上的過程，皆可說是 Render（原意著重於「藝術表現」）；凡有文字或書寫而成的稿件，皆可說是 Script（原意著重於「手寫文稿」）。
翻譯時請留意中文語言的特性，詞語反而是有「限定特化」更為細分的情況（定語指向，特指）。
如菜單，就是限定選擇菜色的單子；渲染，就是限定墨色變化的渲法（上墨後再用水淋擦，使顏色濃淡適宜）和染法（著色落墨於紙張上）；腳本，就是限定寫下腳色劇情安排的底稿文本。
以中文的修飾法來看，要將菜單、渲染、腳本用於資訊領域，屬於譬喻中的借喻法。即將以限定特化的「菜單」比喻成選單、「渲染」比喻電腦畫面色彩呈現、「腳本」比喻執行動作的前後順序安排。
然而，已經特化限定的中文詞語，要再譬喻成資訊領域中的用語，有違中文語言原本的特性，即破壞原先限定的情境，在資訊領域中特別做了重新定義，不再限定。
原文中約定俗成的用語應直譯
至於前面文章曾討論過的 Bug、Patch 等，這都是有典故的，請見這篇。因為有典故，後來約定俗成，就變成英文的「成語」，用 Bug 借代為程式碼中的錯誤，用 Patch 借代為程式碼的修正，並且廣為流傳，成了大家都知道的日常用詞，普及進入大眾文化中。
在這類案例中，唯有將 Bug 和 Patch 翻譯為臭蟲（煩人的蟲）和補丁（或修補檔），才能如實反映出原文語言中的背景文化，並且將這個文化像是搭橋一般介紹到譯者的語言文化中。
若轉意改為「程式碼錯誤」(code
error)、「程式碼修正」(code fix)，雖然也能讓讀者瞭解，但譯文卻丟失了原文中背後的文化脈絡菁華，只剩糟粕。
甚至，讓譯者語言文化衍生出新的、無法解釋的問題：為何程式碼錯誤的圖案是都是用蟲子？為什麼程式碼修正的圖案會是用貼布？
這時就不適合再以譯者所理解的作用，去掉脈絡來轉意改寫。只有將 Bug 和 Patch，或是 Virus、Worm 等這類相當普及的原文譬喻借代詞，如實直接對應翻譯，才能將原文世界中的普及用語文化，引入譯者的語言文化中。
好奇臭蟲和補丁為何的讀者，自會去探查原因，進而瞭解這些約定俗成用語的「通俗」典故，達成譯者應該做的文化橋接（註：文化引介，即自身文化在這個領域上還未發展，譯者將外來文化介紹引入來補完，並往未來開展；譯者作為橋接的中介）目標。
透過這種譯法，才能從以本土脈絡推理外來語言文化的階段，到達能夠直接以新領域語言文化思考表達、成為我們的基礎，並繼續發展的階段。
譯者必須意識到，所謂翻譯，除了翻譯本身外，由於翻譯對象領域多半是自身語言文化中尚缺乏、未成熟、正在擴展的新版圖，所以還負有打造自身語言新領域文化的責任在。
還有，另一種折衷的作法是，在前方補入情境，例如「程式碼臭蟲」或「程式碼補丁」，來限定是指程式碼領域。缺點是變得冗長，如要重複提及時，就變得繁瑣，請斟酌使用。
專業的晦澀黑話維持原文不翻譯，或採作用理解式改寫 Adaption
再來聊另一個例子 Lint，起源自 lint，指「衣物上掉下來的毛絮、線頭」。
linter 程式的誕生，就是原作者的譬喻加借代，指稱「清除洗衣機或烘衣機裡面設計用來收集這些毛絮團塊的裝置 (有一個 lint trap 收集槽）」。所以最早在 Unix 中出現時，設計師以 lint 來命名這個程式。
在中文語言裡，毛絮也無法當作動詞用，如果譯者只講「毛絮」，或甚至「收集毛絮」都會讓人不知所云。
這個詞是高度專業的資訊領域用語，俗稱「行話」或「黑話」，相較於通俗常見的 Bug 或 Patch 等，反而只有程式設計專業才會見到，門檻極高。
所以，僅有極少數人可能查得到 lint 或 linter 的命名起源歷史，更別說是翻譯成毛絮後，這些專業人士會有多少人能讀懂了。
此時兩方文化沒有共同脈絡，用詞甚至過於冷僻，而直譯詞也脫離中文語法，無法順利橋接。因此，lint 一般維持程式原名 lint（全部小寫），就當它是專用的程式名稱。
在這種極端情況下，便極為不適合直譯。真要翻譯，就必須採用作用理解式轉意改寫。lint 如果是當作動詞用的話，則可以說他是梳理；linter 則可稱為「梳理器」。
譯者要注意的是，「lint 在此的作用與目的是梳理，但梳理並不是 lint 的翻譯」，只是從作用來理解這個字背後的意義，並依此轉意改為梳理來稱呼它。
多人參與專案應少用意譯（類同功能對等翻譯 Functional equivalent）
最後，還有一種資訊領域翻譯極少用的風格，即意譯，也稱為「當地本位風格譯法」。請想像一下，有一天原作者如果突然不會自己的語言，也不懂自己的文化了，卻突然說得一口好國語、寫得一手好作文，還懂各種台灣當地人的風俗文化，那麼同樣的句子他會怎麼說？
這種譯法風格，不須考慮文化引介、也不須以原作者創作時的背景脈絡表達。
翻譯出來的成品，就會很像是一個台灣人寫的，非常道地的地方性程式一樣。有一些很想與在地文化接軌的軟體程式，則可能會以這種語氣與說法來翻譯。這其實也更偏向於改作，而非照實翻譯。
然而，出自於外來語言、文化的原文，在翻譯轉換時基於雙方語言特性無法完全對等，以及兩地文化差異的緣故，只能盡可能對應、貼近。
在程式翻譯領域中，實務作業上以「譯完原文意義，並貼切表達」為主；較少花費時間心力雕琢成純母語的在地文化風格，更何況乎這類譯文風格會大受譯者的語文造詣、主觀詮釋、內在涵養影響。
若要如此執行，則必須整套程式都採同樣風格，專案越大越多人參與越難控管，不同譯者間的語文表達方式都有差異，最後必須有一人再次以其主觀統一，重複勞動。
即便完成了，也會和系統中的他家程式語感有所落差。除非是整套系統都能控管，人力與時間足夠，或是出資協助翻譯的業主有所要求、同時贊助譯者的預算充足，否則一般不會採用這種翻譯風格。
在少數使用意譯的情況下，一般是為了好玩以及本土的親切感，來增添程式使用上的樂趣。像是程式對使用者的招呼，出錯時的訊息，或文字範例、書信對話詞語⋯⋯等等。
以上是台灣社群在翻譯自由軟體專案程式時的翻譯風格示例、探討與指引。也歡迎對程式翻譯有興趣的朋友們一起討論。
留言
張貼留言