diff --git a/docs/en/Migration-Guides/Abp-5_0.md b/docs/en/Migration-Guides/Abp-5_0.md
index e9ef522162..1a34de43c9 100644
--- a/docs/en/Migration-Guides/Abp-5_0.md
+++ b/docs/en/Migration-Guides/Abp-5_0.md
@@ -95,6 +95,11 @@ public partial class AddIsActiveToIdentityUser : Migration
 
 For MongoDB, you need to update the `IsActive` field for the existing users in the database.
 
+You can use following script in MongoShell:
+```js
+db.AbpUsers.updateMany({},{$set:{ IsActive : true }})
+```
+
 #### Identity -> Account API Changes
 
 `IProfileAppService` (and the implementation and the related DTOs) are moved to the Account module from the Identity module (done with [this PR](https://github.com/abpframework/abp/pull/10370/files)).
diff --git a/docs/en/UI/AspNetCore/Client-Side-Package-Management.md b/docs/en/UI/AspNetCore/Client-Side-Package-Management.md
index eaccc39119..e9e4e04de5 100644
--- a/docs/en/UI/AspNetCore/Client-Side-Package-Management.md
+++ b/docs/en/UI/AspNetCore/Client-Side-Package-Management.md
@@ -13,7 +13,7 @@ ABP is a modular platform. Every developer can create modules and the modules sh
 
 One challenge is the **versions of the dependant NPM packages**. What if two different modules use the same JavaScript library but its different (and potentially incompatible) versions.
 
-To solve the versioning problem, we created a **standard set of packages** those depends on some common third-party libraries. Some example packages are [@abp/jquery](https://www.npmjs.com/package/@abp/jquery), [@abp/bootstrap](https://www.npmjs.com/package/@abp/bootstrap) and [@abp/font-awesome](https://www.npmjs.com/package/@abp/font-awesome). You can see the **list of packages** from the [Github repository](https://github.com/volosoft/abp/tree/master/npm/packs).
+To solve the versioning problem, we created a **standard set of packages** those depends on some common third-party libraries. Some example packages are [@abp/jquery](https://www.npmjs.com/package/@abp/jquery), [@abp/bootstrap](https://www.npmjs.com/package/@abp/bootstrap) and [@abp/font-awesome](https://www.npmjs.com/package/@abp/font-awesome). You can see the **list of packages** from the [GitHub repository](https://github.com/volosoft/abp/tree/master/npm/packs).
 
 The benefit of a **standard package** is:
 
@@ -22,14 +22,14 @@ The benefit of a **standard package** is:
 
 Depending on a standard package is easy. Just add it to your **package.json** file like you normally do. Example:
 
-````
+```json
 {
   ...
   "dependencies": {
     "@abp/bootstrap": "^1.0.0"
   }
 }
-````
+```
 
 It's suggested to depend on a standard package instead of directly depending on a third-party package.
 
@@ -37,9 +37,9 @@ It's suggested to depend on a standard package instead of directly depending on
 
 After depending on a NPM package, all you should do is to run the **yarn** command from the command line to install all the packages and their dependencies:
 
-````
+```bash
 yarn
-````
+```
 
 Alternatively, you can use `npm install` but [Yarn](https://classic.yarnpkg.com/) is suggested as mentioned before.
 
@@ -69,7 +69,7 @@ The **startup templates** are already configured to work all these out of the bo
 
 A module should define a JavaScript file named `abp.resourcemapping.js` which is formatted as in the example below:
 
-````js
+```json
 module.exports = {
     aliases: {
         "@node_modules": "./node_modules",
@@ -83,7 +83,7 @@ module.exports = {
         
     }
 }
-````
+```
 
 * **aliases** section defines standard aliases (placeholders) that can be used in the mapping paths. **@node_modules** and **@libs** are required (by the standard packages), you can define your own aliases to reduce duplication.
 * **clean** section is a list of folders to clean before copying the files. Glob matching and negation is enabled, so you can fine-tune what to delete and keep. The example above will clean everything inside `./wwwroot/libs`, but keep any `foo.txt` files.
@@ -91,14 +91,14 @@ module.exports = {
 
 An example mapping configuration is shown below:
 
-````js
+```json
 mappings: {
     "@node_modules/bootstrap/dist/css/bootstrap.css": "@libs/bootstrap/css/",
     "@node_modules/bootstrap/dist/js/bootstrap.bundle.js": "@libs/bootstrap/js/",
     "@node_modules/bootstrap-datepicker/dist/locales/*.*": "@libs/bootstrap-datepicker/locales/",
     "@node_modules/bootstrap-v4-rtl/dist/**/*": "@libs/bootstrap-v4-rtl/dist/"
 }
-````
+```
 
 #### install-libs Command
 
diff --git a/docs/zh-Hans/Domain-Driven-Design-Implementation-Guide.md b/docs/zh-Hans/Domain-Driven-Design-Implementation-Guide.md
index c5c2727001..eb3c076341 100644
--- a/docs/zh-Hans/Domain-Driven-Design-Implementation-Guide.md
+++ b/docs/zh-Hans/Domain-Driven-Design-Implementation-Guide.md
@@ -1771,15 +1771,15 @@ public async Task ChangeTitleAsync(Issue issue, string title)
 
 领域逻辑是系统的*核心领域规则*组成,而应用逻辑则满足特定的*用例*.
 
-虽然定义很明确,但是实施起来缺并不容器.你可能无法确定哪些代码应该属于领域层,哪些代码应该属于应用层,本节会尝试解释差异.
+虽然定义很明确,但是实施起来却并不容易.你可能无法确定哪些代码应该属于领域层,哪些代码应该属于应用层,本节会尝试解释差异.
 
 ### 多应用层
 
 当你的系统很大时,DDD有助于**处理复杂问题**.尤其是,**单个领域**需要多个**应用程序运行**,那么**领域逻辑与应用逻辑分离**就变的非常重要.
 
-假设你正字构建一个具有多个应用程序的系统:
+假设你正在构建一个具有多个应用程序的系统:
 
-* 一个**公开的应用网站**,使用ASP.NET Core MVC构建,展示商品给来访者.这样的网站不选哟身份验证即可查看商品.来访者只有执行了某些操作(例如,将商品添加到购物车)后,才需要登录网站.
+* 一个**公开的应用网站**,使用ASP.NET Core MVC构建,展示商品给来访者.这样的网站不需要身份验证即可查看商品.来访者只有执行了某些操作(例如,将商品添加到购物车)后,才需要登录网站.
 * 一个**后台管理系统**,UI使用Angular,通过REST API请求数据.内部员工使用这个系统来维护数据(例如,编辑商品说明).
 * 一个**移动端应用程序**,它比公开的网站UI上更加简洁.它通过REST API或其它技术(例如,TCP sockets)请求数据.
 
@@ -1787,7 +1787,7 @@ public async Task ChangeTitleAsync(Issue issue, string title)
 
 每个应用程序都有不同的**需求**,不同的**用例**(应用服务方法),不同的DTO,不同的**验证**和**授权**规则等.
 
-将所有这些逻辑都集中到一个应用层中,会使你的服务包含太多的`if`条件分支及**复杂的业务逻辑**,从而使你的代码难道开发,**维护**,测试,引发各种问题.
+将所有这些逻辑都集中到一个应用层中,会使你的服务包含太多的`if`条件分支及**复杂的业务逻辑**,从而使你的代码开发,**维护**,测试,引发各种问题.
 
 如果你在一个领域中有多个应用程序