Merge pull request paul-hammant#114 from MilesChou/tw

Translate to Traditional Chinese

config.toml

@@ -1,6 +1,6 @@
-baseurl = "https://trunkbaseddevelopment.com/"
-languageCode = "en-us"
-title = "Trunk Based Development"
+baseurl = "https://tw.trunkbaseddevelopment.com/"
+languageCode = "zh-TW"
+title = "主幹開發"
 theme = "hugo-material-docs"
 metadataformat = "yaml"
 canonifyurls = true
@@ -45,145 +45,155 @@ googleAnalytics = "UA-24415524-3"
 	email   = "[email protected]"
 
 [[menu.main]]
-	name   = "Introduction"
+	name   = "簡介"
 	url    = "/"
 	weight = 1
 
 [[menu.main]]
-	name   = "Context"
+	name   = "情境"
 	url    = "context/"
 	weight = 5
 
 [[menu.main]]
-	name   = "Five-minute overview"
+	name   = "五分鐘概覽"
 	url    = "5-min-overview/"
 	weight = 11
 
 [[menu.main]]
-	name   = "Deciding factors"
+	name   = "決定因素"
 	url    = "deciding-factors/"
 	weight = 21
 
 [[menu.main]]
-	name   = "Version control system features"
+	name   = "版本控制系統的特色"
 	url    = "vcs-features/"
 	weight = 31
 
 [[menu.main]]
-	name   = "Version control system choices"
+	name   = "版本控制系統的選擇"
 	url    = "vcs-choices/"
 	weight = 32
 
 [[menu.main]]
-	name   = "Feature flags"
+	name   = "功能標誌"
 	url    = "feature-flags/"
 	weight = 41
 
 [[menu.main]]
-	name   = "Branch by Abstraction"
+	name   = "抽象分支"
 	url    = "branch-by-abstraction/"
 	weight = 53
 
 [[menu.main]]
-	name   = "Branch for release"
+	name   = "為發布建立分支"
 	url    = "branch-for-release/"
 	weight = 55
 
 [[menu.main]]
-	name   = "Release from trunk"
+	name   = "從主幹發布"
 	url    = "release-from-trunk/"
 	weight = 56
 
 [[menu.main]]
-	name   = "Styles and Trade-offs"
+	name   = "風格和權衡"
 	url    = "styles/"
 	weight = 60
 
 [[menu.main]]
-	name   = "Continuous Integration (CI)"
+	name   = "持續整合"
 	url    = "continuous-integration/"
 	weight = 61
 
 [[menu.main]]
-	name   = "Committing straight to the trunk"
+	name   = "直接提交到主幹"
 	url    = "committing-straight-to-the-trunk/"
 	weight = 62
 
 [[menu.main]]
-	name   = "Short Lived Feature Branches"
+	name   = "短期功能分支"
 	url    = "short-lived-feature-branches/"
 	weight = 63
 
 [[menu.main]]
-	name   = "Continuous Code Review"
+	name   = "持續不斷的程式碼審查"
 	url    = "continuous-review/"
 	weight = 65
 
 [[menu.main]]
-	name   = "Continuous Delivery (CD)"
+	name   = "持續交付"
 	url    = "continuous-delivery/"
 	weight = 71
 
 [[menu.main]]
-	name   = "Concurrent development of consecutive releases"
+	name   = "連續發布的平行開發"
 	url    = "concurrent-development-of-consecutive-releases/"
 	weight = 75
 
 [[menu.main]]
-	name   = "Application strangulation"
+	name   = "應用程式的絞殺策略"
 	url    = "strangulation/"
 	weight = 78
 
 [[menu.main]]
-	name   = "Observed habits"
+	name   = "觀察到的習慣"
 	url    = "observed-habits/"
 	weight = 81
 
 [[menu.main]]
-	name   = "You're doing it wrong"
+	name   = "你這樣做是錯的"
 	url    = "youre-doing-it-wrong/"
 	weight = 91
 
 [[menu.main]]
-	name   = "Alternative branching models"
+	name   = "替代的分支模型"
 	url    = "alternative-branching-models/"
 	weight = 101
 
 [[menu.main]]
-	name   = "Monorepos"
+	name   = "單一版本庫"
 	url    = "monorepos/"
 	weight = 111
 
 [[menu.main]]
