Merging other languages
This commit is contained in:
James Miranda
178
en/10.1.md
178
en/10.1.md
@@ -1,85 +1,93 @@
|
||||
# 10.1 设置默认地区
|
||||
## 什么是Locale
|
||||
Locale是一组描述世界上某一特定区域文本格式和语言习惯的设置的集合。locale名通常由三个部分组成：第一部分，是一个强制性的，表示语言的缩写，例如"en"表示英文或"zh"表示中文。第二部分，跟在一个下划线之后，是一个可选的国家说明符，用于区分讲同一种语言的不同国家，例如"en_US"表示美国英语，而"en_UK"表示英国英语。最后一部分，跟在一个句点之后，是可选的字符集说明符，例如"zh_CN.gb2312"表示中国使用gb2312字符集。
|
||||
|
||||
GO语言默认采用"UTF-8"编码集，所以我们实现i18n时不考虑第三部分，接下来我们都采用locale描述的前面两部分来作为i18n标准的locale名。
|
||||
|
||||
|
||||
>在Linux和Solaris系统中可以通过`locale -a`命令列举所有支持的地区名，读者可以看到这些地区名的命名规范。对于BSD等系统，没有locale命令，但是地区信息存储在/usr/share/locale中。
|
||||
|
||||
## 设置Locale
|
||||
有了上面对locale的定义，那么我们就需要根据用户的信息(访问信息、个人信息、访问域名等)来设置与之相关的locale，我们可以通过如下几种方式来设置用户的locale。
|
||||
|
||||
### 通过域名设置Locale
|
||||
设置Locale的办法之一是在应用运行的时候采用域名分级的方式，例如，我们采用www.asta.com当做我们的英文站(默认站)，而把域名www.asta.cn当做中文站。这样通过在应用里面设置域名和相应的locale的对应关系，就可以设置好地区。这样处理有几点好处：
|
||||
|
||||
- 通过URL就可以很明显的识别
|
||||
- 用户可以通过域名很直观的知道将访问那种语言的站点
|
||||
- 在Go程序中实现非常的简单方便，通过一个map就可以实现
|
||||
- 有利于搜索引擎抓取，能够提高站点的SEO
|
||||
|
||||
我们可以通过下面的代码来实现域名的对应locale：
|
||||
|
||||
if r.Host == "www.asta.com" {
|
||||
i18n.SetLocale("en")
|
||||
} else if r.Host == "www.asta.cn" {
|
||||
i18n.SetLocale("zh-CN")
|
||||
} else if r.Host == "www.asta.tw" {
|
||||
i18n.SetLocale("zh-TW")
|
||||
}
|
||||
|
||||
当然除了整域名设置地区之外，我们还可以通过子域名来设置地区，例如"en.asta.com"表示英文站点，"cn.asta.com"表示中文站点。实现代码如下所示：
|
||||
|
||||
prefix := strings.Split(r.Host,".")
|
||||
|
||||
if prefix[0] == "en" {
|
||||
i18n.SetLocale("en")
|
||||
} else if prefix[0] == "cn" {
|
||||
i18n.SetLocale("zh-CN")
|
||||
} else if prefix[0] == "tw" {
|
||||
i18n.SetLocale("zh-TW")
|
||||
}
|
||||
|
||||
通过域名设置Locale有如上所示的优点，但是我们一般开发Web应用的时候不会采用这种方式，因为首先域名成本比较高，开发一个Locale就需要一个域名，而且往往统一名称的域名不一定能申请的到，其次我们不愿意为每个站点去本地化一个配置，而更多的是采用url后面带参数的方式，请看下面的介绍。
|
||||
|
||||
### 从域名参数设置Locale
|
||||
目前最常用的设置Locale的方式是在URL里面带上参数，例如www.asta.com/hello?locale=zh或者www.asta.com/zh/hello。这样我们就可以设置地区：`i18n.SetLocale(params["locale"])`。
|
||||
|
||||
这种设置方式几乎拥有前面讲的通过域名设置Locale的所有优点，它采用RESTful的方式，以使得我们不需要增加额外的方法来处理。但是这种方式需要在每一个的link里面增加相应的参数locale，这也许有点复杂而且有时候甚至相当的繁琐。不过我们可以写一个通用的函数url，让所有的link地址都通过这个函数来生成，然后在这个函数里面增加`locale=params["locale"]`参数来缓解一下。
|
||||
|
||||
也许我们希望URL地址看上去更加的RESTful一点，例如：www.asta.com/en/books(英文站点)和www.asta.com/zh/books(中文站点)，这种方式的URL更加有利于SEO，而且对于用户也比较友好，能够通过URL直观的知道访问的站点。那么这样的URL地址可以通过router来获取locale(参考REST小节里面介绍的router插件实现)：
|
||||
|
||||
mux.Get("/:locale/books", listbook)
|
||||
|
||||
### 从客户端设置地区
|
||||
在一些特殊的情况下，我们需要根据客户端的信息而不是通过URL来设置Locale，这些信息可能来自于客户端设置的喜好语言(浏览器中设置)，用户的IP地址，用户在注册的时候填写的所在地信息等。这种方式比较适合Web为基础的应用。
|
||||
|
||||
- Accept-Language
|
||||
|
||||
客户端请求的时候在HTTP头信息里面有`Accept-Language`，一般的客户端都会设置该信息，下面是Go语言实现的一个简单的根据`Accept-Language`实现设置地区的代码：
|
||||
|
||||
AL := r.Header.Get("Accept-Language")
|
||||
if AL == "en" {
|
||||
i18n.SetLocale("en")
|
||||
} else if AL == "zh-CN" {
|
||||
i18n.SetLocale("zh-CN")
|
||||
} else if AL == "zh-TW" {
|
||||
i18n.SetLocale("zh-TW")
|
||||
}
|
||||
|
||||
当然在实际应用中，可能需要更加严格的判断来进行设置地区
|
||||
- IP地址
|
||||
|
||||
另一种根据客户端来设定地区就是用户访问的IP，我们根据相应的IP库，对应访问的IP到地区，目前全球比较常用的就是GeoIP Lite Country这个库。这种设置地区的机制非常简单，我们只需要根据IP数据库查询用户的IP然后返回国家地区，根据返回的结果设置对应的地区。
|
||||
|
||||
- 用户profile
|
||||
|
||||
当然你也可以让用户根据你提供的下拉菜单或者别的什么方式的设置相应的locale，然后我们将用户输入的信息，保存到与它帐号相关的profile中，当用户再次登陆的时候把这个设置复写到locale设置中，这样就可以保证该用户每次访问都是基于自己先前设置的locale来获得页面。
|
||||
|
||||
## 总结
|
||||
通过上面的介绍可知，设置Locale可以有很多种方式，我们应该根据需求的不同来选择不同的设置Locale的方法，以让用户能以它最熟悉的方式，获得我们提供的服务，提高应用的用户友好性。
|
||||
|
||||
## links
|
||||
* [目录](<preface.md>)
|
||||
* 上一节: [国际化和本地化](<10.0.md>)
|
||||
* 下一节: [本地化资源](<10.2.md>)
|
||||
# 10.1 Time zones
|
||||
|
||||
## 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.
|
||||
|
||||
Go defaults to the "UTF-8" encoding set, so i18n in Go applications do not need to consider the last parameter. Thus, in our examples, we'll only use the first two parts of locale descriptions as our standard i18n locale names.
|
||||
|
||||
> 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
|
||||
|
||||
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:
|
||||
|
||||
### 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:
|
||||
|
||||
- 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:
|
||||
|
||||
if r.Host == "www.asta.com" {
|
||||
i18n.SetLocale("en")
|
||||
} else if r.Host == "www.asta.cn" {
|
||||
i18n.SetLocale("zh-CN")
|
||||
} else if r.Host == "www.asta.tw" {
|
||||
i18n.SetLocale("zh-TW")
|
||||
}
|
||||
|
||||
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,".")
|
||||
|
||||
if prefix[0] == "en" {
|
||||
i18n.SetLocale("en")
|
||||
} else if prefix[0] == "cn" {
|
||||
i18n.SetLocale("zh-CN")
|
||||
} else if prefix[0] == "tw" {
|
||||
i18n.SetLocale("zh-TW")
|
||||
}
|
||||
|
||||
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.
|
||||
|
||||
### 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"])`.
|
||||
|
||||
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 "]`.
|
||||
|
||||
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 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 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" {
|
||||
i18n.SetLocale("en")
|
||||
} else if AL == "zh-CN" {
|
||||
i18n.SetLocale("zh-CN")
|
||||
} else if AL == "zh-TW" {
|
||||
i18n.SetLocale("zh-TW")
|
||||
}
|
||||
|
||||
Of course, in real world applications, we may require more rigorous processes and rules for setting user regions
|
||||
|
||||
- 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 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
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
|
||||
- [Directory](preface.md)
|
||||
- Previous one: [Internationalization and localization](10.0.md)
|
||||
- Next section: [Localized resources](10.2.md)
|
||||
|
||||
Reference in New Issue
Block a user