風吹草動

最近校對了 GNOME 旗下生態圈的 Warp 程式，也稱為《傳送門》，用於點對點、跨多裝置的檔案傳輸，採用「Magic Wormhole 神奇蟲洞」協定。如果有用過 iPhone 手機的話，類似 AirDrop 這樣的東西。 其中用到了一些傳送、傳輸相關的詞彙，在這裡也稍微辨析一下。 Transfer Transfer 在 Merriam-Webster 和 Oxford Learner's Dictionaries 字典中，此處接近的釋義是：     to cause to pass from one to another : transmit     使其從一處通往另一處 就過去業界的習慣，例如 FTP，File Transfer Protocol，已固定譯為「檔案傳輸協定」，可以直接沿用「傳輸」。 另外，若從檔案放在甲處，接著讓其他乙、丙、丁⋯⋯等處，皆能得到同一份副本，那麼這樣的動作在口語中也被稱為「轉傳」。例如：「欸欸！你剛剛拍的照片記得回去要轉傳給我！」所以，也能視情境譯為「轉傳」。 Transmit Transmit 在 Merriam-Webster 的釋義當中，基本上類同 Transfer，但更著重通過所路經的媒介：     to send or convey from one person or place to another 從一人那傳送或傳遞給另一人那          to cause (something, such as light or force) to pass or be conveyed through space or a medium 使其（某物，如光、力）經由空間或某種媒介通過或傳遞     to send out (a signal) either by radio waves or over a wire 透過無線電波或是線路傳送（訊號） 另外參考 Oxford Learner's Dictionaries：     to send an electronic signal, radio or television broadcast, etc. 送出電子訊號、無線電、電視廣播等。 總體來看，Transmit 類同中文的「傳送」，特別是發送訊號、無線電波等，這一類物理特性的傳送。此外，台灣

以前 RSS feed 剛流行的年代，曾幫 KDE 的 Akregator 翻譯部分內容。 記錄一下當時個人採用的譯詞，Feed 為「消息饋流」，Aggregator 為「匯集器」。 後來 Rhythmbox 也開始支援 Podcast，同樣會用到 feed 一詞；而這類情況下，則不需要消息二字作為前綴，稱「饋流」即可。

sink: 音效工程用語，作為聲音訊流的最終承接播放裝置，例如實體喇叭，也可能是虛擬裝置。 source: 音效工程用語，作為聲音訊流的聲音初始收錄來源，例如實體麥克風，也可能是虛擬裝置，或是監聽前述的承接裝置而來。

如果我們探究 Regular Expression 的「Regular」，會發現它代表的是 Regularity 規律性，在數學中也被譯為「正則性」，指根據發現的某種「常規」來表示。 至於常聽到的「正規表達式」，正規是錯譯。中文的正規代表正式規範，意即英文的 Norm/Normal。 中文的常規與正規不同，最大的差異在於一個是尋常性、普遍性、日常習慣，另一個則是權威性、正式性、官方訂立的標準。 正常二字，則代表既正且常，符合規範而且尋常。 由於中文的「正則」過於冷僻、僵硬，令一般教育下的人們難以理解，識讀性門檻過高（根據 Accessibility 的近用性原則，通常翻譯的識讀性目標，應以國中程度為主），建議翻譯成「常規表達式」。錯譯的正規表達式就別再用了。

軟體翻譯中，Back、Forward 是一組特別需要留意的詞彙。 為什麼呢？因為中文與英文兩種語言，在思考怎樣表達時間的特性不同之故。 以中文為例，在講書籍的前後、事件發生經歷的前後、人生的前後時，採用的是整體觀，亦即你已經知道書籍、事件、人生是一個整體，故開端為前方，尾聲為後方。 書本內容上下文、事件先後順序、人生從小到大，在中文的表達裡，是由前而後的，由原先走到後來。 然而，在英文表達裡，採用的觀點是主觀，亦即你就是當事人，位在所欲觀察的目標之內，隨著文字描述、事情發生、人生經歷，一步一步前進，還未經歷者在你眼前，而經過的則落在你後方。 因此，英文介面中，Forward 指的是行進觀點下的「前進」，Back 則是「返回」，這是最通用的萬能譯法，比較不會發生用詞前後錯亂不一致的問題。 如果要以中文慣有的思路，來表達這裡的 Forward 和 Back，就完全反過來了。Forward 成了「往後」、「往下」，Back 成了「往前」、「往上」。 有的譯者會轉個意思，改用 Next 和 Previous 這組詞的「下一個」、「下一步」，或「上一個」、「上一步」來表達，迴避這個矛盾之處，然而本人並不推薦。 因為這些按鈕有時候是由 Widget 或 Toolkit 提供，很可能有的程式開發者同時用到 Forward/Back 和 Next/Previous 這兩組，而且你也不知道他們思路中的前後上下左右。 例如，你把翻譯寫死成上下，但在介面中的表現卻是左右移動；這遠不如維持用動態感的「前進」和「返回」行進觀來得靈活。簡而言之，轉意改寫式翻譯法可能造成其他未預期的困擾，還是盡量避免為佳。 還有，對於舊版的相容性，稱為 Backward Compatible，是往過去相容。在中文的時間描述裡，往後是指今天以後，往前才是過往，所以這裡的 Backward 其實是「往前」。 如果翻譯成「往後相容」就貽笑大方了，代表這位譯者還不懂中文與英文語言對時間感描述上的差異性。 至於轉意改寫式譯法，在此又必須改變為「向下相容」，因為中文如奮發向上、向上提升等是前進，向下則是後退，是取自逆流而上、鯉躍龍門的典故。這時又和前面提到的上一個、下一個觀點反過來了，無法維持一致，必須適時隨情境調整，很容易弄錯，除非頭腦能時常保持清楚，否則個人不推薦使用。

