BirdGu

使用ruby gettext实现RoR应用的多语言化——Step by Step

BirdGu — Sat, 02 Dec 2006 16:18:35 +0800

作者: BirdGu 链接：http://birdgu.javaeye.com/blog/36970 发表时间: 2006年12月02日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

0. 写本文时使用的环境：
OS: MacOS X 10.4.7
Ruby 1.8.5
Rails 1.1.6
gettext 1.8.0

1. 安装ruby gettext
使用gem安装：

gem install gettext

gem会列出可以安装的gettext的版本。注意，如果是在Windows下安装的话，一定要选择后面带“(mswin32)”的选项，否则会有编译错误。

2. 修改config/environment.rb文件：
在文件头上加入：

$KCODE='u'

require 'jcode'
require 'gettext/rails'

3. 修改app/controllers/application.rb文件
在文件头加入

require 'gettext/rails'

在ApplicationController的类声明后加入对init_gettext的调用。参数是一个字符串，一般取项目名称。这是后面要说到的po和mo文件的文件名。这里假设取'project'。

init_gettext 'project'

4. 修改Rakefile
加入以下内容：

desc "Update pot/po files to match new version." 
task :updatepo do
  MY_APP_TEXT_DOMAIN = "project" 
  MY_APP_VERSION     = "project 0.0.1" 
  GetText.update_pofiles(MY_APP_TEXT_DOMAIN, 
                         Dir.glob("{app,lib}/**/*.{rb,rhtml}"), 
                         MY_APP_VERSION)
end

desc "Create mo-files for L10n" 
task :makemo do
  GetText.create_mofiles(true, "po", "locale")
end

5. 修改rb和rhtml文件，用“_()”调用代替裸字符串。
无论是在rb还是rhtml文件中，都通过“_()”函数得到多语言化的字符串。
比如controller:

class BlogController < ApplicationController
   :
   :
  def create
    @article = Article.new(params[:article])
    if @article.save
      flash[:notice] = _('Article was successfully created.')  #Here!
      redirect_to :action => 'list'
    else
      render :action => 'new'
    end
  end
   :
   :
end

_()函数的参数可以是任意的英文句子，而不需要象在Java应用中一样，遵循properties的命名规则。这样对英文版来说，基本没有额外的工作。

model中validation的错误信息：

validates_presence_of :title, :message => N_("can't be empty!")

注意，这里要用"N_()"，而不是“_()”。
作为主语的属性名称不用写，gettext会自动将属性名加在开头。否则，可以用"%{fn}"代入属性名。gettext会查询数据库，自动产生属性名称的字符串，产生规则是："类名|属性名"。如果属性名是由下划线分隔的多个单词，则将下划线替换为空格，第一个单词的首字母大写，其余单词全部小写。
例如User类的name属性，对应的是"User|Name"，"created_at"属性对应"User|Created at"。
在任意场合可以根据该规则使用多语言化的属性名，最常见的是在表头和表单中的标签。例如在rhtml文件中可以写：


	<%= _("User|Name") %>
	<%= text_field "user", "name" %>

在错误信息中还可以用“%d”代表validates_*中的某些参数，例如：

alidates_length_of :description, :minimum => 10, :message => N_("%{fn} is too short (min is %d characters)")

在view的rhtml文件中，所有需要多语言化的文本都要用“_()”代替，比如：

<%= _('Editing article') %>

<%= start_form_tag :action => 'update', :id => @article %>
  <%= render_partial 'form' %>
  <%= submit_tag _('Edit') %>
<%= end_form_tag %>

<%= link_to _('Show'), :action => 'show', :id => @article %> |
<%= link_to _('Destroy'), {:action => 'destroy', :id => @article}, :confirm => _('Are you sure?') %> |
<%= link_to _('Back'), :action => 'list' %>

6. 准备po目录。
在项目的根目录下创建目录“po”。然后在“po”目录下为没一种语言创建一个目录，目录名是语言代码，语言代码参见：
http://www.w3.org/International/resource-index.html#lang
中文一般用“zh”。其实，如果选择语言的过程完全由应用自己控制的话，目录名不遵循标准也没有关系。

7. 生成pot和po文件。
执行rake任务

rake updatepo

gettext会检查项目load路径中的所有的rb和rhtml文件，搜集调用“_()”或“N_()”的所有地方的参数，生成后缀为pot的文件，存放在po目录下，以及后缀为"po"的文件，在没一种语言的目录下各放一份。pot和po文件的文件名前缀就是前面调用“init_gettext”时的参数。所以如果在application.rb中写"init_gettext 'project'”的话，生成的文件就是“project.pot”和“project.po”。

8. 翻译po文件。
po文件是文本文件，可以使用文本编辑器编辑，但是必须使用Unicode编码。所以请使用支持Unicode的编辑器。另一种方式是使用poedit。（[url]http://www.poedit.org[/url）
在po文件中，没一个文本串的格式如下面的样子：

#: app/views/member/index.rhtml:49
msgid "submit"
msgstr ""

第一行是该字符串出现的位置。如果出现过多次，则会有多行。不要删除或修改该行，否则会影响下面说的merge过程。
第二行msgid就是调用“_()”或“N_()”时的参数。
第三行的双引号中应该填入相应语言的文本。

9. 生成mo文件
执行rake任务

rake makemo

该任务会在项目的根目录下生成locale目录。下面的内容到时候自己看一下就可以了，不需要动的。mo文件是二进制文件，是gettext在运行时真正要用的。

10. 选择语言。
gettext按一下顺序决定使用哪一种语言。
a. 调用GetText.bindtextdomain方法的参数
b. request参数lang
c. Cookie lang的值。
d. Http消息头中HTTP_ACCEPT_LANGUAGE的值。
e. 缺省值“en”（English）

如果让用户自己选择语言，那么只要在controller中用“cookies['lang']=”设置用户使用的语言代码就可以了。

如果要在view中强制使用某种语言的话，可以使用set_locale方法。由此甚至可以做到一个view中使用不用的语言。比如：

<% set_locale "fr" %>
<%=_("Hello world") %>
<% set_locale "en" %>
<%=_("Hello world") %>

11. 递增开发
“rake updatepo”是支持递增开发的。也就是每次运行“rake updatepo”的时候，如果某种语言的目录下没有po文件，则生成新的po文件。如果已经有po文件了，则只是补充新发现的字符串，原来已经翻译过的内容会得到保留，是一个"merge"的过程。这个过程中会发生两中情况，分别在po文件中用特殊的方式标记。
一种是在msgid前插入一行“＃:fuzzy”，比如：

#: app/views/member/index.rhtml:49
#: fuzzy
msgid "submit"
msgstr ""

这表明gettext在merget的过程中遇到某种冲突，需要翻译po文件的人来解决。不过究竟什么样的冲突会导致fuzzy，我现在也不是很清楚。好在这种情况并不多见。发生的使用可能会出现msgid和msgstr之间张冠李戴的情况。
解决冲突以后，一定要把“#: fuzze”这行删除，否则makemo的时候会出现警告。

另一种情况是原来的某个字符串不再被用到，这种情况下gettext并不会删除这个字符串，而是在msgid前加入一行“#: deprecated”。如果这个字符串确实不再被用到了，则可以将这一行连同msgid和msgstr全部删除。否则只删除“#: deprecated”这行，而保留msgid, msgstr。

12. 多人开发时的协作。
gettext可以支持不同的模块使用不用的po文件，不过我还没试过。一般的应用，所有的文本放在一个po文件（一种语言一个）中也可以了。这时如果多个开发人员都去维护po文件的话，在版本管理上可能比较麻烦。所以最好是由一个人统一负责“updatepo, 翻译，makemo”这三个步骤。在某种语言的po文件中找不到某个字符串的时候，gettext会直接显示msgid，这在开发时也够用了。

13. 参考资料：
gettext home page: http://www.yotabanana.com/hiki/ruby-gettext.html

