共计 3948 个字符，预计需要花费 10 分钟才能阅读完成。
Zen Cart最大的缺憾 就是后台的人机交互性体验非常之差劲,
尤其不适合东方人的操作习惯,
本来操作性就繁杂 再加上默认情况下 网店配置为什么语言 后台就为对应的语种,
日常运维着实有点脑袋大,
本来 Zen Cart后台中文化 之教程 满网皆是,
操作方法也很容易 就是几步复制粘贴就完事儿, 但是网上大多教程都是复制来粘贴去,
压根儿就没把其中的要点 提示性的指出, 结果造成按哪些教程操作后的网店,
在实际运营中 会出现诸多语言不匹配的问题, 出现最大最多的就是邮件通知也中文化的问题,
这里再一次的鄙视一下哪些从不验证技术应用类文章可行性的复制党和采集党们一下,
Zen Cart后台中文化 真正的实现 需要两部分 一是 对应的语言文件覆盖与修改
二是 数据库的修改 两者中 后者 如果感觉有一定的复杂性 操作上有难度, 可以忽略掉,
但是 在涉及商店配置项目中, 将无法显示中文菜单,
好了 废话啰嗦完, 开始进入正题,
操作如下:
第一步 都知道的 覆盖对应的语言文件,
进入 你的后台目录/includes/languages/ 下,
将 schinese.php 和 schinese 文件夹 复制一份备用,
以替换后台英文为例, 将此路径下的 english.php 和 english 文件夹更名, 以备后用,
将上面的复制备用的 schinese.php 文件 和 schinese 文件夹 更名为 english.php 和 english,
这样, 就实现了后台中文化, 但是问题远没有结束,
如果仅这样 就会导致 上面提到的网店应用诸多语言项不匹配问题,
继续如下操作, 打开 更名后的 english.php 文件(注: 实际此文件现在为中文语言文件),
将 下面 代码替换为 真英文语言声明文件中的对应的代码:
[php]
setlocale(LC_TIME, ‘zh_CN.UTF-8’);
define(‘DATE_FORMAT_SHORT’, ‘%Y/%m/%d’); // this is used for strftime()
define(‘DATE_FORMAT_LONG’, ‘%Y年 %m月 %d日’); // this is used for strftime()
define(‘DATE_FORMAT’, ‘Y/m/d’); // this is used for date()
define(‘PHP_DATE_TIME_FORMAT’, ‘Y/m/d H:i:s’); // this is used for date()
define(‘DATE_TIME_FORMAT’, DATE_FORMAT_SHORT . ‘ %H:%M:%S’);
define(‘DATE_FORMAT_SPIFFYCAL’, ‘yyyy/MM/dd’); //Use only ‘dd’, ‘MM’ and ‘yyyy’ here in any order
[/php]
替换为
[php]
setlocale(LC_TIME, ‘en_US.UTF-8’);
define(‘DATE_FORMAT_SHORT’, ‘%m/%d/%Y’); // this is used for strftime()
define(‘DATE_FORMAT_LONG’, ‘%A %d %B, %Y’); // this is used for strftime()
define(‘DATE_FORMAT’, ‘m/d/Y’); // this is used for date()
define(‘PHP_DATE_TIME_FORMAT’, ‘m/d/Y H:i:s’); // this is used for date()
define(‘DATE_TIME_FORMAT’, DATE_FORMAT_SHORT . ‘ %H:%M:%S’);
define(‘DATE_FORMAT_SPIFFYCAL’, ‘MM/dd/yyyy’); //Use only ‘dd’, ‘MM’ and ‘yyyy’ here in any order
[/php]
同时 再注意 上面代码中的 这一句
[php]
setlocale(LC_TIME, ‘en_US.UTF-8’);
[/php]
勿必保证此处声明的编码与当前程序后台页面声明编码一至, 不然就会出现乱码
同时保存文件时 一定要注意保存的文件编码格式要与此处的声明的编码一至, 不然还会出现乱码,
勿必保证三码一至 缺一不可 很重要, 切记!!!
然后 继续将下面这几个文件 使用原英文语言包下的文件替换回去,
这几个文件分别为:
你的管理目录/includes/languages/原英文语言包文件夹/email_extras.php
你的管理目录/includes/languages/原英文语言包文件夹/email_welcome.php
你的管理目录/includes/languages/原英文语言包文件夹/email_history.php
注意: 有的同学可能找不齐这三个文件, 没关系, 别死抱着条条框框不放,
不是所有的版本程序这三个文件都有, 但至少有两个email_开头的文件
然后呢 还没完事儿, 动爪儿 继续改文件,
打开 你的管理目录/includes/languages/替换后的英文文件夹/orders.php
查找
[php]
define(‘EMAIL_SEPARATOR’, ‘——————————————————‘);
define(‘EMAIL_TEXT_SUBJECT’, ‘订单更新’);
define(‘EMAIL_TEXT_ORDER_NUMBER’, ‘订单号码:’);
define(‘EMAIL_TEXT_INVOICE_URL’, ‘详细发票:’);
define(‘EMAIL_TEXT_DATE_ORDERED’, ‘订单日期:’);
define(‘EMAIL_TEXT_COMMENTS_UPDATE’, ‘<em>您订单的备注为: </em>’);
define(‘EMAIL_TEXT_STATUS_UPDATED’, ‘您的订单状态更新为:’ . "\n");
define(‘EMAIL_TEXT_STATUS_LABEL’, ‘<strong>新状态:</strong> %s’ . "\n\n");
define(‘EMAIL_TEXT_STATUS_PLEASE_REPLY’, ‘如果您有任何疑问, 请回复电子邮件.’ . "\n");
[/php]
将这段替换为 原英文对应文件 对应区段的代码 即下面代码:
[php]
define(‘EMAIL_SEPARATOR’, ‘——————————————————‘);
define(‘EMAIL_TEXT_SUBJECT’, ‘Order Update’);
define(‘EMAIL_TEXT_ORDER_NUMBER’, ‘Order Number:’);
define(‘EMAIL_TEXT_INVOICE_URL’, ‘Detailed Invoice:’);
define(‘EMAIL_TEXT_DATE_ORDERED’, ‘Date Ordered:’);
define(‘EMAIL_TEXT_COMMENTS_UPDATE’, ‘<em>The comments for your order are: </em>’);
define(‘EMAIL_TEXT_STATUS_UPDATED’, ‘Your order has been updated to the following status:’ . "\n");
define(‘EMAIL_TEXT_STATUS_LABEL’, ‘<strong>New status:</strong> %s’ . "\n\n");
define(‘EMAIL_TEXT_STATUS_PLEASE_REPLY’, ‘Please reply to this email if you have any questions.’ . "\n");
[/php]
如上操作后 就完成了后台中文化的全部修改, 并且不会影响到程序应用语言匹配问题.
然后下面开始第二步, 数据库的修改
这一步如果嫌麻烦 或有技术操作性的障碍, 可以不作,
但正如上面所述, 涉及到商店配置项时, 将无法显示为中文菜单,
先说一下正常汉化方法, 后面再介绍一个偷机取巧的方法,
进入当前程序所使用的数据库,
这里以最为常用的 PHPMyadmin来说 先打开 configuration_group 表 如下图:(点击图片查看大图)
聪明的你 有没有看出门道来, configuration_group 表中 存放着 后台商店配置 项下的全部菜单项信息,
这里只要依次编辑各项 将其下的 英文翻译成对应的中文即可, 如下图:(点击图片查看大图)
修改完configuration_group 表后 继续如此 再修改 configuration表,
修改方法同上 但要注意的是, configuration表中涉及的字段比较多,
只需要将 configuration_title 和 configuration_description 字段中的内容修改为中文即可, 其他字段勿动,
不然出啥乱子了, 别说没有提前告诉你.
这里要修改的项目属实比较多, 全部人为汉化怕是不太实际,
所以有个偷机取巧的方法可用, 将中文版或插件版的程序 这两个表导出来 再导入当前程序数据库下,
但是这个方法有一定的局限性, 如果你当前使用的程序是被开发过,并且涉及到这两个表的, 哪么就不能这么作了,
不然将导致程序出现各种显性隐性问题.
同时, 如果导入的为中文插件版对应的表,而实际使用的程序是英文源版和一些非插件版基础修改的程序,
后台在 商店配置下将出现一些无任何功效的菜单项, 但不会影响程序的正常运营, 只是会出现这些僵尸菜单,
有耐性的话 可以去上面提到的这两个表中 将这些僵尸菜单项删除即可
至此, 一份完整的完美的 Zen Cart后台中文化操作 全部结束!
