Merge branch 'zh-tw' into feature/change-the-code-word-for-zh-tw-tran…

…slation

README.md

@@ -17,6 +17,10 @@ Google has many generalized engineering practices that cover all languages and a
 * **CL**：代表 "changelist"，意思是已提交到版本控制或正在進行程式碼審查的獨立修改。其他組織通常稱之為 "change"、"patch" 或 "pull-request"。
 * **LGTM**：意思是 "Looks Good to Me"，這是程式碼審查者在核准 CL 時所說的話。
 
+## 正體中文翻譯
+
+本書正體中文翻譯由 [Will 保哥](https://blog.miniasp.com/) 完成，原文取自 [Google Engineering Practices Documentation](https://github.com/google/eng-practices)。若有任何問題，歡迎造訪 [Will 保哥的技術交流中心](https://www.facebook.com/will.fans) 與我聯繫！
+
 ## 授權 (License)
 
 該專案中的文件根據 [CC-By 3.0 授權](LICENSE)進行授權，該授權鼓勵您分享這些文件。有關詳細資訊，請參閱<https://creativecommons.org/licenses/by/3.0/>。

review/developer/cl-descriptions.md

@@ -57,7 +57,7 @@ the best approach. If there are any shortcomings to the approach, they should be
 mentioned. If relevant, include background information such as bug numbers,
 benchmark results, and links to design documents.
 
-如果您包含外部資源的連結，要考慮到因存取限制或保留政策，這些連結可能對未來讀者不可見。在可能的情況下，請提供足夠的上下文讓審閱者和未來的讀者理解程式碼。
+如果您包含外部資源的連結，要考慮到因存取限制或保留政策，這些連結可能對未來讀者不可見。在可能的情況下，請提供足夠的上下文讓審查者和未來的讀者理解程式碼。
 
 If you include links to external resources consider that they may not be visible
 to future readers due to access restrictions or retention policies. Where
@@ -176,7 +176,7 @@ Example:
 > instead of Python2, and significantly simplifies some automated build file
 > refactoring tools being worked on currently.
 
-第一句話描述實際正在做什麼。其餘的描述解釋了為什麼要進行更改，並為審查人員提供了很多背景。
+第一句話描述實際正在做什麼。其餘的描述解釋了為什麼要進行更改，並為審查者提供了很多背景。
 
 The first sentence describes what's actually being done. The rest of the
 description explains *why* the change is being made and gives the reviewer a lot

review/developer/handling-comments.md

@@ -1,21 +1,21 @@
-# 如何處理審稿人意見 (How to handle reviewer comments)
+# 如何處理審查者意見 (How to handle reviewer comments)
 
-當您發送一個供審查的 CL 時，您的審查人員可能會對您的 CL 發表多條評論。下面是有關處理審查人員評論的一些有用資訊。
+當您發送一個供審查的 CL 時，您的審查者可能會對您的 CL 發表多條評論。下面是有關處理審查者評論的一些有用資訊。
 
 When you've sent a CL out for review, it's likely that your reviewer will
 respond with several comments on your CL. Here are some useful things to know
 about handling reviewer comments.
 
 ## 不要把它當成個人攻擊 (Don't Take it Personally) {#personal}
 
-審查的目標是維護我們程式庫和產品的品質。當審查者對您的程式碼提出評論時，請把這視為他們試圖幫助您、程式庫和 Google，而不是對您或您的能力的個人攻擊。
+審查的目標是維護我們程式碼庫和產品的品質。當審查者對您的程式碼提出評論時，請把這視為他們試圖幫助您、程式碼庫和 Google，而不是對您或您的能力的個人攻擊。
 
 The goal of review is to maintain the quality of our codebase and our products.
 When a reviewer provides a critique of your code, think of it as their attempt
 to help you, the codebase, and Google, rather than as a personal attack on you
 or your abilities.
 
-有時審查人員會感到沮喪，並在他們的評論中表達這種沮喪。雖然這對於審查人員來說並不是一種好的實踐，但作為開發人員，您應該為此做好準備。問問自己："評審人員試圖要傳達給我哪些建設性的內容？"，然後像他們實際說的那樣去操作。
+有時審查者會感到沮喪，並在他們的評論中表達這種沮喪。雖然這對於審查者來說並不是一種好的實踐，但作為開發人員，您應該為此做好準備。問問自己："審查者試圖要傳達給我哪些建設性的內容？"，然後像他們實際說的那樣去操作。
 
 Sometimes reviewers feel frustrated and they express that frustration in their
 comments. This isn't a good practice for reviewers, but as a developer you
@@ -31,7 +31,7 @@ are too angry or annoyed to respond kindly, then walk away from your computer
 for a while, or work on something else until you feel calm enough to reply
 politely.
 
-通常情況下，如果評審無法以有建設性且有禮貌的方式提供反饋，請親自向他們解釋。如果您無法當面或透過視訊通話與他們交談，請透過私人電子郵件與他們聯繫。以友好的方式告訴他們您不喜歡什麼，以及您希望他們做不同的事情。如果他們對這個私人討論也以非建設性的方式回應，或是沒有達到預期的效果，那就根據情況提升給您的經理。
+通常情況下，如果審查者無法以有建設性且有禮貌的方式提供反饋，請親自向他們解釋。如果您無法當面或透過視訊通話與他們交談，請透過私人電子郵件與他們聯繫。以友好的方式告訴他們您不喜歡什麼，以及您希望他們做不同的事情。如果他們對這個私人討論也以非建設性的方式回應，或是沒有達到預期的效果，那就根據情況提升給您的經理。
 
 In general, if a reviewer isn't providing feedback in a way that's constructive
 and polite, explain this to them in person. If you can't talk to them in person
@@ -52,7 +52,7 @@ add a code comment that explains why the code is there. If a comment seems
 pointless, only then should your response be an explanation in the code review
 tool.
 
-如果審查人員沒有理解你的一些程式碼，未來閱讀這些程式碼的人可能也不會理解。在程式碼審查工具中撰寫回應並不會幫助未來閱讀程式碼的人，但是澄清你的程式碼或新增程式碼註解則能對他們有所幫助。
+如果審查者沒有理解你的一些程式碼，未來閱讀這些程式碼的人可能也不會理解。在程式碼審查工具中撰寫回應並不會幫助未來閱讀程式碼的人，但是澄清你的程式碼或新增程式碼註解則能對他們有所幫助。
 
 If a reviewer didn't understand some piece of your code, it's likely other
 future readers of the code won't understand either. Writing a response in the
@@ -68,14 +68,14 @@ send one out for review, feel like it's done, and be pretty sure that no further
 work is needed. It can be frustrating to receive comments asking for changes,
 especially if you don't agree with them.
 
-在這種情況下，請花些時間退一步並考慮評審者是否提供了有助於程式基礎和 Google 的有價值反饋。你應該始終首先問自己的問題是："我瞭解評審者的要求嗎？"
+在這種情況下，請花些時間退一步並考慮審查者是否提供了有助於程式基礎和 Google 的有價值反饋。你應該始終首先問自己的問題是："我瞭解審查者的要求嗎？"
 
 At times like this, take a moment to step back and consider if the reviewer is
 providing valuable feedback that will help the codebase and Google. Your first
 question to yourself should always be, "Do I understand what the reviewer is
 asking for?"
 
-如果你無法回答那個問題，請詢問審閱者以取得澄清。
+如果你無法回答那個問題，請詢問審查者以取得澄清。
 
 If you can't answer that question, ask the reviewer for clarification.
 
@@ -96,7 +96,7 @@ My understanding is that using Y would be worse because of [these reasons]. Are
 you suggesting that Y better serves the original tradeoffs, that we should weigh
 the tradeoffs differently, or something else?"
 
-請記住，**禮貌和尊重**應始終是首要考慮。如果您不同意審查人員，請尋找合作方式：請求澄清，討論優缺點，並解釋為什麼您執行任務的方法對於程式碼庫、使用者和/或 Google 更優。
+請記住，**禮貌和尊重**應始終是首要考慮。如果您不同意審查者，請尋找合作方式：請求澄清，討論優缺點，並解釋為什麼您執行任務的方法對於程式碼庫、使用者和/或 Google 更優。
 
 Remember,
 **[courtesy and respect](https://chromium.googlesource.com/chromium/src/+/master/docs/cr_respect.md)
@@ -105,7 +105,7 @@ ways to collaborate: ask for clarifications, discuss pros/cons, and provide
 explanations of why your method of doing things is better for the codebase,
 users, and/or Google.
 
-有時候，你可能會對使用者、原始碼庫(codebase)或該項 CL 的情況有更多瞭解，而評審者可能尚未瞭解的內容。如適當地[修正程式碼](#code)，並透過討論與分享更多背景資訊來與評審者互動。通常，你可以基於技術事實與評審者達成共識。
+有時候，你可能會對使用者、程式碼庫(codebase)或該項 CL 的情況有更多瞭解，而評審者可能尚未瞭解的內容。如適當地[修正程式碼](#code)，並透過討論與分享更多背景資訊來與評審者互動。通常，你可以基於技術事實與評審者達成共識。
 
 Sometimes, you might know something about the users, codebase, or CL that the
 reviewer doesn't know. [Fix the code](#code) where appropriate, and engage your
@@ -114,7 +114,7 @@ to some consensus between yourself and the reviewer based on technical facts.
 
 ## 解決衝突 (Resolving Conflicts) {#conflicts}
 
-解決衝突的第一步應該是嘗試與審查人達成共識。如果無法達成共識，請參閱[程式碼審查標準](../reviewer/standard.md)，其中提供了在這種情況下應遵循的原則。
+解決衝突的第一步應該是嘗試與審查者達成共識。如果無法達成共識，請參閱[程式碼審查標準](../reviewer/standard.md)，其中提供了在這種情況下應遵循的原則。
 
 Your first step in resolving conflicts should always be to try to come to
 consensus with your reviewer. If you can't achieve consensus, see

review/developer/index.md

@@ -6,6 +6,6 @@ The pages in this section contain best practices for developers going through co
 
 - [撰寫良好的 CL 描述 (Writing Good CL Descriptions)](cl-descriptions.md)
 - [小的變更清單 (Small CLs)](small-cls.md)
-- [如何處理審稿人意見 (How to Handle Reviewer Comments)](handling-comments.md)
+- [如何處理審查者意見 (How to Handle Reviewer Comments)](handling-comments.md)
 
 參見 [如何進行程式碼審查](../reviewer/index.md)，該篇文章提供了審查者的詳細指導。