diff --git a/en/eBook/10.1.md b/en/eBook/10.1.md
index 0c539e3c..2e234501 100644
--- a/en/eBook/10.1.md
+++ b/en/eBook/10.1.md
@@ -1,6 +1,6 @@
 # 10.1 Time zones
 
-## Finding out the Locale
+## Finding out the locale
 
 A locale is a set of descriptors for a particular geographical region, and can include specific language habits, text formatting, cultural idioms and a multitude of other settings. A locale's name is usually composed of three parts. First (and mandatory) is the locale's language abbreviation, such as "en" for English or "zh" for Chinese. The second part is an optional country specifier, and follows the first with an underscore. This specifier allows web applications to distinguish between different countries which speak the same language, such as "en_US" for U.S. English, and "en_UK" for British English. The last part is another optional specifier, and is added to the locale with a period. It specifies which character set to use, for instance "zh_CN.gb2312" specifies the gb2312 character set for Chinese.
 
@@ -8,18 +8,18 @@ Go defaults to the "UTF-8" encoding set, so i18n in Go applications do not need
 
 > On Linux and Solaris systems, you can use the `locale -a` command to get a list of all supported regional names. You can use this list as examples of some common locales. For BSD and other systems, there is no locale command, but the regional information is stored in `/usr/share/locale`.
 
-## Setting the Locale
+## Setting the locale
 
 Now that we've defined what a locale is, we need to be able to set it according to visiting users' information (either from their personal settings, the visited domain name, etc.). Here are some methods we can use to set the user's locale: 
 
-### Setting the Locale by domain name
+### Setting the locale by domain name
 
-We can set a user's locale via the domain name itself when the application uses different domains for different regions. For example, we can use www.asta.com as our default English website, and the domain name www.asta.cn as its Chinese counterpart. By application of this domain name and set up inside the correspondence between the respective locale, you can set up regions. This treatment has several advantages:
+We can set a user's locale via the domain name itself when the application uses different domains for different regions. For example, we can use www.asta.com as our default English website, and the domain name www.asta.cn as its Chinese counterpart. By setting up separate domains for separate regions, you can detect and serve the requested locale. This type of setup has several advantages:
 
-- Via a URL can be very distinctive identification
-- Users can be very intuitive to know the domain name will be visiting the site in that language
-- Go program is implemented in a very simple and convenient, can be achieved through a map
-- Conducive to search engine crawlers can improve the site's SEO
+- Identifying the locale via URL is distinctive and unambiguous 
+- Users intuitively know which domain names to visit for their specific region or language 
+- Implementing this scheme in a Go application very simple and convenient, and can be achieved through a map
+- Conducive to search engine crawlers which can improve the site's SEO
 
 We can use the following code to implement a corresponding domain name locale:
 
@@ -31,7 +31,7 @@ We can use the following code to implement a corresponding domain name locale:
 		i18n.SetLocale("zh-TW")
 	}
 
-Of course, in addition to the entire domain settings outside the region, we can also be set through the sub-domain areas, such as "en.asta.com" for English sites, "cn.asta.com" indicates Chinese site. Realization of the code is as follows:
+Alternatively, we could have also set locales through the use of sub-domain such as "en.asta.com" for English sites and "cn.asta.com" for Chinese site. This scheme can be realized in code as follows:
 
 	prefix:= strings.Split(r.Host,".")
 
@@ -43,25 +43,25 @@ Of course, in addition to the entire domain settings outside the region, we can
 		i18n.SetLocale("zh-TW")
 	}
 
-Locale setting by domain name as shown above advantages, but we generally do not develop Web applications, when used in this way, because first of all domain names cost is relatively high, the development of a Locale need a domain name, and often the name of the domain does not necessarily uniform apply to, and secondly we do not want to go to each site localization of a configuration, but more is to use the url method with parameters, see the following description.
+Setting locales from the domain name as we've done above has its advantages, however l10n is generally not implemented in this way. First of all, the cost of domain names (although usually quite affordable individually) can quickly add up given that each locale will need its own domain name, and often the name of the domain will not necessarily fit in with the local context. Secondly, we don't want to have to individually configure each website for each locale. Rather, we should be able to do this programmatically, for instance by using URL parameters. Let's have a look at the following description.
 
 ### Locale parameter settings from the domain name
 
