本地化：子域、目录或域
我即将开始我的第一个多语言网站，我想征求大家的意见...
该网站将使用 jQuery，因此始终可以选择使用 jQuery 和会话的组合来管理语言环境。
在网站本地化方面，您发现哪种方法最具成本效益且可维护？
1) 子域（en.、fr.、es.）
2) 目录 (domain.com/fr/)
3) 域（domain.au、domain.it）
4) 会话和 JavaScript（以及任何特定插件）
保留请记住，我没有使用 .NET 平台，因此我将无法利用他们的方法。无论哪种最佳流程，无论是 PHP 还是 ColdFusion，都应该是相同的概念。
I'm about to embark of my first multilingual website and I'd like to get the opinion of everyone...
The site will be utilizing jQuery, so there's always the option of using a combination of jQuery and the Session to manage locale.
What method have you found to be the most cost effective and maintainable when it comes to localization for your website?
1) Sub-Domain (en., fr., es.)
2) Directory (domain.com/fr/)
3) Domain (domain.au, domain.it)
4) Session and JavaScript (and any particular plugins)
Keep in mind that I am not using the .NET platform so I will not be able to utilize their methods. Whatever the best process, whether it's PHP or ColdFusion, it should be the same concept.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是一种观点，而不是事实问答。答 - 所以这是我的观点，无论正确还是错误，
我都会选择子域 (en.mysite.com / fr.mysite.com) ：
你相当容易地控制它
搜索引擎会喜欢它（你可能
从索引中获得光环效应
每个）
同时保持相对和
绝对路径简单（不像
目录）
选择后
区域设置（我稍后将详细介绍），
一切都应该“正常工作”
session / javascript 不可靠
充其量，合规性的噩梦
更糟糕的是
是最后，您正在考虑的任何其他方法都没有明显的好处（我可以立即想到），这些方法也不适用于子域 - 但是，其他方法确实缺乏一些子域灵活性（例如路径）。
有些人正在回答您将如何选择访问者的正确区域设置，例如嗅探浏览器语言。这是一个不同的问题，有很多方法可以做到这一点 - 我建议全部完成，技巧（以及您的决定）是如何确定它们的优先级。例如：浏览器语言 vs. IP 来源 vs. cookie vs. 手动选择 vs. 等等 - 哪一个优先？
玩得开心，本地化可以是一项任务。 =)
This is kind of an opinion rather than a fact Q & A - so here's my opinion, be it right or wrong
I would go with subdomain (en.mysite.com / fr.mysite.com) :
you control it fairly easily
search engines will love it (you may
get a halo effect from indexing
each)
keeps both relative and
absolute pathing simple (unlike like
directory)
after selection of
locale (which i'll detail later),
everything should 'just work'
session / javascript are unreliable
at best, a nightmare of compliance
at worse
And finally, there are no perceivable benefits (that i can immediately think of) of any of the other methods you're considering that do not also apply to subdomain - however, the others do lack some of the subdomain flexibility (like pathing).
Some people are answering how you are going about chosing the proper locale of a visitor, such as sniffing the browser language. That is a different question, there's a number of ways to do that - I suggest to do them all, the trick (and your decision) is how to prioritize them. ex: browser language vs. ip origin vs. cookie vs. manual selection vs. etc - which takes precedence?
have fun, localization can be .....a task. =)
以下是一些可能对您有帮助的文章：
-多语言网站成功的 5 个秘诀2011年
-网站本地化的好技巧
-本地化 - 最佳实践
第一篇文章中的要点也就是说，如果您使用.au或.jp等国家代码顶级域名（ccTLD），可能对当地国家的搜索引擎更友好，但这仍然取决于您的需求。您想要定位替代语言还是整个国家/地区。您还需要注意的另一件事是，与使用子域（www.site/au、www.site/es）相比，维护多个站点（例如 ccTLD）的成本更高。
希望有所帮助。
Here are some articles that may help you:
-Top 5 Tips for Multi-Lingual Website Success in 2011
-Good tips for website localization
-localization - best practices
The point in the first article is, if you use a country code top level domain (ccTLD) such as .au or .jp, it may be more friendly to the search engine in the local country, but it still depends on your need. Do you want to target the alternative language or the whole country. Another thing you also need to be aware of is that the cost for maintaining multiple sites such as in ccTLD is higher in comparison to use subdomain instead (www.site/au, www.site/es)..
hope that helps.
我们通常使用本地化来检测客户端的浏览器语言。如果浏览器的语言是“FR”，我们将从语言文件夹中填充所有法语文件。使用单独的不同子域是不同的故事。
We, generally, use localization for detecting client's browser language. If browser's language is "FR", we're gonna populate all french language files from our language folders. Using separate to different sub-domains are different stories.