Skip to content

Instantly share code, notes, and snippets.

@fntsrlike
Last active September 15, 2024 23:09
Show Gist options
  • Save fntsrlike/cf1e96d60b6f34fab725599b06dfcb2a to your computer and use it in GitHub Desktop.
Save fntsrlike/cf1e96d60b6f34fab725599b06dfcb2a to your computer and use it in GitHub Desktop.
《Pro Git》第二版中文文件翻譯對照表與規範

《Pro Git》第二版中文文件翻譯對照表與規範

由於原本 Pro Git zh-tw 翻譯社群共筆的服務 hackpad 已經停止運作,並被移植到 Dropbox Paper。為了有利於本份資料在社群共享、傳播,故將其從 Dropbox Paper 輸出,並存在 Gist 備存。

相關議題可以參照 progit/progit2-zh-tw#38#39

前言

很慶幸的,有各位熱心的夥伴參與翻譯,其實就算是單人翻譯的狀況,常常會發生有些專有名詞或者是格式上前後不一的狀況。所以開了一個 pad 專門記錄這些規範以及參考的翻譯對照表。有些是我個人的一些想法,如果夥伴們有其他的意見跟想法歡迎提出來討論。 關於專有名詞翻譯的部分,我能理解部分夥伴會覺得就保留英文即可,但我會希望文件也類似於中文翻譯書般,第一次出現時我們可以以 專有名詞中文翻譯 (英文原文)的呈現方式來表示,讓讀者可以產生中英關聯,之後同份文件再次出現將只會出現中文翻譯。這樣做是因為對於初學者來說不會因為滿滿的英文專有名詞而產生抗拒。當然前提是在於中文的翻譯是否能夠達意,這部分建議參考對岸的一些翻譯,有時候比我們Pro Git的還直觀。但對於像 Laravel, Composer 等是名字、指令等就不強求要中文對照,這類不會有統一翻法更不容易從翻譯中知道用意的,就保留英文即可。如果不清楚該怎麼翻才好也可以留著與大家討論。 下面的規範會隨著我校對時一起更新,謝謝大家的參與。

規範

  • 英數的左右保持一個空白,才不會跟中文黏在一起,不容易閱讀。
  • 中文句讀請使用全形標點符號「。」
  • 破折號,由二個 U+2014 構成,前後不留空格。
    • 「——」二個 U+2014 (倉頡輸入法 ZXAY)
    • 「──」二個 U+2500 (微軟輸入法用[Ctrl + Alt + , ] > Z)
    • 不是「-」(連字號、減號),也不是全形版本的 U+FF0D「-」
    • 不是「—」(連接號,單個 U+2014)
    • 不是「一」(國字、U+4E00)
  • 省略號「……」
    • 參考 維基百科
    • 重點 1:二個 U+2026
    • 重點 2:「……」和「等等」不能同時使用,請擇一。
  • 將英文的符號 ``'' 改用中文的符號 「」
    • 舉例:英文符號在簡中網頁出現的效果
    • 用「」較適當。
  • 請閱讀 Markup 語法,請勿讓語法錯亂。
  • 建議:在 Transifex 上開一個 project, 由主持人把定案的加入glossary
    • 好處: 最右側有
      • suggestion (不確定怎麼翻的時候用)
      • history (誰在何時做了什麼修改)
      • glossary (每個單詞也可以再有各自的 comment)
      • comments (可以解釋為何如此翻譯)
    • 缺點:一開始用很不習慣, 速度也不夠快, 不像 Hackpad 反應即時
  • 建議:把術語對照表(glossary)變成 g0v 或 l10n-tw 的子專案以擴大社群參與並增加層次區分
  • Git 命令的術詞加註原文

專有名詞對照(按照英文字母排序)

以下按英文及數字排序,由於討論可能涉及多個術語,加之為使列表簡潔,請一律在附註區發表意見。 為求方便附註不以出現順序編號,僅在附註區依編號排序,目前無附註的請自行加入。 小提示:可使用瀏覽器搜尋 [數字] 快速跳躍,省去拉捲軸的麻煩