Review 一般而言可以概分為兩大意義： to examine or study again 以及 to give a critical evaluation of 兩者。 前者，即為「再看一次、再研究一次」；後者，「給予評論、評價」。 以資訊領域來說，比較常用的情境有： 一、程式開發時的同儕互審，有另一個人再次看過寫好的程式碼，其實就是中文的「 檢閱 」，讓同儕檢查再看一次。 或是像軟體管理中心類應用，用來表達收錄的軟體包，有經過軟體庫的發行散布方查看過檔案是否有無遭修改，經某某檢查確認，此時同樣也是中文的「檢閱」。 在資訊領域中，Review 的原文意義沒有中文裡「校訂」、「校對」、「審查」等，那麼深入到「修正」或「詳細刪改內容」的地步，只是單純講說「有人再看過一次」而已。 二、在同樣是軟體管理中心、擴充套件中心這一類應用，通常會提供欄位給使用者，填寫他們對於軟體的評論，此時則是「評論」。

Repository 在軟體管理領域，有倉庫（倉儲）和物流分發的概念：上游軟體發行商所架設的軟體包存放中心，稱為 Repository「軟體庫」；而其中所存放的，皆是經過打包封存的軟體，以方便傳輸，散布流通到使用者的電腦中，稱為 Package 「軟體包」。 至於版本控制系統領域，Repository 則指稱存放所有想進行版本控制的檔案的集中處所，以方便共享協作，此即所有版控檔案的存放處，所以直接譯為「儲存庫」即可，也有人根據情境對應譯為「版控庫」。 Commit, Revision 每一次版本修改後，將檔案送交版控系統留紀錄的行為，稱為 Commit 送交（亦可稱為送交版次，指送交行為留下的版次紀錄），或 Revision 修訂版次（指版本有新的修訂記錄了）；其術語不同，是同一個行為的不同觀點下的稱呼。 Checkin, Check out Check in 指的是將你正在處理作業中的檔案，複製回 Repository 中作為新版本的動作，稱為檢入（視角站在 Repository 中往外看）。 Check out 指的是將 Repository 中的檔案作為新版，複製到你的工作空間的動作，稱為檢出（視角站在 Repository 中往外看）。 Push, Pull, Pull request 如果是分散式版控系統，有多個 Repository 時，一般區分為本地端 (local) 和遠端 (remote) 兩處。以簡單的說法來解釋的話（這裡只講概念，不涉及更多細節），將本地端內容變動送去給遠端合併時，稱為 Push「推送」；如果反過來，將遠端內容變動拉來給本地端合併時，稱為 Pull「拉取」。 至於提請遠端拉取你自己本地端所作的改動，就是向對方提出 Pull Request「拉取請求」。

我們先來看 Meta 這個字根。 Meta- : change : more than : beyond Origin : New Latin & Medieval Latin, from Latin or Greek; Latin, from Greek, among, with, after, from meta among, with, after; akin to Old English mid, mith with, Old High German mit. Meta 目前在英文中有變易、不只是、超越之上的意思。而 Meta 字根的起源具有 among, with, after, from 等意思。 所以 Meta 如果對應到中文，可以是之中、之後、之上（超越）、轉變。 而 metadata 同時代表 among data、after data、beyond data、transformation data、transcending data，其普遍解釋為 data about data。 以相機拍攝的照片為例，拍攝的相片檔，內部會有一組相機攝影時的相關資訊，例如時刻、地理位置、光圈、快門、ISO、製造廠商……這些就是 data about data，一組關於攝影當下的資料。 而相片整理程式，或是影像處理程式、Raw 顯影程式等，都可以根據這組 metadata 再進一步利用，例如做成相簿、自動上標籤、根據地理位置分類等等。 承先啟後 所以，細究 metadata 有一個重要的關鍵特色，就是「承先啟後」，譯者應該刻意強調將之翻譯出來。 中介資料 Metadata 從元初的資料而來，經歷轉變昇華，統整後得出一組相關的新資料，而可以開造新後；換句話說，是一種中介性質的資料 —「 中介資料 」（用「中繼資料」亦可，但不如中介資料明確，也易誤為 Relay data）。 統理資料 如果從統理過程的角度來看，亦可說是「統理資料」，這也是 Meta-analysis 會被稱為統合分析的原因。  詮釋資料 但如果要把 metadata 說成「詮釋資料」，就不是所有情境下都能使用的了，只有具備統合、統理過後性質的 metadata 可以這樣說。至於如上述案例的相片相關資訊，並沒有外加任何「詮釋」，很不適合。 後設資料 另外，例如圖書館藏系

Pool Pool 在資訊領域中，取的是 to combine (things, such as resources) in a common pool or effort 的概念，即是將眾多資源集中在一處的池子。單獨出現時，意思為「集池」。 Storage Pool 又如果，明確知道該 Pool 指的其實是 Storage Pool 時，亦可直接譯為「儲藏池」；有時也可能是 Sever Pool「伺服器池」等，請視情況而定。 Storage Pool，指的是把所有可以提供 Storage 的資源集中成一池，其詞眼自然是「池」；故譯為某某池，此處則是將所有儲藏功能集合而成的池，即為「儲藏池」。順帶一提，在微軟 Windows 10 以後，都將 Storage 譯為儲存體，這個意象容易和 Volume 混淆，有點不妥。 Thin Provisioning Thin Provisioning 此處的 Thin，指的是 scantily supplied，意思是資源不夠了很吃緊，只能「限縮供應」，是上述儲藏池的常見應用場景之一，可以有效節省空間使用。 Volume Volume，廣義代表 the amount of a substance occupying a particular volume（物質所佔據的特定體積），也同時暗示  a roll (as of papyrus, leather, or parchment) for writing a document（記錄文件內容的卷宗）。而卷宗的概念，就是文字或其內容，化身在實體世界佔據空間的物質本體。 在 Storage 功能領域下，Volume 的概念是 「存放內容的容器」，或是「存放內容的空間區塊」。早期在磁碟管理程式中，也曾翻譯成「儲存區」（如 Gparted）、磁碟區（如微軟磁碟工具）、儲區（Fedora/RHEL 早期的 Anaconda 安裝程式）。 然而，Sector 也譯為「磁區」，故 Volume 作磁碟區的翻譯較為不妥。 中文的「卷宗」一詞，代表公私機關分類彙存的文件；或是存放文件的紙夾。既然是分類彙存、存放檔案的容器，那麼類似「桌面」、「資料夾」、「封存」、「存檔」等辦公用詞，類比延伸到桌面環境中，成為電腦資訊領域術語的習慣，確實也可以同理類推到數位情境下繼續使用，即檔案系統的存放單位，譯