Ruby-GetText-Package HOWTO for Ruby on Rails: http://www.yotabanana.com/hiki/ruby-gettext-howto-rails.html

Using Gettext To Translate Your Rails Application: http://manuals.rubyonrails.com/read/chapter/105

*: 本文中的部分例子代码来自上述参考资料。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

prototype.js+IE6的一个怪异问题。

BirdGu — Tue, 07 Nov 2006 15:54:16 +0800

作者: BirdGu 链接：http://birdgu.javaeye.com/blog/32934 发表时间: 2006年11月07日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

今天在调试一个功能的时候碰到了一个古怪的问题。
功能很简单。在一个页面中使用prototype.js的Ajax.Updater异步刷新一个div块的内容。后台是webworks，用JSP生成要填入div的HTML片段。
在FireFox中一切正常。但在IE6中只要触发这个功能，IE6立刻停止响应了，占用CPU接近100%。
通过跟踪发现，在FireFox中，XMLHttpRequest的readyState的变化顺序是0，1，2，2，3，4。而在IE6中是0,1,2，然后IE就停止响应了。

你们猜猜是什么原因。

稍后公布答案。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

ASP模式应用中多客户数据管理方案探讨

BirdGu — Sat, 21 Oct 2006 11:04:57 +0800

作者: BirdGu 链接：http://birdgu.javaeye.com/blog/28976 发表时间: 2006年10月21日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

ASP（Application Service Provider）模式应用与普通应用之间的一个重要差别是ASP系统需要管理多个客户的数据。不同客户之间的数据完全独立，没有关联。不允许一个客户查询另一个客户的数据。即使多个客户共享一个数据库，对单个客户来说，其它客户的数据可以看作是不存在的。这里主要讨论在J2EE应用中如何解决这个问题。当然，这里讨论的方法对于其它架构的系统可能也适用。

方案1：单数据源，单套表。
所有客户的数据都存放在一个数据库的同一套表中，在部分表中增加标示字段，表明该记录是属于哪个客户的。具体哪些表中要增加标示字段当然要看具体应用，不过我觉得可能大部分表示实体对象的表中都需要加。在很多查询条件中都需要包括这个标示字段。即使是用户自定义的查询，系统也需要在查询条件中加入该字段。

优点：数据源和数据库的管理都比较简单。数据源管理方面和普通的J2EE应用没有差别。

缺点：增加程序的复杂性。如果应用比较复杂，很多数据表都需要加入客户表示字段，很多查询都需要包括该字段，会比较麻烦。如果有遗漏，特别是查询条件中遗漏该字段，就会造成一个客户看到另一个客户的数据。另外，需要在系统的安全性方面做比较细致的设计。比如，某个功能通过在URL中包含某个实体的关键字以查询该实体的信息，或对该实体进行操作。在普通应用中后台只需要根据关键字查出该实体即可。但是在ASP应用中，就必须额外判定该实体是否属于当前登录用户，或者要在查询中条件中加入客户标示。当然如果有办法自动完成这样的检查或者自动修改发到数据库的查询条件，这个缺点就可以避免。只是我现在还没有想到这样做的好方法。

-------------------------------------
方案2：多套表，多数据源

数据库中每个客户一套表。可以是MySql, PostgresSQL, SQLServer中的不同数据库，或者Oracle中的不同schema。在应用服务器中配制不同的数据源，或者使用不同的连接池。在访问数据库，需要得到数据库连接时，根据当前用户所属的客户选择合适的数据源或者连接池。

优点：不同客户的数据物理分离，安全性比较好。除了获取数据库连接部分的程序以外，其它程序和普通应用没有两样。不同客户的数据可以放置在不同的数据库服务器中，分担数据库服务器的负荷。

缺点：数据库连接的利用效率不高。ASP模式的主要客户是中小企业。这样带来的结果是客户数可能会很多，但是单个客户的用户数和并发登录数都不会太多。在系统这边来说，则是数据源或连接池很多，但每一个的利用效率都不高。在数据库服务器这边仍然会有很多连接，因为每个数据源或连接池都需要保持一定数量的可用连接。这样通过连接池共享数据库连接而减少总连接数的好处被大大削弱了。