0

  • 3-way merge => 三方合併 [39]

A

  • abbreviate => 縮寫
  • access => 存取
  • add => 加入 [9]
  • ambiguous => 模稜兩可
  • amend => 修訂 [32]
  • ancestor => 祖代、祖提交 [56]
  • annotate => 附註、加註
  • annotated tag => 附註標籤
  • apply => 套用
  • argument => 引數 [61]
  • assume => 假設
  • authentication => 核對、核對身份 [40]
  • author => 作者
  • autocrlf => 自動 (Windows?) 行尾(不譯更好?)

B

  • backslash => 反斜線
  • bad => 不良 [30]
  • bare repo => 裸版本庫 [15]
  • base => 基底 [1]
  • bisect => 二分搜尋 [23]
  • bitmap => [11]
  • blame => 究責 [22]
  • blob => blob (保留原文不譯) [27]
  • body => 內文[55]
  • branch => 分支 [13]
  • bug => 臭蟲
  • bundle => 綑綁包 [2] (暫定)

C

  • cache => 快取 [10]
  • CC => 副本
  • certificate => 憑證 [45]
  • Centralized => 中央(式), 集中(式) [65]
  • change => 變更
  • checksum => 校驗碼
  • checkout => 檢出 [44]
  • cherry-pick => 揀櫻桃 [29]
  • chunk => 區塊
  • clean => 乾淨的 [4]
  • clear => 清除 [3]
  • client => 用戶端
  • clone => 克隆、拓製 (暫定) [26]
  • code review => 審閱程式碼
  • command => 命令 [33]
  • command line => 命令行 [34]
  • commit => 提交 [8]
  • commit-ish => 提交 [8]
  • compares => 比對
  • config => 配置 [41]
  • conflict => 衝突
  • configuration variable => 組態變數 [41]
  • credential => 證書 [45]
  • current => 目前 [17]

D

  • dangling => [50]
  • dashboard => 資訊主頁
  • delete => 刪除 [3]
  • deploy => 部署
  • daemon => 背景程式 [58]
  • describe => 描述 [48]
  • diff (noun) => 差異 [37]
  • diff (verb) => 差異比對 [37]
  • directory => 目錄
  • dirty => 不乾淨的 [4]
  • discard => 丟棄
  • discussion thread => 討論串
  • distribution => 發行版、散佈版

E

  • email => 寄信(v.)、電子郵件(n.) [47]
  • entry 條目
  • EOL => 行尾 或維持 EOL
  • export => 匯出

F

  • fallback => [49]
  • fast-forward => 快進 [31]
  • fetch => 獲取 [24] (暫定)
  • filename expansion (i.e. globbing) => 檔名擴展、檔名延伸
  • fork => 保持原文不翻譯 [63]

G H

  • Hash => 雜湊(值)
  • head => 頭端
  • HEAD => 這個不翻(全大寫)
  • HEAD detached => 脫離/脫節?
  • header => 標頭
  • helper [n.] => 助手[5]
  • hook => 掛鉤 [18]
  • host(v.) => 託管
  • hunk => 區塊[62]

I

  • ignore => 忽略
  • inline diff => 行內差異 [37]
  • issue => 議題
  • issue tracking => 議題追蹤 [19]

J K

  • key => 鍵[53]

L

  • line => 列、行 [34]
  • log => 日誌 [35]
  • local => 本地、本地端
  • lightweight => 輕量級

M

  • mailbox => 郵箱
  • mask => 遮罩
  • match => 匹配
  • metadata => 元資料、中繼資料
  • merge => 合併
  • mirror => 鏡像 [67]
  • missing => 遺失

N O

  • undo => 復原
  • orphan => 孤立