Stream 一般常見是指「串流」的模式，亦即檔案或內容不在本機上，從遠端一串一串如水流般流進本機中播放的情況。 而在 fedora/rhel/centos 作業系統的 dnf 軟體包管理系統中，近期引進了 Stream 的新概念，其實就類似過去的 Channel，將 Devel、Testing、Stable 這三種分支渠道，分別集成為一整套軟體包集合，作為虛擬的軟體庫概念來使用。採用同個概念，只是讓它更細緻、更模組化，然後換了個新說法，改稱為 Stream，「流道」。

有時候在翻譯網頁內容時，會遇到一些格式標記，其中要特別注意的是 <i>、<o>、* 這種斜體標記。 在程式處理自動將中文字型轉成斜體後，通常會向後傾倒，遮住後接的第一個漢字或英文字。 所以請在 <i>斜體</i> 內容之後補入一個半形空格，來改善後面文字被遮住的情況。至於斜體標記後方接的是標點符號時，就不需要再補入空格了。 <i>斜體</i> 內容之前如果還有中文字，可以考慮在前方也補入空格，來平衡後方加空格的排版視覺效果。

Stats 是 Statistics 的縮寫，所以是「統計數據」，簡稱「統計」。 常看到軟體（例如某Press的 App 工具）翻錯成「狀態」的 ⋯ ⋯ 狀態一般是 States。 如果你看到介面中有圖示是長條圖，又看到長條圖的圖示旁邊寫著「狀態」，那麼就是翻譯者譯錯了。

現代中文是形容詞放在物品之前的語言，例如「高山」，是指高的山。 所以遇到 Something '%s' 這樣的情況時，要怎麼翻譯呢？ 一般來說 %s 是佔位符，代替某段字串名稱，來形容前面這個物件，所以通常是「%s 物件」。 例如 "Command '%s'"、"Module %s"，就是『「%s 」命令』、「%s 模組」。 只要是 %s 是形容詞，來形容這個 Something，那麼就是「%s 物件」。 譯者可以將 %s 唸作「某某」，來判別在中文語感中，%s 屬於形容詞還是名詞。 不過也有例外，通常是在假定編號，或是命名物件、強調檔案人物名稱時發生。 例如 "Object %i"（%i、%d、%f 等是各種數字的佔位符），就是「物件%i」，會以物件1、物件2 為編號名稱呈現，即中文某甲、某乙表示法的概念，這時候這個 %i 才是字詞的重心，是被「物件」形容的代詞。 這裡如 %i 等數字佔位符，譯者可以念作「甲乙丙丁」，來判別在中文語感中，%i 之類屬於形容詞還是代詞。 雖說可以如此區分，不過中文是很寬容的語言；所以這兩種情況如果都直接譯成「某某 %s」的形式，實務上也依然可以接受。譯者可以自己決定自己喜歡的表達形式，只要採用同一種風格，從一而終即可。

Template 在泛用情境下，譬喻為模具，其作用為「 模本 」，而使用者可以將其翻模，做出新品後修改成自己的版本使用，也可說就像是臨摹用的本子一樣。 以 GNU/Linux 為例，xdg-user-dirs 中定義的 Templates 資料夾，目的就是用來存放這一類的檔案模本。 Template 在文書處理情境下，與前述類似，是樣式與格式設定後的「範本」，使用者可以根據事先設定好的範本，再修改為自己的版本使用。

Domain 在泛用情境下，稱為「屬域」，譬喻為領地，即所屬之域。 例如 SELinux 這套強制性取用控制架構中，就會用到 Domain 這個詞，作為分類檔案所屬領域之用。 Domain 在網路管理情境下，則稱為「網域」。

今天來探討一下與中文「程式」一詞，相關的資訊領域英文詞翻譯。 程式 首先，我們先來瞭解一下，什麼是「程式」啊？ 打開教育部國語詞典，會看到下列介紹： 訂立一定的準式以為法則。 《管子・明法》：「法者，天下之程式也。」近似詞：法式       格式。 如：「公文程式」。 引導電腦依特定方式運作並產生結果的一組指令。 程式一詞，最早的概念是指法則規範，一套明確的規則系統，給天下人作規範之用。起先中文的「程式」一詞，代表的是英文的 Code。 後來電腦時代開始，所謂 Program 、 Code 都是一套寫下的來的規則系統，給機器作執行之用。 Program, Code Program 一詞偏向有目的導向情境，即為了完成某項作業內容，而設計出來的機器執行規則，隱含目的性質。 Code 一詞偏向物件指稱情境，即專指寫下來的那一套機器執行規則內容，隱含本源性質。 當時的譯者，將 Program 譯為程式，Code 譯為程式碼，透過這個「碼」的詞眼，來強調出給機器（如編譯器、直譯器等）讀的代碼規則內容。 而這裡的代碼，指的是各程式語言（無論高階、低階）所約定使用的指代用詞符碼，像是 if、else、AND、XOR 等等這些「碼」。 Codebase 最近在協助 Standard for Public Code 作翻譯校對時，看到 Codebase 一詞，以及該專案《詞彙表》中的解釋，讓我在想怎麼稱呼它才合適？是程式碼基底嗎？程式基底呢？或是代碼庫？ Codebase 的解釋翻譯成中文後是這樣子的：     任何獨立分離的統合包，內含執行部分政策或軟體所需的程式（包含源碼與政策）、測試與文件等的整套內容。     舉例而言，這個具體形式可以是文件，或是版本控制的儲存庫。 喔喔喔！所以 Codebase 指的是那一整套讓「程式」可以執行運作的「底下的內容」（含源碼和其他一切東西），可以放在文件或儲存庫裡。 所以很明顯的，這裡的 Code 指涉程式的本源性質，而 Base 是基底，那麼 Codebase 就是「程式基底」了，和什麼庫無關。值得留意的是，雖然這裡的 Code 描述了程式的本源性質，但不能完全對應為程式「碼」，因為它也同時包含源碼 以外 的物件。 也有人將 Codebase 直譯為「源碼庫」的，以源碼二字指出程式的本源概念，雖不那麼適切，但還可以理解與接受。 Sour

