diff --git a/index.md b/index.md
index e38f557..c4535af 100644
--- a/index.md
+++ b/index.md
@@ -30,7 +30,7 @@ consumers of your library:
 1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with [`PATCH`](http://semver.org/#summary) in semantic versioning).
 2. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates
   with [`MINOR`](http://semver.org/#summary) in semantic versioning).
-3. **BREAKING CHANGE:** a commit that has the text `BREAKING CHANGE:` at the beginning of its optional body or footer section introduces a breaking API change (correlating with [`Major`](http://semver.org/#summary) in semantic versioning). A breaking change can be
+3. **BREAKING CHANGE:** a commit that has the text `BREAKING CHANGE:` at the beginning of its optional body or footer section introduces a breaking API change (correlating with [`MAJOR`](http://semver.org/#summary) in semantic versioning). A breaking change can be
   part of commits of any _type_. e.g., a `fix:`, `feat:` & `chore:` types would all be valid, in addition to any other _type_.
 4. Others: commit _types_ other than `fix:` and `feat:` are allowed, for example [the Angular convention](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit) recommends `docs:`, `style:`, `refactor:`, `perf:`, `test:`, `chore:`, but these tags are not mandated by the conventional commits specification.
 <br />
@@ -61,7 +61,7 @@ debug issues across project boundaries.
 
 The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
 
-1. commits MUST be prefixed with a type, which consists of a verb, `feat`, `fix`, etc.,
+1. commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc.,
    followed by a colon and a space.
 2. the type `feat` MUST be used when a commit adds a new feature to your application
   or library.
diff --git a/lang/es/index.md b/lang/es/index.md
index 802fbd0..e31fb4e 100644
--- a/lang/es/index.md
+++ b/lang/es/index.md
@@ -30,7 +30,7 @@ consumers of your library:
 1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with [`PATCH`](http://semver.org/#summary) in semantic versioning).
 2. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates
   with [`MINOR`](http://semver.org/#summary) in semantic versioning).
-3. **BREAKING CHANGE:** a commit that has the text `BREAKING CHANGE:` at the beginning of its optional body or footer section introduces a breaking API change (correlating with [`Major`](http://semver.org/#summary) in semantic versioning). A breaking change can be
+3. **BREAKING CHANGE:** a commit that has the text `BREAKING CHANGE:` at the beginning of its optional body or footer section introduces a breaking API change (correlating with [`MAJOR`](http://semver.org/#summary) in semantic versioning). A breaking change can be
   part of commits of any _type_. e.g., a `fix:`, `feat:` & `chore:` types would all be valid, in addition to any other _type_.
 
 <br />
@@ -64,7 +64,7 @@ debug issues across project boundaries.
 
 The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
 
-1. commits MUST be prefixed with a type, which consists of a verb, `feat`, `fix`, etc.,
+1. commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc.,
    followed by a colon and a space.
 2. the type `feat` MUST be used when a commit adds a new feature to your application
   or library.
diff --git a/lang/es/spec/v1.0.0-beta.1.md b/lang/es/spec/v1.0.0-beta.1.md
index 47013a6..2a4901e 100644
--- a/lang/es/spec/v1.0.0-beta.1.md
+++ b/lang/es/spec/v1.0.0-beta.1.md
@@ -30,7 +30,7 @@ consumers of your library:
 1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with [`PATCH`](http://semver.org/#summary) in semantic versioning).
 2. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates
   with [`MINOR`](http://semver.org/#summary) in semantic versioning).
-3. **BREAKING CHANGE:** a commit that has the text `BREAKING CHANGE:` at the beginning of its optional body or footer section introduces a breaking API change (correlating with [`Major`](http://semver.org/#summary) in semantic versioning). A breaking change can be
+3. **BREAKING CHANGE:** a commit that has the text `BREAKING CHANGE:` at the beginning of its optional body or footer section introduces a breaking API change (correlating with [`MAJOR`](http://semver.org/#summary) in semantic versioning). A breaking change can be
   part of commits of any _type_. E.g., a `fix:`, `feat:` & `chore:` types would all be valid, in addition to any other _type_.
 
 <br />
@@ -64,7 +64,7 @@ debug issues across project boundaries.
 
 The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
 
-1. commits MUST be prefixed with a type, which consists of a verb, `feat`, `fix`, etc.,
+1. commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc.,
    followed by a colon and a space.
 2. the type `feat` MUST be used when a commit adds a new feature to your application
   or library.
diff --git a/lang/es/spec/v1.0.0-beta.md b/lang/es/spec/v1.0.0-beta.md
index ad1e042..942f3bd 100644
--- a/lang/es/spec/v1.0.0-beta.md
+++ b/lang/es/spec/v1.0.0-beta.md
@@ -30,7 +30,7 @@ consumers of your library:
 1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with [`PATCH`](http://semver.org/#summary) in semantic versioning).
 2. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates
   with [`MINOR`](http://semver.org/#summary) in semantic versioning).
-3. **BREAKING CHANGE:** a commit that has the text `BREAKING CHANGE:` at the beginning of its optional body or footer section introduces a breaking API change (correlating with [`Major`](http://semver.org/#summary) in semantic versioning). A breaking change can be
+3. **BREAKING CHANGE:** a commit that has the text `BREAKING CHANGE:` at the beginning of its optional body or footer section introduces a breaking API change (correlating with [`MAJOR`](http://semver.org/#summary) in semantic versioning). A breaking change can be
   part of either a `fix:` or `feat:` _type_ commit.
 
 <br />
@@ -64,7 +64,7 @@ debug issues across project boundaries.
 
 The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
 
-1. commits MUST be prefixed with a type, which consists of a verb, `feat`, `fix`, etc.,
+1. commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc.,
    followed by a colon and a space.
 2. the type `feat` MUST be used when a commit adds a new feature to your application
   or library.
diff --git a/lang/it/index.md b/lang/it/index.md
index 7688465..fe2f71d 100644
--- a/lang/it/index.md
+++ b/lang/it/index.md
@@ -29,7 +29,7 @@ l'intento al consumatore della libreria:
 
 1. **fix:** un commit di _tipo_ `fix` risolve un errore nel codice (correlato al [`PATCH`](http://semver.org/#summary) in un versionamento semver).
 2. **feat:**  un commit di _tipo_ `feat` introduce una nuova funzionalità al codice (correlato al [`MINOR`](http://semver.org/#summary) in un versionamento semver).
-3. **BREAKING CHANGE:** un commit che contiente il testo `BREAKING CHANGE:` all'inizio delle sezioni opzionali _corpo_ o _piè di pagina_, introduce una breaking API change (correlato al [`Major`](http://semver.org/#summary) in un versionamento semver).
+3. **BREAKING CHANGE:** un commit che contiente il testo `BREAKING CHANGE:` all'inizio delle sezioni opzionali _corpo_ o _piè di pagina_, introduce una breaking API change (correlato al [`MAJOR`](http://semver.org/#summary) in un versionamento semver).
 Una _breaking change_ può essere parte di un commit di qualsiasi _tipo_.
 Es: I tipi `fix:`, `feat:` & `chore:` sono tutti validi.
 4. Altro: Sono ammessi altri _tipi_ oltre `fix:` e `feat:`, ad esempio [la convenzione Angular](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit) raccomanda `docs:`, `style:`, `refactor:`, `perf:`, `test:`, `chore:`, ma questi non sono coperti da questa specifica.
@@ -62,7 +62,7 @@ rimuovere errori tra progetti.
 
 Le parole “DEVE”, “NON DEVE”, “RICHIESTO”, “DOVRÀ”, “NON DOVRÀ”, “DOVREBBE”, “NON DOVREBBE”, “RACCOMANDATO”, “POTREBBE” e “OPZIONALE” devo essere interpretata come da specifica [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
 
-1. Un commit DEVE iniziare con un _tipo_, il quale consiste in un verbo, `feat`, `fix`, etc.,
+1. Un commit DEVE iniziare con un _tipo_, il quale consiste in un sostantivo, `feat`, `fix`, etc.,
    seguito dai due punti ed uno spazio.
 2. Il _tipo_ `feat` DEVE essere usato quando un commit aggiunge una funzionalità
    all'applicazione o libreria.
diff --git a/lang/it/spec/v1.0.0-beta.1.md b/lang/it/spec/v1.0.0-beta.1.md
index 6ba1c3a..d686a20 100644
--- a/lang/it/spec/v1.0.0-beta.1.md
+++ b/lang/it/spec/v1.0.0-beta.1.md
@@ -29,7 +29,7 @@ l'intento al consumatore della libreria:
 
 1. **fix:** un commit di _tipo_ `fix` risolve un errore nel codice (correlato al [`PATCH`](http://semver.org/#summary) in un versionamento semver).
 2. **feat:**  un commit di _tipo_ `feat` introduce una nuova funzionalità al codice (correlato al [`MINOR`](http://semver.org/#summary) in un versionamento semver).
-3. **BREAKING CHANGE:** un commit che contiente il testo `BREAKING CHANGE:` all'inizio delle sezioni opzionali _corpo_ o _piè di pagina_, introduce una breaking API change (correlato al [`Major`](http://semver.org/#summary) in un versionamento semver).
+3. **BREAKING CHANGE:** un commit che contiente il testo `BREAKING CHANGE:` all'inizio delle sezioni opzionali _corpo_ o _piè di pagina_, introduce una breaking API change (correlato al [`MAJOR`](http://semver.org/#summary) in un versionamento semver).
 Una _breaking change_ può essere parte di un commit di qualsiasi _tipo_.
 Es: I tipi `fix:`, `feat:` & `chore:` sono tutti validi.
 <br />
@@ -63,7 +63,7 @@ rimuovere errori tra progetti.
 
 Le parole “DEVE”, “NON DEVE”, “RICHIESTO”, “DOVRÀ”, “NON DOVRÀ”, “DOVREBBE”, “NON DOVREBBE”, “RACCOMANDATO”, “POTREBBE” e “OPZIONALE” devo essere interpretata come da specifica [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
 
-1. Un commit DEVE iniziare con un _tipo_, il quale consiste in un verbo, `feat`, `fix`, etc.,
+1. Un commit DEVE iniziare con un _tipo_, il quale consiste in un sostantivo, `feat`, `fix`, etc.,
    seguito dai due punti ed uno spazio.
 2. Il _tipo_ `feat` DEVE essere usato quando un commit aggiunge una funzionalità
    all'applicazione o libreria.
diff --git a/lang/it/spec/v1.0.0-beta.md b/lang/it/spec/v1.0.0-beta.md
index 89b9c08..a713fc6 100644
--- a/lang/it/spec/v1.0.0-beta.md
+++ b/lang/it/spec/v1.0.0-beta.md
@@ -29,7 +29,7 @@ l'intento al consumatore della libreria:
 
 1. **fix:** un commit di _tipo_ `fix` risolve un errore nel codice (correlato al [`PATCH`](http://semver.org/#summary) in un versionamento semver).
 2. **feat:**  un commit di _tipo_ `feat` introduce una nuova funzionalità al codice (correlato al [`MINOR`](http://semver.org/#summary) in un versionamento semver).
-3. **BREAKING CHANGE:** un commit che contiente il testo `BREAKING CHANGE:` all'inizio delle sezioni opzionali _corpo_ o _piè di pagina_, introduce una breaking API change (correlato al [`Major`](http://semver.org/#summary) in un versionamento semver).
+3. **BREAKING CHANGE:** un commit che contiente il testo `BREAKING CHANGE:` all'inizio delle sezioni opzionali _corpo_ o _piè di pagina_, introduce una breaking API change (correlato al [`MAJOR`](http://semver.org/#summary) in un versionamento semver).
 Una _breaking change_ può essere parte di entrambi i _tipi_ `fix:` w `feat:`.
 <br />
 Un _contesto_ potrebbe essere aggiunto al _tipo_ di commit, al fine di offrire ulteriori informazioni contestuali.
@@ -62,7 +62,7 @@ rimuovere errori tra progetti.
 
 Le parole “DEVE”, “NON DEVE”, “RICHIESTO”, “DOVRÀ”, “NON DOVRÀ”, “DOVREBBE”, “NON DOVREBBE”, “RACCOMANDATO”, “POTREBBE” e “OPZIONALE” devo essere interpretata come da specifica [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
 
-1. Un commit DEVE iniziare con un _tipo_, il quale consiste in un verbo, `feat`, `fix`, etc.,
+1. Un commit DEVE iniziare con un _tipo_, il quale consiste in un sostantivo, `feat`, `fix`, etc.,
    seguito dai due punti ed uno spazio.
 2. Il _tipo_ `feat` DEVE essere usato quando un commit aggiunge una funzionalità
    all'applicazione o libreria.
diff --git a/lang/pl/index.md b/lang/pl/index.md
index c8eb206..c5ee756 100644
--- a/lang/pl/index.md
+++ b/lang/pl/index.md
@@ -29,7 +29,7 @@ do użytkowników Twojej biblioteki:
 
 1. **fix:** dostarczenie _typu_ `fix` naprawia błąd obecny w Twoim kodzie (powiązane z [`PATCH`](http://semver.org/#summary) w wersjonowaniu semantycznym).
 2. **feat:** dostarczenie _typu_ `feat` wprowadza nowe funkcje do Twojej biblioteki (powiązane z [`MINOR`](http://semver.org/#summary) w wersjonowaniu semantycznym).
-3. **BREAKING CHANGE:** dostarczenie, które posiada tekst `BREAKING CHANGE:` na początku jego opcjonalnego ciała bądź stopki wprowadza zmianę łamiącą kompatybilność API (powiązane z [`Major`](http://semver.org/#summary) w wersjonowaniu semantycznym). Zmiana łamiąca kompatybilność wsteczną może być elementem zmian każdego innego _typu_, np. `fix:`, `feat:` & `chore:` - wszystkie byłyby poprawne, w dodatku do każdego innego _typu_.
+3. **BREAKING CHANGE:** dostarczenie, które posiada tekst `BREAKING CHANGE:` na początku jego opcjonalnego ciała bądź stopki wprowadza zmianę łamiącą kompatybilność API (powiązane z [`MAJOR`](http://semver.org/#summary) w wersjonowaniu semantycznym). Zmiana łamiąca kompatybilność wsteczną może być elementem zmian każdego innego _typu_, np. `fix:`, `feat:` & `chore:` - wszystkie byłyby poprawne, w dodatku do każdego innego _typu_.
 
 <br />
 Przy typie dostarczenia może zostać podany zakres w celu dostarczenia dokładniejszej informacji o kontekście dostarczenia.
diff --git a/lang/pl/spec/v1.0.0-beta.1.md b/lang/pl/spec/v1.0.0-beta.1.md
index c8eb206..c5ee756 100644
--- a/lang/pl/spec/v1.0.0-beta.1.md
+++ b/lang/pl/spec/v1.0.0-beta.1.md
@@ -29,7 +29,7 @@ do użytkowników Twojej biblioteki:
 
 1. **fix:** dostarczenie _typu_ `fix` naprawia błąd obecny w Twoim kodzie (powiązane z [`PATCH`](http://semver.org/#summary) w wersjonowaniu semantycznym).
 2. **feat:** dostarczenie _typu_ `feat` wprowadza nowe funkcje do Twojej biblioteki (powiązane z [`MINOR`](http://semver.org/#summary) w wersjonowaniu semantycznym).
-3. **BREAKING CHANGE:** dostarczenie, które posiada tekst `BREAKING CHANGE:` na początku jego opcjonalnego ciała bądź stopki wprowadza zmianę łamiącą kompatybilność API (powiązane z [`Major`](http://semver.org/#summary) w wersjonowaniu semantycznym). Zmiana łamiąca kompatybilność wsteczną może być elementem zmian każdego innego _typu_, np. `fix:`, `feat:` & `chore:` - wszystkie byłyby poprawne, w dodatku do każdego innego _typu_.
+3. **BREAKING CHANGE:** dostarczenie, które posiada tekst `BREAKING CHANGE:` na początku jego opcjonalnego ciała bądź stopki wprowadza zmianę łamiącą kompatybilność API (powiązane z [`MAJOR`](http://semver.org/#summary) w wersjonowaniu semantycznym). Zmiana łamiąca kompatybilność wsteczną może być elementem zmian każdego innego _typu_, np. `fix:`, `feat:` & `chore:` - wszystkie byłyby poprawne, w dodatku do każdego innego _typu_.
 
 <br />
 Przy typie dostarczenia może zostać podany zakres w celu dostarczenia dokładniejszej informacji o kontekście dostarczenia.
diff --git a/lang/pl/spec/v1.0.0-beta.md b/lang/pl/spec/v1.0.0-beta.md
index 14e40e7..8878777 100644
--- a/lang/pl/spec/v1.0.0-beta.md
+++ b/lang/pl/spec/v1.0.0-beta.md
@@ -29,7 +29,7 @@ do użytkowników Twojej biblioteki:
 
 1. **fix:** dostarczenie _typu_ `fix` naprawia błąd obecny w Twoim kodzie (powiązane z [`PATCH`](http://semver.org/#summary) w wersjonowaniu semantycznym).
 2. **feat:** dostarczenie _typu_ `feat` wprowadza nowe funkcje do Twojej biblioteki (powiązane z [`MINOR`](http://semver.org/#summary) w wersjonowaniu semantycznym).
-3. **BREAKING CHANGE:** dostarczenie, które posiada tekst `BREAKING CHANGE:` na początku jego opcjonalnego ciała bądź stopki wprowadza zmianę łamiącą kompatybilność API (powiązane z [`Major`](http://semver.org/#summary) w wersjonowaniu semantycznym). Zmiana łamiąca kompatybilność wsteczną może być elementem zmian  _typu_, `fix:` lub `feat:`.
+3. **BREAKING CHANGE:** dostarczenie, które posiada tekst `BREAKING CHANGE:` na początku jego opcjonalnego ciała bądź stopki wprowadza zmianę łamiącą kompatybilność API (powiązane z [`MAJOR`](http://semver.org/#summary) w wersjonowaniu semantycznym). Zmiana łamiąca kompatybilność wsteczną może być elementem zmian  _typu_, `fix:` lub `feat:`.
 <br />
 Przy typie dostarczenia może zostać podany zakres w celu dostarczenia dokładniejszej informacji o kontekście dostarczenia.
 Zawiera się on w nawiasach następujących bezpośrednio po typie, np. `feat(parser): dodano możliwość parsowania list`.
diff --git a/lang/zh-Hans/index.md b/lang/zh-Hans/index.md
index 40e3e3d..30e66af 100644
--- a/lang/zh-Hans/index.md
+++ b/lang/zh-Hans/index.md
@@ -31,7 +31,7 @@ language: zh-Hans
 4. 其它在 `fix:` 和 `feat:` 之外的提交 _类型_ 也都是支持的，例如 [Angular 约定](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit) 中推荐使用 `docs:`、`style:`、`refactor:`、`perf:`、`test:`、`chore:`，但这些标签在约定式提交规范中并不是强制性的。
 
 <br />
-可以为提交类型添加一个围在圆括号内的作用域，以为其提供额外的上下文信息。例如，`feat(parser): add ability to parse arrays`。
+可以为提交类型添加一个围在圆括号内的作用域，以为其提供额外的上下文信息。例如 `feat(parser): add ability to parse arrays.`
 
 ## 介绍
 
@@ -45,13 +45,13 @@ language: zh-Hans
 
 ## 约定式提交规范
 
-本文档中的关键词 “必须”，“禁止”，“需要”，“应当”，“不应当”，“应该”，“不应该”，“推荐”，“可以” 和 “可选” 应按照 [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) 的描述解释。
+本文档中的关键词 “必须”、“禁止”、“需要”、“应当”、“不应当”、“应该”、“不应该”、“推荐”、“可以” 和 “可选” 应按照 [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) 的描述解释。
 
-1. 每个提交都**必须**使用类型字段前缀，这由一个形如 `feat` 或 `fix` 的动词组成，其后接冒号和空格。
+1. 每个提交都**必须**使用类型字段前缀，这由一个形如 `feat` 或 `fix` 的名词组成，其后接冒号和空格。
 2. 当一个提交为应用或类库实现了新特性时，**必须**使用 `feat` 类型。
 3. 当一个提交为应用修复了 bug 时，**必须**使用 `fix` 类型。
 4. 可选的作用域字段**可以**在类型后提供。作用域是描述代码库中某个部分的词组，封装在括号中，形如 `fix(parser):` 等。
-5. 描述字段**必须**紧接在类型或作用域前缀之后。描述指的是对 pull request 的简短描述，形如：_fix: array parsing issue when multiple spaces were contained in string._
+5. 描述字段**必须**紧接在类型或作用域前缀之后。描述指的是对 pull request 的简短描述，形如 _fix: array parsing issue when multiple spaces were contained in string._
 6. 在简短描述之后，**可以**编写更长的提交正文。正文**必须**起始于描述字段结束的一个空行后。
 7. 在正文结束的一个空行后，**可以**编写页脚。页脚**应当**包含额外的元信息（例如它所修复的 issue，类似 `fixse #13, #5` 等）。
 8. 破坏性变更**必须**在提交的正文或脚注加以展示。一个破坏性变更**必须**包含大写的文本 `BREAKING CHANGE`，紧跟冒号和空格。
diff --git a/lang/zh-Hans/spec/v1.0.0-beta.1.md b/lang/zh-Hans/spec/v1.0.0-beta.1.md
index 40e3e3d..30e66af 100644
--- a/lang/zh-Hans/spec/v1.0.0-beta.1.md
+++ b/lang/zh-Hans/spec/v1.0.0-beta.1.md
@@ -31,7 +31,7 @@ language: zh-Hans
 4. 其它在 `fix:` 和 `feat:` 之外的提交 _类型_ 也都是支持的，例如 [Angular 约定](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit) 中推荐使用 `docs:`、`style:`、`refactor:`、`perf:`、`test:`、`chore:`，但这些标签在约定式提交规范中并不是强制性的。
 
 <br />
-可以为提交类型添加一个围在圆括号内的作用域，以为其提供额外的上下文信息。例如，`feat(parser): add ability to parse arrays`。
+可以为提交类型添加一个围在圆括号内的作用域，以为其提供额外的上下文信息。例如 `feat(parser): add ability to parse arrays.`
 
 ## 介绍
 
@@ -45,13 +45,13 @@ language: zh-Hans
 
 ## 约定式提交规范
 
-本文档中的关键词 “必须”，“禁止”，“需要”，“应当”，“不应当”，“应该”，“不应该”，“推荐”，“可以” 和 “可选” 应按照 [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) 的描述解释。
+本文档中的关键词 “必须”、“禁止”、“需要”、“应当”、“不应当”、“应该”、“不应该”、“推荐”、“可以” 和 “可选” 应按照 [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) 的描述解释。
 
-1. 每个提交都**必须**使用类型字段前缀，这由一个形如 `feat` 或 `fix` 的动词组成，其后接冒号和空格。
+1. 每个提交都**必须**使用类型字段前缀，这由一个形如 `feat` 或 `fix` 的名词组成，其后接冒号和空格。
 2. 当一个提交为应用或类库实现了新特性时，**必须**使用 `feat` 类型。
 3. 当一个提交为应用修复了 bug 时，**必须**使用 `fix` 类型。
 4. 可选的作用域字段**可以**在类型后提供。作用域是描述代码库中某个部分的词组，封装在括号中，形如 `fix(parser):` 等。
-5. 描述字段**必须**紧接在类型或作用域前缀之后。描述指的是对 pull request 的简短描述，形如：_fix: array parsing issue when multiple spaces were contained in string._
+5. 描述字段**必须**紧接在类型或作用域前缀之后。描述指的是对 pull request 的简短描述，形如 _fix: array parsing issue when multiple spaces were contained in string._
 6. 在简短描述之后，**可以**编写更长的提交正文。正文**必须**起始于描述字段结束的一个空行后。
 7. 在正文结束的一个空行后，**可以**编写页脚。页脚**应当**包含额外的元信息（例如它所修复的 issue，类似 `fixse #13, #5` 等）。
 8. 破坏性变更**必须**在提交的正文或脚注加以展示。一个破坏性变更**必须**包含大写的文本 `BREAKING CHANGE`，紧跟冒号和空格。
diff --git a/lang/zh-Hans/spec/v1.0.0-beta.md b/lang/zh-Hans/spec/v1.0.0-beta.md
index 5e61fec..291c083 100644
--- a/lang/zh-Hans/spec/v1.0.0-beta.md
+++ b/lang/zh-Hans/spec/v1.0.0-beta.md
@@ -31,7 +31,7 @@ language: zh-Hans
 4. 其它在 `fix:` 和 `feat:` 之外的提交 _类型_ 也都是支持的，例如 [Angular 约定](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit) 中推荐使用 `docs:`、`style:`、`refactor:`、`perf:`、`test:`、`chore:`，但这些标签在约定式提交规范中并不是强制性的。
 
 <br />
-可以为提交类型添加一个围在圆括号内的作用域，以为其提供额外的上下文信息。例如，`feat(parser): add ability to parse arrays`。
+可以为提交类型添加一个围在圆括号内的作用域，以为其提供额外的上下文信息。例如 `feat(parser): add ability to parse arrays.`
 
 ## 介绍
 
@@ -45,13 +45,13 @@ language: zh-Hans
 
 ## 约定式提交规范
 
-本文档中的关键词 “必须”，“禁止”，“需要”，“应当”，“不应当”，“应该”，“不应该”，“推荐”，“可以” 和 “可选” 应按照 [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) 的描述解释。
+本文档中的关键词 “必须”、“禁止”、“需要”、“应当”、“不应当”、“应该”、“不应该”、“推荐”、“可以” 和 “可选” 应按照 [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) 的描述解释。
 
-1. 每个提交都**必须**使用类型字段前缀，这由一个形如 `feat` 或 `fix` 的动词组成，其后接冒号和空格。
+1. 每个提交都**必须**使用类型字段前缀，这由一个形如 `feat` 或 `fix` 的名词组成，其后接冒号和空格。
 2. 当一个提交为应用或类库实现了新特性时，**必须**使用 `feat` 类型。
 3. 当一个提交为应用修复了 bug 时，**必须**使用 `fix` 类型。
 4. 可选的作用域字段**可以**在类型后提供。作用域是描述代码库中某个部分的词组，封装在括号中，形如 `fix(parser):` 等。
-5. 描述字段**必须**紧接在类型或作用域前缀之后。描述指的是对 pull request 的简短描述，形如：_fix: array parsing issue when multiple spaces were contained in string._
+5. 描述字段**必须**紧接在类型或作用域前缀之后。描述指的是对 pull request 的简短描述，形如 _fix: array parsing issue when multiple spaces were contained in string._
 6. 在简短描述之后，**可以**编写更长的提交正文。正文**必须**起始于描述字段结束的一个空行后。
 7. 在正文结束的一个空行后，**可以**编写页脚。页脚**应当**包含额外的元信息（例如它所修复的 issue，类似 `fixse #13, #5` 等）。
 8. 破坏性变更**必须**在提交的正文或脚注加以展示。一个破坏性变更**必须**包含大写的文本 `BREAKING CHANGE`，紧跟冒号和空格。
diff --git a/spec/v1.0.0-beta.1.md b/spec/v1.0.0-beta.1.md
index a8baae5..d4ef927 100644
--- a/spec/v1.0.0-beta.1.md
+++ b/spec/v1.0.0-beta.1.md
@@ -30,7 +30,7 @@ consumers of your library:
 1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with [`PATCH`](http://semver.org/#summary) in semantic versioning).
 2. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates
   with [`MINOR`](http://semver.org/#summary) in semantic versioning).
-3. **BREAKING CHANGE:** a commit that has the text `BREAKING CHANGE:` at the beginning of its optional body or footer section introduces a breaking API change (correlating with [`Major`](http://semver.org/#summary) in semantic versioning). A breaking change can be
+3. **BREAKING CHANGE:** a commit that has the text `BREAKING CHANGE:` at the beginning of its optional body or footer section introduces a breaking API change (correlating with [`MAJOR`](http://semver.org/#summary) in semantic versioning). A breaking change can be
   part of commits of any _type_. e.g., a `fix:`, `feat:` & `chore:` types would all be valid, in addition to any other _type_.
 
 <br />
@@ -64,7 +64,7 @@ debug issues across project boundaries.
 
 The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
 
-1. commits MUST be prefixed with a type, which consists of a verb, `feat`, `fix`, etc.,
+1. commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc.,
    followed by a colon and a space.
 2. the type `feat` MUST be used when a commit adds a new feature to your application
   or library.
diff --git a/spec/v1.0.0-beta.md b/spec/v1.0.0-beta.md
index 38f4530..1e6bf21 100644
--- a/spec/v1.0.0-beta.md
+++ b/spec/v1.0.0-beta.md
@@ -29,7 +29,7 @@ consumers of your library:
 1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with [`PATCH`](http://semver.org/#summary) in semantic versioning).
 2. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates
   with [`MINOR`](http://semver.org/#summary) in semantic versioning).
-3. **BREAKING CHANGE:** a commit that has the text `BREAKING CHANGE:` at the beginning of its optional body or footer section introduces a breaking API change (correlating with [`Major`](http://semver.org/#summary) in semantic versioning). A breaking change can be
+3. **BREAKING CHANGE:** a commit that has the text `BREAKING CHANGE:` at the beginning of its optional body or footer section introduces a breaking API change (correlating with [`MAJOR`](http://semver.org/#summary) in semantic versioning). A breaking change can be
   part of either a `fix:` or `feat:` _type_ commit.
 
 <br />
@@ -63,7 +63,7 @@ debug issues across project boundaries.
 
 The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
 
-1. commits MUST be prefixed with a type, which consists of a verb, `feat`, `fix`, etc.,
+1. commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc.,
    followed by a colon and a space.
 2. the type `feat` MUST be used when a commit adds a new feature to your application
   or library.