Update english documentation - 2 (#608)

* Updates english documentation

* updates english documentation

README.md

@@ -12,7 +12,7 @@
 
 CAP is a library based on .Net standard, which is a solution to deal with distributed transactions, has the function of EventBus, it is lightweight, easy to use, and efficient.
 
-In the process of building an SOA or MicroService system, we usually need to use the event to integrate each service. In the process, the simple use of message queue does not guarantee the reliability. CAP adopts local message table program integrated with the current database to solve exceptions that may occur in the process of the distributed system calling each other. It can ensure that the event messages are not lost in any case.
+In the process of building an SOA or MicroService system, we usually need to use the event to integrate each service. In the process, simple use of message queue does not guarantee reliability. CAP adopts local message table program integrated with the current database to solve exceptions that may occur in the process of the distributed system calling each other. It can ensure that the event messages are not lost in any case.
 
 You can also use CAP as an EventBus. CAP provides a simpler way to implement event publishing and subscriptions. You do not need to inherit or implement any interface during subscription and sending process.
 
@@ -26,7 +26,7 @@ You can also use CAP as an EventBus. CAP provides a simpler way to implement eve
 
 ### NuGet
 
-You can run the following command to install CAP in your project.
+CAP can be installed in your project with the following command.
 
 ```
 PM> Install-Package DotNetCore.CAP
@@ -53,7 +53,7 @@ PM> Install-Package DotNetCore.CAP.MongoDB     //need MongoDB 4.0+ cluster
 
 ### Configuration
 
-First, you need to config CAP in your Startup.cs：
+First, you need to configure CAP in your Startup.cs：
 
 ```cs
 public void ConfigureServices(IServiceCollection services)
@@ -87,7 +87,7 @@ public void ConfigureServices(IServiceCollection services)
 
 ### Publish
 
-Inject `ICapPublisher` in your Controller, then use the `ICapPublisher` to send message
+Inject `ICapPublisher` in your Controller, then use the `ICapPublisher` to send messages
 
 ```c#
 public class PublishController : Controller
@@ -135,7 +135,7 @@ public class PublishController : Controller
 
 **In Controller Action**
 
-Add the Attribute `[CapSubscribe()]` on Action to subscribe message:
+Add the Attribute `[CapSubscribe()]` on Action to subscribe to messages:
 
 ```c#
 public class PublishController : Controller
@@ -212,7 +212,7 @@ public void ShowTime2(DateTime datetime)
 ```
 `ShowTime1` and `ShowTime2` will be called at the same time.
 
-BTW, You can specify the default group name in the configuration :
+BTW, You can specify the default group name in the configuration:
 
 ```C#
 services.AddCap(x =>
@@ -224,13 +224,13 @@ services.AddCap(x =>
 
 ### Dashboard
 
-CAP v2.1+ provides dashboard pages, you can easily view message that were sent and received. In addition, you can also view the  message status in real time in the dashboard. Use the following command to install the Dashboard in your project.
+CAP v2.1+ provides dashboard pages, you can easily view messages that were sent and received. In addition, you can also view the message status in real time in the dashboard. Use the following command to install the Dashboard in your project.
 
 ```
 PM> Install-Package DotNetCore.CAP.Dashboard
 ```
 
-In the distributed environment, the dashboard built-in integrated [Consul](http://consul.io) as a node discovery, while the realization of the gateway agent function, you can also easily view the node or other node data, It's like you are visiting local resources.
+In the distributed environment, the dashboard built-in integrates [Consul](http://consul.io) as a node discovery, while the realization of the gateway agent function, you can also easily view the node or other node data, It's like you are visiting local resources.
 
 ```c#
 services.AddCap(x =>

docs/content/index.md

@@ -14,7 +14,7 @@ CAP is a library based on .net standard, which is a solution to deal with distri
 
 ## Introduction
 
-In the process of building an SOA or MicroService system, we usually need to use the event to integrate each service. In the process, the simple use of message queue does not guarantee the reliability. CAP adopts local message table program integrated with the current database to solve exceptions that may occur in the process of the distributed system calling each other. It can ensure that the event messages are not lost in any case.
+In the process of building an SOA or MicroService system, we usually need to use the event to integrate each service. In the process, simple use of message queue does not guarantee reliability. CAP adopts local message table program integrated with the current database to solve exceptions that may occur in the process of the distributed system calling each other. It can ensure that the event messages are not lost in any case.
 
 You can also use CAP as an EventBus. CAP provides a simpler way to implement event publishing and subscriptions. You do not need to inherit or implement any interface during subscription and sending process.
 

docs/content/user-guide/en/cap/configuration.md

@@ -49,13 +49,13 @@ The default consumer group name, corresponds to different names in different Tra
 This is a new configuration option introduced in the CAP v2.4 version. It is used to specify a version of a message to isolate messages of different versions of the service. It is often used in A/B testing or multi-service version scenarios. Following are application scenarios that needs versioning:
 
 !!! info "Business Iterative and compatible"
-    Due to the rapid iteration of services, the data structure of the message is not fixed during each service integration process. Sometimes we add or modify certain data structures to accommodate the newly introduced requirements. If you have a brand new system, there's no problem, but if your system is already deployed to a production environment and serves customers, this will cause new features to be incompatible with the old data structure when they go online, and then these changes can cause serious problems. To work around this issue, you can only clean up message queues and persistent messages before starting the application, which is obviously fatal for production environments.
+    Due to the rapid iteration of services, the data structure of the message is not fixed during each service integration process. Sometimes we add or modify certain data structures to accommodate the newly introduced requirements. If you have a brand new system, there's no problem, but if your system is already deployed to a production environment and serves customers, this will cause new features to be incompatible with the old data structure when they go online, and then these changes can cause serious problems. To work around this issue, you can only clean up message queues and persistent messages before starting the application, which is obviously not acceptable for production environments.
 
 !!! info "Multiple versions of the server"
     Sometimes, the server's server needs to provide multiple sets of interfaces to support different versions of the app. Data structures of the same interface and server interaction of these different versions of the app may be different, so usually server does not provide the same routing addresses to adapt to different versions of App calls.
 
 !!! info "Using the same persistent table/collection in different instance"
-    If you want multiple different instance services to use the same database, in versions prior to 2.4, we could isolate database tables for different instances by specifying different table names. That is to say, when configuring the CAP, it is implemented by configuring different table name prefixes.
+    If you want multiple different instance services to use the same database, in versions prior to 2.4, we could isolate database tables for different instances by specifying different table names. After version 2.4 this can be achived through CAP configuration, by configuring different table name prefixes.
 
 > Check out the blog to learn more about the Versioning feature: https://www.cnblogs.com/savorboard/p/cap-2-4.html
 
@@ -68,7 +68,7 @@ During the message sending process if message transport fails, CAP will try to s
 During the message sending process if consumption method fails, CAP will try to execute the method again. This configuration option is used to configure the interval between each retry.
 
 !!! WARNING "Retry & Interval"
-    By default, retry will start after **4 minutes** of failure to send or consume, in order to avoid possible problems caused by setting message state delays.    
+    By default if failure occurs on send or consume, retry will start after **4 minutes** in order to avoid possible problems caused by setting message state delays.    
     Failures in the process of sending and consuming messages will be retried 3 times immediately, and will be retried polling after 3 times, at which point the FailedRetryInterval configuration will take effect.
 
 #### ConsumerThreadCount 
@@ -94,10 +94,10 @@ T1 : Message Type
 T2 : Message Name  
 T3 : Message Content
 
-Failure threshold callback. This action is called when the retry reaches the value set by `FailedRetryCount`, you can receive notification by specifying this parameter to make a manual intervention. For example, send an email or notify.
+Failure threshold callback. This action is called when the retry reaches the value set by `FailedRetryCount`, you can receive notification by specifying this parameter to make a manual intervention. For example, send an email or notification.
 
 #### SucceedMessageExpiredAfter
 
 > Default: 24*3600 sec (1 days)
 
-The expiration time (in seconds) of the success message. When the message is sent or consumed successfully, it will be removed from persistent when the time reaches `SucceedMessageExpiredAfter` seconds. You can set the expiration time by specifying this value.
+The expiration time (in seconds) of the success message. When the message is sent or consumed successfully, it will be removed from database storage when the time reaches `SucceedMessageExpiredAfter` seconds. You can set the expiration time by specifying this value.

docs/content/user-guide/en/cap/messaging.md

@@ -4,15 +4,15 @@ The data sent by using the `ICapPublisher` interface is called `Message`.
 
 ## Scheduling
 
-After CAP receives a message, it sends the message to Transport, which is transported by transport.
+After CAP receives a message, it sends the message to Transport(RabitMq, Kafka...), which is transported by transport.
  
 When you send message using the `ICapPublisher` interface, CAP will dispatch message to the corresponding Transport. Currently, bulk messaging is not supported.
 
 For more information on transports, see [Transports](../transports/general.md) section.
 
-## Persistent 
+## Storage 
 
-CAP will store the message after receiving it. For more information on storage, see the [Persistent](../persistent/general.md) section.
+CAP will store the message after receiving it. For more information on storage, see the [Storage](../persistent/general.md) section.
 
 ## Retry
 
@@ -20,7 +20,7 @@ Retrying plays an important role in the overall CAP architecture design, CAP ret
 
 ### Send retry
 
-During the message sending process, when the broker crashes or the connection fails or an abnormality occurs, the CAP will retry the sending. Retry 3 times for the first time, retry every minute after 4 minutes, and +1 retries. When the total number of times reaches 50,CAP will stop retrying.
+During the message sending process, when the broker crashes or the connection fails or an abnormality occurs, CAP will retry the sending. Retry 3 times for the first time, retry every minute after 4 minutes, and +1 retry. When the total number of retries reaches 50,CAP will stop retrying.
 
 You can adjust the total number of retries by setting `FailedRetryCount` in CapOptions.
 
@@ -32,10 +32,10 @@ The consumer method is executed when the Consumer receives the message and will
 
 ## Data Cleanup
 
-There is an `ExpiresAt` field in the database message table indicating the expiration time of the message. When the message is sent successfully, the status will be changed to `Successed`, and `ExpiresAt` will be set to **1 hour** later. 
+There is an `ExpiresAt` field in the database message table indicating the expiration time of the message. When the message is sent successfully, status will be changed to `Successed`, and `ExpiresAt` will be set to **1 hour** later. 
 
 Consuming failure will change the message status to `Failed` and `ExpiresAt` will be set to **15 days** later.
 
 By default, the data of the message in the table is deleted **every hour** to avoid performance degradation caused by too much data. The cleanup strategy `ExpiresAt` is performed when field is not empty and is less than the current time. 
 
-That is to say, the message with the status Failed (normally they have been retried 50 times), if you do not have manual intervention for 15 days, it will **also be** cleaned up.
+That is to say, the message with the status Failed (by default they have been retried 50 times), if you do not have manual intervention for 15 days, it will **also be** cleaned up.

docs/content/user-guide/en/cap/serialization.md

@@ -19,7 +19,7 @@ public class YourSerializer: ISerializer
 }
 ```
 
-Then register your implementation in the container:
+Then register your implemented serializer in the container:
 
 ```
 

docs/content/user-guide/en/cap/transactions.md

@@ -4,7 +4,7 @@
 
 CAP does not directly provide out-of-the-box MS DTC or 2PC-based distributed transactions, instead we provide a solution that can be used to solve problems encountered in distributed transactions.
 
-In a distributed environment, using 2PC or DTC-based distributed transactions can be very expensive due to the overhead involved in communication, as is performance. In addition, since distributed transactions based on 2PC or DTC are also subject to the **CAP theorem**, it will have to give up availability (A in CAP) when network partitioning occurs.
+In a distributed environment, using 2PC or DTC-based distributed transactions can be very expensive due to the overhead involved in communication which affects performance. In addition, since distributed transactions based on 2PC or DTC are also subject to the **CAP theorem**, it will have to give up availability (A in CAP) when network partitioning occurs.
 
 > A distributed transaction is a very complex process with a lot of moving parts that can fail. Also, if these parts run on different machines or even in different data centers, the process of committing a transaction could become very long and unreliable.
 

docs/content/user-guide/en/persistent/general.md

@@ -1,8 +1,8 @@
 # General
 
-CAP needs to use storage media with persistence capabilities to store event messages, such as through databases or other NoSql facilities. CAP uses this approach to deal with loss of messages in all environments or network anomalies. Reliability of messages is the cornerstone of distributed transactions, so messages cannot be lost under any circumstances.
+CAP needs to use storage media with persistence capabilities to store event messages in databases or other NoSql facilities. CAP uses this approach to deal with loss of messages in all environments or network anomalies. Reliability of messages is the cornerstone of distributed transactions, so messages cannot be lost under any circumstances.
 
-## Persistent
+## Persistence
 
 ### Before sent
 
@@ -23,7 +23,7 @@ Since Kafka is born with message persistence using files, Kafka will ensure that
 
 ## Storage
 
-After CAP is started, two tables are generated into the persistent, by default the name is `Cap.Published` and `Cap.Received`.
+After CAP is started, two tables are generated in used storage, by default the name is `Cap.Published` and `Cap.Received`.
 
 ### Storage Data Structure
 

docs/content/user-guide/en/persistent/in-memory-storage.md

@@ -1,6 +1,6 @@
 # In-Memory Storage
 
-Persistent storage of memory messages is often used in development and test environments, and if you use memory-based storage you lose the reliability of local transaction messages.
+In-memory storage is often used in development and test environments, and if you use memory-based storage you lose the reliability of local transaction messages.
 
 ## Configuration
 

docs/content/user-guide/en/persistent/sqlserver.md

@@ -3,7 +3,7 @@
 SQL Server is a relational database management system developed by Microsoft. CAP supports SQL Server database. 
 
 !!! warning "Warning"
-    We currently use `Microsoft.Data.SqlClient` as the database driver, which is the future of SQL Server drivers, and we have abandoned `System.Data.SqlClient`, we suggest you switch into.
+    We currently use `Microsoft.Data.SqlClient` as the database driver, which is the future of SQL Server drivers, and we have abandoned `System.Data.SqlClient`, we suggest that you switch to.
 
 ## Configuration
 

docs/mkdocs.yml

@@ -92,7 +92,7 @@ nav:
           - Azure Service Bus: user-guide/en/transports/azure-service-bus.md
           - Amazon SQS: user-guide/en/transports/aws-sqs.md
           - In-Memory Queue: user-guide/en/transports/in-memory-queue.md
-      - Persistent:
+      - Storage:
           - General: user-guide/en/persistent/general.md
           - SQL Server: user-guide/en/persistent/sqlserver.md
           - MySQL: user-guide/en/persistent/mysql.md