Command, Instruction 目前，在資訊領域的翻譯中，通常是將 Command 翻譯成「命令」，而命令又細分為低階的 Instruction 譯為「指令」，與高階的 Statement 譯為「陳述」相對。 然而，在台灣資訊領域剛興起的早期，中文用詞並未明確區分命令和指令的不同，常以口語中比較常講的「指令」一詞，同時稱呼 Command 與 Instruction。 截至2023年止，流通於市面上的最新電腦書籍，也都仍多以指令來稱呼 Command，已是民間相當普遍的習慣用語。 雖然大眾對於 Command 要稱命令還是指令，已經混用分不清；不過對譯者來說，依然建議應該明確區分 Command 與 Instruction 的差異。 Script 至於 Script 一詞，在台灣資訊領域社群（如 Unix/Linux 系統，或 Perl、Python、Lua 語言等技術社群）與電腦書籍中，多稱之為「指令稿」，少數稱「命令稿」。本人則建議應依據上述區分法，稱呼為「命令稿」；而指令稿，則屬於可被接受的翻譯。 在微軟系統所採用的翻譯用語中，則將 Script 稱為指令碼（想強調出指令型程式碼的意味）或腳本，兩者混用，但這兩者都不是理想的翻譯。 Script 英文本意所著重的意象，在於「文字手稿」，而依據英語概念泛化的特性，它同時可以指稱演戲給各腳色看的底稿（稱為腳本）、手寫字的文稿、各語言的書寫文字、手寫體等等。 因此 Script 簡單而言，就是「文稿」；再精細探討用一個漢字來表達 詞眼 的話，就約略對應到「稿」。 台灣資訊領域程式用語主流翻譯風格 接著套用 台灣資訊領域翻譯文化 ：「只有譬喻式的英文詞（類似中文修辭的借代法）會跨情境直譯，至於其他所有模糊泛用的英文詞，皆會區別英文詞的不同情境，來對應翻譯成不同的中文詞」的精神，應該翻譯為「某某 稿 」，這也是前人當初會譯為「命令稿」的緣由。 這種考慮情境的直譯法，屬於形式對等翻譯 (formal equivalent)。 新譯詞發想 簡述以上台灣風格新譯詞的發想步驟為： 先瞭解該英文單字的泛化模糊概念整體 定下詞眼為骨幹 添補他字為肉以全該情境下之意義 至於把 Script 稱為腳本的直譯法，則是簡體中文常見的翻譯風格。 這種不考慮情境的形式對等 (formal equivalent without cont

看過不少翻譯把 Plugin 翻譯為外掛程式的，然而中文裡的外掛，一般情況下不是指 Plugin/Plug-in。 所謂「外掛」程式指的是：掛在主程式之外，必須另外同步開啟執行的程式，用於改變主程式的行為，多見於遊戲破解用。例如作者童年時期常聽到的「遊戲修改大師」，就是知名的外掛程式。 口語中常聽見的：「他某某遊戲開外掛」或「他根本是開掛了吧！怎麼會這麼強！」，用的就是這詞的本意。 外掛程式，對應至英文，其實是 Game MOD hacking tool，其中 MOD 指的是 modification。 回過頭看這個 Plugin，沿襲台灣資訊領域翻譯詞彙很喜歡用某某元件、某某套件、某某件的稱呼慣例，例如 Addon/Add-on 被稱呼為附加元件，Extension 稱為擴充套件，Widget 稱為元件，Component 稱為組件等等⋯⋯那當然將這個 Plugin 依循這個規則套入後，就是「插入式元件」了！簡稱「插件」，這也是台灣一直都有人在用的翻譯詞。 而將 Plug-in 翻成外掛程式一派的翻譯法，則是認為 Plug-in 是將其他程式引入主程式的元件，目的是為了另外執行一個程式，掛到原本的主程式上執行，所以行為作用也類同外掛程式。 不過麻煩的是，簡體中文翻譯也將 Plugin 譯為「插件」，導致有些台灣翻譯者對這個詞不大喜歡，認為兩者應該區分，應將 Plugin 另外稱為「外掛程式」。而翻譯為外掛程式的缺點之一，是沒有遵循這一類程式被稱為「某某件」的慣例，至少也該是「外掛元件」；至於折衷的說法，應該稱為「外掛插件」。 本人是從開始接觸翻譯時，就將 Plugin 翻譯為插件的那一派。雖然能理解與尊重刻意區別作法的原因，但個人不大推薦將 Plugin 轉意改寫譯為外掛程式，因為外掛這個詞在普遍大眾認知裡已有不同的意思，更偏向「作弊」、「黑客密技」、「難以置信的強大」之意。 亦即，一般臺灣人所知的「外掛」早已與 Plugin 無關，實在沒有必要再刻意把他們綁在一起。Plugin 就應獨立叫它「插件」吧。 如果為了區分與簡體中文譯詞的分別，而刻意選用無法表達 Plugin 原意，且台灣中文詞也是不同意思的譯詞，並不大符合翻譯者該遵循的守則呢。

在程式設計領域中，常講的是 Class 類別，以及 Type 型別。 不過 Type 在 MIME 這種討論檔案類型的一般情境下，更常被稱為「類型」（蘋果翻譯為「種類」）。 由於程式設計領域已經很普及講 Class 為「類別」、Type 為「型別」這樣的用法，所以建議跟隨既有約定成俗的翻譯。 如果譯者想要做出跨領域的翻譯詞彙對應，Category 就建議不要再稱類別，可採用「分類」來描述，以便區別出這些英文與中文間的差異；而 Catalog (Catalogue) 大多情況下都是指商品、產品型號的收錄集合，故稱「型錄」。 另外，Catalogue 的英文意思裡，除了產品的型錄，也包含書目的「目錄」，這兩者都可以說是 Catalogue，沒有像中文這樣仔細再區分成兩個慣用詞。不過在資訊領域中，Catalogue 指稱書目的目錄情況則較為罕見。 中文還有一個會對應翻譯成「目錄」的英文詞，是 Directory。Directory 的原意是以字母順序排列的條目列表，條目如名字或地址等，常見為地址簿、黃頁簿、名冊等，也是收錄大量條目，故也稱為「目錄」。 在文書處理軟體中，也有譯者將 Table of Contents (Contents) 譯為中文的「目錄」，其實以過去沿襲而來的傳統來說，這是錯誤稱呼。在早期圖書產業與圖書文獻學中，皆稱之為「 目次 」。 簡而言之，古代書籍如章回小說、經典，每章每回每段都會有一個開頭的區分標題，稱為「題目」(Title)。為了方便查找，在書籍的最前方放一份列表，列出題目的次序，稱為「目次」(Table of Contents)。如果有許多藏書，為了方便清點與查找各書，會做一本收錄各書籍的「目錄」(Catalogue)。 至於「書目」(Bibliography)，是指「研究書籍外形、出版及版本，以究明書籍歷史之一門學問」，或「某一特定主題或由或某一著者所撰之著作清單」、「在撰述一著作或一篇文章時，所參用之資料清單」。換句話說，書目就是指文獻資料 (Reference)。 可惜的是，在 Word 最早把 Contents 譯為目錄後，大眾也受到影響，逐漸忘記過去「目次」的說法，反而讓不大正確的目錄一詞替代成為了主流。市場上的中文書籍，僅有少數幾家出版社，仍繼續維持「目次」一詞的用法。屢次查資料剛好見到日文 Wikipedia，還延續將 Co

英文裡有很多指涉中文標籤、標記、標示、註記概念的不同詞彙，例如 Tag、Tab、Label、Ｍark 等。  如果我們探究英語的 Tag 、Tab、 Label 、Mark 本意，會發現：   Tag 是附在物體上（如衣物是產品在展示時的懸線掛牌標籤）的標示； Tab 是凸出物體上（如衣領後面的標籤、衣身側邊的標籤）的標示； Label 單純指那個標籤（標籤紙、標籤條等）本身，或標籤上的內容； Mark 是指任何的記號標示。 而中文沒分那麼細，沒有為這這些不同的標籤方式，特別創造出四種不同對應的詞，都可以說是標籤、標記。最麻煩的是，有的軟體中還會同時使用到這些詞；或是原先只有 Label 功能，後來又追加了 Tag 功能等⋯⋯所以譯者最好一開始翻譯前，就先定下有所區別的翻譯方案啊！ 以軟體中的常見用語來看， Tag 除了平時的標籤意義外，更常作為動詞使用，指涉做標籤、貼上標籤的「動作」，所以更貼近中文的做「標記」這一詞。 Tab 常見於分頁瀏覽的使用情境，模擬一些筆記本上凸起，協助使用者為內容作分類用的「分頁標籤」，中文裡也簡稱「頁籤」。這也是瀏覽器「分頁」瀏覽一詞的起源。 Label 既然是指那個標籤本身，那就更貼近「標籤」了。 Mark 除了標記外，也有做上註記的概念，如馬克筆原文就是 Marker，是方便在物件上寫下註記，所以可以稱為「標註」來與他者區分。

很簡單，我手寫我口。 例如有個英文字詞決定不翻，在這理舉例為 Pizza 好了。 也許今天這個譯者是個 Pizza 極端愛好者，想說 Pizza 如果講中文的披薩，根本不夠傳神，失去原文那個 zza 的美妙語感，也就表達不出 Pizza 口感與滋味的美妙，所以刻意維持原文。 那麼他想叫幾個 Pizza 來和大家一起分著吃，這樣多個 Pizza，需要說是好幾個 Pizzas 嗎？ 當然是不用囉！中文語境下的英文字，是不用複數變化的，維持 Pizza 即可。 不管他想叫幾個 Pizza，字句中都只要講 Pizza 就好，把 Pizza 視為一個中文詞，維持遵循中文語法沒有複數型的慣例即可。 如果看到有以前的譯者多寫了 s，看見的各位在修整翻譯時，也可以幫他拿掉，順手更新一下。

Commit 與 Submit 這兩個詞語，在資訊領域中都很常用，而它們之間有什麼分別呢？ 我們先來看看個人在翻譯實務上最推薦的英英字典，Merriam-Webster 的解說之中，最接近版本控制下，或議題追蹤器中所用的 Commit 或 Submit 為何： Commit     to consign or record for preservation 送交保存，或是留下紀錄保存起來。 //commit it to memory     to put into a place for disposal or safekeeping 放到某處棄置，或安放保存。 //The chaplain committed the sailor's body to the deep.     to refer (something, such as a legislative bill) to a committee for consideration and report 提供（事項，例如法案）給委員會作考量並報告。     to obligate or pledge oneself 投身、致力 綜合上述來看，Commit 此處的關鍵意義，在於送交、保存、留紀錄、安放、交付以供考量，以及自願投入。 Submit      to yield to governance or authority 屈服於治理單位或主管機關。     to subject to a condition, treatment, or operation 提請處理、處置或作業。 // the metal was submitted to analysis      to yield oneself to the authority or will of another 屈服於主管機關或他人的意志。 兩者的重大差別，在於 Commit 偏向個人，和送交、保存、紀錄有關；而 Submit 則是相當強調下對上，要提請處理、裁決，甚至是必須得屈服、遵從上面的意志。 所以，Commit 就是「送交保存留紀錄」，簡單點稱為「送交」或「送存」，而由於國家圖書館已有圖書館法定義的「送存」行為，故不推薦使用避免歧義，建議使用「送交」；Submit 則是提請處置，而且是下對上的關係，以中文用法為例，類似提交

Match 分為兩個階段，一是先去比對你所要的目標，二是接著找到符合你要求的項目。 至於 A 和 B 兩者相比對，有沒有一致的情況，例如新密碼與舊密碼，或是新密碼與再輸入一次這種，則是相符。

Time out 有兩種，一種是超過預計完成的限定時間，逾時了；一種是時間倒數計時，時間到了。 如果是等待超過時限了的動詞，那麼譯作「逾時」。 如果像是省電模式下，螢幕自動關閉前的不活動時間倒數計時這類名詞，則譯作「時限」。

羅列如下： Verify 核驗 Verification 驗證 Authenticate 核對（身分） Authentication 認證/核實 Authorization 授權 Credential 憑證 Certificate 證書

Token，是種替代物、信物，例如政府發行用以代替交易信任價值的貨幣、替代全部的一部分、象徵記號、在較大會議中代表少數群體的代表等。 Token 類似漢文化中所稱的「符」，即憑信的器物、象徵標記，譯為「代符」。 常見的 Token 用法之一，就是註冊帳號，寫下電子郵件地址後，對方網站寄來一組 Token，通常是一串英文字符與號碼的隨機組合，來向你確認收到的 Token 有沒有和該網站相符，以確認你的信箱有效，以及符合註冊者的身分。 這就是對象網站發予你「代符」（意為：代表信物），用以確認是否符合，來通過信箱與身分的驗證。 如果還想要更清楚表達，可以補全其意說是「通行代符」。 代符這個譯詞一直都存在，收錄在台灣早期流行的電腦字典中，例如 Dr. Eye 譯點通、Yahoo 奇摩字典等，也在學術界中被採用，例如2011年元智大學發表的 論文 《以代符基底比對程式輸出之程式作業評分機制之研發與評估》。 早期亦有將 Token 翻譯為「符記」的。符、記，為「符」號、「記」號之組合字，並非字典收錄的字詞，是早年譯者自行創造組合的譯詞。然而符記二字，兩者同時暗示了 Symbol 的意涵，容易讓讀者有所誤會，未表達出「代表」、「代替」之意涵，個人認為是不佳的翻譯。 而看過令人覺得有趣的翻譯就是權杖、令牌了，但真的相去甚遠啊！只會讓我想到「你製杖嗎？」，「不，我販劍」的網路笑話。 Token 早期多用於代表通行用的代表信物，後來也慢慢變成一種處理方式，將所要處理的資料流，分段逐個以符號表示，稱為「tokenization」，即「符元化處理」：將資料區分為一個一個單元，將每個單元以一段符號表示，以符為元的處理。

在資訊領域用詞的台式翻譯法，只有譬喻式的英文詞（類似中文修辭的借代法）會跨情境直譯。至於其他所有模糊泛用的英文詞，皆會區別英文詞的不同情境，來對應翻譯成不同的中文詞，此即「情境限定對等直譯」。 舉例而言，如 Menu 沒有菜，不會是菜單；Render 沒有水墨，不會是渲染；Script 沒有演員，就不會是腳本。像菜單、渲染、腳本等這些中文詞語，原先都已經是情境限定才會使用的特化詞語。 「菜單」是餐廳用語、「渲染」是水墨畫用語， 「腳本」是戲劇類用語。   台灣資訊領域的社群翻譯風格文化，簡單濃縮就是：盡量避免取用過去已限定情境的特化中文詞，不重新定義成新的資訊領域中文詞用法，而是再發想、創造出資訊領域專用的新譯詞來表達。 資訊領域新譯詞發想 台灣主流風格新譯詞的發想步驟為： 先瞭解該英文單字的泛化模糊概念整體 定下詞眼為骨幹 添補他字為肉以全該情境下之意義 以 Script 為例，其英文本意所著重的意象，在於「文字手稿」，而依據英語概念泛化的特性，它同時可以指稱演戲給各腳色看的底稿（稱為腳本）、手寫字的文稿、各語言的書寫文字、手寫體等等。 因此 Script 簡單而言，就是「文稿」；再精細探討用一個漢字來表達 詞眼 的話，就約略對應到「稿」。 接著套用台灣社群譯法：「只有譬喻式的英文詞（類似中文修辭的借代法）會跨情境直譯；至於其他所有模糊泛用的英文詞，皆會區別英文詞的不同情境，來對應翻譯成不同的中文詞」的精神，應該翻譯為「某某 稿 」，這也是前人當初會譯為「指令稿」或「命令稿」的緣由。 這種翻譯方式，屬於一般照顧情境脈絡的形式對等翻譯  (formal equivalent) 。 說到這，有的人會說，那麽像 Virus 病毒、Worm 蠕蟲、Bug 臭蟲⋯⋯等，這些呢？ 這些詞語不都是已經限定情境用在生物領域了嗎？ 跨情境類比借代詞 像這類英文詞彙，在英文原文中都是一種跨情境類比的譬喻借代，即以其原領域的意義，直接挪用到資訊領域借代使用，擴增原詞彙的使用情境。 例如病毒，取其自我複製與破壞宿主機能的特性，類推挪用至資訊領域。台灣式翻譯也循同樣邏輯，這一類詞彙便不用翻譯成新的對應詞，可重複採用原先有的中文詞，再擴增其新的資訊領域意義。   這與前者「重新定義已經限定情境特化的中文詞」不同，而是同理類推挪用，擴增出新的資訊領域意義。   有的人會說，像是 將 Menu

行，其字形本源是中央一條大路，左右旁開兩條小路的十字路口。 往前走向中央的大路，演變出行（ㄒㄧㄥˊ）走的意思；也是直行（ㄏㄤˊ）的由來。 列，其字形本源是歹加刀，歹是裂開的圖像，再加刀代表用刀劃開。 分開、劃開變成多個，演變出擺開、排開、一個一個的意思；也是橫列的由來。 在指稱行列時，自然是以眼前方向為直向，稱為行；左右擺開一個一個為橫向，稱為列。 台灣延續直書與行列的本源傳統，依然採用直行、橫列來描述排版的文字方向。 然而數位設備最早誕生自橫排為主的西方國家，數位化時也為了相容常見的歐美文字，漢字跟著橫向排列，於是橫書成為數位排版系統中最早支援的漢字排列方向，早於直書支援。 最早的軟體中文翻譯，是明確區分橫列的，例如「列印」(print)、「命令列」(command line)、「換列」(change line)、「新列」(new line) 等，皆是出自這個時期。 後來文書排版系統興起，也有越來越多軟體支援直書。而直書的所說的行，也因為排版軟體通行之故，大眾依口語直接被挪用至橫書情境使用，行的語義開始擴及並滲入橫書。這也約莫是圖形介面軟體、Windows 作業系統開始大幅流行之時。 文書排版系統中，有一指稱文字流方向的特定術語，Line，沒有區分方向，亦即可以是直書，也可以是橫書。 早期譯者還會視程式特性，在如終端機、文字編輯器軟體中，會將其翻譯為「列」，如「換列」(change line)、「列號」(line number)、「列印」(print) 等。在中文排版軟體興起後，開始出現「換行」(對應至英文的 new line 或 change line 或 line wrap)、「行號」的說法，並逐漸被大眾挪用到橫向語境中。 因此，目前臺灣的程式翻譯，在確定文字明確用於橫向情境，或譯者確定該程式沒有直書情境時，例如終端機、命令列程式、程式碼編輯器，會採用「列」來對應 Line。 至於同時能支援直書或橫書的軟體，例如文書編輯器，或是譯者無法確定程式的文字方向時，則採用廣被接受可同時指稱直書與橫書的「行」來對應 Line。 總結來說，「行」可以是 line，原先是直書，後來也被用於橫書；「列」也可以是 line，明確用於橫書情境。 至於試算表軟體，或其他可清晰區分直、橫單位的軟體，依然採用直行、橫列的標準譯法。 如 column 為欄（少數譯者譯為行），以及 row

Archive 這一詞的翻譯常被胡亂對應成 Compress，這還滿讓人困擾的。 資料存檔是一門學問，存檔是指整個行為過程，封存是其中的動作，而壓縮只是封存的一種方法。 archive 封存 (verb)/封存檔 (noun)/存檔庫 (noun) archive file 封存檔

在討論作文時，所謂的文章結構、篇章結構，用其他詞來換句話說是指「布局」。 schema 這一詞，指的是資料格式的「結構綱要」（詳細說法），其結構要有哪些哪些，集合成綱要作為格式要求，簡稱為「綱要」（一般簡要說法）。

剛打開電腦，突然看到 clone 一詞，想起關於複製這類詞語，好像還沒有把以前我的翻譯方案寫下來。 copy 複製 (verb)/副本 (noun) 動詞為複製，製作而成的名詞為副本。 動作是將選取內容複製到記憶體中，如放到剪貼簿中供後續使用。 註：蘋果系統翻譯方案採用「拷貝」。 duplicate 再製 再製作一份的意思，通常複製品會有其製作當下的特性或屬性，例如製作時間。 動作是複製並貼上。 註：蘋果系統翻譯方案採用「複製」，與常見微軟方案將 copy 譯為「複製」相衝。雖然兩方譯祠相同，但各自指稱不同概念，duplicate vs. copy。 clone 拓製 有兩種意思：     一、僅複製原作品特性或屬性，可供套用至其他物件之上，例如選取文件中特定內容後，可以複製其文字樣式、排版設定，並且可重複套用至其他同類內容中，常用於文書處理情境。常見代表圖示為刷子，近似拓印、或翻印的概念。 動作是複製物件的格式設定到剪貼簿中，供後續拓展套用到其他物件上。     二、完全比對複製一份的意思，通常複製品完全等同原作品，包含製作時間、修改時間、設定組態等特性或屬性皆相同，常用於虛擬機管理情境。根據原作可大規模拓展製作的概念。 動作是複製並貼上，而且新品與原作完全相同。

Configuration 和 Layout 的譯詞比較混亂，大家各行其事，有自己的翻譯方案。 Configuration 在台灣的資訊領域社群中，Configuration 最常見的翻譯為「組態」，即組合型態，那為什麼說是組合型態呢？ Configuration: 構成部分（成分）或其元素的相對安排 (Merriam-Webster) relative arrangement of parts or elements: such as     (1) shape 外形安排     (2) contour of land 地貌排列           例：configuration of the mountains     (3) functional arrangement 功能編排           例：a small business computer system in its simplest configuration 某物的成分或一組事物的構成安排； 如此的安排 可形塑成某外型或形狀 (Oxford Learner's) an arrangement of the parts of something or a group of things; the form or shape that this arrangement produces     例：The design is based on four configurations of squares 電腦）構成電腦系統的設備和程式，以及使其得以運行的設置方式 (Oxford Learner's) computing) the equipment and programs that form a computer system and the way that these are set up to run     例：Performance will vary depending on your hardware and software configurations. 綜合以上來看，可簡單理解為「構成某事物，使其展現出某型態或功能的成分安排」，所以將 Configuration 翻譯成「組態」，是很適宜、貼切的翻譯呢！ Configure 其動詞 Configure，就

