资源文件（多语言）的管理

现在很多产品都有国际化或者说多语言的需求。即使产品现阶段不需要做多语言，但在产品设计上也大多会预留多语言的设计。

通俗来讲，多语言的设计也就是用资源文件的方式来编写程序代码。所有前端页面看得见的静态文字都不是写的死代码，而是用常量的方式获取的，资源文件里定义了所有的常量。

在这里我不会对多语言的实现做过多讲解（毕竟我不是技术专家，就不在这里班门弄斧了），我想跟大家分享的是，如何建置和管理多语言资源文件的内容。

写这篇文章之前，我在网上搜索了一下，并未找到相关文章，也无从参考，所以这也是我萌生写这篇文章的原因。把我的想法与大家分享。

大家在做多语言时常见的方法有：

一，针对软件系统的每一个页面或模块中的显示元素写键值对key-value。做得稍微好一点的，也只不过是把一些比较常用的重复度特别高的单独提取出来写键值对。这样做的好处是，思路很清晰，有多少页面就写多少分类的键值对，很容易查找。但是缺点就是重复度可能很高，不容易做风格的统一。这多半是开发的做法，省事。

二，比较激进的做法，就是不做任何分类（页面或模块的分类），而是整个系统都写在一起来做键值对key-value。这样做最大的好处是，容易保持语言风格的统一，几乎可以杜绝重复。缺点是非常不易查找，开发用起来会非常的不爽，日后资源文件的管理者也比较难以维护，不知道到底哪些地方会用到哪些Key。这种多半是项目经理的做法，反正我把所有的key和翻译都写出来了，开发你们爱用不用，我不管了。

那么有没有更好的方法呢？

结合上面两种方法的优缺点，我想到的解决方案是：

首先，把整个资源文件分成三个分类：一类是业务实体，一类是页面或模块，一类是通用。别急，容我一一解释他们到底是什么东西。

业务实体，这个词对于产品经理或者需求分析人员来说应该不陌生。我们在做产品需求分析的时候，首先是要分析用例和场景，也就是系统有哪些需求。然后会分析业务实体，这些用例有哪些实体来承载，最终来完成或实现业务价值。我们就拿学生管理系统来举例，学生可能就是一个实体，这个实体有学号，名称，性别，年龄等属性。我们就对他进行键值对key-value。之后常见会用到的他们的地方可能有，学生编辑页面每个属性前面的Label标签里的文字，学生列表Table表格上面的列头的名称文字等等。

第二类，页面或模块，就是系统要展示给用户的所有页面。比如刚刚说的学生列表页面展示，在这个页面上除了实体相关的内容需要国际化以外，还有一些与实体无关的部分。比如，按钮的名称，错误提示语等，这些的键值对key-value就需要写在这里。

第三类，通用，系统中一定存在一些类似通用模组或者通用控件。比如，系统级别的错误提示信息，通用翻页控件上面的文字等等，这些内容就需要写在这里了。

所以整个资源文件的结构类似下面的样子：（只要稍微讲解了业务之后，开发就很容易上手使用了。日后资源文件管理者维护起来也方便易读。）

<--分类1，业务实体-->

        <--实体1，学生-->name：姓名；sex：性别；key-value, key value...

        <--实体2，班级-->key-value, key value...

<--分类2，页面/模块-->

        <--页面1，学生列表-->key-value, key value...

        <--页面2，添加学生-->key-value, key value...

<--分类3，通用-->

        <--错误消息-->key-value, key value...

        <--通用控件-->key-value, key value...

总结：

	优点	缺点
每个页面或模块建key-value	维护简单，一目了然	容易产生大量重复的定义，不易做风格的统一
全局建key-value	几乎不会有重复定义	维护很不方便，开发不易使用。后期修改成本高
分三类建key-value	分层清晰，维护比较容易，开发使用也容易上手。 可能会有重复定义，但不会大量存在	需要先把业务实体分析正确，如果业务实体变动很大，那将是一个灾难

还是那句老话，所有的方法都没有绝对的好与坏，还是要看那种方法适合你和你的项目以及团队。

如果大家有更好的方法，也请多多指教，欢迎提意见和建议，非常感谢大家！