EE-Forum.org的WP多语言版本改造

引子——被“樯”逼出的故事

为方便英文内容，需要一个全英文站点。本打算在国外平台上创建博客，这半年多我已创建过两个，不久竟然都被“樯”了（应该和我去创建博客没关系吧， 相应的平台网站整体性被“樯”）。其中一个被“樯”几个月后，又可从国内访问了。这样的遭遇并不仅是最近这两次，更早以前我还试过。这么被折腾几次，恢复 了也不敢继续用，因为是长期工作角度的考虑，真被它玩不起。无奈还是考虑放在自己的网站上。本打算在ee-forum.org下另装一套英文wp，但发现 有些多语言支持插件描述的功能相当不错，就起了直接改造ee-forum.org支持多语言的念头。

方案选择

在WP的插件库中搜寻，发现不少多语言支持的方案（可用multilingual, language等关键字搜索）。大约浏览了多个类似功能插件的介绍，其中有一款看似不错，但是收费，而本站解决方案全部采用的是免费的wp资源。通过阅读插件描述，发现©xili的几款插件(其插件主页，竟然也被“樯”了！），思路简洁合理，它完全基 于wp本身的数据结构（参见：WP标签和分类的数据结构和使用特点）和多语言支持（基于.mo）拓展出可实时切换的多语言支持功能，且有较多的下载数，和好评数。特别是，最近正紧跟wp3.0，3.1进行更新。此外，它看来是有实力的专业的机构（我并没有去特意了解）所提供，xili系列还有许多其它插件。于是我选择了 xili所称“多语言三部曲”即：xili-language, xili-dictionary, xili-tidy-tags。当然，这有个前提，即所采用的主题界面信息使用_e(), __()方式，支持语言翻译。

实施

做此工作没有找到其他可借鉴的信息，也走过一些弯路，这里只简要报告成功的过程，希望它对有类似需要的朋友有所帮助。

• 从后台安装xili-language, xili-dictionary, xili-tidy-tags，启用之。
• 进入xili-language设置，已发现了两个语言：zh_CN, en_US（另外还有en_EN相当于默认的后台语言吧。这个方案可添加N种语言，但我只需要2种），所以几乎无需更改什么设置。
• 为已有的文章（posts）、页面等设置语言（此方案会根据文章或页面的语言来决定整个界面语言）。
• 更新各语言的.mo：这是关键的第二步。打开xili-dictionary，导入当前主题的词语、当前分类词语、网站信息，导入后形成了巨大的 词汇表，其目的是为每个语言形成完整的互相对应的词语，在xili-dictionary的界面上可以完成这一工作，但我采用导入后，分别导出生成新的 po（我的方案是两种：zh_CN.po, zh_US.po），然后用PoEdit分别进行翻译，然后编译成mo上传（这个方案绕开了xili-dictionary的词汇表管理，似乎有缺点，也 有方便之处）。
  这一过程完成后，多语言界面就生效了。
• 标签改造：这是其多语言改造的第三步。打开Tidy Tags，它将自动所有当前标签的表，然后将其按语言分组，这样，使用其附带的Tags cluds小工具，就可以显示不同语言的标签云了。（我还没发现标签自动对译捆绑的方法，或者是因为有些功能还没研究透彻:-)）
• 其它问题：这些琐碎的问题占了大部分工作时间。有些细致的设置，比链接的按语言分类、对边栏标题的支持等。其中，边栏小工具的标题，我是手工添加到mo中的。有几款插件不支持，只好淘汰了。

小结

环境：Linux/MySQL/WordPress 3.1 (zh_CN), UTF-8, Mimbo 3.0 theme

完成的多语言功能要点：

• 形成了简体中文（zh_ch）和英语（en_us）两种语言版本，并可随时动态添加更多语种。
• 按浏览器语言自动选择进入主页的语言。
• 按文章/页面的语言自动选择界面语言。
• 不同主页的语言界面信息全部是本语言，本语言的文章（posts）被优先显示。
• 整个分类系统（及说明）有完整的多语言版，且通过分类索引时，只出现该语言的内容（自动添加例如?lang=en_us这样的参数）。
• 在使用标签时，应当只选与post/page设置同语言或跨语言组的。
• 在导航菜单可添加语言版本选择菜单。

还遗留一些小问题，例如：

