web多语言url的设计
来源:互联网 发布:阿里云9元建站教程 编辑:程序博客网 时间:2024/05/22 14:33
因为项目要支持国际化,最近跟一个同事在讨论多语言版本下面url如何设计,假如我们需要支持en和cn的版本。
他倾向于支持如下的url格式,后续以格式1指代:
/en/group/abc.html/cn/group/abc.html
而我则倾向于只提供一套url,lang的信息在其它地方携带,后续以格式2指代,譬如:
/group/abc.html?lang=en
对于格式1,它的好处在于非常清晰的就告知用户当前网页是什么语言的,但是我觉得还有几个不足:
nginx location的适配,为了适配url里面的lang,我们需要将所有的location改成如下形式:
/(.+)/group/abc.html
改动比较大,同时nginx所有的location匹配都只能走正则匹配,性能稍微有点损耗。
url跳转,假如用户现在在 /en/group/abc.html下面,切换成cn页面,如何正确的跳转到/cn/group/abc.html,也是需要考量的,我并不认为这个很容易,尤其是在nginx以及后端django都需要按照统一规则处理情况下。
虽然有很多网站都是采用格式1的方式来支持国际化,譬如apple,nginx的官网,但是我发现当它们在涉及语言切换的时候,很多都跳转到了该语言的首页,可能这样实现更简单吧(这绝对是我的臆想!!!)。
对于我倾向的格式2,想到的有三种方式带上lang的信息:
- 参数携带,譬如上面的/group/abc.html?lang=en
- cookie携带,譬如在cookie里面设置 lang=en
- Accept-Language,当没有任何lang信息的时候根据Accept-Language判断
当用户切换语言,或者url参数里面有lang信息的时候,我们会将该lang信息设置到cookie里面,这样下次访问的时候就可以根据cookie里面的访问了。
可以看到,格式2有明显的几个好处:
- url不变,无论增加多种语言,url仍然是同一个url,语言切换的时候也不会进行url跳转。
- restful,我认为,在restful模式中,lang并不是资源,而是资源用来展示的一种方式,这个跟Content-Type类似。
但是,格式2也有一些不足的地方,主要就在静态文件缓存,因为是同一个url,浏览器会对静态文件缓存,如果切换了lang,那么很有可能缓存的仍然是切换之前lang对应的文件。
总之,两种格式的url在业界都有使用,据我观察,google,facebook,twitter在处理多语言的时候,采用的是格式2的方式,而我们在经过讨论之后,也决定采用格式2的方式。
- web多语言url的设计
- URL的设计
- go web开发之url路由设计
- 关于URL+method、通用参数封装的设计思路(java web,SSM框架)
- web.xml的URL Patten
- Web 端 URL 的处理
- 面向搜索引擎的URL设计
- 网站URL的设计规划
- 网站URL的设计规划
- 网站URL的设计规划
- web url
- Web 开发与设计语言大盘点
- Web 开发与设计语言大盘点
- Web 开发与设计语言大盘点
- Web 开发与设计语言大盘点
- Web 开发与设计语言大盘点
- Web开发与设计语言大盘点
- Web 开发与设计语言大盘点
- “不但攻击快,力量更是强的离谱,而且竟然还有对时间的掌控?在那一刻不仅时间变慢,我的动作也是受到了不用程度的影响!若不是自己身处在领域中,恐怕还真来不及挡住这一招!”想到这里,科里不由得暗自心惊
- OCM_环境准备
- 来吧,尽管来吧,我全都接下了
- 重温数据结构:堆,堆排序,优先队列,TopK问题
- 老中医治蛋变成绿色了
- web多语言url的设计
- mysql 连接url中useUnicode=true&characterEncoding=UTF-8 的作用
- sql2008中安全审计详细介绍
- wxTimer的简单实用
- LeetCode Binary Tree Traversal
- Axis2调用服务端
- COM组件中WindowsMediaPlayer的主属性和事件用法
- 动态内存分配(C++)
- js正则表达式验证限制文本框输入数字