Modified pages to discuss chapter composition

docs/practice/designing.md

@@ -19,7 +19,7 @@ title: Designing a flow
 
 ### Designing messages  
 
-*There are risks that multiple nodes have dependencies by messages passing the nodes.*  
+*There are risks that multiple nodes have dependencies by messages passing through nodes.*  
 *For other developers to reuse flows, it is important to design messages so that dependencies get to be relaxed. This chapter proposes a guide about designing message.*  
 
 *We have already written actual contents on [here](https://github.com/node-red/node-red.github.io/wiki/Flow-Guideline-Contents).*  
@@ -28,7 +28,7 @@ title: Designing a flow
 
 *`msg` is a JavaScript object that contains a key-value structure like JSON. While a `msg` transits across multiple nodes, the nodes use some keys and values of the `msg`. If two or more nodes of them use the same key for different their own purposes, preparing `msg` for input of the nodes is so difficult.*  
 
-*Therefore, policies of key-value structure are needed and this subsection describes it as such as followings,*   
+*Therefore, policies of key-value structure are needed and this subsection describes it as followings,*   
 
 * *Top-level keys of `msg` are used to control the functionality of node*  
 * *`msg.payload` is used as input parameters of a process of a node*  
@@ -43,9 +43,9 @@ title: Designing a flow
 
 #### Using persistent storage outside of Node-RED  
 
-*If you handle the large amount of data, it is **not** recommended to set the data into `msg` since `msg` can be a cause of a lack of memory. Instead, you had better put the data on a persistent storage that is in outside of Node-RED and use reference to the data for handling the data.*  
+*If you handle the large amount of data, it is **not** recommended to set the data into `msg` since `msg` can exhaust available memory. Instead, you had better put the data on a persistent storage that is outside of Node-RED and use reference to the data for handling the data.*  
 
-#### Processing in order of arrival of messages  
+#### Processing messages in order of their arrival  
 
 *Since Node-RED (JavaScript) processes asynchronously, a node cannot assume that it executes process for arrival `msgs` by the order of arrival.*    
 

docs/practice/implementation.md

@@ -10,15 +10,15 @@ title: Implementation of flow
 
 *Http in/out/request nodes are useful for the integration. However, if you do not want to expose endpoints of small flows, you can make sub flows from the small flows and create an additional flow to integrate sub flows.*  
 
-### Managing environmental variables  
+### Managing flow parameter  
 
-*Global context can be used as an environmental variable of flow execution. However, if you use the global context in various nodes, identifying dependencies between nodes becomes a hard work, and it can lead to bugs. To minimize the dependence on the global context, it is necessary to make it easier to see where the global context is used.*    
+*Global context can be used as a parameter of flow execution. However, if you use the global context in various nodes, identifying dependencies between nodes becomes a hard work, and it can lead to bugs. To minimize the dependence on the global context, it is necessary to make it easier to see where the global context is used.*    
 
 ### Flows that can have adverse effects  
 
-*With Node-RED, even non-programmers can easily enjoy coding. However, Node-RED (as of 0.19.5) does not strict restrictions on creating flows and debugging tools such as a lint, you can easily create dangerous flows that can cause bugs. In particular, it is also possible to lead to resource exhaustion of Node-RED engine.*      
+*With Node-RED, even non-programmers can easily enjoy coding. However, Node-RED (as of 0.19.5) does not place strict restrictions on creating flows and does not provide debugging tools such as a lint. Thus, you can easily create dangerous flows that can cause bugs. In particular, it is also possible to lead to resource exhaust of Node-RED engine.*      
 
-*This chapter shows certain cautions and principles not to create such dangerous flows.*    
+*This chapter shows certain cautions and principles preventing from creating such dangerous flows.*    
 
 ### Error Handling  
 

docs/practice/index.md

@@ -1,11 +1,11 @@
 ---
 layout: docs
 toc: practice-toc.html
-title: Introduce
+title: Introduction
 ---
-*This guide is for who understands the basic fuctinality and want to develop more clear and reusable flows. If you thik that you are beginner, please read **[User Guide](https://nodered.org/docs/user-guide/)** and **[Cookbook](https://cookbook.nodered.org/)** first.*  
+*This guide is for developers who understand the basic fuctinality and want to develop more clear and reusable flows. If you think that you are beginner, please read **[User Guide](https://nodered.org/docs/user-guide/)** and **[Cookbook](https://cookbook.nodered.org/)** first.*  
 
-*In Node-RED, users can create flows easily and ad hoc. However, if you want to create more reusable and readable flows, some tips, practices and know how may be needed. Therefore, we would propose to create a new flow development guideline page to show such knowledge on Node-RED official page. We believe this page is useful for most Node-RED users.*  
+*In Node-RED, users can create flows easily and in ad hoc manner. However, if you want to create more reusable and readable flows, some tips, practices and know how may be needed. Therefore, flow development guideline page is intended for gathering such knowledge. We believe this page is useful for most Node-RED users.*  
 
 *Before adding guideline to the Node-RED official page through a pull request, we would like to discuss contents and where to place it with somebody who are interested in this guideline. This wiki page is for discussing them.*  
 

docs/practice/readability.md

@@ -9,17 +9,17 @@ title: Improving readability
 
 ### Naming rule  
 
-*Name of nodes, tabs and subflow is important for readability and reusability of flows. This chapter presents some effective naming rules of them.(italic)*  
+*Name of nodes, tabs and subflow is important for readability and reusability of flows. This chapter presents some effective naming rules of them.*  
 
 ### Using proper nodes  
 
 *Each node can be used flexibly. For example, a function node can cover the same function of Change node, Switch node and so on. However, using a proper specialized node for your objective contributes improving understandability of your flows. This chapter introduces the roles and usage of core nodes such as **Change, Switch, Template, Link, HTTP**.*  
 
-*The **Function** node and **Exec** node are useful for JavaScript and other language developers because they can write JavaScript codes and commands directly. However, heavy use of them makes understanding flow difficult for other developers. This chapter describes a caution of these nodes and shows examples of alternative methods against Function node and Exec node.*  
+*The **Function** node and **Exec** node are useful for JavaScript and other language developers because they can write JavaScript codes and commands directly. However, heavy use of them makes understanding of flow difficult for other developers. This chapter describes a caution of these nodes and shows examples of alternative methods against Function node and Exec node.*  
 
 #### Link node
 
-*You can divide the flows when it be too long by using Link node. And it allows you create flows accroding to the size of the display and makes the layout clean.*  
+*You can divide the flows when it become too long by using Link node. And it allows you to create flows accroding to the size of the display and makes the layout clean.*  
 
 ### Changing icon