---
image: https://l10n.tw/l10n-tw-logo/%E5%9C%96%E7%89%87/l10n-tw-logo.png
lang: zh-tw
---

# 自由軟體正體中文化翻譯風格指引 (Traditional Chinese L10N Translation Style Guide)

[TOC]

## 前言

本文目的是希望為目前正體中文翻譯環境，設立共同的翻譯風格指引。
指引並非「規範」，謹作為一種「共通的翻譯法風格」供社群譯者參考。

如有任何建議，您可以在正體中文譯者郵遞論壇提出，或加入<svg aria-hidden="true" focusable="false" data-prefix="fab" data-icon="telegram" class="svg-inline--fa fa-telegram fa-w-16" role="img" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 496 512" style="width: 14px; height: 14px"><path fill="currentColor" d="M248 8C111 8 0 119 0 256s111 248 248 248 248-111 248-248S385 8 248 8zm121.8 169.9l-40.7 191.8c-3 13.6-11.1 16.9-22.4 10.5l-62-45.7-29.9 28.8c-3.3 3.3-6.1 6.1-12.5 6.1l4.4-63.1 114.9-103.8c5-4.4-1.1-6.9-7.7-2.5l-142 89.4-61.2-19.1c-13.3-4.2-13.6-13.3 2.8-19.7l239.1-92.2c11.1-4 20.8 2.7 17.2 19.5z"></path></svg> [Telegram 群組](https://t.me/l10n_tw)一同線上討論，也竭誠歡迎您加入我們的行列。

各個專業領域有不同的術語，同一個字詞在不同的領域下，也可能有不同的稱呼，或是不同的意義，所以在處理專業領域的程式時，需要謹守一些準則與心法，才能將翻譯處理得好。以下內容根據 GNOME 專案下的 GIMP 翻譯為例。

對於翻譯者，建議您列印本文件，以便在翻譯時隨時查閱。
#### 正體中文譯者社群郵遞論壇
翻譯群組郵遞論壇：[e-mail]
網頁版：https://lists.slat.org/mailman3/postorius/lists/zh-l10n.lists.slat.org/

來加入論壇：請發一封信到 [e-mail]
或是到上述網址去 subscribe。

想離開論壇：發一封信到 [e-mail]
或是到上述網址去 unsubscribe。

## 基本守則

當譯者在考量某個詞彙或整體語句的翻譯時，必須一併考量原作者創作時的文化背景（例如程式用詞背後的情境脈絡、作者可能的文化涵養），以及譯者自身語言的文化背景（本土文化下的情境脈絡、自身的語文造詣和內在涵養），然後試圖在兩者之間比擬對應（試圖以本土語言與文化貼近原作），如此才能得出好讀的、如實呈現的翻譯。

即：**信實傳遞原文化背景與情境，並以自身語言貼切表達**。（此為思果提出的信達貼守則）

## 術語翻譯訂立

以 GIMP 這套影像處理領域的專業程式來說，想要翻譯得好，就需要瞭解常見、已知的影像處理專業術語作為參考資料。

這些用語可以從台灣人撰寫的網頁資料，或是出版的專業書籍取得，並作為譯詞參考。