• 如何控制在某一语言界面中完全不显示其它语言的文章、页面。这涉及到较多方面。
• 标签如何实现像分类那样的完全对应。
• 文章、页面的语言对应版本之间可设置链接，但尚不知如何简单切换。
• 等等。

其中有些是我对这个方案的细节了解运用不够，这套插件本身也有不少可改进的空间。还有些似乎与使用的汉化版有某种关系：这样的多语言方案，其实由纯 的原语版本做起更好，更纯粹。换言之，有这种灵活的多语言方案，就不应该用那种死板的“汉化”改造方式，这一点，也是我们设计企业应用方案时的一个基本考 虑。

是二级域名也要备案，还是白名单来了？

刚刚访问网站的邮件服务子域名， http://mail.ee-forum.org ，得到如下画面：

未备案的二级域名解析

其它几个子域名，例如一直可以正常访问的 calendar.ee-forum.org，也得到上述结果。这些子域名和邮件服务，都是使用google的免费站点服务，邮件迄今工作是正常的，而在线文 档，则几个月前开始，进入不能用状态（偶尔能打开一下），协作站点（sites，提供类似在线协作编辑站点页面的功能），同样也不能用很久了，这些明显都是被“墙”掉的， 你访问时会得到服务器超时或无法解析的错误，和上述提示不是一回事。

而以上上述几个子域名，都是用“URL转发”的方式，指向谷歌的对应网址的，奇怪的是，在得到上述阻截的同时，一级域名，ee-forum.org 访问是正常的（这是国内已正常备案的域名），而URL转发的目标，例如 https://mail.google.com/a/ee-forum.org 也是正常可访问的，登录到我的域名解析服务商那里看，也没有异常。

这就奇怪了：要么，这是G.F-W检测域名解析服务的机制有一点偏差，把这种情况判别为需要备案；要么，就是开始要求二级域名也要备案？或者是域名指向国外链 接也要备案？如果是后者的话，那就意味着白名单。

所谓白名单，就是说一切可以看见的，都是预先备案的。打个比方说，你在广场上可以随意和人交流，但你不想 和潜在的疯子对话，你很可能通过其它途径，了解疯子的特征，然后拒绝符合这种特征的人，这就是黑名单策略。然而，有人也许会要求所有说话的人先提交一个 精神正常的证明，然后你才愿意与他对话（大家是否会认为他才精神不正常呢^_^）。这两种策略，就如同其名字一样，是天地之别。也许妈妈正在高堂上说：孩子，不要和陌生人说话。

顺便说一下，不知何时开始，曾经正常很久的 http://groups.google.com/group/Enterprise-Engineering 也不能访问了。到底是什么法律决定上述的非常正常、增值、优秀而且免费的服务不能用了呢？是严格贯彻党和国家的政策，还是无良商人拉大旗做虎皮，借机封杀 竞争对手呢？不得而知。不过最近的风声鹤唳，完全不像是抽风的样子。也许，党和国家似乎真的作出了重大的、历史性的决定，要对互联网实行全面封闭的政策了。

几款杂志-内容管理型主题的选择

WordPress的世界，真是一个生机勃勃的天地。灵活的有机系统架构，丰富多彩的主题、插件，追求精致、完美的风气，都让我很幸福。

最初的兴奋之后，开始遇到“幸福的烦恼”。目不暇接的主题，难免挑花了眼。在一番搜索和学习之后，渐渐熟悉了这个世界的一些语言，也归纳出自己的需求：

多数的主题是追求个性与视觉效果、多媒体展示的个性日志型。它们太丰富、太漂亮了，但不是我这次的任务。我想要的东西，被称为“杂志”(magazine)型，或“内容管理系统”（CMS）型，以文本展示为主，且不属于“新闻”风格的。而版面布局，则并非如外观那么花样百出，是有一定规律的。循着这些线索，搜索不再盲目，很快有了些眉目。

分享是这个世界的精髓。就把自己这几天“看楼”的结果归纳记录一下，也顺便分享给象我一样的菜鸟们。

我的首选：Darren Hoyt 的 Mimbo 3.0