-	name   = "Expanding Contracting Monorepos"
+	name   = "擴大或是收縮單一版本庫"
 	url    = "expanding-contracting-monorepos/"
 	weight = 112
 
 [[menu.main]]
-	name   = "Game Changers"
+	name   = "變革推動者"
 	url    = "game-changers/"
 	weight = 121
 
 [[menu.main]]
-	name   = "Publications"
+	name   = "出版"
 	url    = "publications/"
 	weight = 131
 
 [[menu.main]]
-	name   = "Book on this topic"
+	name   = "書籍"
 	url    = "book/"
 	weight = 132
 
 [[menu.main]]
-	name   = "Key to branch diagrams"
+	name   = "分支圖示的說明"
 	url    = "key/"
 	weight = 141
 
 [[menu.main]]
-	name   = "Contributions"
+	name   = "致謝貢獻者"
 	url    = "contributions/"
 	weight = 151
 
+[[menu.main]]
+	name   = "翻譯詞彙表"
+	url    = "translation-glossary/"
+	weight = 201
+
+[[menu.main]]
+	name   = "繁體中文翻譯團隊"
+	url    = "translators/"
+	weight = 211
+
 [blackfriday]
 	smartypants	= true
 	fractions = true
@@ -193,4 +203,9 @@ googleAnalytics = "UA-24415524-3"
 [sitemap]
   changefreq = "weekly"
   priority = 0.5
-  filename = "sitemap.xml"
+  filename = "sitemap.xml"
+
+[markup]
+	[markup.goldmark]
+		[markup.goldmark.renderer]
+			unsafe = true

content/5-min-overview/index.md

@@ -1,9 +1,10 @@
 ---
 date: 2016-01-01T09:42:02+05:00
-title: Five-minute overview
+title: 五分鐘概覽
 weight: 11
 ---
 
+<!--
 ## Distance
 
 {{< quote title="Branches create distance between developers and we do not want that" >}}
@@ -24,6 +25,26 @@ that might:
 
 Trunk-Based Development is a branching model that reduces this distance to the minimum. 
  
+-->
+
+## 距離
+
+{{< quote title="建立分支會在開發者之間創造距離，而我們不希望這樣" >}}
+&mdash; Frank Compagner, Guerrilla Games
+{{< /quote >}}
+
+當我們使用能夠透過網路存取程式碼版本控制系統時，實際的物理距離不再是一個大問題。這是因為影音視訊技術，如螢幕共享，不論實際距離如何，我們都可以即時溝通與協作。因此，在現代的開發環境中，我們不太需要擔心團隊成員之間的物理距離所帶來的影響。
+
+Frank 所說的「距離」，指的是開發過程中，多個元件、模組或多個團隊的程式碼如何整合到一個可部署或可發布的二進制檔案中的挑戰。這裡的「距離」並非指物理距離，而是指程式碼整合的難度和複雜性。當整合過程存在這種距離時，可能會遇到以下幾種情況：
+
+* 破壞一些意想不到的功能
+* 合併過程會遇到困難
+* 重複的工作被執行，直到合併後才被發現
+* 直到合併後才發現不兼容或不合適的問題
+
+主幹開發是能夠將距離最小化的分支模型。
+
+<!--
 ## What it is
 
 {{< note title="Notes" >}}
@@ -35,7 +56,18 @@ called 'trunk' at all.
 
 There are many deciding factors before a development team settles on Trunk-Based Development, but here is a short overview 
 of the practices if they do:
+-->
 
+## 它是什麼？
+
+{{< note title="Notes" >}}
+* 在本網站上，提到「開發者」一詞時，指的是對相同可建置專案進行自動化測試的「測試人員」。
+* 在本網站上，提到「主幹」（trunk）時，它實際上指的是團隊中的開發者們，集中進行開發的單一版本庫中的一個分支。該分支可能會稱為「main」，不一定會稱為「trunk」。
+{{< /note >}}
+
+在開發團隊決定採用主幹開發之前，有許多決定性因素需要考慮，但如果他們確實選擇這種方式，這裡有一個簡短的實踐概覽：
+
+<!--
 ### Releasability of work in progress
 
 Trunk-Based Development will always be **release ready**