P

  • pack => 打包(檔) [2]
  • pack file => 打包檔 [2]
  • pager => 分頁器[68]
  • parameter => 參數 [61]
  • parent => 親代、親提交 [56]
  • patch => 補綴 [16]
  • pathspec => 路徑規格 [7]
  • pattern => 模式、式樣 [69]
  • phrase => 字眼、措詞、字詞
  • project => 專案
  • programmatic interface => 應用程式介面
  • prune => 翦除 [3]
  • pull => 拉取、拉收 (暫定) [25]
  • pull request => 拉取請求、拉收請求 (暫定) [25]
  • push => 推送
  • policy => 策略? 政策? [59]

Q R

  • rebase => 變基、變更基底 [1]
  • reachable => 可觸達
  • redo => 重做
  • regex => 正規表示式
  • register => 登錄;註冊(申請會員時) [21]
  • ref => 參照 [6]
  • refer => 參照 [6]
  • reference => 參照 [6]
  • reflog => 參照日誌 [6] [35]
  • refmap => 參照映射 [11]
  • refresh => 重新整理、重整 [51]
  • refspec => 參照規格 [7]
  • remote => 遠端
  • remove => 移除 [3]
  • repo => 版本庫、庫 [15]
  • repository => 版本庫 [15]
  • reset => 重設 [46]
  • resolve => 解決
  • revert => 反轉 [28]

S

  • safecrlf => (保持原文)
  • shell => 殼層
  • shallow => 淺層(的)
  • short ref => 短參照 [6]
  • show => 展示 [57]
  • sign => 簽字 [14]
  • signed => 已簽字 [14]
  • skip => 略過、跳過
  • squash => 壓縮 [60]
  • stage => 預存(區) [10]
  • staged => 已預存 [10]
  • staging => 預存 [10]
  • staging area => 預存區 [10]
  • stash => 收藏 [12] (暫定)
  • store => 儲藏 [12] (暫定)
  • strip => 去除 [3]
  • subject => 主旨[55]
  • submodule => 子模組
  • superproject => 上層專案 [43]

T

  • tag => 標籤
  • track => 追蹤 [19]
  • tree => 樹
  • tree-ish => 樹 [8]

U

  • unified diff => 統合差異 [37]
  • unpack => 解包 [2]
  • upstream (n.) => 上游
  • unreachable
  • untracked => 未追蹤 [19]
  • unversioned => 未版控 [42]
  • URL/URLs => 網址

V

  • valid => 有效 [20]
  • value => 值[53]
  • verbose => 詳盡 [52]
  • versioned => 己版控 [42]

W

  • whitespace => 空白字元 [36]
  • working tree => 工作樹 [54]
  • working directory => 工作目錄 [54]

X Y Z

參考資料

  1. 微軟詞彙翻譯查詢
  2. Git-it 台灣
  3. Git 風格指南
  4. muan/training kit#1
  5. ihower 的 Git 版本控制系統
  6. 自由軟體翻譯的守則
  7. 國家教育研究院雙語詞彙、學術名詞暨辭書資訊網
  8. 由唐鳳等人與台灣教育部貢獻之萌典,其被釋出到公有領域(public domain)
  9. 自由軟體正體中文化工作指引 (L10n)
  10. 科技翻譯面面觀 by 侯捷 [66]

相關專案

  1. Git 主程式的簡體中文語系檔
  2. Pro Git 2 版繁中化專案
  3. Git Cola 繁中 po 檔
  4. gitextensions 繁中 xlf 檔gitextensions 外掛的繁中 xlf 檔
  5. gitg 繁中 po 檔
  6. TortoiseGit 繁中 po 檔