不知道為什麼，常看到 highlight 直譯成高光，是很直白啦！（哭笑不得） 也有意譯成突顯的，這麼說也是沒錯，但就是感覺怪怪的。 在電腦資訊界裡常見的 highlight 作法，是將某個亮度高的色彩套到某段文字上，或是提高某段文字的對比，來方便使用者辨明要查找的東西、要強調的事物在哪裡。 實際上這就是標明啊！Highlight 標明。 註：早期 Office 書籍中，也有「以使用者介面實際作用」來指稱 Highlight 的說法，稱為「反白」，就是指文字標明後的白底會反過來變黑底，而在現代暗色系背景越來越普遍的情況下，此說法已經不再貼切了。

在電腦資訊領域中，有兩個近似的詞 Record 和 Log，都是某種紀錄，但用法不同。  Record 和 Log 兩者間最大區別，在於 Log 必定會有時間，格式都是以日期時間開頭，才後接事件紀錄，並按照不同日期切分區段。至於 Record 就單純是指記下來的那個紀錄。 所以對應到中文，Log 就是日記、日誌。 以日常會講到的語境脈絡下，日誌比較有規範感、正式感，因此建議將 Log 對應翻譯成「日誌」，Log file「日誌檔」，Changelog「變更日誌」。 起先，Log 多用於記錄重大系統事件、操作上的例外情況等，方便管理者注意、瞭解系統有出什麼狀況。 後來，電腦界又誕生了 Journal。Journal 也是一種 Log，其日誌的記錄目的，在於方便管理者稽查操作行為、統計相關數據，尤其是要能用於系統復原。常用於指稱檔案系統（如 IBM 發展的 JFS、Linux 系統常用的 ext3 等）的日誌、作業系統幕後服務等基礎元件的日誌（如 systemd 提供的 journald）。 資訊領域常有這種同義英文詞，刻意被區分開來，並且各自賦予有細微差異的專用用途情況。 舉例來說，像是防火牆行為也有分 Deny、Reject、Block，這都會讓譯者有點頭大。要成為一位稱職的資訊領域翻譯者實難啊！ 如果還想要明確區分 Journal 和 Log 的翻譯，不建議再把日記一起拉下海，場面會變得更加混亂。較好的作法是根據其專門用途作形容詞修飾，基於 Journal 的特性常用在檔案系統、作業系統幕後服務等範疇，可以特意稱為「系統日誌」，當然要繼續說是「日誌」也是可以的。

