[FIX] [WEBSITE-9279] fix parameter priority documentation

docs/en-us/dev/user_doc/guide/parameter/priority.md

@@ -6,7 +6,7 @@ DolphinScheduler has three parameter types:
 * [Parameter Context](context.md): parameters passed by upstream task nodes
 * [Local Parameter](local.md): parameters belong to its node, which is the parameters defined by the user in [Custom Parameters]. The user can define part of the parameters when creating workflow definitions.
 
-Due to there are multiple sources of the parameter value, there will raise parameter priority issues when the parameter name is the same. The priority of DolphinScheduler parameters from high to low is: `Global Parameter > Parameter Context > Local Parameter`
+Due to there are multiple sources of the parameter value, there will raise parameter priority issues when the parameter name is the same. The priority of DolphinScheduler parameters from high to low is: `Local Parameter > Parameter Context > Global Parameter`
 
 In the case of upstream tasks can pass parameters to the downstream, there may be multiple tasks upstream that pass the same parameter name:
 
@@ -21,11 +21,11 @@ Followings are examples shows task parameters priority problems:#############
 
 ![png01](/img/globalParam/image-20210723102938239.png)
 
-The [useParam] node can use the parameters which are set in the [createParam] node. The [useParam] node cannot obtain the parameters from the [noUseParam] node due to there is no dependency between them. Other task node types have the same usage rules with shell example here.
+The [useParam] node can use the parameters which are set in the [createParam] node. The [useParam] node cannot obtain the parameters from the [noUseParam] node due to there is no dependency between them. Other task node types have the same usage rules with the Shell example here.
 
 ![png02](/img/globalParam/image-20210723103316896.png)
 
-The [createParam] node can use parameters directly. In addition, the node creates two parameters named "key" and "key1" and "key1" has the same name as the one passed by the upstream node and assign value "12". However, due to the priority rules, the value assignment "12" is discarded and the value from the upstream node is finally used.
+The [createParam] node can use parameters directly. In addition, the node creates two parameters named "key" and "key1", and "key1" has the same name as the one passed by the upstream node and assign value "12". However, due to the priority rules, the value assignment will assign "12" and the value from the upstream node is discarded.
 
 2: Use SQL nodes to explain another case.
 
@@ -35,6 +35,6 @@ The following shows the definition of the [use_create] node:
 
 ![png04](/img/globalParam/image-20210723104411489.png)
 
-"status" is the own parameters of the node and set by the current node. However, the user also sets the "status" parameter when saving, assigning its value to -1. Then the value of status will be -1 with higher priority when the SQL is executed. The value of the node's own variable is discarded.
+"status" is the own parameters of the node set by the current node. However, the user also sets the "status" parameter (global parameter) when saving the process definition and assign its value to -1. Then the value of status will be 2 with higher priority when the SQL executes. The global parameter value is discarded.
 
 The "ID" here is the parameter set by the upstream node. The user sets the parameters of the same parameter name "ID" for the [createparam1] node and [createparam2] node. And the [use_create] node uses the value of [createParam1] which is finished first.

docs/zh-cn/dev/user_doc/guide/parameter/priority.md

@@ -6,9 +6,9 @@ DolphinScheduler 中所涉及的参数值的定义可能来自三种类型：
 * [上游任务传递的参数](context.md)：上游任务传递过来的参数
 * [本地参数](local.md)：节点的自有变量，用户在“自定义参数”定义的变量，并且用户可以在工作流定义时定义该部分变量的值
 
-因为参数的值存在多个来源，当参数名相同时，就需要会存在参数优先级的问题。DolphinScheduler 参数的优先级从高到低为：`全局参数 > 上游任务传递的参数 > 本地参数`
+因为参数的值存在多个来源，当参数名相同时，就需要会存在参数优先级的问题。DolphinScheduler 参数的优先级从高到低为：`本地参数 > 上游任务传递的参数 > 全局参数`
 
-在上游任务传递的参数的情况下，由于上游可能存在多个任务向下游传递参数。当上游传递的参数名称相同时：
+在上游任务传递的参数中，由于上游可能存在多个任务向下游传递参数，当上游传递的参数名称相同时：
 
 * 下游节点会优先使用值为非空的参数
 * 如果存在多个值为非空的参数，则按照上游任务的完成时间排序，选择完成时间最早的上游任务对应的参数
@@ -25,7 +25,7 @@ DolphinScheduler 中所涉及的参数值的定义可能来自三种类型：
 
 <img src="/img/globalParam/image-20210723103316896.png" alt="image-20210723103316896" style="zoom:50%;" />
 
-其中节点【createParam】在使用变量时直接使用即可。另外该节点设置了 "key" 和 "key1" 两个变量，这里用户用定义了一个与上游节点传递的变量名相同的变量 key1，并且赋值为 "12"，但是由于我们设置的优先级的关系，这里的值 "12" 会被抛弃，最终使用上游节点设置的变量值。
+其中节点【createParam】在使用变量时直接使用即可。另外该节点设置了 "key" 和 "key1" 两个变量，这里用户用定义了一个与上游节点传递的变量名相同的变量 key1，并且赋值为 "12"，但是由于我们设置的优先级的关系，这里的值 "12" 会被使用，最终上游节点设置的变量值会被抛弃。
 
 2：我们再以 sql 节点来解释另外一种情况
 
@@ -35,6 +35,6 @@ DolphinScheduler 中所涉及的参数值的定义可能来自三种类型：
 
 ![image-20210723104411489](/img/globalParam/image-20210723104411489.png)
 
-"status" 是当前节点设置的节点的自有变量。但是用户在保存时也同样设置了 "status" 变量，并且赋值为 -1。那在该 SQL 执行时，status 的值为优先级更高的 -1。抛弃了节点的自有变量的值。
+"status" 是当前节点设置的节点的自有变量。但是用户在保存工作流时也同样设置了 "status" 变量（全局参数），并且赋值为 -1。那在该 SQL 执行时，status 的值为优先级更高的 2。抛弃了全局变量中的值。
 
 这里的 "id" 是上游节点设置的变量，用户在节点【createParam1】、节点【createParam2】中设置了相同参数名 "id" 的参数。而节点【use_create】中使用了最先结束的【createParam1】的值。