附註

  • [1] base 建議譯為「基底」。其他如「基礎」容易和 basic 搞混,「基準」比較偏向 standard,根基會想到 root 。 rebase 原文可能是「reset base」之縮寫,直譯為「重設基底」,大陸常稱「變基」,大致符合原意(雖有點難聽), Tortoise Git 亦用之,建議採用。 Progit 一版譯為「衍合」,但較難與 rebase 原文有所關聯。

  • [2] bundle, pack, package 大陸均譯為「包」,易致混淆。建議 bundle 譯為「綑綁包」,「pack」譯為「打包檔」或「打包」(視語境為名詞或動詞,另,為名詞時「pack file」亦譯為「打包檔」),「unpack」譯為「解包」

  • [3] clear, delete, prune, remove, strip 意義相近,但有微妙不同,故無特殊需求時建議譯文與原文一一對應。「prune」原意是翦除植物之枝幹,故建議用「翦除」。「strip」亦有「剝除」之譯法(TortoiseHg),但考慮常用於「strip space」,建議「去除」。

  • [4] clean (n.) 可譯為「乾淨的」。 clean (v.) 譯為「清理」 dirty 大陸譯為「髒」或「骯髒」,似較不流暢。考慮其主要與 clean「乾淨」對比,建議譯作「不淨的」或「不乾淨的」。

  • [5] help 不建議譯為易有歧義的「說明」。大陸譯為「幫助」,國人似較常用「協助」。

  • [6] reference (ref) 一般譯作「參照」及「參考」,建議沿用

  • [7] refspec、pathspec

  • [8] commit 一般譯為「提交」,建議沿用。

commit-ish, tree-ish 之「-ish」主要用於指令介紹的 <commit/tree-ish>,大意是「類似OO的」,但 Git 相關指令並沒有明確區分(寫 的地方給它 也可被接受),因此翻譯時不加詞尾。

  • [9] 大陸常用「添加」,國人習慣較常用「加入」

  • [10] staging area 、 index 、 cache 是同一東西的不同稱呼。「stage」以往多稱「暫存」,但易造成混淆。staging area 有軍事上「整裝區」、「整備區」之意,建議用「預存」,其可包括「git add 已將檔案存入資料庫」「stage 為 git commit 之預備」等意義,且 staging area = 預存區、 staged = 已預存,亦相當自然。若用「預備」則不像動詞,會導致「staged」不易翻譯。

「index」可沿用「索引」,「cache」建議沿用「快取」(亦有「暫存」、「緩存」等說法)。

  • [11] refmap 建議譯為「參照映射」,用「參照地圖」或「參照圖」可能較難理解。

bitmap

  • [12] stash 原文大致為「藏起來」(不要讓 git add 發現)的幽默式用法,不易找到確實對應,TortoiseGit 舊用「藏起」感覺較怪,「隱藏」易與 hide (隱藏檔)混淆,「儲藏」易與 store 混淆,「暫存」易與 cache (Git 中即 stage)混淆,其他如「匿藏」、「窩藏」、「安藏」、「納藏」、「保藏」、「祕藏」等亦不甚通順,建議用大致可理解、無明顯歧義詞、可作動詞及名詞用的「收藏」,儘管無法完全譯出原汁原味。

store 避免與 save 混淆,建議「保存」或「儲藏」?

  • [13] branch 依習慣用「分支」,避免用「分枝」。

  • [14] sign, signed, signature

  • [15] repository 自 VCS 以來在中文界常譯為「版本庫」,目前亦無明顯問題,建議沿用,英文簡稱「repo」可視情況使用簡稱「庫」。

