發表文章

sink 承接; source 來源

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

Regular Expression 常規(正則)表達式

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

Back 返回, Backward 返回/往前/往上, Forward 前進/往後/往下, Previous 上一個, Next 下一個

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

Review 檢閱/評論

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

Repository 軟體庫/儲存庫, Revision 修訂版次, Check in 檢入, Check out 檢出, Pull 拉取, Push 推送, Pull Request 拉取請求

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

metadata 中介資料

我們先來看 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 從元初的資料而來,經歷轉變昇華,統整後得出一組相關的新資料,而可以開造新後;換句話說,是一種中介性質的資料 —「 中介資料 」。 如果從統理過程的角度來看,亦可說是「統理資料」,這也是 Meta-analysis 會被稱為統合分析的原因。 但如果要把 metadata 說成「詮釋資料」,就不是所有情境下都能使用的了,只有具備統合、統理過後性質的 metadata 可以這樣說。至於如上述案例的相片相關資訊,並沒有外加任何「詮釋」,很不適合。 另外,例如圖書館藏系統在整理書目時,各書目的 metadata 也被稱為「後設資料」。各位讀到這裡應該就能明白了,那是圖書館藏在整理書目時,一組後

Pool 集池, Storage Pool 儲藏池, Thin Provisioning 限縮供應, Volume 卷宗/存集, Storage Volume 儲藏卷宗

Pool 在資訊領域中,取的是 to combine (things, such as resources) in a common pool or effort 的概念,即是將眾多資源集中在一處的池子。單獨出現時,意思為「集池」。 又如果,明確知道該 Pool 指的其實是 Storage Pool 時,亦可直接譯為「儲藏池」;有時也可能是 Sever Pool「伺服器池」等,請視情況而定。 Storage Pool,指的是把所有可以提供 Storage 的資源集中成一池,其詞眼自然是「池」;故譯為某某池,此處則是將所有儲藏功能集合而成的池,即為「儲藏池」。 Thin Provisioning 此處的 Thin,指的是 scantily supplied,意思是資源不夠了很吃緊,只能「限縮供應」,是上述儲藏池的常見應用場景之一,可以有效節省空間使用。 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 作磁碟區的翻譯較為不妥。 中文的「卷宗」一詞,代表公私機關分類彙存的文件;或是存放文件的紙夾。既然是分類彙存、存放檔案的容器,那麼類似「桌面」、「資料夾」、「封存」、「存檔」等辦公用詞,類比延伸到桌面環境中,成為電腦資訊領域術語的習慣,確實也可以同理類推到數位情境下繼續使用,即檔案系統的存放單位,譯者不需要再另外創造新詞(如蘋果系統採用此譯詞)。 另外,也有取用「卷」為詞眼,以作用於儲藏領域為形容詞,構成「儲藏卷」或「儲存卷」的譯法,供各位參考。 不過卷宗本意就是儲存檔案之用,Volume 如果還要再說是儲存用

Stream 串流/流道

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

斜體 處理譯法

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

Stats 統計(數據)

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

Something '%s' 譯法

現代中文是形容詞放在物品之前的語言,例如「高山」,是指高的山。 所以遇到 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 模本/範本

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

Domain 屬域/網域

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

Program 程式, Code 程式碼, Codebase 程式基底, Source Code 源始碼/源碼(原始碼), Object Code 目的碼

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