若社群已有現成的出版書籍，可作為術語用詞對照。像是專業的辦公生產力領域下，如 LibreOffice 套裝程式為例，則有《[LibreOffice 排版設計](http://url.slat.org/dwl-tw)》一書能參考。

本指引整理了早期譯者，在初次遇到還沒有譯詞的時候所採取的做法。若已經有習慣譯詞用語偏好的人，可以繼續採用屬於自己社會文化時期的用語。

舉例而言，如 Render 一詞，在資訊領域發展早期，約莫是圖形介面剛起步的階段，常用「算圖」，後來則有「算繪」等譯詞推出；接著再看 2025 年時，幾乎一般群眾都已習慣稱呼為「渲染」。不同時期的人所學會、慣用的詞語不同，故用詞也反映譯者成長的年代。若個人有強烈詞語偏好，則建議從本指引中學會發想譯詞、判斷譯詞的方法即可，至於自己喜歡用什麼，由譯者自主決定就行。

術語的譯詞訂立方法如下：

### 一、理解

對於那些找不到對應中文資料的詞語，則可以先瞭解詞語的使用情境，例如查詢 [Wikipedia 維基百科](https://zh.wikipedia.org/wiki/Wikipedia:%E9%A6%96%E9%A1%B5)、[Merriam-Webster](https://www.merriam-webster.com/)、[Oxford Learner's Dictionaries](https://www.oxfordlearnersdictionaries.com/) 英英字典，或是**程式提供的文件說明網頁、新版本的 Release Note**（此為重中之重的要點）等，以及查詢得到的英文討論資料等。以資料為據，先弄懂詞語的用途、原理、概念。

拿 GIMP 舉例，最重要的參考資料是 GIMP Documentation，即 [2.10 版的使用手冊](https://docs.gimp.org/2.10/en/)。每當不清楚詞語意義時，必先查找文件以瞭解對應情境。

接著我們來看 Dodge 和 Burn 這一組用語作案例探討，在 [GIMP Documentation 中](https://docs.gimp.org/2.10/en/gimp-tool-dodge-burn.html)是「The Dodge or Burn tool uses the current brush to lighten or darken the colors in your image. 」

另外，Dodge / Burn 的圖示是一根遮擋光線的棒子，類似視力檢查的遮擋棒，如上圖。

在搜尋引擎中輸入「Dodge Burn Wikipedia」，可以在[維基百科中](https://en.wikipedia.org/wiki/Dodging_and_burning)得知，原來這是相片印刷用暗房處理技巧用語，是負片投影轉正程序，並附圖解說 Burn 以加強曝光，來達到變更暗（相紙照到更多光，顯影越多顯得越暗）；Dodge 以遮蔽曝光，來達到變更亮的效果（相紙照到較少光，顯影越少顯得越亮）。

[By きたし](https://commons.wikimedia.org/w/index.php?curid=2159366) - Own work, CC BY-SA 2.5

### 二、貼近

接著揣想用中文要怎麼說比較好，在這個發想過程中，可以參考[劍橋英漢字典](https://dictionary.cambridge.org/zht/%E8%A9%9E%E5%85%B8/%E8%8B%B1%E8%AA%9E-%E6%BC%A2%E8%AA%9E-%E7%B9%81%E9%AB%94/)，或是[教育部重編國語辭典](https://dict.revised.moe.edu.tw/)等，以及網路有的資料（如[樂詞網](https://terms.naer.edu.tw/)等），來逼近出適當的中文詞語。如果找不到適當的對應詞語，則進入發想創造。

譯者要注意的是，既有的常見翻譯很有可能是不良翻譯。請先理解原文與概念，再試著用自己的語言說，只有在想不到詞彙能比擬後，才去找已有的中文資料，並將微軟系統譯詞、蘋果系統譯詞、各軟體公司譯詞、樂詞網搜集之譯詞作為最後一道參考。當參考這些資料後，都覺得無法表達出原作的意義，就進入自己發想階段。

此處以 Dodge 和 Burn 這一組用語為例，在輸入「Dodge Burn 暗房」關鍵字後，搜尋引擎可以找到「[躲避和燒錄](https://cg2010studio.com/2012/02/27/%E8%BA%B2%E9%81%BF%E5%92%8C%E7%87%92%E9%8C%84-dodging-and-burning/)」（2012）以及「[數位銀鹽攝影術 一場逆向行駛的暗房之旅](https://pinealgland-edu.medium.com/%E6%95%B8%E4%BD%8D%E9%8A%80%E9%B9%BD%E6%94%9D%E5%BD%B1%E8%A1%93-%E4%B8%80%E5%A0%B4%E9%80%86%E5%90%91%E8%A1%8C%E9%A7%9B%E7%9A%84%E6%9A%97%E6%88%BF%E4%B9%8B%E6%97%85-fab9a90cf09d)」 （2022）兩篇比較有用的文章，讓我們參考其用語。

至於輸入「Dodge Burn Photoshop」搜尋，則可以知道該主流軟體採用「Dodge 加亮」和「Burn 加深」為改寫。

前者去情境脈絡直譯為 Dodge 躲避和 Burn 燒錄，後者改寫為加光、減光，而既有的主流軟體則改為加亮、加深。此三者未能表達出功能圖示所表達遮蔽與曝光關聯的概念，皆不貼切，所以進入發想創造。

### 三、發想

台灣主流風格新譯詞的發想步驟為：

* 先瞭解該英文單字的泛化模糊概念整體
* 定下詞眼為骨幹
* 添補他字為肉以全該情境下之意義

並套用台灣社群譯法：「只有譬喻式的英文詞（類似中文修辭的借代法）會跨情境直譯；至於其他所有模糊泛用的英文詞，皆會**區別英文詞的不同情境，來對應翻譯成不同的中文詞**」。

以 Dodge 為例，其英文本意所著重的意象，在於「閃躲」，是要「躲避光線，來達成變亮」，並且圖示同時也在表達遮蔽與曝光的概念，其詞眼必須用到「遮」。因此 Dodge 的譯詞，需同時表達這兩個概念，「遮」、「亮」，即「遮亮」。

以 Burn 為例，其英文本意所著重的意象，在於「曝燒」，是要「曝露光線，來達成變暗、變深」，並且圖示同時也在表達遮蔽與曝光的概念，其詞眼必須用到「曝」。因此 Burn 的譯詞，需同時表達這兩個概念，「曝」、「深」，即「曝深」。而這裡之所以用深而不用暗，是為了與 Photoshop 使用的詞語更加相容。

### 四、譯詞識讀要求

另外，根據 Accessibility 的近用性原則，通常翻譯的識讀性目標，應以國中程度為主。

例如 Regular expression，一般譯為「正則表達式」，然而由於中文的「正則」過於冷僻、僵硬，令一般國民教育下的人們難以理解，識讀性門檻過高。

這裡的「Regular」，代表的是 Regularity 規律性，在數學中也被譯為「正則性」，指根據發現的某種「常規」來表示，故今日建議翻譯成「常規表達式」。此譯法亦可與 Normalization 的正規化、歸一化作區別對應，避免重複對應。

### 五、避免重複對應

對於相同術語或短語所採用的譯詞，必須前後一致。程式翻譯與文學作品性質不同，注重再現性、重複性與一致性。

術語譯詞盡可能一對一對應，避免讓同一個中文詞彙，重複與多個不同概念而被區分使用的英文術語對應。

## 常見翻譯風格

在處理大型程式翻譯時，除了譯詞的統一外，還需要依循共同的翻譯風格。這裡所說的翻譯風格，指的是翻譯的譯法，即直譯、意譯、音譯、音意皆譯等，這些翻譯時所本的概念。純粹音譯因為無法讓讀者直接瞭解意義，故在現代程式翻譯中已不再使用。

在程式翻譯時，通常有以下幾種作法：

### 一、直譯

類同翻譯學中的「形式對等翻譯」(Formal equivalent)，直接將原文的文化和語言脈絡移植過來。

以程式翻譯為例，像是將 Menu 在無論任何情境下，皆譯為「菜單」，就是一種去情境脈絡的**不對等直譯**法；而譯為「選單」，則是情境對應下的**對等直譯**法。

### 二、意譯

類同翻譯學中的「功能對等翻譯」(Functional equivalent)，在理解原文的文化和語言脈絡之後，改用自己的語言文化來描述類似的意象與概念。

以程式翻譯為例，像是將協助使用者操作程式、得知程式相關資訊的 Help，翻譯為「說明」，就是一種從幫助概念中抽出說明意象的的中文式換句話說。

而這種意譯相當注重語境，必須精確對應，但只能專項專用，無法通用、汎用到不同情境。一旦丟失情境，意譯很容易變成脫譯或錯譯。

### 三、改寫

又稱為「作用理解式翻譯」，即根據譯者自身的實際程式操作經驗與理解為基礎，忽略原文的語言和背景脈絡，重新發想個方便讀者理解的**自創內容**，來替換直譯下或意譯下使用者仍難以理解，或譯者難以翻譯的內容。

在網頁領域中有個 Breadcrumb 詞彙，直譯為「麵包屑」，文化背景出自大眾普遍熟知的格林童話「糖果屋」，用來譬喻這個功能會指出網頁在整個網站階層中的位置，協助使用者有效瞭解及探索網站，就像沿途丟下的麵包屑一樣，能指引使用者。

而使用者可以從導覽標記記錄的最後一個導覽標記開始，依網站階層往上瀏覽，一個階層一個階層往回探索。

在這個案例下，直譯為「麵包屑」是合宜的作法，無論是原文文化背景脈絡，或是台灣的常民文化背景脈絡，大多能理解這個譬喻。

若想要改寫，譯者會以實際操作介面，或其所理解的個人解析，來主觀詮釋、介紹這個概念。

Breadcrumb 常見改寫為「網址導覽標記」，是直接略過原文不管，跳過文化引介的門檻，以翻譯詞直接讓使用者理解介面中該詞語的「實際作用」為何，方便讀者能在去文化脈絡的情境下知道它的「實際作用」，而不用先知道糖果屋的故事。

根據作者主觀詮釋改寫的譯法，**最常見缺陷是譯者容易有盲點，或是詞語重複對應**，造成未來譯詞碰撞的可能。

像是軟體管理程式中的 Package，早期常見譯為「套件」（現多譯為「軟體包」），是譯者改用擴充套件的概念來表達 Package 能擴充各種新功能。

然而 Package 原意的重點在於和 Repository 相對，是物流封裝包裹遞送的觀念，在這個翻譯中卻完全不見。甚至造成和 Extension 擴充套件（真正意義上的套件）、Suite 套裝軟體（成套的軟體套件）、Distribution 散布版（團體或單位發行的整份散布品，又被稱為發行套件、分發套件、發行版）⋯⋯等詞語碰撞，譯者必須另外再發想不同的詞語來避開。

亦即，「套件」一詞在中文語境和文化脈絡下雖然是合理的改稱，但並不是 Package 合適的對等翻譯。

另外，在早期多工作業系統中，Process 常見譯為「行程」（現多譯為「程序」或「處理程序」），便是改用行程安排的概念來表達 Process 的意義。而今日手機普遍，原始意義上的行程 (Event) 安排程式（如行事曆）已大行其道，就會造成一般人（不懂電腦 Process 的常民）溝通與閱讀上的誤解。

這類譯法，屬於以既有的文化脈絡來描述外來新知，並推知其意義的階段。這就像中國剛開始西化的時候，也習慣用傳統思維解讀外來的洋學。

一旦學術發展到一定程度後，累積了底子，就不必再用過去本土有限的詞彙與概念，推理外國的語言文化，而會開始走向直接以新學治新學，並往上發展開枝散葉的階段。

### 四、直譯加改寫

回到 Breadcrumb 的案例來看，譯者亦可以選擇**直譯加改寫的合譯法**，像是採取「麵包屑導覽」這樣的翻譯風格。

另外再以 git 命令的 plumbing、porcelain 類別為例，前者直譯為管道工作，後者為瓷器，是一組代表管道與馬桶（或洗臉盆）的譬喻，即做工黑手之於傻瓜使用者。而這些詞語，對於英文母語者的一般常民也是苦手，仍是少數專業人士才能懂的譬喻。

如果以中文直接表達管道、瓷器相當難解，因為中文與英語的最大差別在於：相對於英語的詞語是模糊泛化概念，中文則是情境限定指稱，所以英語讀者看到不會覺得奇怪，而中文讀者卻會覺得自己讀不到限定的情境脈絡，所以多半認為一定是譯者在亂翻譯⋯⋯

因此，這類情況也可以採取直譯加改寫的合譯法，如 plumbing 髒手水管、porcelain 友善瓷盆，這樣處理。

### 五、維持原文不翻譯

當詞語極為專業，像是 mipmap，其中「MIP」來自於拉丁語 multum in parvo 的首字母，意思是「放置很多東西的小空間」，是為了加快算繪速度並減少鋸齒的可能，而將貼圖預先處理成一系列已經運算、最佳化過的多種解析度圖片所組成的檔案。這樣的貼圖就稱為 mipmap。

此時兩方文化沒有共同脈絡，用詞甚至過於冷僻，而直譯成「多物小空間貼圖」也過於冗長，無法順利橋接。因此，mipmap 一般維持原名 mipmap（全部小寫），就當它是專用的英文術語名稱；或是稱為 mip 貼圖。

在這種極端情況下，便極為不適合直譯。真要翻譯，就必須採用作用理解式轉意改寫。也許根據其設計目的，可以說是「速用多段貼圖」。

譯者要注意的是，「mip 在此的**作用與目的**是快速使用、採多段式，但速用多段並不是 mip 的翻譯」，我們只是從作用來理解 mip 這個字背後的概念，並依此轉意改為速用多段來稱呼它。

## 程式翻譯風格指引

原文出自於他語，翻譯在轉換時基於語言特性無法完全對等，以及兩地文化差異的緣故，譯者只能盡可能對應、貼近，故程式翻譯一定會有翻譯味存在。

在程式翻譯領域中，實務作業上以**譯完原文關鍵詞意義，並整體貼切表達**為主。

### 一、心法

即**句子結構**以整體意譯為佳（類同功能對等翻譯），並以流暢的中文表達。

至於句中**關鍵詞或術語**，則請先以情境限定直譯（類同形式對等翻譯）為基本原則出發，再視以下情況延伸考慮。

### 二、以情境限定對等直譯為基本原則（類同形式對等翻譯 Formal Equivalence）

當原文的背景文化與詞語，在台灣本地的情境脈絡下能比擬、互通時，則直譯。在此提醒譯者，我們必須注意到，直譯法是**有情境限定**的。

一般而言，台灣社群主流翻譯風格下，只有譬喻式的英文詞（類似中文修辭的借代法）會跨情境直譯；而至於其他所有模糊泛用的英文詞，皆會區別英文詞的不同情境，來對應翻譯成不同的中文詞。

舉例而言，如 Menu 沒有菜，非餐廳情境，不會是菜單；Render 沒有水墨，不會是渲染；Script 沒有演員，就不會是腳本。像菜單、渲染、腳本等這些中文詞語，原先都已經是情境限定才會使用的特化詞語。「菜單」是餐廳用語、「渲染」是水墨畫用語，「腳本」是戲劇類用語。

譯者多會先抓到能表達概念的詞眼，接著在這之上延伸來補完情境。

努力在譯詞中補完直譯所缺失的情境概念，是台灣本土翻譯與中國式翻譯之間最明顯的差別。中國式翻譯則極少顧及情境。

像是菜單，台灣社群風格譯法會改說是「選單」；渲染，會說是「算繪」；腳本，會說是「命令稿」等，我們會依據情境與作用來調整對應用語，是與原文語境對等的譯法。

譯者應盡量避免取用過去已限定情境的特化中文詞，不將其重新定義成新的資訊領域中文詞用法，而是再發想、創造出資訊領域專用的新譯詞來表達。

#### 跨情境類比借代詞即直譯

那麽有的人會問，像 Virus 病毒、Worm 蠕蟲、Bug 臭蟲⋯⋯等，這些呢？ 這些詞語不都是已經限定情境用在生物領域了嗎？譯者是不是該另外補完資訊領域下的情境？

像這類英文詞彙，在英文原文中都是一種跨情境類比的譬喻借代，即以其原領域的意義，直接挪用到資訊領域借代使用，擴增原詞彙的使用情境。

例如病毒，取其自我複製與破壞宿主機能的特性，類推挪用至資訊領域。台灣式翻譯也循同樣邏輯，這一類詞彙便不用翻譯成新的對應詞，可重複採用原先有的中文詞，再擴增其新的資訊領域意義。

這與前者「重新定義已經限定情境特化的中文詞」不同，而是同理類推挪用，擴增出新的資訊領域意義。

有的人會說，像是將 Menu 譯為菜單時，菜色就是選項們；將 Render 譯為渲染時，水墨就是電腦畫面中的色彩呈現；將 Script 譯為腳本時，演員就是變數們，這些也都是一種中文語境下的同理類推啊！但，真的是這樣嗎？

#### 英語模糊泛用 vs 中文限定特化

請注意，這是因為英文語言中，詞語特性常有「模糊泛用」的情況（一詞多義，泛指）。

例如，凡有列表清單可選擇的，皆可以類推說是 Menu（原意著重於「列為表單」）；凡有藝術性轉譯呈現到另一個領域上的過程，皆可說是 Render（原意著重於「藝術表現」）；凡有文字或書寫而成的稿件，皆可說是 Script（原意著重於「手寫文稿」）。

翻譯時請留意中文語言的特性，詞語反而是有「限定特化」更為細分的情況（定語指向，特指）。

如菜單，就是限定選擇菜色的單子；渲染，就是限定墨色變化的渲法（上墨後再用水淋擦，使顏色濃淡適宜）和染法（著色落墨於紙張上）；腳本，就是限定寫下腳色劇情安排的底稿文本。

以中文的修飾法來看，要將菜單、渲染、腳本用於資訊領域，屬於譬喻中的借喻法。即把已限定特化的「菜單」比喻成選單、「渲染」比喻電腦畫面色彩呈現、「腳本」比喻執行動作的前後順序安排。

然而，已經特化限定的中文詞語，要再譬喻成資訊領域中的用語，有違中文語言原本的特性，即破壞原先限定的情境，在資訊領域中特別做了重新定義，不再限定。

### 三、原文中約定俗成的用語應直譯

至於 Bug、Patch 等，是有典故的，請參見[這篇](http://breezymove.blogspot.com/2017/03/bug-vs-patch.html)。因為有典故，後來約定俗成，就變成英文的「成語」，用 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 Equivalence）個人風格

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

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

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

然而，出自於外來語言、文化的原文，在翻譯轉換時基於雙方語言特性無法完全對等，以及兩地文化差異的緣故，只能盡可能對應、貼近。

在程式翻譯領域中，實務作業上以「**譯完原文關鍵詞意義，並整體貼切表達**」為首要目標；較少再花費時間心力雕琢成個性化的在地文化風格，更何況乎這類譯文風格會大受譯者的語文造詣、主觀詮釋、內在涵養影響。

若要如此執行，則必須整套程式都採同樣風格，專案越大越多人參與越難控管，不同譯者間的個人語文表達方式都有差異，最後必須有一人再次以其主觀統一，重複勞動。

即便完成了，也會和系統中的他家程式語感有所落差。除非是整套系統都能控管，人力與時間足夠，或是出資協助翻譯的業主有所要求、同時贊助譯者的預算充足，否則一般不會採用這種翻譯風格。

在少數使用意譯的情況下，一般是為了好玩以及本土的親切感，來增添程式使用上的樂趣。像是程式對使用者的招呼，出錯時的訊息，或文字範例、書信對話詞語⋯⋯等等，通常只在特定情境下使用。

以上是台灣社群在翻譯自由軟體專案程式時的翻譯風格示例、探討與指引。也歡迎對程式翻譯有興趣的朋友們一起討論。

## 作者

- Cheng-Chia Tseng <[e-mail]>, 2024, 2025.

本文依據《[創用 CC 姓名標示 4.0 國際](http://creativecommons.org/licenses/by-nc-sa/3.0/https://creativecommons.org/licenses/by/4.0/legalcode.zh-hant)》權條款給予授權。

---

## 更新紀錄

2024-11-03
@zerngjia 發表了第一版的翻譯風格指引