通过专门介绍免费模板的寂静街日志发现了这个主题。它有简约而严谨的文字内容网站风格，布局经典，结构合理，而且相当简单精炼，没有过多的花样。提供了独立.po/mo的界面用语文件，这样就很方便形成不同语言的版本。然而，这个主题再另外的方面也有个性：它提供的配置的东西很少。如果觉得它的基本功能不够用，那就要自己动手做二次开发了。在前面看过许多模板的基础上，我发现这一款已经相当符合预期，所以准备先选这一款，再按自己的规划进行优化和小小的改造，首先做的事情，就是按照网站的用语需求习惯，做了自己的汉化文件。链接：英文版在线演示

备选：Melvin Lee 的 Arras Theme  1.3.6

好多地方都在推荐这款主题，它同样具有经典的布局，调整起来更加灵活，并且支持幻灯片方式的展示，设置首页的题头图片等。我本来已经初步认定选择它，有两个理由让我忍痛（真的很喜欢它首页布局、配置的灵活性）割爱：

• 它的图片与幻灯，不是我的静态文字为主的内容网站最需要的，要动手改，是怎么都想避免的。
• 先从简单做起吧，Minbo 3.0现有的功能虽然没有它灵活，但对我的任务而言，应该够用了。

其它参考

给我留下较深印象的杂志/内容管理型主题，还有：

Mehmet Ozekinci Magazine Theme – Chinese 1.0

与 Arras类似风格的布局，我最喜欢它紧凑的三栏设计。暂时没有选用的原因，是因为先熟悉了前者，而它预留的，很大的图形广告位置（这种模式看来现在很时兴），也是我的网站暂时不需要的。

c.bavota Magazine Basic 2.5.6

真的非常喜欢这个主题的设计。我形容为简单而有特色的“小报”风格，在内容网站的典型导航结构框架下，主页采用1、2、3堆叠的版块设计，和自动取图显示，既简单实用又别具特色。我没有选它的原因只是它的风格不符合我的学术、学习型内容网站。

这里总共提到四款主题，似乎不多，但它们是在我安装、初步尝试过的，不下十几二十种里筛选出来的。对于需要建立比个人网站更丰富，但规模不大的严肃内容型网站（不是小型日志、博客）的朋友来说，相信这些推荐是有价值的，找出他们也并不容易啊。

WP标签和分类的数据结构和使用特点

WordPress建立了一个词语（term）表，在此基础上，建立词语分类系统表（term_taxonomy），建立不同分类法各自可用的词语表。其数据关系如图所示（根据wp 2.9）。

可以看到三种分类系统：标签（post_tag）、分类（category）、链接分类（link_category），这三种标识可以理解为“词语”的不同用途。

根据数据结构，和少量试验，留意到以下几点：

1）post中，每个独立发出的对象都有一个记录，例如每个文章版本和上传的媒体文档，wp可以为其单独关联标签或分类，即，每个版本使用的标签不同，都有记录，上传媒体文档也可以关联标签和分类，但此功能目前还未包含在wp 2.9中。

2）标签、分类等不同分类法使用同一个“词汇表”，词汇的“别名”（slug，注意，不是name）是唯一的。所以当试图在tag或category中分别添加同名词汇（已别名为准），系统会对应到已有词汇表，并拒绝添加slug重复的词汇（但并没有任何提示）。
例如：
已有标签别名“abc”，此时在分类中添加一个别名为“abc”的分类，系统不会重复添加词汇表，而是设定为将同一词汇“abc”作为标签使用。反之亦然。

初步体会：

1）在创建标签、分类、链接分类时，保持名称和别名（name, slug）一致。虽然系统允许你改成不一致，但那样容易给应用管理带来困惑。

2）虽然分类、标签等是分别使用的，但对意义相同的词语保持一致，这样语义明确，将来想修改时，可以仅在一处一次性修改，很方便。

3）对于内容少的个人日志而言，分类和标签也许用好一套就可以了。但对于有较多内容，需要提供全部内容的良好索引机制而言，分类系统和标签系统各自有不同的用途，互相配合使用，需要自己有一个清晰的规划。笼统地说，标签是面向发布对象的，分类则是预设的，一般而言，分类宜简明恒定、标签比较随意。

升级WordPress 2.8.6 到 2.9

网站刚建，正在配置优化，看到最新版的2.9，是一个较重要的版本升级，于是决定先升级再配置、优化。在后台自动升级，不成功，出现以下错误提示：

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 2764934 bytes) in /home5/ninoneum/public_html/ee-forum.org/wp/wp-includes/http.php on line 1331

搜索结果很多，就不引用了，得知这是php或wp设置参数问题，建议无非三条：

