项目的 v1.0 完成了，然后被告知，需要添加 i18n 支持。我们用的框架是 struts2 + spring，其中 spring 只做 bean 相关的生产以及配置工作，按照最简单的，就是建立一个个的 .properties 文件。在 1.0 版本的系统里，我把所有的 Action 都去继承自己写的一个 AbstractAction (简称 AA ) 了，并且，我在这个 AA 里重载 了 ActionSupport 的 getText(String key) 方法，去我们数据库内的一张 messages 表内取与 key 对应的文本。但是没有考虑 i18n。当然，如果在这个基础上添加 i18n 支持的话，不外乎添加一个 locale/language 的字段，简单。
麻烦的是，页面上的 <s:text name="xxx"/> 好像用不了，只能改为 <s:property value="xxx" escape="true/false"/>。早上，小组开了个小会讨论 i18n 的解决方案。最后确定，采用通用的 .properties 文件的做法。但我还是觉得这个做法不是那么多好，原因如下：
1. 开发期间，修改资源文件，当前的这个 web context 不断的 reload，麻烦，若系统添加了需要登录的权限验证，那就是超级麻烦。
2. 对于 key-value-pair 的管理，按照 DRY 的原则，若 value 相同，那么就应该把 key 置为相同的，可如果是在两个 Action 里的呢？向父类 AA 里提取？那么，命名方式呢？(我们现在采取了如此多命名方式：login.invalid_username, profile.change_password_success，.前的是 Action 的名字)。
3. 对于问题 2，独立开发的话，问题不会很大。但是小组配合，若 partner 不在旁边的那个位置，这就是一场灾难。
4. <s:text/> 方法很好用，但是仅限于在 view/action 层。我们系统里有一个导出 excel 功能，表头 label 的 i18n，好吧，我功力太浅，没有找到在一个外部 utils 包内的完全脱离语境的情况下如何取得这些 resource bundles。----关于问题1，可能有人认为统一改好后统一测试不就得了。但是作为一个 web 开发人员，我个人认为，看到页面效果后再进行下一步，是给我前面动作的肯定，信心的提升，不看页面就往下走，可能效率极高，但是更可能自找麻烦。
TDD 不是就认为我们应该多测试么？
麻烦的是，页面上的 <s:text name="xxx"/> 好像用不了，只能改为 <s:property value="xxx" escape="true/false"/>。早上，小组开了个小会讨论 i18n 的解决方案。最后确定，采用通用的 .properties 文件的做法。但我还是觉得这个做法不是那么多好，原因如下：
1. 开发期间，修改资源文件，当前的这个 web context 不断的 reload，麻烦，若系统添加了需要登录的权限验证，那就是超级麻烦。
2. 对于 key-value-pair 的管理，按照 DRY 的原则，若 value 相同，那么就应该把 key 置为相同的，可如果是在两个 Action 里的呢？向父类 AA 里提取？那么，命名方式呢？(我们现在采取了如此多命名方式：login.invalid_username, profile.change_password_success，.前的是 Action 的名字)。
3. 对于问题 2，独立开发的话，问题不会很大。但是小组配合，若 partner 不在旁边的那个位置，这就是一场灾难。
4. <s:text/> 方法很好用，但是仅限于在 view/action 层。我们系统里有一个导出 excel 功能，表头 label 的 i18n，好吧，我功力太浅，没有找到在一个外部 utils 包内的完全脱离语境的情况下如何取得这些 resource bundles。----关于问题1，可能有人认为统一改好后统一测试不就得了。但是作为一个 web 开发人员，我个人认为，看到页面效果后再进行下一步，是给我前面动作的肯定，信心的提升，不看页面就往下走，可能效率极高，但是更可能自找麻烦。
TDD 不是就认为我们应该多测试么？
第二个问题,多搞几个文件就可以了,不同的propertie文件也可以有同样的key啊,只要你jsp里搞好bundle哪个文件
就好
跑起来后确实很舒服，修改小遗漏也很方便。
但是开发阶段的扰人哪
我们现在有分文件，基本上一个 action 对应一个 properties 文件，这个也是业界推荐的。
问题2是这些 pair 的管理问题，这个项目里个位数级别的页面数我已经觉得烦了，真怕大项目里做这事。就是不同的人做不同的页面，然后可能一大堆的重复。再可能同时往父类的 properties 文件里提，然后，在 svn update 的时候，一大片鲜红的 conflict 其他几个问题，在开发阶段头疼，特别是一开始没有想到项目在后续阶段需要支持国际化的这个时候。
另外，讨论的人真少