--- 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 翻譯為例。 對於翻譯者,建議您列印本文件,以便在翻譯時隨時查閱。 #### 正體中文譯者社群郵遞論壇 翻譯群組郵遞論壇:zh-l10n@lists.slat.org 網頁版:https://lists.slat.org/mailman3/postorius/lists/zh-l10n.lists.slat.org/ 來加入論壇:請發一封信到 zh-l10n-join@lists.slat.org 或是到上述網址去 subscribe。 想離開論壇:發一封信到 zh-l10n-leave@lists.slat.org 或是到上述網址去 unsubscribe。 ## 基本守則 當譯者在考量某個詞彙或整體語句的翻譯時,必須一併考量原作者創作時的文化背景(例如程式用詞背後的情境脈絡、作者可能的文化涵養),以及譯者自身語言的文化背景(本土文化下的情境脈絡、自身的語文造詣和內在涵養),然後試圖在兩者之間比擬對應(試圖以本土語言與文化貼近原作),如此才能得出好讀的、如實呈現的翻譯。 即:**信實傳遞原文化背景與情境,並以自身語言貼切表達**。(此為思果提出的信達貼守則) ## 術語翻譯訂立 以 GIMP 這套影像處理領域的專業程式來說,想要翻譯得好,就需要瞭解常見、已知的影像處理專業術語作為參考資料。 這些用語可以從台灣人撰寫的網頁資料,或是出版的專業書籍取得,並作為譯詞參考。 若社群已有現成的出版書籍,可作為術語用詞對照。像是專業的辦公生產力領域下,如 LibreOffice 套裝程式為例,則有《[LibreOffice 排版設計](http://url.slat.org/dwl-tw)》一書能參考。 術語的譯詞訂立方法如下: ### 一、理解 對於那些找不到對應中文資料的詞語,則可以先瞭解詞語的使用情境,例如查詢 [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. 」 ![stock-tool-dodge-22](https://hackmd.io/_uploads/rJ7hE-BWJx.png) 另外,Dodge / Burn 的圖示是一根遮擋光線的棒子,類似視力檢查的遮擋棒,如上圖。 在搜尋引擎中輸入「Dodge Burn Wikipedia」,可以在[維基百科中](https://en.wikipedia.org/wiki/Dodging_and_burning)得知,原來這是相片印刷用暗房處理技巧用語,是負片投影轉正程序,並附圖解說 Burn 以加強曝光,來達到變更暗(相紙照到更多光,顯影越多顯得越暗);Dodge 以遮蔽曝光,來達到變更亮的效果(相紙照到較少光,顯影越少顯得越亮)。 ![640px-Darkroom_dodging.svg](https://hackmd.io/_uploads/SkKWSbB-1x.png) ![640px-Darkroom_burn.svg](https://hackmd.io/_uploads/BJoGr-rWJe.png) [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 規律性,在數學中也被譯為「正則性」,指根據發現的某種「常規」來表示,故今日建議翻譯成「常規表達式」。 ## 常見翻譯風格 在處理大型程式翻譯時,除了譯詞的統一外,還需要依循共同的翻譯風格。這裡所說的翻譯風格,指的是翻譯的譯法,即直譯、意譯、音譯、音意皆譯等,這些翻譯時所本的概念。純粹音譯因為無法讓讀者直接瞭解意義,故在現代程式翻譯中已不再使用。 在程式翻譯時,通常有以下幾種作法: ### 一、直譯 類同翻譯學中的「形式對等翻譯」(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 等,是有典故的,請參見[這篇](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 equivalent) 最後,還有一種資訊領域翻譯極少用的風格,即意譯,也稱為「當地本位風格譯法」。請想像一下,有一天原作者如果突然不會自己的語言,也不懂自己的文化了,卻突然說得一口好國語、寫得一手好作文,還懂各種台灣當地人的風俗文化,那麼同樣的句子他會怎麼說? 這種譯法風格,不須考慮文化引介、也不須以原作者創作時的背景脈絡表達。 翻譯出來的成品,就會很像是一個台灣人寫的,非常道地的地方性程式一樣。有一些很想與在地文化接軌的軟體程式,則可能會以這種語氣與說法來翻譯。這其實也更偏向於改作,而非照實翻譯。 然而,出自於外來語言、文化的原文,在翻譯轉換時基於雙方語言特性無法完全對等,以及兩地文化差異的緣故,只能盡可能對應、貼近。 在程式翻譯領域中,實務作業上以「譯完原文意義,並貼切表達」為主;較少花費時間心力雕琢成純母語的在地文化風格,更何況乎這類譯文風格會大受譯者的語文造詣、主觀詮釋、內在涵養影響。 若要如此執行,則必須整套程式都採同樣風格,專案越大越多人參與越難控管,不同譯者間的語文表達方式都有差異,最後必須有一人再次以其主觀統一,重複勞動。 即便完成了,也會和系統中的他家程式語感有所落差。除非是整套系統都能控管,人力與時間足夠,或是出資協助翻譯的業主有所要求、同時贊助譯者的預算充足,否則一般不會採用這種翻譯風格。 在少數使用意譯的情況下,一般是為了好玩以及本土的親切感,來增添程式使用上的樂趣。像是程式對使用者的招呼,出錯時的訊息,或文字範例、書信對話詞語⋯⋯等等。 以上是台灣社群在翻譯自由軟體專案程式時的翻譯風格示例、探討與指引。也歡迎對程式翻譯有興趣的朋友們一起討論。 ## 作者 - Cheng-Chia Tseng <zerngjia@gmail.com>, 2024. 本文依據《[創用 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 發表了第一版的翻譯風格指引