1. 修改php.ini                            memory_limit = xxM
2. 在程序里面添加                     ini_set(‘memory_limit’, ‘xxM’);
   对wp，wp-settings.php 中有设定（在某个版本开始我没求证）
3. 在根目录.htaccess 添加     php_value memory_limit xxM

具体数值应该比现有限制加一倍，例如 32M(33554432) -> 64M

据说修改了php.ini，可能要重启服务器。后面的方法，则可能受到服务器设置的限制，不一定生效。我使用的是Bluehost服务器，但我无法修改php.ini，想着没事最好不要去找服务商，于是找到 wp-settings.php 先试试运气。一找就找到了：

if ( !defined(‘WP_MEMORY_LIMIT’) )
define(‘WP_MEMORY_LIMIT’, ’32M’);

if ( function_exists(‘memory_get_usage’) && ( (int) @ini_get(‘memory_limit’) < abs(intval(WP_MEMORY_LIMIT)) ) )
@ini_set(‘memory_limit’, WP_MEMORY_LIMIT);

将上面的数字32M改为64，再回到后台执行升级，OK

今天股票也涨了，运气不错滴说;-)

—-

顺便保留一个帖子，作为备忘。这里解释了在Bluehost上修改php.ini无需重启的特点，和一些操作的注意事项。

Bluehost Clarification

Maximus284 – December 18, 2008 – 09:17

I am one of the tech support staff for the bluehost companies and i would like to clarify a few settings on our system.

Your PHP.INI file is the file you need to modify in order to increase your memory limit.

the settings you will need to modify are these:

max_execution_time = 30 ; Maximum execution time of each script, in seconds (set this to something high like 300)

max_input_time = 60 ; Maximum amount of time each script may spend parsing request data (set this to something high like 600)

memory_limit = 10M ; Maximum amount of memory a script may consume (set this to something like 500M)

Then in the php config icon of your account, set your site to the php5 (single php.ini) settings as the Fast CGI is not compatible with some drupal installations. if you find that fast cgi works, great if not, just stay on the php 5 setting.

Also, you do Not need to , and you cannot reboot the server on bluehost. We have a special modification to our server that allows the php.ini files to be initialized on the fly and it does not need to be restarted every time a change is made. Therefore, make the changes in the php.ini and refresh your site a couple of times and the new settings will be applied.

To see if the settings you are making in your account are taking affect, put a phpinfo.php file in your account and use the <? phpinfo(); ?>

Lastly, do not use the php_flag variable in our server. The .htaccess file does not recognize that flag and it will result in your account producing a 500 error, just make your modifications to the php.ini file itself.

If the above memory fix does not solve your problem, there may be a file in the drupal that is limiting your memory usage. (as this line suggests here: “ini_set(‘memory_limit’, ’12M’); in your sites/default/settings.php file”)

If all the above doesn’t work, contact the bluehost support and drupal to see if there are any other fixes to your problem and/or any other files you may need to modify.

Thanks

—-

站点目录结构及相关规则

目录结构结合固定链接（permalink）、文章静态化方案设计。

目录	说明
\wp\wp\wp-contents	WordPress安装目录正常的客户化设置（themes,plugins）均在contents之下
\pub	公开发布目录：所有对外公开访问资源应置于此目录下
\pub\1998-2009	旧网站静态文档，永久保留，对旧链保持重定向到新路径
\pub \<author>	作者发布目录：有投稿或以上权限的作者发布对象时自动创建。其结构对应Permalink设置，在页面静态化时自动生成：/pub/%author%/%year%-%monthnum%-p%post_id%.html
\pub\file\<yyyy\mm>	媒体库目录：上传媒体添加于此。设置“默认上传路径”为服务器绝对路径，配合与之吻合的“文件完整URL地址”实现；启用“年-月目录”选项
\pub\category\<categories>	分类目录（虚拟）：permalinke第一节，加上分类层级url
\pub\yyyy\mm\ archives	归档目录（虚拟）：系统自动形成，permalinke第一节、二节，加上月
\pub\tag	标签目录（虚拟）：自动设置
\intellian	准备用于intellian域名停留的专门目录。类似独立于WP的功能，以根下的独立目录创建。

说明：

