diff --git a/en/eBook/09.2.md b/en/eBook/09.2.md
index b5209cae..1af7f49d 100644
--- a/en/eBook/09.2.md
+++ b/en/eBook/09.2.md
@@ -1,41 +1,41 @@
-# 9.2 Filter inputs
+# 9.2 Filtering inputs
 
-Filter user data is a Web application security. It is to verify the legitimacy of the process data. Through all of the input data is filtered to avoid malicious data in the program to be mistaken belief or misuse. Most Web application vulnerabilities because no user input data for proper filtration caused.
+Filtering user data is one way we can improve the security of our web apps, using it to verify the legitimacy of incoming data. All of the input data is filtered in order to avoid malicious code or data from being mistakenly executed or stored. Most web application vulnerabilities arise form neglecting to filter input data and naively trusting it. 
 
-We introduce filtering data is divided into three steps:
+Our introduction to filtering data is divided into three steps:
 
-1. the identification data, the data needs to be filtered to figure out from where
-2. the filtering data, we need to figure out what kind of data
-3. the distinction between filtered and tainted data, so if there is assurance attack data after filtering allows us to use a more secure data
+1. identifying the data; we need to filter the data to figure out where it originated form
+2. filtering of the data itself; we need to figure out what kind of data we have received
+3. distinguish between filtered (sanitized) and tainted data; after the data has been filtered, we can be assured that it is is secure
 
-## Identify data
+## Identifying data
 
-"Identification data" as a first step because you do not know " what the data is, where it comes from," the premise that you would be unable to properly filter it. The data here is provided internally all from non-code data. For example: all data from the client, but the client is not the only external data source, a database interface data provided by third parties, also be an external data source.
+"Identifying the data" is our first step because most of the time, as mentioned, we don't know where it originates from. Without this knowledge, we would be unable to properly filter it. The data here is provided internally all from non-code data. For example: all data comes from clients, however clients that are users are not the only external sources of data. A database interface providing third party data could also be an external data source.
 
-The data entered by the user is very easy to recognize we Go, Go through the `r.ParseForm` after the user POST and GET data all on the `r.Form` inside. Other input is much harder to identify, for example, `r.Header` Many of the elements are manipulated by the client. Often difficult to identify which of these elements of the input, so the best way is to put inside all the data as a user input. ( Ex `r.Header.Get("Accept-Charset")` This is also seen as user input, although these most browsers manipulation )
+Data that has been entered by a user is very easy to recognize in Go. We use `r.ParseForm` after the user POSTs a form to get all of the data inside the `r.Form`. Other types of input are much harder to identify. For example in `r.Header`s, many of the elements are often manipulated by the client. It can often be difficult to identify which of these elements have been manipulated by clients, so it's best to consider all of them as having been tainted. The `r.Header.Get("Accept-Charset")` header field, for instance, is also considered as user input, although these are typically only manipulated by browsers.
 
-## Filter data
+## Filtering data
 
-Data sources in the know, you can filter it. Filtering is a bit formal terms, it is expressed in peacetime there are many synonyms, such as validation, cleaning and decontamination. Despite the apparent meaning of these terms are different, but they all refer to the same treatment: to prevent illegal data into your application.
+If we know the source of the data, we can filter it. Filtering is a bit of a formal use of the term. The process is known by many other terms such as input cleaning, validation and sanitization. Despite the fact that these terms somewhat differ in their meaning, they all refer to the same thing: the process of preventing illegal data from making its way into your applications.
 
-There are many ways to filter data, some of which are less secure. The best way is to check the filter as a process, you have to check before using the data to see whether they meet the legal requirements of the data. And do not try to correct the illegal data kindly, and let the user presses the rules to enter your data. History has proved that the attempt to correct invalid data often lead to security vulnerabilities. Here an example: "The recent construction of the banking system after the upgrade, if the password behind the two is 0, just enter the front four can log into the system," which is a very serious flaw.
+There are many ways to filter data, some of which are less secure than others. The best method is to check whether or not the data itself meets the legal requirements dictated by your application. When attempting to do so, it's very important not to make any attempts at correcting the illegal data; this could allow malicious users to manipulate your validation rules for their own needs, altogether defeating the purpose of filtering the data in the first place. History has proven that attempting to correct invalid data often leads to security vulnerabilities. Let's take a look at an overly simple example for illustration purposes. Suppose that a banking system asks users to supply a secure, 6 digit password. The system validates the length of all passwords.  One might naively write a validation rule that corrects passwords of illegal lengths: "If a password is shorter than the legal length, fill in the remaining digits with 0s". This simple rule would allow attackers to guess just the first few digits of a password to successfully gain access to user accounts!
 
-Filtering data using the following several major libraries to operate :
+We can use several libraries to help us to filter data: 
 
-- Strconv package the following string into the correlation function, because the `r.Form` Request returns a string, and sometimes we need to convert it to an integer/floating point, `Atoi`, `ParseBool`, ` ParseFloat `,` ParseInt ` other function can come in handy.
-- String pack Here are some filter function `Trim`, `ToLower`, `ToTitle` other functions, can help us to obtain information in accordance with the format specified.
-- Regexp package to handle some of the complex needs, such as determining whether the input is Email, birthdays and the like.
+- The strconv package can help us to convert user inputed strings into specific types, since `r.Form`s are maps of string values. Some common string conversions provided by strconv are `Atoi`, `ParseBool`, ` ParseFloat ` and  `ParseInt`.
+- Go's `strings` package contains some filter functions like `Trim`, `ToLower` and `ToTitle`, which can help us to obtain data in a specific formats, according to our needs.
+- Go's `regexp` package can be used to handle cases which are more complex in nature, such as determining whether an input is an email address, a birthday, etc. 
 
