風吹草動

軟體翻譯中，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 在網路管理情境下，則稱為「網域」。