bare repo 有稱「純庫」,但似不易理解,「裸庫」較易理解但不文雅。

  • [16] patch 大陸習稱「補丁」,TortoiseGit 用「 」,因「補綴」一詞有部分動詞性質也較易連接其他字(如「補綴檔」 vs 「補丁檔」),且補丁令人感覺簡陋粗糙,但 patch 不是也不該是這樣的東西,故建議用「補綴」。

  • [17] current 大陸稱「當前」,建議用國人較習慣之「目前」。

  • [18] hook 大陸稱「鉤」,國人似較習慣用「掛鉤」。另,不用「掛勾」、「掛鈎」。備案:鉤子

  • [19] track 大陸稱「跟蹤」,國人似較習慣用「追蹤」。另,不用「追踪」。

  • [20] valid, invalid 依習慣用「有效」、「無效」,不用「合法」、「非法」。

  • [21] register 若非用於「註冊會員」之類的場合,建議用「登錄」,不用「註冊」。

  • [22] 按發明人 Linus 的風格,blame 原文大約是「找出是誰亂搞」的詼諧口吻,若用「歸責」太似 atrbitution,若用 TortoiseGit 舊用之「讉責」又過於負面。建議用「究責」,因「究」可理解為「研究」「考察」,同時「究責」可提示 git blame 具有「找出哪部分是誰幹的」之特徵,語氣也可以和原文相近。

  • [23] bisect 按官方 help 敘述即是 binary search (二分搜尋),建議譯為完整的「二分搜尋」,需要簡稱時可考慮「二分」。

  • [24] fetch 原意為「抓」或「拿」。大陸稱「獲取」,備選有「擷取」、「提取」、「抓取」、「拿取」、「拾取」、「取得」等

  • [25] pull = 拉收、拉取?

  • [26] clone

  • [27] blob = binary large object,直譯為「二進位大型物件」。但用直譯太麻煩,而簡稱二大、二物、二件、二檔、二進物之類都很怪,唯一較好的似乎只有「二進檔」,但它畢竟是物件不是檔案,有混淆的疑慮(比如一個 pack 檔案裡面可以有很多個 blob,此時稱二進檔就比較怪)。目前建議維持原文 blob(或考慮大寫的 Blob、BLOB)

  • [28] revert 常用於「revert commit XXX」,建議用「反轉」。不建議「復原」、「還原」、「回復」,因「反轉提交 XXX」比「回復提交 XXX」更不易誤解,而「復原」、「還原」還可能與 undo 混淆。備選:「逆轉」、「倒轉」

  • [29] cherry-pick

  • [30] bad 常用於 bad object 、 bad revision 、 bad revision(bisect 途中)etc。大陸直譯「壞」,建議「不良」。備選:不佳、不好

  • [31] fast-forward 大陸用「快進」,相當簡潔貼切,可從之。

  • [32] 以下數詞相似但有微妙區別,若無特殊需求,原則上建議一一對應:

  • modify <=> 修改

  • revise <=> 改版

  • amend <=> 修訂

  • update <=> 更新

  • correct <=> 糾正、更正

  • fix <=> 修正

  • improve <=> 改善、改良

  • [33] command => 「指令」?「命令」?

  • [34] line 應譯為「行」或「列」?

  • [35] log, ref"log", etc => 記錄?日誌?

  • [36] whitespace 譯為「空白字元」,因其是統稱包括 " ", "\t", etc 多種空白字元

  • [37] diff 作名詞時多用「差異」,做動詞時建議用「差異比對」,即將「差異」置前。修飾型如「unified diff」、「inline diff」等則形容詞置前如「統合(式)差異」、「行內(式)差異」。

  • [38] inline, "inline" diff, etc 建議依習慣用「行內」

  • [39] n-way merge => n 方?n 路?n 向?合併

  • [40] authentication => 核對、核對身份

  • [41] config, configure => 配置?組態?設定? configured => ? configuration variable => ?

  • [42] versioned, unversioned 可考慮用簡稱「版控」翻譯:已版控、未版控,若要詳細則用(已/未)版本化、受版本控制、納入版本控制似乎都過於冗贅。

  • [43] superproject 可譯為「上層專案」

  • [44] checkout => 檢出?簽出?

  • [45] certificate 憑證, credential 證書

  • [46] reset => 重置? 重設?

  • [47] email

  • [48] git describe 不翻? ref: https://www.kernel.org/pub/software/scm/git/docs/git-describe.html

  • [49] fallback

  • [50] dangling

  • [51] refresh 建議依習慣用「重新整理」,須簡稱時可用「重整」。不建議大陸譯法「刷新」。

  • [52] verbose 原文大意是指多話,中文建議用「詳盡」(「詳細」則用於 detailed),若用「冗長」容易誤會為那些內容不必要,「囉嗦」「嘮叨」「多嘴」等主要用於口語,用於文字輸出較不符合中文語感。

  • [53] git config 中的 key 和 value

  • [54] working tree, work tree, working directory

  • [55] subject & body

  • [56] parent、ancestor

  • [57] show

  • [58] daemon

  • [59] policy 策略? 政策?

  • [60] squash

  • [61] parameter, argument 假設在 A() function 呼叫 B(x, y, z) ,在 A function 中稱 x, y, z 為 parameter,在 B(a, b, c) function 中稱 a, b, c 為 argument。一般 parameter 譯為「參數」, argument 譯為「引數」

  • [62] hunk 用在 patch 檔

  • [63] fork 保持原文不翻譯?

  • [64] skip

  • [65] Centralized

      Pro Git 2 中有幾個地方用到
      1. Centralized Version Control System,目前翻成「集中式版本控制系統」
      2. Centralized server,目前翻成「中央伺服器」
      3. Centralized authentication,則**待確認**。
      其它: 查了 [svn book 1.6](http://svnbook.red-bean.com/index.zh.html) 簡體中文,使用「中央」;在 [某個鏡像](http://mirror.sars.tw/SVN_book/book.html) 也是使用「中央」。
    
  • [66] 侯捷 - 我心目前最敬佩的譯者,摘要 科技翻譯面面觀 by 侯捷 一些字句如下,激勵大家,提醒自己:

    - 翻譯是一種半創造性的工作,沒有強烈的興趣,不可能做得來,也不可能做得好。
    - 翻譯是一座橋樑,沒有橋樑,那些缺乏撐竿跳絕技又不會游泳的群眾,沒有辦法到達彼岸。
    - 中國歷史上最大的翻譯事業,大概是佛典的翻譯。
    - 教育上: 閱讀原文書或許問題不大,但不可能像閱讀中文書那麼快、那麼印象深刻、那麼有效率。
    - 業界上: 優質中譯本的出現對他們的求知仍然不啻荒漠甘霖。
    - 譯者這邊的盲點在於過度高估自己,低估影響。
    - 最重要的工作是讓讀者儘可能把所有時間花在技術的學習上。
    - 研究圈不需要翻譯,教育圈才需要。
    - 當技術被寫入書中,其實已經不新,這時候我寧願它在譯者手上多花個一年半載,把品質做好。
    - 科技生根和術語中文化,我認為18竿子也打不著。
    - 完全要從讀者的角度思考。[..]。專業讀物,我贊成某些術語以原文為主述方式,必要時附加中文譯詞,最好再補個英中對照表。
    - 曾銘源先生:Terminology only makes sense to people in that particular field, why bother to give it another alias (Chinese translation)? 
    - 對術語譯名遵循兩大原則:(1) 儘量選用二字詞 (2) 儘量有「突出性」。前者唸起來乾淨俐落漂亮,後者使術語看起來像個術語,不和一般用語混淆(避免不當耗費讀者的時間)。
    - 看待異己世界,不要懷有敵意,更不要總以自我為中心。
    - 一定要清楚一點:你們所面對的讀者是什麼樣的水平。意義缺缺、近乎跳樑的事,就別做了。
    - 好書一旦被譯壞,讀者就別想再有好譯本可讀,造成的荼害將長期而絕對。
    - 信:忠信、忠於原文 
    - 達:譯文句子通順易明
    - 雅:用字優雅
    - 希望各位謹記,你們筆下出去的東西,影響的不是一個兩個人,是一千兩千個人,甚至一萬兩萬個人。我們都應該懷著戰戰兢兢的心情。
    
  • [67] mirror => 鏡像 (動詞)

    fully mirror the repository => 鏡像了整個版本庫
    
  • [68] pager => 分頁器

  • [69] pattern => 式樣、模式

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment