Home I18n和数据库移植 两个很炫酷但是不好用的概念 Goodbutnotpragmaticconceptions I18nandsupportingmultipledatabase
Post
Cancel

I18n和数据库移植 两个很炫酷但是不好用的概念 Goodbutnotpragmaticconceptions I18nandsupportingmultipledatabase

有感而发

工作这么多年,只有在最初的日子里对这两个概念很有激情。

之后却没在任何一个正式项目中使用到过。

i18n:  国际化。 可以允许我们一次性的写好 文字,就可以根据不同的语言支持来切换需要显示的语言。

可惜的是,有下面几个特点:

1. 不同的语言体系根本没法通用。比如:  对于英文的 "posted at 2015 by siwei" 和 中国的 “siwei 发表于 2015”, 语法结构完全不一样。 如果要分别写成 "posted at {0} by {1}" 和 "{0} 发表于 {1}"的话,也可以。

2. 维护起来太困难了。有没有见过某个项目中,只有en 等欧洲语言才可用,我们cn语言根本就没法用? 

2. 实用性很少。除了常见的几种论坛之外,很难见到跨国的大项目。(youtube 除外)

适应多种数据库。

这个特性从ORM刚诞生的时候就有了。最初接触到的是 hibernate. 只要你使用HQL, 就可以做到无缝移植。现在的rails也是这样。

不过现实中根本不是。用了MYSQL,就会一直用下去。用了ORACLE,也会一直用下去。 MYSQL可能与 sqlite最接近,但是很多小细节也不同。并且在rails代码里不可避免的会使用 native sql. 移植起来很费力气。

This post is licensed under CC BY 4.0 by the author.

脱离rails使用activerecord Usestandaloneactiverecordwithoutrails

Phantomjs初体验 Phantomjsin5minutes