一个i18n的方案请人拍砖

我认为这个问题已经脱离I18N的范畴了。

用户输入一个英文，你先将其翻译成中文，然后返回给他搜索结果。

这显然是属于机器翻译的范畴了。

两个方案，1 使用现有的翻译api或者字典
         2 人工建立一个翻译词库

你现在的方式其实就是方案2。

这个翻译的问题解决了，问题还没完---你还得给他返回搜索结果。

这个问题同样也有两个方案：
1 对用户输入进行翻译
2 在索引的数据上，添加对应的英文关键词。

你在用的是1 ，1修改了用户的输入，有时显得很笨拙。
其实2也很简单，你为luccnce的索引加上一个keyword字段，然后将中文英文都填进去即可。

这是个比较复杂的需求,compiere(一个开源的erp)中是使用专门一个表存多语言数据的,取数据的时候根据需要的语言用sql取出相应的数据,osCommerce中也有类似的实现
用hibernate的话,hmmm,可能就不能直接简单的load,get,saveOrUpdate了

    楼主你的需求想通过国际化来实现，思路似乎不对。国际化，并不适用搜索。国际化更加适应这样的场景：根据用户的使用环境中来决定显示的文本，这种映射关系是程序预先定义好的，并且这种关系只能是单向的（key-->value）。

    如果要实现你的需求，使用lucene或者其他的映射方式还是比较实际一点。

做i18居然用数据库，明显的把问题复杂化嘛。影响服务器的性能姑且不说，“笔”的事例我觉得跟业务逻辑的细分有关。

产品名称有必要放在resource文件中吗。。真的是简单问题复杂化。。。

明显是个应用问题，非要套上I18N的枷锁。
I18N的概念的初衷是为了解决，相同的功能在不同地区及语言环境的显示问题。
非要使用这个思路解决产品本身功能性问题，就不是特别合适。既不方便，也很难优化提高效率。
有个朋友说的很对，东方和西方在很多思想上是不一致的。 只有却定功能的前提下，用另一种语言让特定的用户使用而已，而非解决软件的操作方法和查询结果的多寡问题。 就算你费劲的让他输入特定语言查到了特定解决，但他使用软件的操作方法和思维习惯你能兼顾的了吗？
如果你的方案没办法解决根本问题，就不要在一个“就和”的方案上走下去。走的越远，一旦碰壁，就需要退的更远。

总之，I18N很难承受内容管理之重。

呵呵，居然想起这个帖子了， 先把应用场景说清楚，这样比较好讨论：

比如我的站点是电器公司的，客户关心冰箱，除了品牌，价格外，最注重的就是它的功能，有许多条款确实不需要做i18n，比如电耗、容积、这些是每台冰箱都有的东西，可以用一个个field来表示，但是以后的产品可能有新的功能，这个就没办法通过增加field来是实现了，因此留了个descript来容纳这些东西：

比如 冰箱A:  WLAN 下载 菜谱 光合 保鲜
比如 冰箱B:  臭氧 异味清除 光合 保鲜
     冰箱C:  真空保存 臭氧杀菌

这里这些关键词是我人为抽取出来的，这个设计是为了 对这些description做一个i18n的搜索用的：

比如输入“臭氧"， 冰箱B和C应该被显示出来，而英国人输入ozone，得到是一致的结果，这里利用了hibernate search,来自动为description分词，索引。


简单一句话，这个方案是针对输入无法预测的string字段的一个解决办法。