From 5b935ded2e6b2cbdb3cf24f327b49ed23e31858d Mon Sep 17 00:00:00 2001 From: Haowei Hsu Date: Thu, 19 Oct 2023 06:49:51 -0400 Subject: [PATCH] fix(zh-hant): Distinguish translations of 'Release/Publish' --- content/v1.0.0-beta.4/index.zh-hant.md | 10 +++++----- content/v1.0.0/index.zh-hant.md | 12 ++++++------ 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/content/v1.0.0-beta.4/index.zh-hant.md b/content/v1.0.0-beta.4/index.zh-hant.md index 7561cfe..933b199 100644 --- a/content/v1.0.0-beta.4/index.zh-hant.md +++ b/content/v1.0.0-beta.4/index.zh-hant.md @@ -104,7 +104,7 @@ closes issue #12 ### 在初始的開發階段，我該如何處理提交說明？ -我們建議你可以就像是產品已經發布的那樣去執行。因為通常都會 *有人* 使用你的軟體，即使是你的軟體開發的同事們，他們會希望知道修正了什麼以及有什麼重大變更等資訊。 +我們建議你可以就像是產品已經發行的那樣去執行。因為通常都會 *有人* 使用你的軟體，即使是你的軟體開發的同事們，他們會希望知道修正了什麼以及有什麼重大變更等資訊。 ### 提交標題中的類型應該要用大寫還是小寫？ @@ -124,18 +124,18 @@ closes issue #12 ### 這與 SemVer 有什麼關係呢？ -`fix` 類型的提交應該對應到 `PATCH` 版本。`feat` 類型的提交應該對應到 `MINOR` 版本。含有 `BREAKING CHANGE` 的提交，無論是什麼類型，都應該要對應到 `MAJOR` 版本。 +`fix` 類型的提交應該對應到 `PATCH` 發行版。`feat` 類型的提交應該對應到 `MINOR` 發行版。含有 `BREAKING CHANGE` 的提交，無論是什麼類型，都應該要對應到 `MAJOR` 發行版。 ### 我對慣例式提交做了擴充 (例如：`@jameswomack/conventional-commit-spec`)，我該如何管理這些擴充的版本呢？ -我們推薦使用 SemVer 來發布你對這份規範的擴充 (並且也鼓勵你做些擴充！) +我們推薦使用 SemVer 來發行你對這份規範的擴充 (並且也鼓勵你做些擴充！) ### 如果我不小心用錯提交類型，該怎麼辦？ #### 當你使用規範中但是錯誤的類型，例如：將 `feat` 寫成 `fix` -在合併或是發布這個錯誤之前，我們推薦使用 `git rebase -i` 來編輯提交歷史。 -而在發布之後，根據你使用的工具與流程，會有不同的清理方式。 +在合併或是發行這個錯誤之前，我們推薦使用 `git rebase -i` 來編輯提交歷史。 +而在發行之後，根據你使用的工具與流程，會有不同的清理方式。 #### 當你使用 *非* 規範中的類型時，例如：將 `feat` 寫成 `feet` diff --git a/content/v1.0.0/index.zh-hant.md b/content/v1.0.0/index.zh-hant.md index 06fae90..a7f94fa 100644 --- a/content/v1.0.0/index.zh-hant.md +++ b/content/v1.0.0/index.zh-hant.md @@ -136,7 +136,7 @@ Refs: #123 ### 在初始的開發階段，我該如何處理提交說明？ -我們建議你可以就像是產品已經發布的那樣去執行。因為通常都會 *有人* 使用你的軟體，即使是你的軟體開發的同事們，他們會希望知道修正了什麼以及有什麼重大變更等資訊。 +我們建議你可以就像是產品已經發行的那樣去執行。因為通常都會 *有人* 使用你的軟體，即使是你的軟體開發的同事們，他們會希望知道修正了什麼以及有什麼重大變更等資訊。 ### 提交標題中的類型應該要用大寫還是小寫？ @@ -156,18 +156,18 @@ Refs: #123 ### 這與 SemVer 有什麼關係呢？ -`fix` 類型的提交應該對應到 `PATCH` 版本。`feat` 類型的提交應該對應到 `MINOR` 版本。含有 `BREAKING CHANGE` 的提交，無論是什麼類型，都應該要對應到 `MAJOR` 版本。 +`fix` 類型的提交應該對應到 `PATCH` 發行版。`feat` 類型的提交應該對應到 `MINOR` 發行版。含有 `BREAKING CHANGE` 的提交，無論是什麼類型，都應該要對應到 `MAJOR` 發行版。 ### 我對慣例式提交做了擴充 (例如：`@jameswomack/conventional-commit-spec`)，我該如何管理這些擴充的版本呢？ -我們推薦使用 SemVer 來發布你對這份規範的擴充 (並且也鼓勵你做些擴充！) +我們推薦使用 SemVer 來發行你對這份規範的擴充 (並且也鼓勵你做些擴充！) ### 如果我不小心用錯提交類型，該怎麼辦？ #### 當你使用規範中但是錯誤的類型，例如：將 `feat` 寫成 `fix` -在合併或是發布這個錯誤之前，我們推薦使用 `git rebase -i` 來編輯提交歷史。 -而在發布之後，根據你使用的工具與流程，會有不同的清理方式。 +在合併或是發行這個錯誤之前，我們推薦使用 `git rebase -i` 來編輯提交歷史。 +而在發行之後，根據你使用的工具與流程，會有不同的清理方式。 #### 當你使用 *非* 規範中的類型時，例如：將 `feat` 寫成 `feet` @@ -180,7 +180,7 @@ Refs: #123 ### 慣例式提交要如何處理回退提交 (revert commit)？ -回退程式碼可能非常複雜：你是回退了多個提交嗎？如果你回退了一個功能，那麼下一個版本釋出應該要是修正檔嗎？ +回退程式碼可能非常複雜：你是回退了多個提交嗎？如果你回退了一個功能，那麼下一個發行版應該要是修正檔嗎？ 慣例式提交沒有強制定義回退的行為。反而，我們將這個問題留給工具的作者，靈活運用 _類型_ 以及 _頁腳_ 來開發處理回退的邏輯。