Comment 在資訊領域中是很常用的字，例如發表評論、對事物下註解、解釋說明等，都會用到。然而，有些程式裡，同時會出現另一個很相似的詞，Annotation，並區分兩者的不同作用。那麼譯者要怎樣面對、處理這樣子的情況呢？ 查詢 Merriam-Webster 和 Oxford Learner's 字典中的解釋後，可以大略得到以下意義： Comment 意見、輿論 something that you say or write that gives an opinion on or explains somebody/something (Oxford)     例：Keep up to date with all the latest news and comment. (Oxford)     例：constructive comments (Merrieam-Webster) 批評 criticism that shows the faults of something (Oxford)     例：The results are a clear comment on government education policy.     例：There was a lot of comment about his behaviour. 作說明、插圖解說、批評內容的備註 a note explaining, illustrating, or criticizing the meaning of a writing (Merriam-Webster)     例：Comments on the passage were printed in the margin. Annotation 在書中或對文字寫下解說或批評的備註 a note or notes added to a book or text giving explanations or comments; the act of adding these notes (Merriam-Webster)     例：The bibliography was provided with helpful annotations. (Merriam-Webster) 綜合以上，可以看出 Comment 涵蓋

RFC 2119 五級要求 必須MUST / 要求REQUIRED / 應當SHALL（強制要求，必須如此） 應該SHOULD / 建議RECOMMENDED 得以MAY / 可選擇OPTIONAL（有選擇，可以） 不該SHOULD NOT / 不建議NOT RECOMMENDED 禁止MUST NOT / 不得SHALL NOT（強制禁止，絕對不可） 台灣法律用語三級要求 應 = MUST （強制要求，必須如此） 得 = MAY（有選擇，可以） 不得 = MUST NOT（強制禁止，絕對不可）