另一个缺点是如果需要增加客户时，需要在应用服务器中配制新的数据源，或者修改应用自己的数据库连接池配制。某些情况下可能无法作到在应用不中断的情况下使这些配制生效。

------------------------------------
方案3：多套表，多Schema，单数据源。

这个方案基本是方案2的变种。很多数据库提供Schema，比如PostgresSQL中，同一个数据库下可以有多个Schema，Oracle中，每个用户就是一个Schema。即使用同一个用户登录数据库，只要在表名前加上schema名字，就能访问不同schema中的表。不同客户的数据就可以存放在不同的schema中。这样就能用同一个数据源或连接池，只是在所有的表名前要根据当前用户加上合适的shcema名字。如果要程序员自己这么做当然是很麻烦的。但如果用Hibernate就方便了。因为Hibernate中可以配制default schema，Hibernate在生成SQL时会自动在表名前加上schema名字。

因此如果使用Hibernate实现该方案就需要多个SessionFactory，每个客户对应一个SessionFactory。除了default schema以外，这些SessionFactory的配置完全一样。当程序需要SessionFactory的时候，需要有一个分配程序根据当前用户选择合适的SessionFactory。这些SessionFactory可以在系统启动时根据配制文件全部建立好，也可以采取lazy initialize的方法，这样也能支持动态增加客户。

优点：除了方案2的优点以外，共享数据源或连接池，效率更高。

缺点：对实现手段有一定依赖性。使用Hibernate会比较容易实现，其它方式我不清楚。每个SessionFactory都会有一定开销。多个SessionFactory会增加这部分开销，增加到多少程度，对性能有多少影响还有待测试。多个SessionFactory的情况下，二级缓存会否互相干扰，还是每个SessionFactory有各自自己的二级缓存也有待测试。

------------------------------------
所有以上方案都是所有客户共享同一个应用（WAR或EAR）。这种方式有一个缺点，不过这个缺点和数据源无关。如果用户可以以点菜式的方式选购不同功能，也就是说虽然不同客户共享一个应用，但是提供给他们的功能是不同的。这种情况下，程序中会有很多地方要判断用户是否可以使用某功能。这会带来另一种麻烦。这个和权限控制有类似，也许可以用Acegi之类的框架解决。但和权限控制又不完全一样。因为有时简单地提示用户他无权使用某功能可能不够友好，而需要以一种更优雅的方式提供用户降级过的系统功能。当然这个和具体应用有关，这里就不展开了。

------------------------------------
方案4：多套表，多应用

这个方案和以上方案不同，除了数据物理分离以外，应用也物理分离。每个客户有各自自己的WAR或EAR。如果使用方案3中的多Schema的方法，那么数据源可以共享，每个应用的SessionFactory有不同的default schema。

优点：应用简单。这样的应用和普通的J2EE应用没有任何区别。支持高度定制化的系统功能。每个应用基本相同，又可以有很大差别。比如用户没有选择的功能更本就不部署。

缺点：应用服务器中每个应用都会有一定的开销，占用一定的固定的内存。这个开销来自于应用服务器管理应用的数据结构；每个应用的class loader，和读入的类的字节码（应用服务器会判断出不同应用的同样名字的类具有同样的字节码，从而只保存一份吗？对次我表示高度怀疑）；每个应用还可能会有自己的线程，比如任务调度线程。这些开销可能会使一个应用服务器能部署的应用不会太多（和ASP模式的潜在客户数比较），从而在客户数比较大的情况下需要增加应用服务器的数目。

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

[原创]巨星沉浮——看看超级计算机排行榜。

BirdGu — Fri, 29 Sep 2006 15:08:16 +0800

