CMS的多语言机制

CMS做为内容管理平台，多语言是必备的功能之一。不过多语言本身也是比较复杂的，因此很多国内的CMS都无法支持多语言，有支持的，但是考虑不够全面，开发的时候，会出现各种BUG，导致很难完全使用。

整体上来讲，多语言类似把CMS的维度升级了，之前是一维的，平面的，多语言相当于增加了一个维度，每个语言就是一个站点，相当于之前是做一个站点，多语言可以在一个站点里面做出N个子站点。

比如，我们翻译英文，其实也可以翻译成其他中文，这边是服务1，翻译成服务2，类似多一个子站。站1叫服务1，站2叫服务2，两个还是有关联。听起来有点绕口，但是道理是一样的。

多语言主要涵盖界面翻译、内容翻译，此外还有一些配置、货币符号等相关联的，所以，不仅仅是翻译的问题，是要有一套完整的多语言体系和机制，本文就CMS的多语言机制做一个简单分析，仅供参考。

之前也讲过几篇关于CMS和多语言的，有兴趣可以点击阅览。

1. 界面如何翻译

很久很久以前，做软件都有一个语言包，用来翻译界面，语言包一般通用的格式是PO格式，里面的内容其实就是一一对应的翻译而已，没有什么特别。

这个只是对于界面，或者说皮肤的翻译，这个比较简单。

类比网站就是写死在代码的里面的翻译，比如代码里面写了个Home，那就翻译成首页。

补充一下，还是用得上 :) 后台界面很多是固定的，所以完全可以写死代码，界面翻译，这种就是类似于传统软件。

一般CMS中，这种菜单类的功能都是可以配置的，甚至很多页面都是CMS可以直接建出来的，但这部分可以属于建站部分，也可以属于内容部分，严格来讲，其实这部分不属于内容部分，因为内容只是article和tag之类的，菜单等部分属于建站部分。

在Drupal里面，对这类内容起了一个名字，叫配置，所有的这些设置，包括网站的名字、网站的介绍等等，类似于建站部分的工作，但是需要翻译，都叫配置。

Drupal的核心配置是可以翻译的，因此，只要生成了一个配置，这个配置在Drupal里面，就默认可以翻译了。

因此，解决了这类配置的翻译，也就是顺理成章的实现了菜单的翻译。

举例来说：

1. 全站的配置，站名、Logo、站点说明等。

2. 全站的主菜单，和菜单对应的URL，都要支持翻译。

3. 我们开发了一个功能，API读取淘宝店铺信息，后台要填写淘宝店铺名称、API Key等信息。

那么新建的这个页面和后台页面都要翻译的话，这些配置信息都要可以翻译，所以就是类似的配置翻译。

内容的翻译，是重中之重，那么要实现内容翻译，应该如何架构？

Drupal的内容翻译在内核自带，也就是每一个content，默认就有一个语言，如果只有一种语言，就是默认语言，如果启用了多语言，那么就有一个语言版本。

1）所有的语言的content id是相同的，所以启用了多语言加载content的时候，需要指定语言版本。

2）同一个content的翻译的不同语言的版本，做一个记录。

所以，数据表里面有一个source content，就是标记是从那个内容翻译过来的。

整体的架构，我们可以参考下图，从建站的角度来讲，配置翻译是一个核心要点，这样可以让所有模块都能兼容多语言。

另外，想要了解跟过关于CMS管理视频的产品，也可以了解我们的《开源在线视频教学平台介绍》。