@@ -45,21 +77,41 @@ live now with what we have", the worst response would be "give us one hour". The
 busy with tricky or even time-consuming tasks (therefore partially complete), but in an hour, they are able to go live 
 with something just stabilized from the trunk. Perhaps they can do it in less than an hour. The rule, though, is to **never break 
 the build**, and **always be release ready** because the CIO or the business may surprise you.
+-->
+
+### 進行中工作的可發布性
+
+主幹開發始終應該是**隨時可發布的**狀態
 
+如果一位高層經理拜訪開發團隊，並布達命令：「競爭對手 X 已經推出了功能 Y，現在就用我們擁有的東西上線」，更糟的消息是「給我們一小時」。開發團隊當下可能正在忙於解決一些複雜或者需要較長時間才能完成的任務（這意味著這些任務目前只做到一半），但在一小時內要求他們立即上線，他們能夠中挑選一些已達到穩定狀態的功能或程式碼，並將其部署上線。也許他們能在不到一小時內做到。然而，規則是**永遠不要破壞建置**，並且**總是準備好發布**，因為 CIO 或業務部門可能會突然給你帶來驚喜。
+
+<!--
 #### Where releases happen
 
 A key facilitating rule is that Trunk-Based Development teams exclusively **either** release directly from the 
 trunk - see [release from trunk](/release-from-trunk/), **or** they make a branch from the trunk specifically for 
 the actual release. See [Branch for release](/branch-for-release/).
 Teams with a higher release cadence do the former, and those with a lower release cadence do the latter. 