作者: BirdGu 链接：http://birdgu.javaeye.com/blog/25312 发表时间: 2006年09月29日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Top500 (www.top500.org) 项目开始于1993年。目的是跟踪高性能计算领域的发展趋势。每年6月和11月会推出全球运算速度最快的500个computer systems (因为集群技术的使用，有些系统可能已经不适合继续称为计算机了)。Top 500项目使用Linpack基准测试程序，测试结果的单位是FLOPS，即每秒浮点运算数。不过常用的单位是GFLOPS，1G等于10的9次方。近年来也常用TFLOPS，就是10的12次方了。

从1993年到现在13年时间了，回顾这个榜单，也能从一个侧面反映这10多年来IT业界的一些历史。

厂商篇

说起超级计算机就不能不说Cray。1993年6月的Top500中Cray占到了205台，41.00%。当年Cray在超级计算机领域的领导地位可见一斑。

不过93年的时候Cray已经在走下坡路了。到1996年11月（当年Cray的创始人Seymour Cray在一次交通事故中去世，同年Cray被SGI收购）Cray在Top500中的份额跌到了26.2%，然后是2000年6月的10.8%， 2003年6月的5.2%，2006年6月的3.2%(16台)。我们清晰地看到了巨星陨落的轨迹。

80年代后期MPP（大规模并行计算）开始崛起。这方面的先驱者包括了Thinking Machines，93年6月榜单上的另一个明星。虽然数量不多，只有54台，占10.8%，但是它包揽了前四名，再加上第7名，Top10中占了一半。而Cray只能包揽第9到第20。当时Cray对MPP是不太感冒的，认为为这样的系统开发软件是非常困难的。

但是Thinking Machines的衰落却比Cray要快得多。因为他的业务过份以来DARPA的合同，靠着DARPA的合同在1989年获得了盈利（82年成立的），但是1991年DARPA受到批评，认为它在采购中过分偏向Thinking Machinese，对IBM和Cray不公平。因此，1992年，公司再次陷入亏损。1994年申请破产保护，然后硬件部分出售给SUN，公司本体转型为一家做数据挖掘的软件公司，然后在1999年被Oracle收购。

在Top500榜上，Thinkning Machines的份额在94年6月上升到15.8%，Top10中还有4台。95年6月跌到7.40%，99年6月，从榜上完全消失。

DARPA从善如流，给了IBM和Cray以公平，却毁掉了Thinking Machines。

今天IBM无疑是Top500上的天王巨星。2006年6月，Top500中IBM占了47.8%（239台），超过93年时的Cray。而且IBM包揽了前3名，再加上第8名，Top10中有4个，11名到20名中还有7台IBM。今天在超级计算机领域，IBM已经远远超过了当年Cray曾取得过的地位。

谁能想到在93年6月的榜单上，IBM的成绩是0呢？不过到当年11月的时候，IBM就已经有16台上榜，最好的成绩是一台IBM 9076-005 SP1，排名76。这应该是属于IBM RS6000系列的。

另外，HP的发展也很快。93年6月的时候只有3%的份额，到2000年6月上升到10.6%，2006年6月的时候达到了31.2%，仅次于IBM。而且这两家加起来就有79%份额。所以第三名Dell就只有可怜的4.4%的份额了。

不过93年HP的成绩是有水分的。当年列在HP名下的有一个DECmpp SX 200，排名175，写的Vendor是Hewlett-Packard(Compaq)。但是当时DEC还没有被Compaq收购，Compaq也没有被HP收购。可怜的DEC!

Top500还有一个大输家，就是日本。93年6月富士通，日立，NEC三家合计站了20%，但是到2006年6月，这个比例已经下降到了不足3%。日本在超级计算机领域已经被美国远远甩在了后面。不过超级计算机毕竟是要用钱堆出来的，所以这也从侧面反映了日本在90年代以后经济上的衰退。

不过日本也并非没有亮点。NEC的Earth Emulator在2002年6月到2004年6月间连续两年占据榜首位置，即使到了2006年6月仍然据第十。Earth Emulator拥有640个计算节点，每个节点有8个向量型的运算处理器。这个目前普遍采用的使用通用CPU的MPP系统，在思路上还是有很大不同的。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