Finalize grammar and sentence restructuring for 10.1.md [en]
This commit is contained in:
@@ -12,7 +12,7 @@ Go defaults to the "UTF-8" encoding set, so i18n in Go applications do not need
|
||||
|
||||
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
|
||||
### From the 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 setting up separate domains for separate regions, you can detect and serve the requested locale. This type of setup has several advantages:
|
||||
|
||||
@@ -45,7 +45,7 @@ Alternatively, we could have also set locales through the use of sub-domain such
|
||||
|
||||
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
|
||||
### From URL parameters
|
||||
|
||||
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"])`.
|
||||
|
||||
@@ -76,15 +76,15 @@ Of course, in real world applications, we may require more rigorous processes an
|
||||
|
||||
- IP Address
|
||||
|
||||
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.
|
||||
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 or City libraries](http://dev.maxmind.com/geoip/legacy/geolite/) 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 locale-specific content according to which region was returned.
|
||||
|
||||
- User profile
|
||||
|
||||
Of course, you can also let users provide you with drop-down menus or whatever way set the appropriate locale, then we have the information entered by the user, it is saved to the account associated with the profile, when the user login again, this time to set up replicated to the locale setting, so that you can guarantee that every time the user accesses are based on their previously set locale to get the page.
|
||||
You can also let users provide you with their locale information through an input element such as a drop-down menu (or something similar). When we receive this information, we can save it to the account associated with the user's profile. When the user logs in again, we will be able to check and set their locale settings -this guarantees that every time the user accesses the website, the returned content will be based on their previously set locale.
|
||||
|
||||
## Summary
|
||||
|
||||
Through the above description shows that you can set the Locale There are many ways that we should be selected according to the different needs of different settings Locale way to allow a user to its most familiar way to get the services we provide, improve application user friendliness.
|
||||
In this section, we've demonstrated a variety of ways with which user specific locales can be detected and set. These methods included setting the user locale via domain name, subdomain name, URL parameters and directly from client settings. By catering to the specific needs of specific regions, we can provide a comfortable, familiar and intuitive environment for users to access the services that we provide.
|
||||
|
||||
## Links
|
||||
|
||||
|
||||
Reference in New Issue
Block a user