+-->
+
+#### 發布在哪裡進行？
+
+一個關鍵的協助發布的原則是，採用主幹開發的團隊僅能**直接從主幹發布**──見[從主幹發布](https://trunkbaseddevelopment.com/release-from-trunk/),**或者**他們專門從主幹建立一個分支用於實際的發布。見[為發布建立分支](https://trunkbaseddevelopment.com/branch-for-release/)。發布頻率較高的團隊採用前者方法，而發布頻率較低的團隊則採用後者方法。
 
+<!--
 ### Checking out / cloning
 
 All developers in a team working on an application/service, clone and checkout from the trunk. They will 
 update/pull/sync from that branch many times a day, **knowing** that the build passes. Their fast 
 source-control system means that their delays are a matter of a few seconds for this operation. They are now 
 integrating their teammates' commits on an hour-by-hour basis.
+-->
+
+### checkout 或 clone
+
+所有團隊中的開發者在開發一個應用程式或服務時，都會從主幹進行 clone 和 checkout 的操作。他們會在一天之內多次從該分支進行更新、拉取或同步的操作，**也確信**建置會是成功的。因為程式碼版本控制系統運行的非常快速，在進行上述操作時，僅需要耗時數秒就能完成。由於這樣的高效率，使得團隊能夠實現更加緊密的整合流程，他們能夠每小時就整合隊友的最新提交，確保他們的工作始終與主幹保持同步。
 
+<!--
 ### Committing
 
 Similarly, developers completing a piece of development work (changes to source code), that does not 
@@ -70,7 +122,17 @@ The developer needs to run the build, to prove that they did not break anything
 is pushed anywhere. They might have to do an update/pull/sync before they commit/push the changes back to the team's 
 version control server, and additional builds too. There's a risk of a race condition there, but let us assume that is not 
 going to happen for most teams.
+-->
 
+### 提交
+
+同樣地，當開發者完成了一項開發工作（對程式碼的變更），而這項工作並不會破壞建置時，他們會將把它提交回主幹。這個提交不會破壞建置應該是可以被證明的。這次提交的細節程度（一個開發者一天內隱式進行多少次提交）可能會有所不同，這是通過經驗學習的，但通常提交範圍都是小的。
+
+開發者需要執行建置，以證明他們的提交沒有破壞任何東西，然後才能將提交推送到任何地方。在他們提交或推送更改回團隊的程式碼版本控制系統**之前**，他們可能需要先進行更新、拉取或同步，並且還需要進行額外的建置。這裡存在推送競賽[^race-condition]的風險，但讓我們假設對於大多數團隊來說，這種情況不會發生。
+
+[^race-condition]: 推送競賽（Race condition）指的是多個操作在沒有適當同步的情況下同時訪問某些資源，導致結果無法預測或者出現錯誤的情況。在這個情境中，如果兩個或更多的開發者同時嘗試提交他們的更改，可能會導致一個推送競賽，從而影響最終的程式碼合併結果。
+
+<!--
 ### Code Reviews
 
 The developer needs to get the commit reviewed. Some teams will count the fact that the code was 'pair programmed' 
@@ -91,7 +153,21 @@ Note: You want to keep
 the commentary/approval/rejection that is part of the review for historical and auditing purposes, but you do not want to 
 keep the branch. Specifically, you do not want the developers to focus on the branch after the code review and merge back
 to the trunk.
+-->
+
+### 程式碼審查
+
+開發者需要讓提交的程式碼接受審查。有些團隊會認為「配對程式設計」 就等同於自動完成了程式碼審查。而其他團隊則會採用傳統的方法，在提交程式碼到主幹之前進行審查。在現代的系統解決方案中，審查幾乎總是意味著建立一個分支或分叉（拉取請求），讓團隊成員可以看到。
 
+<img srcset="trunk_pr.png 1x,[email protected] 2x">([分支圖示的說明](/key/))
+
+^ 圖中的對話框是以特殊風格呈現的程式碼審查評論。
+
+程式碼審查的分支在審查完成後可以（也應該）被刪除，並且生命週期非常短暫。對於剛開始使用主幹開發的團隊來說，這可能會有些困難。
+
+註：你希望保留審查過程中的評論、批准或拒絕等記錄，以供歷史回顧和審計之用，但你不想保留那個分支。具體來說，你不希望開發者在程式碼審查完成並合併回主幹後，還專注於那個分支。
+
+<!--
 ## A safety net
 
 [Continuous Integration](/continuous-integration/) (CI) daemons are set up to watch the trunk (and the 
@@ -105,21 +181,51 @@ will allow the CI server to do that automatically.
 The high bar is verifying the commit before it lands in the trunk. Short-lived Pull Request branches are the modern
 place for that.
  
+-->
+
+## 防護網
+
+[持續整合](/continuous-integration/)（CI）會設置常駐程式來監控主幹（和用於審查的[短期功能分支](/short-lived-feature-branches/)），並盡可能快速且全面地向團隊大聲且明顯地通報主幹出現問題。有些團隊會鎖定主幹並退回變更。有些團隊則允許持續整合服務器自動做這件事。
+
+<img srcset="5trunk1.png 1x,[email protected] 2x">([分支圖示的說明](/key/))
+
+更高的標準是在提交合併到主幹之前進行驗證。在現在軟體開發中，偏向使用短期的拉取請求分支來進行這樣的驗證。
+
+<!--
 ## Developer team commitments
 
 As stated, developers are pledging to be rigorous and not break the build. They're also going to need to consider 
 the impact of their potentially larger commits, especially where renames or moves were wholesale, and adopt techniques
 to allow those changes to be more easily consumed by teammates.
+-->
+
+## 開發團隊的責任
 
+如前面所述，開發者已承諾嚴格執行，他們將不會使建置過程失敗。此外，他們必須要意識到他們的大規模提交可能會對項目產生重大影響，尤其是當進行大量的重命名或文件移動時。因此，開發者需要採用相應的技巧和方法，以確保他們的改動可以被其他團隊成員更輕鬆地接受和整合。
+
+<!--
 ## Drilling into 'Distance'
 
 Problematic 'distance' has a few tangible examples:
 
 * Late merges of development that happened more than a couple of days ago
   * Difficult merges in particular
 * A breaking build that lowers development team throughput, and diverts resources while it is being fixed
+-->
+
+## 深入瞭解「距離」
+
+「距離」這一概念性問題有幾個具體的例子：
 
+* 遲來的合併，如果在開發工作的幾天後才合併到主幹，可能會造成問題。
+  * 特別是那些難以合併的情況。
+* 如果建置過程出現問題，不僅會降低開發團隊的工作效率，而且在修復建置問題期間還需要額外投入資源。
+
+<!--
 # References elsewhere
+-->
+
+# 外部參考連結
 
 <a id="showHideRefs" href="javascript:toggleRefs();">show references</a>