Re: [討論] Git 術語中譯計畫 2.0
※ 引述《bassann (Sorry or please?)》之銘言：
: 標題: Re: [討論] Git 術語中譯計畫 2.0
: 時間: Tue May 12 17:05:11 2015
:
: 恕刪。
:
: 大家好。我在 GitHub 工作。
遇到大咖了@@" 幸會幸會XD
:
: 過去有碰到幾次這類的問題，我個人現在立場是英文
: 為主、中文為輔翻譯最好。如果要直接取代本來的原
: 文的 CLI 說明，容易造成不同語言說明中的斷層。
這點我部分同意，後面一起說
:
: GitHub 在做軟體的時候也有面臨類似的語言選擇 –
: 雖然不是翻譯，但當初因為選擇了不同的詞，讓很多
: 使用者搞不清楚按鈕的功用。最常被提起的例子就是
: "Sync" 按鈕，到底 Sync 是只有 Pull 、還是 Pull
: + Merge 、還是 Fetch 呢？
我沒裝過 GitHub 軟體，不過以此例來看，我想就算是
英美人士也一樣會有 sync 是什麼意思的疑惑，所以我
不覺得這是中文翻譯的問題，而是原文就用了和指令本
身不同的詞造成。
:
: ---
:
: 以原 po 範例 Git 中文化指令說明中的 commit 和
: log 來說：
:
: commit 記錄變更到版本庫
: log 顯示提交日誌
:
: 如果只看這個中文解釋要怎麼知道 log 和 commit
: 的關係呢？ 而我們看英文版的：
:
: commit Record changes to the repository
: log Show the commit history log
:
: 可以清楚看到 log 的說明中提到 commit，而
: commit 就是另外一個指令的名稱。
:
: 這就是我覺得最大的問題。我們現在不會 100% 中文
: 化 Git 的 CLI，而這個差異就會產生理解上的斷層。
: （我想大家也同意我們不應該中文化 cmd）
這也是我遲疑的主要理由，因為指令本身不譯，所以無
論翻得多好，使用者還是要自己努力把互動訊息中的「
提交」和 commit 指令連結起來。
現在好像還沒找到簡單的方法可以讓使用者在輸入像
git commit --help 時知道 commit 對應的中文翻譯是
「提交」，如果這可以解決，或許問題會小很多。
不過這種情況的比例不是很高，主要是 stage, commit,
log, reset, merge, rebase, revert 等幾個詞，可能
10 個上下吧，其他進階的 git update-index, git
ls-files 之類幾乎不會以中文形式出現在互動訊息中，
所以整體而言影響或許不是那麼大。
再說我寫程式也十幾年了，常常思考時還是「進入這個
目錄，複製那個檔案，然後OOXX」，然後再轉換成程式
碼，而不是一開始就「進入這個 directory，copy 那
個 file，然後OOXX」，如果其他寫程式的也是像我這
樣，就說明這種 directory=目錄 之類的轉換主要只是
習慣問題而已，如果中譯夠統一且普及，使用者應該看
到「提交」就能反射出 commit，問題便不大。
當然，CLI 譯成中文對入門和上手的幫助有沒有大過於
這種銜接上的問題，還很難說就是了...
:
: 以 git-scm 來說，我覺得這樣的翻譯模式最好：
:
: > Git 有三種表達檔案的狀態：已提交 (committed)、
: > 已修改 (modified) 及已暫存 (staged)。 已提交
: > 意謂著資料己安全地存在讀者的本地端資料庫。
之以必須要如此，主要原因也是 CLI 的訊息輸出 (比如
git status) 寫的是 committed, modified, staged。
假使 CLI 輸出譯成中文而且被廣為使用，此處是否還需
要附註原文，也許就沒那麼確定了（就像大家討論
Windows 操作不太會附註原文一樣）。
當然說歸說，以現今趨勢不太可能讓大家通通使用中文
版 CLI 啦，所以附註 CLI 重要關鍵輸出的原文還是不
得不為XD
:
: 這也就是為什麼我們當初翻譯 git-it 文件 [1] 時
: 選擇保留所有英文專有名詞，而只用類似 superscript
: 的方式來做註解。
我覺得 git-it 的做法很有創意，只是它用的附註標籤有
點特別，沒辦法用 <ruby> <rb> <rt> 加 CSS 使它在不
支援的瀏覽器上正常呈現樣式嗎？
另外就是裡面的譯詞及文句以我的標準覺得還有不少可以
優化的地方。可能我太龜毛吧XD
還有就是這種做法不曉得適不適合 Pro Git 採用...
:
: ---
:
: 至於說「Git 很難用」我倒是不太同意，不容易理解
: 可能是真的。但這個問題癥結就不在於 Git 的 CLI，
: 而在於大部分人不理解 Git 的 data structure。
: 理解了的話，我認為「指令」叫什麼就不重要了，知
: 道想要達成的結果最重要，所以我完全雙手贊成更多
: 中文的教學文件。
其實一般批評 Git 難學難用，一方面是 data structure
比較複雜，另一方面是它的指令分類比較不符合一般使
用習慣。
比如 git checkout 如果不加路徑是把 HEAD 切換到不
同分支，但如果加路徑則是不切換 HEAD、只是把某
commit 某路徑下的東西弄出來。對很多使用者而言兩者
分屬不同指令會比較符合直覺（Hg 就是分別用 update
和 revert）。
還有就是 stage 的設計真的是兩面刃，這玩意導致 Git
指令複雜度高上許多，像 diff 就至少有 git diff、
git diff HEAD、git diff --cached 三種。
當然我還是 Git 派的，之前也批過 Hg 幾回，這部分等
VCS 板開出來再戰吧XDD
:
: 但 CLI 訊息的中文化我就還是存疑。除非是使用中英
: 並存的模式。
如果要做，我會考慮盡量在合理範圍附上英文，畢竟中
文化的主要目的是讓大家好上手、易理解嘛。
不過範圍有點難確立，比如是否每個「提交」後面都要
附上 (commit) 呢？
:
: ---
:
: 當初有請一些朋友一起幫忙翻譯文件，裡頭有些相關
: 的討論，給大家參考：
:
: [1] https://github.com/jlord/git-it/pull/65
: [2] https://github.com/muan/24pullrequests/pull/1
:
: 以上。 :)
感謝提供資訊，合十
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 59.115.3.170
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1431438444.A.4FF.html
※ 編輯: danny0838 (59.115.3.170), 05/12/2015 21:50:49
※ 編輯: danny0838 (59.115.3.170), 05/12/2015 21:51:04
※ 編輯: danny0838 (59.115.3.170), 05/12/2015 23:19:44
推
05/13 01:03, , 1F
05/13 01:03, 1F
→
05/13 01:03, , 2F
05/13 01:03, 2F
推
05/13 01:10, , 3F
05/13 01:10, 3F
→
05/13 01:11, , 4F
05/13 01:11, 4F
推
05/13 01:14, , 5F
05/13 01:14, 5F
→
05/13 01:15, , 6F
05/13 01:15, 6F
→
05/13 01:15, , 7F
05/13 01:15, 7F
越講越長決定回文了XD
推
05/13 08:59, , 8F
05/13 08:59, 8F
我個人是覺得「最佳化」和「優化」都可接受，
但兩者意思不太一樣，
前者比較接近 optimize，後者比較像 improve。
不過現實上很多 optimize 結果其實只是 improve，
所以用「優化」也沒什麼錯XD
另外前文用的「優化」要表達的就是 improve，
而不是對 optimize 的翻譯，所以別戰我亂翻XD
※ 編輯: danny0838 (59.115.3.170), 05/13/2015 11:09:23
※ 編輯: danny0838 (59.115.3.170), 05/13/2015 11:14:19
※ 編輯: danny0838 (59.115.3.170), 05/13/2015 11:27:41
※ 編輯: danny0838 (59.115.3.170), 05/13/2015 11:36:01
※ 編輯: danny0838 (59.115.3.170), 05/13/2015 11:43:17
推
05/13 11:49, , 9F
05/13 11:49, 9F
※ 編輯: danny0838 (59.115.3.170), 05/13/2015 13:25:39
※ 編輯: danny0838 (59.115.3.170), 05/13/2015 13:35:10
※ 編輯: danny0838 (59.115.3.170), 05/13/2015 13:40:36
討論串 (同標題文章)