1. 分类、标签、归档url与permalinke有牵连，待澄清
2. 目录结构是作者优先还是年月（即网站整体）优先，反映了网站发展的策略。wp仍体现了个人网站（博客）的传统，有标签、多级分类、周期归档三种汇总导航机制，缺少默认的按作者组织与导航。此目录方案以作者优先，形成互补，便于作者独立性管理。
3. 目录的结构与使用规则，部分与.htaccess的设置有关。

样式表修改

标题一：字体大小颜色格式样例CSS stylesheet如何

标题二：字体大小颜色格式样例CSS stylesheet如何

标题三：字体大小颜色格式样例CSS stylesheet如何

标题四：字体大小颜色格式样例CSS stylesheet如何

标题五：字体大小颜色格式样例CSS stylesheet如何

标题六：字体大小颜色格式样例CSS stylesheet如何

段落：字体大小颜色格式样例CSS stylesheet如何。测试中创建了一个用户名为“author”，以此用户添加的文章使用固定链接permalink访问时总是404——找不到。经过一番折腾，发现问题可能是固定链接设置里的 %author%，把这个换成别的，或吧author创建的文章作者改成别的用户，上述错误就不出现了。这是个很小，很特别的问题吧。

用户author和Permalink设置上发生的小问题

测试中创建了一个用户名为“author”，以此用户添加的文章使用固定链接permalink访问时总是404——找不到。

经过一番折腾，发现问题可能是固定链接设置里的 %author%，把这个换成别的，或吧author创建的文章作者改成别的用户，上述错误就不出现了。

这是个很小，很特别的问题。

上传文件路径移到wp安装目录之外的问题

目的

将上传路径由wp安装目录中转移到其他位置。

问题

相关设置在杂项“默认上传路径”（默认为 wp-content/uploads）和“文件的完整URL地址”（默认为空白）。前者为相对地址，相对于当前wp安装目录。改成绝对地址（形如 /pub/files），在我的虚拟服务器上，就直接定位到真正的根目录了，所以上传会报告“无法创建。。。是否有权限之类的”。网上有不少都说是要修改权限，有些人遇到的也许是权限问题，但对虚拟主机用户，可能主要是这里的“绝对路径跑出界”的问题，（为此我也折腾了一番，授所有的权都没有用，才想到这个）。

方案

将默认上传路径改为虚拟主机服务器上的绝对地址，形如：

/…/…/MyDomainName/pub/files （…/… 部分是什么，视乎你的主机）

同时，将“文件的完整URL地址”设为：

http:// MyDomainName/pub/files

* 这两者的设置必须是一致的，否则会出问题，造成404文档找不到的错误。

其它问题：

• 没有普通文件上传。全部被归为“媒体”，上传有些文件类型如xml，log，则报告不符合安全规则之类。
• 文章中“添加媒体”默认的位置为“相册”。在控制板上叫做“媒体库”。

修改安装目录遇到的问题

目的：把WordPress安装到根目录下的子目录wp中，内容（默认在 wp的 wp-content 子目录），包括permalink或将来静态化目标、上传的文档的目录，则改在安装目录之外，在网站根目录下创建。例如：

• 安装目录为：\wp
• 发布目录为： \pub
• 上传文档目录为：\pub\files

过程：

按主机管理员提示，在wp下执行 install.php ，报告正常，出现 adim 登陆页面。登陆正常。然后，修改博客地址，修改前：

• WordPress安装地址（URL）:  http://<mydomain>/wp
• 博客地址（URL）：http://<mydomain>/wp

改为

• WordPress安装地址（URL）:  http://<mydomain>/wp
• 博客地址（URL）：http://<mydomain>

有提示：“如果您想让博客地址和 WordPress 的安装地址 不相同 的话，请在这里输入您期望的地址。” 按照其中提示的步骤，复制 index.php到根目录，并修改

require(‘./wp/wp-blog-header.php’);    改为   require(‘./wp-blog-header.php’);

在此之前，设了自定义固定链接：

• /pub/%year%/%monthnum%/p%post_id%.html

上述操作完成（根目录.htaccess 自动创建），复制修改好的index.php到根目录，操作完毕。

问题：无法从根目录 index.php 进入

执行 index.php，出错，无法进入wp。改回原来状态，恢复正常。

问题分析与解决：

根目录下有一个index.html，执行index.php，总是被转向读出该文件。估计与访问根目录的默认文档设置顺序有关（未查证）。将index.html删除，就正常了。