-The most common way is to set the Locale to bring inside in the URL parameters, such `www.asta.com/hello?locale=zh` or `www.asta.com/zh/hello`. So that we can set the region: `i18n.SetLocale(params["locale"])`.
+The most common way of implementing l10n is to set the desired locale directly in the URL parameters, such `www.asta.com/hello?locale=zh` or `www.asta.com/zh/hello`. This way, we can set the region like so: `i18n.SetLocale(params["locale"])`.
 
-This setup has almost speaking in front of the domain name Locale setting all the advantages, it uses a RESTful way, so we do not need to add additional methods to deal with. However, this approach requires a link inside each one corresponding increase in the parameter locale, this may be a bit complicated and sometimes quite cumbersome. However, we can write a generic function that url, so that all the link addresses are generated through this function, then this function which increases `locale = params [" locale "]` parameter to alleviate it.
+This setup has almost all the advantages of prepending the locale in front of the domain and it's RESTful, so we don't need to add additional methods to implement it. The downside to this approach is that it requires a corresponding locale parameter inside each link, which can be quite cumbersome and may increase complexity. However, we can write a generic function that produces these locale-specific URLs so that all links are generated through it. This function should automatically add a locale parameter to each link so when users click them, we are able to parse their requests with ease: `locale = params [" locale "]`.
 
-Maybe we want to look more RESTful URL address that, for example: `www.asta.com/en/books` (English site) and `www.asta.com/zh/books` (Chinese site), this approach is more conducive to the URL SEO, but also more friendly for the user, can be accessed through the URL of the site that intuitive. Then such a URL address to get through router locale(reference section which describes the router REST plug-in implementation):
+Perhaps we want our URLs to look even more RESTful. For example, we could map each of our resources under a specific locale like `www.asta.com/en/books` for our English site and `www.asta.com/zh/books` for the Chinese one. This approach is not only more conducive to URL SEO, but is also more friendly for users. Anybody visiting the site should be able to access locale-specific website resources directly from the URL. Such URL addresses can then be passed through the application router in order to obtain the proper locale (refer to the REST section, which describes the router plug-in implementation):
 
 	mux.Get("/:locale/books", listbook)
 
 ### From the client settings area
 
-In some special cases, we need the client's information rather than through the URL to set Locale, such information may come from the client to set the preferred language( the browser settings), the user's IP address, the user at the time of registration fill the location information. This approach is more suitable for Web -based applications.
+In some special cases, we require explicit client information in order to set the locale rather than obtaining it from the URL or URL parameters. This information may come directly from the client's browser settings, the user's IP address, or the location settings filled out by the user at the time of registration. This approach is more suitable for web-based applications.
 
 - Accept-Language
 
-When a client requests information in the HTTP header there `Accept-Language`, clients will generally set this information, the following is the Go language to achieve a simple `Accept-Language` under implementation sets the region code:
+When a client requests information using an HTTP header set with the `Accept-Language` field, we can use the following Go code to parse the header and set the appropriate region code: 
 
 	AL := r.Header.Get("Accept-Language")
 	if AL == "en" {
@@ -72,10 +72,11 @@ When a client requests information in the HTTP header there `Accept-Language`, c
 		i18n.SetLocale("zh-TW")
 	}
 
-Of course, in practical applications, it may require more rigorous judgment to be set area
+Of course, in real world applications, we may require more rigorous processes and rules for setting user regions 
+
 - IP Address
 
-Another set of the client area is the user access IP, we according to the corresponding IP library, corresponding to the IP access to areas of the world that is more commonly used GeoIP Lite Country this library. This setting regional mechanism is very simple, we only need to check the user's IP IP database and then return to the country regions, according to the results returned by setting the corresponding regions.
+Another way of setting a client's region is to look at the user's IP address. We can use the popular GeoIP GeoLite Country library to help us relate user IP addresses to their corresponding regional areas. Implementing this mechanism is very simple: we only need to look up the user's IP address inside our database and then return the country regions, according to the results returned by setting the corresponding regions.
 
 - User profile