zh_tw: translate README and fix symobol present

1. translate README into zh_tw folder for people who want to
contribute tranditional chinese.
2. fix some symobol present like original source.

Signed-off-by: Samuel Jiang <[email protected]>

Author: jyangchisyan

_articles/zh-tw/README.md

@@ -1,16 +1,16 @@
-# :wrench: 正體中文的翻譯工作正在進行中..... :wrench:
+# 開源軟體指南 繁體中文
 
-## 翻譯規則
+[開源軟體指南](https://opensource.guide/) 是一份給個人、開源社群或是公司希望學習如何運行和貢獻開源項目的資源指南。
 
-|規則名稱|翻譯方式|
-|:-|:-|
-|引號轉換 quotation change|原作中引句使用雙引號`""`部分改為`「」`|
-|小括號轉全形 fullwidth parentheses|原作中`()` 換成 `（）`，使用新注音可透過按 \` 後 `shift`+`(` 輸入全形小括號|
-|大小標轉粗體 Bold the title|因為字的格式相同，導致標題與內文視覺上分不出來，所以需要將大小標轉為粗體|
-|中英文之間加空格 whitespace between languages|為使排版易讀，中英文字之間需用半形空格格開|
-|引文省略時表達方式|簡中使用（。。。）但應該保留(...)|
+## 貢獻
 
-## 銘謝
+網站是由[Jekyll](https://jekyllrb.com/) 套件建立而成。請先閱讀 [貢獻指引](https://github.com/github/opensource.guide/blob/master/CONTRIBUTING.md) 來了解如何回饋以及貢獻。
 
-[opencc](https://github.com/BYVoid/OpenCC) 協助繁簡體字轉換
-[tmonk](https://github.com/felixshai) 致力翻譯以及彙整維護
+## 授權
+
+內容以 [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/) 的方式釋出。請參閱 [notices](https://github.com/github/opensource.guide/blob/master/CONTRIBUTING.md) 文件以了解歸音指南、貢獻條款、軟體以及第三方授權權限。
+
+## 人員致謝
+
+1. [opencc](https://github.com/BYVoid/OpenCC): 協助繁簡體字轉換簡化翻譯效率。
+2. [tmonk](https://github.com/felixshai): 致力彙整維護翻譯。

_articles/zh-tw/best-practices.md

@@ -150,15 +150,15 @@ related:
 
 可能在你的社群裡有人不斷提交一些不符合專案需求的貢獻。對你們雙方來說，不停的拒絕他的提交，會令雙方都很尷尬。
 
-如果你發現有人對你的專案很上心，但是就是需要調教，那就耐心一點。給他解釋明白每次它的提交爲什麼不符合專案需求。嘗試著讓他先做一些簡單一點的事，比如那些標有 _"good first issue"_ 标签的issue，以此让他慢慢习惯。如果你有时间的话，考虑教Ta怎么完成第一次贡献，或者在社区找一个人教Ta。
+如果你發現有人對你的專案很上心，但是就是需要調教，那就耐心一點。給他解釋明白每次它的提交爲什麼不符合專案需求。嘗試著讓他先做一些簡單一點的事，比如那些標有 _"good first issue"_ 標籤的issue，以此讓他慢慢習慣。如果你有時間的話，考慮教他怎麼完成第一次的貢獻，或者在社區找一個人來負責。
 
 ## 有效利用社群
 
 你不需要凡事親力親爲。這就是社群存在的原因！即使你沒有一個活躍的貢獻者社群，但是如果你有很多用戶的話，拉他們來幹活兒。
 
 ### 分擔工作量
 
-如果你正在尋找其他人來參與, 從身邊的人開始。
+如果你正在尋找其他人來參與，從身邊的人開始。
 
 當你看到新的貢獻者不停的提交貢獻，通過分配給他們更多任務來表示認可。如果別人願意的話，記錄下別人是怎麼成長爲領導者的過程。
 

_articles/zh-tw/building-community.md

@@ -252,7 +252,7 @@ Atom 專案的 Issues 沒有投票機制，因為 Atom 團隊並不會遵循投
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
-如何循循善誘的將討論串引導到有益的方向，是一門藝術。直接要求人們不要發沒有建設性的文，要大家別浪費彼此的時間，這樣做是沒有效的。（。。。）反而，你必須設立一些限制條件，給大家一個方向，讓大家的意見最終導向成你所期待的結果，這樣就不像是無用的口頭訓斥。
+如何循循善誘的將討論串引導到有益的方向，是一門藝術。直接要求人們不要發沒有建設性的文，要大家別浪費彼此的時間，這樣做是沒有效的。（...）反而，你必須設立一些限制條件，給大家一個方向，讓大家的意見最終導向成你所期待的結果，這樣就不像是無用的口頭訓斥。
 
   <p markdown="1" class="pquote-credit">
 — @kfogel, [_打造開源軟體_](https://producingoss.com/en/producingoss.html#common-pitfalls)

_articles/zh-tw/code-of-conduct.md

@@ -10,7 +10,7 @@ related:
   - leadership
 ---
 
-## 我爲什麼需要行爲守則？
+## 我爲什麼需要行爲守則
 
 行爲守則是一份確立專案參與者行爲規範的文件。採用和執行行爲守則可以幫助你們的社群營造積極的氛圍。
 

_articles/zh-tw/getting-paid.md

@@ -154,7 +154,7 @@ related:
   <img src="https://avatars1.githubusercontent.com/u/1076721?v=3&s=460" class="pquote-avatar" alt="avatar">
   多年以來，我們一直都是網站友好圖標資源的領先者，社群超過2千萬人，併爲7千萬網站提供資源，其中包括 Whitehouse.gov。 (...) 3年前我們發佈了Font Awesome 的第4個版本。Web技術從那時起改變了更多事情，而且坦率的說Font Awesome 都有點過時。 (...) 這也是我們剛剛發佈 FontAwesome 5的原因之一，我們模塊化和重寫了 CSS，並從上到下重新設計了每一個圖標。我們積極的探討更好的設計、更好的一致性、以及更好的可讀性。
   <p markdown="1" class="pquote-credit">
-— @davegandy, [Font Awesome Kickstarter 衆籌視頻](https://www.kickstarter.com/projects/232193852/font-awesome-5)
+— @davegandy, [Font Awesome Kickstarter 群眾募資影片](https://www.kickstarter.com/projects/232193852/font-awesome-5)
   </p>
 </aside>
 

_articles/zh-tw/how-to-contribute.md

@@ -467,7 +467,7 @@ related:
 
 在下面的情形時，請你務必使用 PR：
 
-* 提交簡易的補丁 （例如拼寫錯誤、失效的超連結、或者是其它較明顯的錯誤）
+* 提交簡易的補丁 (例如拼寫錯誤、失效的超連結、或者是其它較明顯的錯誤)
 * 開始一項別人請求的任務，或者是過去在 issue 中早就討論過的事情
 
 一個 PR 並不代表工作已經完成了。它通常是儘早開啓一個 PR ，這樣其他人可以了解或者給你一些回饋。只需要標記爲 "WIP"（Working in Progress）。你可以隨時添加任何留言。

_articles/zh-tw/leadership-and-governance.md

@@ -14,7 +14,7 @@ related:
 
 當專案開始有條不紊的進行，人員也開始穩定，那麼你就應該開始社群的治理了。對於社群的治理，你或許有一些疑問，諸如如何將常規專案的貢獻者納入你的工作流？如何才能判斷應該賦予誰提交的權限？又或者是如何解決社群的債務？如果你對這些有疑問的話，我們這裏會盡力幫你解決。
 
-## 開源專案中通常都有那些角色？
+## 開源專案中通常都有那些角色
 
 很多專案針對貢獻者角色和身份均遵循相似的結構。
 
@@ -50,7 +50,7 @@ related:
   </p>
 </aside>
 
-## 該如何將這些領導力角色正規化？
+## 該如何將這些領導力角色正規化
 
 將領導力角色正規化，可以幫助人們找到歸屬感，且可以讓其它社群成員明白應該找誰能夠獲得幫助。
 
@@ -77,7 +77,7 @@ related:
 另外，如果你的專案在託管在GitHub上，考慮將你的專案從個人賬戶遷移到某個組織，而且要爲組織增加額外的一個備份的管理員。
 [GitHub 上的組織](https://help.github.com/articles/creating-a-new-organization-account/) 能夠讓權限管理和多倉庫管理更加的輕鬆，而且可通過 [共享所有權](../building-community/#分享專案的所有權)來保護你的專案。
 
-## 何時該賦予提交者權限？
+## 何時該賦予提交者權限
 
 有的人認爲專案應該對所有人都開放提交訪問，從而讓任何人都可以做出貢獻。理由是這樣做的話，會讓人們感到擁有這個專案，進而達到鼓勵的目的。
 
@@ -93,7 +93,7 @@ related:
   </p>
 </aside>
 
-## 對於開源專案來說有那些常見的治理結構？
+## 對於開源專案來說有那些常見的治理結構
 
 關於開源專案有三類通用的相關治理結構。
 
@@ -109,7 +109,7 @@ related:
 * [精英模式模版](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
 * [Node.js 的自由貢獻規則](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951#.m9ht26e79)
 
-## 當我創建開源專案時，需要專門撰寫一份治理文件嗎？
+## 當我創建開源專案時，需要專門撰寫一份治理文件嗎
 
 其實沒有什麼合適的時間來撰寫專案的治理，但是可以根據社群的動態來進行恰當的定義。開源治理最好的也是最難的部分是有社群本身來塑造！
 
@@ -137,7 +137,7 @@ related:
 
 和這個世界上很多的其它商業產品一樣，商業能夠激勵開發者去積極的貢獻於專案，通過他們靠譜的提交貢獻。顯而易見的是，一位因花了自己的時間和精力的開發者獲得報酬，理應比沒有獲得報酬的更具持久性，當然，這對於某些聖徒是不成立的，或者這麼說吧，報酬是能體現一個貢獻度的衆多衡量因素的其中之一。所以將你的專案討論聚焦於貢獻上，不要讓人們分散精力去思考或做其它的事情。
 
-## 我是否需要一個法律實體來支持我的專案?
+## 我是否需要一個法律實體來支持我的專案
 
 除非你特別的有錢，其實你根本沒有必要爲開源專案而專門搞一個法律實體來支持。
 

_articles/zh-tw/legal.md

@@ -14,7 +14,7 @@ related:
 
 向世界分享你們具有創造性的工作，這是一個多麼令人激動和有價值的經歷。這也意味著你們必須擔心一堆你們不清楚的法律問題。幸運的是，你們不必從頭開始。我們已經涵蓋了你們的法律需求。（在你們行動前，請確定閱讀了我們的[免責聲明](https://github.com/cnbo/open-source-guide/blob/gh-pages/notices.md)。）
 
-## 爲什麼大家非常擔心有關開源的法律問題？
+## 爲什麼大家非常擔心有關開源的法律問題
 
 很高興你們提問！當你們行創造性工作（例如寫作，圖形或程式碼）時，默認情況下該作品屬於專有版權（copyright）。也就是說，法律承認你們是你們作品的作者，他人在沒有經得你們同意的情況下不能使用你們的工作。
 
@@ -26,7 +26,7 @@ related:
 
 最後，你們的專案可能具有你們不知道的許可證要求的依賴關係。你們的專案社群，或者你們的僱主政策也可能要求你們使用特定的開源許可協議。
 
-## 公開的GitHub專案是開源的嗎？
+## 公開的GitHub專案是開源的嗎
 
 當你們在GitHub上[創建一個新專案](https://help.github.com/articles/creating-a-new-repository/) 時，你們可以選擇將倉庫設置成**private**或者**public**。
 
@@ -52,7 +52,7 @@ related:
   </p>
 </aside>
 
-## 哪個開源許可協議適合我的專案？
+## 哪個開源許可協議適合我的專案
 
 如果你們是小白，那麼使用[MIT License](https://choosealicense.com/licenses/mit/)，不容易出錯。它很短，很容易理解，並允許任何人做任何事情，只要他們保留許可證的副本，包括你們的版權聲明。如果你們需要，您們能夠根據不同的許可協議發佈專案。
 
@@ -72,7 +72,7 @@ related:
 
 當你們在GitHub上創建了一個新專案，它給你們提供了選擇許可協議的機會。包括上面提到的可以使你們的GitHub專案開源的許可協議。如果你們想要瞭解其他選擇，可以通過查閱[choosealicense.com](https://choosealicense.com)找到適合你們專案（即使它[不是軟體](https://choosealicense.com/non-software/)）的許可協議。
 
-## 如果我想更換專案的許可協議，該怎麼辦？
+## 如果我想更換專案的許可協議，該怎麼辦
 
 大多數專案絕不需要更換許可協議。但是情況偶爾有變。
 
@@ -86,7 +86,7 @@ related:
 
 或者，你們可以讓貢獻者事先同意（通過額外的貢獻者協議 - 見下文）在某些條件下更改某些許可協議，這些更改將超過現有的開源許可協議。這會改變許可協議改的複雜性。如果在執行許可協議更改時，你們仍然想要和專案利益相關者進行溝通，你們需要從你們律師那得到更多幫助。
 
-## 我的專案需要額外的貢獻者協議嗎？
+## 我的專案需要額外的貢獻者協議嗎
 
 可能不要。對於大多數的開源專案，一個開源許可協議可作用與所有貢獻者和用戶。
 
@@ -120,7 +120,6 @@ related:
 
 * **第三方資源：**你們的專案有其他人創建的依賴或者使用他人的程式碼？如果這些事開源專案，你們需要遵守第三方資源的開源許可協議。首先，選擇與第三方資源的開放源許可協議一起使用的許可協議（見上文）。如果你們的專案修改或者發佈第三方開源資源，那麼你們法律團隊還想知道你們符合第三方開源許可協議的其他條件，例如保留版權聲明。如果你們使用了其他沒有開源許可協議的程式碼，那麼你們可能會要求第三方資源的維護者[添加一個開源許可協議](https://choosealicense.com/no-license/#for-users)，要是你們得不到許可，你們只能停止使用他們的程式碼。
 
-
 * **商業機密：**請考慮專案中是否有公司不想對外公開的東西。如果是這樣的話，你們只能開源專案的一部分，得保護好公司的商業機密。
 
 * **專利：**你們公司是否申請了與你們專案有關的專利？如果開源源程式碼，這會對公司的專利進行[公開披露](https://en.wikipedia.org/wiki/Public_disclosure)。可悲的是，你們可能被要求等待（或者公司會重新思考應用程序）。如果你們期望從擁有大量專利組合的公司的員工那裏得到貢獻，們的法律團隊可能希望你們使用來自貢獻者的明確專利授權的許可協議（例如Apache 2.0或GPLv3）或其他貢獻者協議（見上文）。

_articles/zh-tw/metrics.md

@@ -10,7 +10,7 @@ related:
   - best-practices
 ---
 
-## 爲何要度量所有?
+## 爲何要度量所有
 
 數據，只有在充滿智慧的運用它，才能發揮出其應有的功效。作爲一名開源專案的維護者，可以利用數據來助自己一臂之力。
 

_articles/zh-tw/starting-a-project.md

@@ -14,7 +14,7 @@ related:
 
 所以你在考慮開始參與開源？恭喜！世界讚賞你的貢獻。讓我們來談談開源是什麼，以及人們這樣做。
 
-### "開源"是什麼意思？
+### "開源"是什麼意思
 
 當一個專案被開源，這意味着**任何人都可以出於任何目的查看，使用，修改和分發你的專案**。 這些權限通過[開源許可](https://opensource.org/licenses)強制實施。
 
@@ -49,15 +49,15 @@ related:
 
 開源並不僅僅限於軟件。您可以開源任何事物，從數據集到書本。查看 [GitHub Explore](https://github.com/explore) 開找找有什麼是你可以開源的。
 
-### 開源是指"免費"嗎？
+### 開源是指"免費"嗎
 
 開源最大的吸引之一是它不花錢。 但是，"免費"只是開源的總體價值的一個副產品。
 
 因爲[開源許可證要求](https://opensource.org/osd-annotated)任何人可以幾乎出於任何目使用，修改和共享您的專案，專案本身往往是免費的。 如果該專案花錢使用，任何人也都可以合法地複製和使用免費版本。
 
 因此，大多數開源專案是免費的，但"免費"不是開源定義的一部分。 有些方法可以通過雙重許可或有限功能間接地爲開源專案收費，同時仍然遵守開源的官方定義。
 
-## 我是否應該發起我自己的開源專案?
+## 我是否應該發起我自己的開源專案
 
 簡單來說，答案是肯定的，因爲無論結果如何，啓動您自己的專案來瞭解開源的工作原理是一個好方法。
 
@@ -358,6 +358,6 @@ related:
   </label>
 </div>
 
-## 你做到了！
+## 你做到了
 
 恭喜你開源了你的首個專案。不論結果如何，對開源社群都是一份禮物。隨着每次commit,comment和pull request，你正在爲自己或者他人創造學習和成長的機會。