chore: Add principles for English titles and change all English titles (

#3444)

Due to there're too many typo errors in the English titles when translating, we have to force some principles and update them all together.

CONTRIBUTING.md

@@ -132,7 +132,20 @@ BREAKING CHANGE:
 
 Look at [these files](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit) for more details.
 
-## Release
+### Principles of English Translations
+
+We follow the normal principles of English articles when translating, however, due to there're some special principles of titles, we should follow these rules:
+
+- For nouns, verbs, pronouns, adjectives and adverbs, capitalize the first character. For prepsitions, articles, conjections, interjections and auxiliary words, the first character should be in lowercase. **the character of the first word and the last word for title should be capitalized, regardless of what it is**.
+- For proper nouns such as the direct reference of a variable or the name of a plugin, we must use backtick (underneath the 'Esc') to surround them and keep what they are in origin.
+- For prepsitions more than 5 characters, their first characters should be also capitalized, otherwise not.
+- For some very important titles or some fixed proper nouns such as methods of Http: POST,GET,PUT,DELETE, every charater can be capitalized (USE WITH CAUTION).
+- If the article belongs to the form of O-V (Object-Verb) such as "Config Management", we'd better translate it as "Management Configuration", or "Managing Configuration" in the form of "gerund+noun".
+- If your title is taken as a sentence, write in 'Sentence Case' (e.g: In FAQ, each title is actually an English sentence).
+
+For more info, please refer [English Title Case].
+
+## Release Management
 
 Egg uses semantic versioning in release process based on [semver].
 
@@ -185,3 +198,4 @@ All tags mentioned above means the tags of npm in `package.json`.
 [1.x milestone]: https:/eggjs/egg/milestone/1
 [npm]: http://npmjs.com/
 [How to deploy an npm package]: https://fengmk2.com/blog/2016/how-i-publish-a-npm-package
+[English Title Case]: https://headlinecapitalization.com/

CONTRIBUTING.zh-CN.md

@@ -136,6 +136,19 @@ BREAKING CHANGE:
 
 详情请查看具体[文档](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit)。
 
+### 英语翻译规范
+
+英语正文按照一般英语语法规律书写即可，但标题比较特殊，应该按照以下规范进行书写：
+
+- 名词、动词、代词、形容词、副词等首字母大写，介词、冠词、连词、感叹词和助词首字母小写，*标题第一个单词、最后一个单词无论词性首字母应该大写*。
+- 专有名词（如直接引用某个变量，或者某个插件名称等），必须使用反单引号（键盘上 Esc 正下方）进行引用，并保持原来大小写。
+- 超过5个字母的介词首字母应该大写，否则一律小写。
+- 如果是重要提示性标题，或者是专有名称标题（例如 Http 请求方法：GET，POST，PUT，DELETE），可以全部字母都用大写（慎重考虑）。
+- 如果标题属于“动宾”性质的短语（如“配置管理”），尽量翻译成“宾+动词名词”的形式（Configuration Management），或者是“动名词+宾语”的形式（Managing Configuration）。
+- 如果标题被当做一个完整的英语句子，请按照英语句子的语法格式大小写（如：常见问题 FAQ 中每一个标题都是一个英语句子）。
+
+有关详情，可以参考[英语标题大小写]。
+
 ## 发布管理
 
 egg 基于 [semver] 语义化版本号进行发布。
@@ -189,3 +202,4 @@ egg 基于 [semver] 语义化版本号进行发布。
 [1.x milestone]: https:/eggjs/egg/milestone/1
 [npm]: http://npmjs.com/
 [我是如何发布一个 npm 包的]: https://fengmk2.com/blog/2016/how-i-publish-a-npm-package
+[英语标题大小写]: https://headlinecapitalization.com/

docs/source/en/advanced/cluster-client.md

@@ -22,7 +22,7 @@ In addition, it's relatively inefficient to transmit data via messenger, since m
 
 So is there any better way? The answer is: YES! We provide a new type of model to reduce the complexity of this type of client encapsulation. The new Model bypasses the Master by establishing a direct socket between Agent and Worker. And as an external interface, Agent maintains shared connection among multiple Worker processes.
 
-## core idea
+## Core Idea
 
 - Inspired by the [Leader/Follower](http://www.cs.wustl.edu/~schmidt/PDF/lf.pdf) model.
 - The client is divided into two roles: 
@@ -56,7 +56,7 @@ win / +------------------+ \ lose
 +--------+ +-------------------+
 ```
 
-## Client interface type abstraction
+## Client Interface Type Abstraction
 
 We abstract the client interface into the following two broad categories, which is also a specification of the client interface. For clients that are in line with norms, we can automatically wrap it as Leader / Follower mode.
 
@@ -108,12 +108,12 @@ class Client extends Base {
 }
 ```
 
-## exception handling
+## Exception Handling
 
 - If Leader "dies", a new round of port contention will be triggered. The instance which seizes the port will be elected as the new Leader.
 - To ensure that the channel between Leader and Follower is healthy, heartbeat mechanism needs to be introduced. If the Follower does not send a heartbeat packet within a fixed time, the Leader will proactively disconnect from the Follower, which will trigger the reinitialization of Follower.
 
-## protocol and time series to invoke
+## Protocol and Time Series to Invoke
 
 Leader and Follower exchange data via the following protocols:
 
@@ -159,7 +159,7 @@ Leader and Follower exchange data via the following protocols:
  | |
 ```
 
-## specific use
+## Specific Usage
 
 In the following I will use a simple example to introduce how to make a client support Leader / Follower mode in the framework.
 
@@ -494,7 +494,7 @@ in conclusion:
 
 Students who are interested may have look at [enhanced multi-process development model](https:/eggjs/egg/issues/322) discussion process.
 
-## the configuration items related to cluster-client in the framework 
+## The Configuration Items Related to Cluster-Client in the Framework 
 
 ```js
 /**

docs/source/en/advanced/loader.md

@@ -89,7 +89,7 @@ From the scene above we can see the relationship of application, plugin and fram
 +-----------------------------------+--------+
 ```
 
-## loadUnit
+## LoadUnit
 
 Egg regards application, framework and plugin as loadUnit, because they are similar in code structure, here is the directory structure:
 
@@ -164,7 +164,7 @@ The plugin1 is framework1's dependent plugin, the object key order of plugin1 af
 
 See [Loader.getLoadUnits](https:/eggjs/egg-core/blob/65ea778a4f2156a9cebd3951dac12c4f9455e636/lib/loader/egg_loader.js#L233) method for details.
 
-### File order
+### File Order
 
 The files that will be loaded by default are listed above. Egg will load files by the following order, each file or directory will be loaded according to loadUnit order (application, framework and plugin are different):
 
@@ -250,23 +250,23 @@ If you need to modify the expiring time, please see [this document](https://gith
 
 Deprecated methods:
 
-## beforeStart
+## `beforeStart`
 
 `beforeStart` is called during the loading process, all of its methods are running in parallel. So we usually execute some asynchronized methods (e.g: Check the state of connection, in [`egg-mysql`](https:/eggjs/egg-mysql/blob/master/lib/mysql.js) we use this method to check the connection state with mysql). When all the tasks in `beforeStart` finished, the state will be `ready`. It's NOT recommended to excute a function that consumes too much time there, which will cause the expiration of application's start.plugin developers should use `didLoad` instead, for application developers, `willReady` is the replacer.
 
-## ready
+## `ready`
 
 All the methods mounted on `ready` will be executed when load ends, and after all the methods in `beforeStart` have finished executing. By the time Http server's listening also starts. This means all the plugins are fully loaded and everything is ready, So we use it to process some tasks after start. For developers now, we use `didReady` instead.
 
-## beforeClose
+## `beforeClose`
 
 All the methods mounted on `beforeClose` are called in an inverted order after `close` method in app/agent instance is called. E.g: in [`egg`](https:/eggjs/egg/blob/master/lib/egg.js), we close logger, remove listening methods ...,ect.Developers SHOULDN'T use `app.beforeClose` directly now, but in the form of class to implement `beforeClose` instead.
 
 __We don't recommend to use this function in a PROD env, because the process may end before it finishes.__
 
 What's more, we can use [`egg-development`](https:/eggjs/egg-development#loader-trace) to see the loading process.
 
-### Loading File rules
+### File-Loading Rules
 
 The framework will convert file names when loading files, because there is a difference between the file naming style and the API style. We recommend that files use underscores, while APIs use lower camel case. For examplem `app/service/user_info.js` will be converted to `app.service.userInfo`.
 
@@ -348,7 +348,7 @@ The mention above is just a description of the Loader wording, please see [Frame
 
 Loader also supports some low level APIs to simplify code when extending, [here](https:/eggjs/egg-core#eggloader) are all APIs.
 
-### loadFile
+### `loadFile`
 
 Used to load a file, such as loading `app/xx.js`:
 
@@ -368,7 +368,7 @@ module.exports = app => {
 
 If the file exports a function, then the function will be called with `app` as its parameter, otherwise uses this value directly.
 
-### loadToApp
+### `loadToApp`
 
 Used to load files from a directory into the app, such as `app/controller/home.js` to `app.controller.home`.
 
@@ -387,7 +387,7 @@ The method has three parameters `loadToApp(directory, property, LoaderOptions)`:
 2. Property is app's property.
 3. [LoaderOptions](#LoaderOptions) are some configurations.
 
-### loadToContext
+### `loadToContext`
 
 The difference between loadToApp and loadToContext is that loadToContext loads files into ctx instead of app, and it's a lazy loading. It puts files into a temp object when loading, and instantiates objects when calling ctx APIs.
 
@@ -420,7 +420,7 @@ So this class will only be instantiated when first calling, and will be cached a
 
 ### LoaderOptions
 
-#### ignore [String]
+#### `ignore [String]`
 
 `ignore` could ignore some files, supports glob, the default is empty.
 
@@ -431,7 +431,7 @@ app.loader.loadToApp(directory, 'controller', {
 });
 ```
 
-#### initializer [Function]
+#### `initializer [Function]`
 
 Processing each file exported values, the default is empty.
 
@@ -452,7 +452,7 @@ app.loader.loadToApp(directory, 'model', {
 });
 ```
 
-#### caseStyle [String]
+#### `caseStyle [String]`
 
 File conversion rules, could be `camel`, `upper`, `lower`, the default is `camel`.
 
@@ -470,7 +470,7 @@ app/controller | lower
 app/middleware | lower
 app/service | lower
 
-#### override [Boolean]
+#### `override [Boolean]`
 
 Overriding or throwing exception when encounter existing files, the default is false.
 
@@ -484,7 +484,7 @@ app/controller | true
 app/middleware | false
 app/service | false
 
-#### call [Boolean]
+#### `call [Boolean]`
 
 Calling when export's object is function, and get the return value, the default is true
 

docs/source/en/advanced/plugin.md

@@ -129,11 +129,11 @@ The `dependencies` and `optionalDependencies` are learnt from `npm`, most time w
 
 Attention: if you are using `optionalDependencies`, framework won't verify the activation of these dependencies, they are only for sorting loading orders. In such situation, the plugin will go through other ways such as `interface detection` to decide processing logic.
 
-## What can plugin do?
+## What can Plugin Do?
 
 We've discussed what plugin is. Now what can it do?
 
-### Built-in Objects API Extension
+### Built-in Objects API Extensions
 
 Extend the built-in objects of the framework, just like the application
 
@@ -181,7 +181,7 @@ Extend the built-in objects of the framework, just like the application
  };
  ```
 
-### Initialization on application starting
+### Initialization on Application Starting
 
 - If you want to read some local config before startup:
 
@@ -394,7 +394,7 @@ As you can see, all we need to do for this plugin is passing the fields that nee
  }
  ```
 
-##### Dynamically Instantiate
+##### Dynamically Instantiating
 
 Instead of declaring the configuration in the configuration file in advance, we can dynamically initialize an instance at the runtime of the application.
 
@@ -468,7 +468,7 @@ It's well welcomed to your contributions to the new plugins, but also hope you f
  }
  ```
 
-## Why do not use the npm package name as the plugin name?
+## Why Do Not Use the `npm` Package Name as the Plugin Name?
 
 Egg defines the plugin name through the `eggPlugin.name`, it is only unique in application or framework, that means **many npm packages might get the same plugin name**, why design in this way?
 

docs/source/en/advanced/view-plugin.md

@@ -5,7 +5,7 @@ In most cases, we need to read the data, render the template and then present it
 
 This article describes the framework's specification constraints on the View plugin, and we can use this to encapsulate the corresponding template engine plugin. The following takes [egg-view-ejs] as an example.
 
-## Plugin directory structure
+## Plugin Directory Structure
 
 ```bash
 egg-view-ejs
@@ -21,7 +21,7 @@ egg-view-ejs
 └── package.json
 ```
 
-## Plugin naming convention
+## Plugin Naming Convention
 
 * Follow the [plugin development specification](./plugin.md)
 * According to the convention, the names of plugins start with `egg-view-`
@@ -46,7 +46,7 @@ module.exports = {
 };
 ```
 
-## View base class
+## View Base Class
 
 The next step is to provide a View base class that will be instantiated on each request.
 
@@ -96,7 +96,7 @@ The three parameters of the `renderString` method:
 * locals: same with `render`.
 * viewOptions: same with `render`.
 
-## Plugin configuration
+## Plugin Configuration
 
 According to the naming conventions mentioned above, the configuration name is generally the name of the template engine, such as ejs.
 
@@ -173,7 +173,7 @@ First declare a dependency on [egg-security]:
 
 Besides, the framework provides [app.injectCsrf](../core/security.md#appinjectcsrfstr) and [app.injectNonce](../core/security.md#appinjectnonncestr), for more information on [security section](../core/security.md).
 
-### Unit tests
+### Unit Tests
 
 As a high-quality plugin, perfect unit testing is indispensable, and we also provide lots of auxiliary tools to make it painless for plugin developers to write tests with, see [unit testing](../core/unittest.md) and [plugin](./plugin.md) docs.
 

docs/source/en/basics/config.md

@@ -10,7 +10,7 @@ Here are some common control tactics:
 
 we choose the last strategy, namely **configure with code**, The change of configuration should be also released after reviewing. The application package itself is capable to be deployed in several environments, only need to specify the running environment.
 
-### Multiple environment configuration
+### Multiple Environment Configuration
 
 This framework supports loading configuration according to the environment and defining configuration files of multiple environments. For more details, please check [env](../basics/env.md).
 
@@ -25,7 +25,7 @@ config
 
 The corresponding configuration file will be loaded simultaneously when you set up env and the default configuration with the same name will be overwritten. For example, `prod` environment will load `config.prod.js` and `config.default.js`. As a result, `config.prod.js` will overwrite the configuration with identical name in `config.default.js`.
 
-### How to write configuration
+### How to Write Configuration
 
 The configuration file returns an object which could overwrite some configurations in the framework. Application can put its own business configuration into it for convenient management.
 
@@ -84,7 +84,7 @@ module.exports = appInfo => {
 };
 ```
 
-### Sequence of loading configurations
+### Sequence of Loading Configurations
 
 Applications, plugin components and framework are able to define those configs. Even though the structure of catalog is identical but there is priority (application > framework > plugin). Besides, the running environment has the higher priority.
 
@@ -99,7 +99,7 @@ Here is one sequence of loading configurations under "prod" environment, in whic
 
 **Note: there will be plugin loading sequence, but the approximate order is similar. For specific logic, please check the [loader](../advanced/loader.md) .**
 
-### Merging rule
+### Rules of Merging
 
 Configs are merged using deep copy from [extend2] module, which is forked from [extend] and process array in a different way.
 
@@ -115,7 +115,7 @@ extend(true, a, b);
 ```
 As demonstrated above, the framework will overwrite arrays instead of merging them.
 
-### Configuration result
+### Configuration Result
 
 The final merged config will be dumped to `run/application_config.json`(for worker process) and `run/agent_config.json`(for agent process) when the framework started, which can help analyzing problems.