MultipleLanguageSystem多语言系统设计

因为项目需要，设计了多语言系统，需求是能够实时切换语言类型（例：CN,EN）

在经过思考以后，对原来的方案做了一些改进

一。原来的多语言数据保存为二进制文件，编剧用的xlsx，类似：

但是这样有他不好的地方：就是xlsx表在一个时间内只能一个人操作，如果多人同时操作，因为他是二进制文件，上传SVN时会产生冲突，这时候就很尴尬， 面临着要么自己白干要么别人白干的艰难选择。

所以后来做了2个方面的改进：一是将编辑工具由xlsx变为Unity的序列化的ScriptObject文本文件，二是拆分为单独的语言包，每种语言对应一份单独的ScriptObject文件。这样的好处是首先ScriptObject作为文本文件，svn操作时能够进行合并，那么多人协作就变为可能。然后拆分为单独的语言包后更加灵活，并且干净

而放弃用xlsx那么也损失了xlsx带来的一些命令和快捷操作的便利性，需要自己开发一些功能来使编辑更方便，比如最简单的增删改查

架构解释如下：

一。MultipleLanguageSystem作为核心管理，他的功能如下：保留当前的语言状态（CN,EN）;维持一个委托列表，当语言状态发生变化的时候需要通知所有注册组件重新请求对应语言数据

二。MultipleLanguageData多语言数据对象，保存所有的语言数据（CN,EN），已经当前应用的语言数据。MultipleLanguageSystem发生语言切换时也切换当前应用的语言数据（CN->EN)，并且对MultipleLanguageSystem提供数据支持（传入一个id，返回对应文本）

三。Text or TextMesh，TextMesh是Unity新加的文本格式，在字体效果上（Outline。。）要比原来的Text上要好很多，并且能够轻松实现图文混排，在新项目上的话我会考虑全部采用TextMesh。这一部分作为显示组件，在激活的时候要把自身注册要MultipleLanguageSystem（Action），接受到语言变更回调时，需要去和MultipleLanguageSystem请求新的对应语言文本，（MultipleLanguageSystem只是作为一个中转，一方面接受显示组件请求，另一方面从MultipleLanguageData数据对象中获得文本返回给显示组件）

大体的架构如此。但是在这里面，我一直有个地方犹豫不绝，那就是数据集的key，是一个int的id好，还是一个string好。

用id的话，当突然想在原来的id组里面插入一个（比如在2，3中插一个,因为id的不可重复性，那么会造成原来的id修改，而这无疑会导致原来项目中引用到这些id的内容需要全部变动），再一个就是id的意义不明确，不管是怎么定义（比如前2位表示啥，再后两位表示啥。。），总归不能很好的让人一看就能明白。

那么采用string呢。string可以让人一眼就能看明白这个数据集是啥意思。但是他也有坏处，一个是string作为一个key，要维持他的唯一性，在性能上不如id，而且填一个string会更容易出错（大小写了，空格了。。），而如果把他转换为Enum呢？因为数据的增大，这回导致这个Enum的长度喜人。。

最后项目中是采用了id,主要是从出错率和性能上考虑，而为了不会轻易变动id，会让持续添加的数据排列看起来不那么讨人喜欢