-Filtering Data In addition to checking authentication, in particular, you can also use the whitelist. Assuming that you are checking the data is illegal, unless it can prove that it is legitimate. Using this method, if an error occurs, it will only lead to the legitimate data as it is illegal, and not the opposite, although we do not want to make any mistakes, but it is better than the illegal data as legitimate data much more secure.
+Filtering incoming data in addition to authentication can be quite effective. Let's add another technique to our repertoire, called whitelisting. Whitelisting is a good way of confirming the legitimacy of incoming data. Using this method, if an error occurs, it can only mean that the incoming data is illegal, and not the opposite. Of course, we don't want to make any mistakes in our whitelist by falsely labelling legitimate data as illegal, but this scenario is much better than illegal data being labeled as legitimate, and thus much more secure.
 
-## Distinguish filter data
+## Distinguishing between filtered and tainted data
 
-If you have completed the above steps, data filtering work is basically completed, but when writing Web applications, we also need to distinguish between filtered and tainted data, because it can guarantee the integrity of data filtering without affecting the input data. We agreed to put all filtered data into a variable called global Map (CleanMap). Then two important steps needed to prevent contamination of data injection:
+If you have completed the above steps, the job of filtering data has basically been completed. However when writing web applications, we also need to distinguish between filtered and tainted data because doing so can guarantee the integrity of our data filtering process without affecting the input data. Let's put all of our filtered data into a global map variable called `CleanMap`. Then, two important steps are required to prevent contamination via data injection:
 
-- Each request must be initialized CleanMap an empty Map.
-- Join inspection and prevent a variable from an external data source named CleanMap.
+- Each request must initialize `CleanMap` as an empty map.
+- Prevent variables from external data sources named `CleanMap` from being introduced into the app.
 
-Next, let's use an example to reinforce these concepts, see the following form
+Next, let's use an example form to reinforce these concepts:
 
 	<form action="/whoami" method="POST">
 		Who am I:
@@ -47,7 +47,7 @@ Next, let's use an example to reinforce these concepts, see the following form
 		<input type="submit" />
 	</form>
 
-In dealing with this form of programming logic, very easy to make the mistake that can only be submitted in one of three choices. In fact, an attacker can simulate the POST operation, `name = attack` submission of such data, so at this point we need to do a similar deal with whitelist
+In dealing with this type of form, it can be very easy to make the mistake of thinking that users will only be able to submit one of the three `select` options. In fact, POST operations can easily be simulated by attackers. For example, by submitting the same form with `name = attack`, a malicious user could introduce illegal data into our system. We can use a simple whitelist to counter these types of attacks:
 
 	r.ParseForm()
 	name := r.Form.Get("name")
@@ -56,10 +56,9 @@ In dealing with this form of programming logic, very easy to make the mistake th
 		CleanMap["name"] = name
 	}
 
-The above code we initialize a `CleanMap` variable name is obtained when the judge `astaxie`, `herry`, `marry` after one of the three
-We store data in the `CleanMap` being, so you can make sure `CleanMap["name"]` data is legitimate, and thus the rest of the code to use it. Of course, we can also increase the else part of illegal data processing, possibility is that the form is displayed again with an error. But do not try to be friendly and output data to be contaminated.
+The above code initializes a `CleanMap` variable, and a name is only assigned after checking it against an internal whitelist of legitimate values (`astaxie`, `herry` and `marry` in this case). We store the data in the `CleanMap` instance so you can be sure that `CleanMap["name"]` holds a validated value. Any code wishing to access this value can then freely do so. We can also add an additional `else` statement to the above `if` whitelist for dealing with illegal data, a possibility being that the form was displayed with an error. Do not try to be too accommodating though, or you run the risk of accidentally contaminating your `CleanMap`.
 
-The above method for filtering a set of known legitimate value data is very effective, but there is a group known for filtering data consisting of legal characters when it did not help. For example, you may need a user name can only consist of letters and numbers:
+The above method for filtering data against a set of known, legitimate values is very effective. There is another method for checking whether or not incoming data consists of legal characters using `regexp`, however this would be ineffectual in the above case where we require that the name be an option from the select. For example, you may require that user names only consist of letters and numbers:
 
 	r.ParseForm()
 	username := r.Form.Get("username")
@@ -70,7 +69,7 @@ The above method for filtering a set of known legitimate value data is very effe
 
 ## Summary
 
-Data filtering in the Web security play a cornerstone role in most of the security problems are the result of filtering the data and validation of data caused by, for example, the front section of CSRF attacks, and the next will be introduced XSS attacks, SQL injection and so there is no serious cause for filtering data, so we need special attention to this part of the content.
+Data filtering plays a vital role in the security of modern web applications. Most security vulnerabilities are the result of improperly filtering data or neglecting to properly validate it. Because the previous section dealt with CSRF attacks and the next two will be introducing XSS attacks and SQL injection, there was no natural segue into dealing with as important a topic as data sanitization, so in this section, we paid special attention to it.
 
 ## Links