在電腦資訊界中打滾，總會常見到 Release Note 一詞。通常是軟體的發行單位推出新版本時，一併附上該次版本值得注意的變動、新功能與特性、 臭蟲 修正等簡要資訊，讓使用者可以一次概覽產品的新狀態，好準備採用。  軟體產品正式推出時，這個動作稱為「Release」。在正式發行之前，可能會有內部測試「Alpha」，再來外部測試「Beta」兩個階段。外部測試時也算是一種 release，但非正式 release，所以稱為 Pre-release，比較繁複的會依次 Release Candidate 發行候選版 1 2 3 下去，直到確認產品沒有重大問題 (blocker) 阻擋發行，就會宣布正式 Release。 以公開透明開發，而且採自由軟體授權的 LibreOffice 為例，在產品新版的內部開發階段，依據情況而定，主導開發者（或品管者）會在提交特定功能，或臭蟲修正的程式碼到儲存庫的同時，也一併在 Wiki 中對應版本的 Release Note 裡寫下簡短的概要介紹。 Fedora 這套 GNU/Linux 作業系統也是一樣，在新版的內部開發階段，開發者會先提案變更的 Change Proposal 給工程執導委員會確認，接著進入開發過程，等到時程表約略要推出新版時，再由工程執導委員會 (Engineering Steering Committee, ESC) 評估進度並確認是否完成，通過品管測試後，推出整套作業系統的 Release Candidate。反覆測試幾次無重大問題後，最終發布 Release Note 與新版本推出的消息給大眾，讓大眾可以開始採用。 瞭解一般軟體產品開發的流程後，我們來看 Release Note 和 Release Candidate 的翻譯怎麼說比較好。 個人推薦翻譯者可以多參考 Merriam-Webster Dictionary 或 Oxford Learner's Dictionaries 英英字典的英文解說，來瞭解與確認對應詞語在英語世界中是怎樣被理解與使用的，而非我們自己過去學習時以中文詞先入為主以為的概念。 以 Oxford Learner's Dictionaries 為例，符合上述情境的 Release 釋義有：    stop holding something:  to stop ho

剛好被問到這兩個字的翻譯，已經在 LibreOffice 中使用多年。 Property 在 Oxford Learner's Dictionaries 釋義為：      a thing or things that are owned by somebody; a possession or possessions 指屬於誰所有的物品，更貼近「屬性」。   Attribute 在 Oxford Learner's Dictionaries 釋義為：     a quality or feature of somebody/something 指某人某物的品質或特質特徵，更貼近「特性」。