2.建立以utf-8为编码的表结构，importlanguage标识属于什么语言版本 但在某个版本下，就搜索属于这个版本的文字来显示。其他文字不显示。 DROP TABLE IF EXISTS `zz_importer`; CREATE TABLE IF NOT EXISTS `zz_importer` ( `importID` int(11) NOT NULL auto_increment, `importTime` date NOT NULL default '0000-00-00', `improtfile` varchar(100) NOT NULL default '', `importlanguage` varchar(100) NOT NULL default '' PRIMARY KEY (`importID`) ) ENGINE=MyISAM DEFAULT CHARSET=uft-8;
这个要有语言包（一般数组结构）；切换根据网站或用户选项切换。2、所有编码均用utf8;3、时区切换（根据用户时区自动切换）4、字符要排序的可用二进制以上mediawiki的做法。
语言资源数据（比如文字 标题啥的）存放进DB
PHP显示层每个页面加入判断客户端浏览=器语言或IP归属地的逻辑 在读取DB的语言资源数据具体LZ可以看看这里
传送门以前我做的
http://www.google.com/webelements/#show-translate
$lang['hello'] = "Hello";
而在lang_fi.php中则是
$lang['hello'] = "Terve";
而在lang_cn.php中则是
$lang['hello'] = "你好";
在实际的页面中, 比如index.php里,在include了对应的语言文件后, 就直接 echo $lang['hello']; 即可得到你想要的语言的显示了.至于楼上有高手提到的wiki类网站,算是比较极端的例子吧,那种资料性的网站内容当然要进数据库了,但是感觉那个严格来算和多语言没很大关系,因为中文版的词条解释和英文版的词条解释根本就是两篇文章了,并不是简单的语言转换问题.建议楼主使用框架,一般框架都设计好了多语言支持了.
多语言网站，顾名思义就是能够以多种语言（而不是单种语言）为用户提供信息服务，让使用不同语言的用户都能够从同个网站获得内容相同的信息。 多语言网站实现方案 1，静态：就是为每种语言分别准备一套页面文件，要么通过文件后缀名来区分不同语言，要么通过子目录来区分不同语言。 例如对于首页文件index_en.htm提供英语界面，index_gb.htm提供简体中文界面，index_big.htm提供繁体中文界面，或者是en/index.htm提供英语界面，gb/index.htm提供简体中文界面，big/index.htm提供繁体中文界面，一旦用户选择了需要的语言后，自动跳转到相应的页面，首页以下其他链接也是按照同样方式处理。从维护的角度来看，通过子目录比通过文件后缀名来区分不同语言版本显得要简单明了。 2，动态：站点内所有页面文件都是动态页面文件（PHP，ASP等）而不是静态页面文件，在需要输出语言文字的地方统一采用语言变量来表示，这些语言变量可以根据用户选择不同的语言赋予不同的值，从而能够实现在不同的语言环境下输出不同的文字。 例如：语言变量ln_name，当用户选择的语言是英语时赋值为“Name”，当用户选择的语言是简体中文时赋值为“姓名”，这样就可以适应不同语言时的输出。 采用静态方式的优点是页面直接输出到客户端，不需要在服务器上运行，占用服务器的资源比较少，系统能够支持的并发连接数较多，缺点是要为每种语言制作一套页面文件，很多内容即使是和语言无关的也要分不同语言来存储，因此占用的存储空间较多。 采用动态方式和静态方式的优缺点正好相反，它的优点是动态页面文件只有一套，不同语言的文字使用语言变量来存储，和语言无关的内容只存储一份，占用的存储空间较少，并且扩展新语言比较容易，缺点需要在服务器上运行，然后把结果输入到客户端，占用服务器的资源比较多，系统能够支持的并发连接数较少。 动态数据存贮涉及的一些技术问题 由于现在网站上动态应用日益增多，相当多的网站还会使用文件或者数据库来存储应用信息，因此如果文件或者数据库中存储的内容与语言相关时，还需要特别注意。对于存储在数据库中信息，可以采取以下几种方式支持多语言： 1，在数据库级别支持多语言：为每种语言建立独立的数据库，不同语言的用户操作不同的数据库。 2，在表级别支持多语言：为每种语言建立独立的表，不同语言的用户操作不同的表，但是它们在同一个数据库中。 3，在字段级别支持多语言：在同一个表中为每种语言建立独立的字段，不同语言的用户操作不同的字段，它们在同一个表中。 由于数据库中有大量的信息（如标志，编码，数字等）是用于内部处理使用的，与语言无关的，因此在数据库级别支持多语言会导致空间的极大浪费，在字段级别支持多语言最大的问题是一旦需要支持新的语言，由于需要修改表结构，维护起来非常麻烦，可扩展性不好。 相比之下，在表级别支持多语言比较好，因为并不是所有的表都需要支持多语言，对于与语言无关的表，不同语言的用户共用一套，那些和语言相关的表根据支持语言的种类来建立，不同语言的用户存取访问不同的表格。这样使得维护简单，节省了存储空间，即使是扩展起来也比较方便，只要把需要支持多语言的表，多建立一套即可。 还需要注意的问题是：有些表中某些字段是不同语言版本的表共享的（例如库存量），由于各种语言的表之间的相对独立性，使得数据共享有些困难。解决的方法有两个： 1，不同语言的表的共享字段同步：也就是说，只要修改了其中一个表的共享字段，其他语言表中该字段也作相应改变，实际上当不同语言的用户同时访问时处理还是比较麻烦的，并且扩充新语言时修改工作比较大。 2，增加一个新的表：把所有语言共享的字段（例如货物编号，产地编码等）全部放在这个表，支持多语言的表只存放与各种语言相关的字段。不同语言的用户在使用数据库时，需要操作两个数据表。
比较而言，第二种方法比较简单，并且效率比较高，维护也比较方便。 应用字符集的选择 一个定位于不同语言国家的企业网站势必需要提供多种语言版本的产品和销售信息来满足其世界各地使用不同语言的客户和合作伙伴，其中包括法语、德语、意大利语、葡萄牙语、西班牙语、阿拉伯语等等。但有一个问题却极易被网站设计者们所忽略。这就是网站的字符集设置问题。 一般我们使用的是简体中文(GB2312)字符集，而对多语言网站来说，中文字符集却可能会使你辛辛苦苦的努力功亏一篑。原因很简单：就是这个毫不起眼的小小字符集在作怪。 计算机应用领域中存在着几十种互不相同的字符集，而不同语言客户在浏览不同语言网页时，往往会因为相互间所使用字符集无法兼容而出现乱码情况。我们在浏览国外一些网站时，往往也会出现为了能正常地看到网站上的信息而不得不在各种字符集之间来回切换的情况。 试想一下：如果一个网站提供了中，英，法，德等多种语言版本的内容，内容全之又全，设计美仑美奂。我们在中文编码环境下浏览这些非中文版本的页面觉得非常完美，现在一个法国客户对你的产品发生了兴趣，当他进到法语版面一看—乱码多多，甚至可能整个版面都一塌里糊涂。你的网站再下大工夫又有什么意义呢? 所以对提供了多语言版本的网站来说，Unicode字符集应该是最理想的选择。它是一种双字节编码机制的字符集，不管是东方文字还是西方文字，在Unicode中一律用两个字节来表示，因而至少可以定义65536个不同的字符，几乎可以涵盖世界上目前所有通用的语言的每一种字符。 所以在设计和开发多语言网站时，一定要注意先把非中文页面的字符集定义为“utf-8”格式。 这一步非常重要，原因在于若等页面做好之后再更改字符集设置，可说是一件非常非常吃力不讨好的工作，有时候甚至可能需要从头再来，重新输入网站的文字内容。 HTML中的META标签： <META HTTP-EQUIV=“Content-Type” CONTENT=“text/html; CHARSET=字符集">
不写，根据浏览器默认字符集显示
charset=gb2312 简体中文
charset=big5 繁体中文
charset=EUC_KR 韩语
charset=Shift_JIS 或 EUC_JP 日语
charset= KOI8-R / Windows-1251 俄语
charset=iso-8859-1 西欧语系（荷兰语,英语,法语,德语,意大利语,挪威语,葡萄牙语,瑞士语.等十八种语言）http://www.microsoft.com/
charset=iso-8859-2 中欧语系
charset=iso-8859-5 斯拉夫语系（保加利亚语,Byelorussian语,马其顿语,俄语,塞尔维亚语,乌克兰语等）
charset=uft-8 unicode多语言 PHP与脚本引擎页码的概念
由于我们传统使用的内码像Big5,GB2312与unicode并不是一一对应,故两者之间的转换要靠codepage(页码)来实现
<?php=Language=VBScript CodePage=xxx?>
不写，根据服务器端解析引擎默认代码页自动解析并返回浏览器。
如果制作的网页脚本与WEB服务端的默认代码页不同，则必须指明代码页：
codepage=936 简体中文GBK
codepage=950 繁体中文BIG5
codepage=437 美国/加拿大英语
codepage=932 日文
codepage=949 韩文
codepage=866 俄文
codepage=65001 unicode UFT-8
前言：
多语言网站开发，重点的还是在解决语言之间的问题。
那如何解决这个问题呢？大概就分三步走：
1.页面多语言
2.数据库多语言
3.用户访问语言统一
1.页面多语言
需要考虑的问题：
A.用户登陆时候，自动识别字符，调用不同的语言包？
B.用户切换不同语言时候，调用不同的语言包？
C.增加多语言后的目录结构？
页面多语言也就是外观的多语言化，这里可以采用静态的语言包的方式。
设计时候就应该包括language的目录，针对不同语言有独立的子目录。
如英文language/en ,简体中文language/gb,繁体中文language/b5 （可以扩展其他语言）
每个目录下就包含了对每个页面的语言版本。选择语言版本时候就可以调用相应版本的语言包。
具体做法：
0.利用js语言，识别浏览器语言，在调用不同的语言包.
1.language/en/global.ln是针对英文版的全局语言包。
2.global.ln 内容为：
$title = "English webstie";
$charset = "UTF-8";
3.index.php调用：
<?php
require_once()
?>;
<html>;
<head>;
<title>;$title<title>;
<meta http-equiv="content-type" content="text/html;charset=$charset">;
</head>;
<body>;</body>;
</html>;
这样通过扩展就可以实现页面的多语言化.
2.数据库多语言
这个考虑的问题：
A.后台录入数据的多语言化？
B.用户在不同版本下，提交的内容，如何保存？
C.提供三种语言包，还是提供英文和简体，简体通过转化提供繁体？
数据库多语言就是达到多语言在数据库里面的统一。就需要采用utf-8统一编码。
无论什么语言的文字，都统一使用utf-8来存放到数据库里面。采用表字段来表识
属于什么语言版本的文字。
具体：
A.对于后台添加的问题：
1.后台添加时候，就需要多语言化的录入。先建立一个以utf-8编码的数据库，录入英文/简体，简体在通过转化为繁体，
再以utf-8编码方式存于数据库中。
2.建立以utf-8为编码的表结构，importlanguage标识属于什么语言版本
但在某个版本下，就搜索属于这个版本的文字来显示。其他文字不显示。
DROP TABLE IF EXISTS `zz_importer`;
CREATE TABLE IF NOT EXISTS `zz_importer` (
`importID` int(11) NOT NULL auto_increment,
`importTime` date NOT NULL default '0000-00-00',
`improtfile` varchar(100) NOT NULL default '',
`importlanguage` varchar(100) NOT NULL default ''
PRIMARY KEY (`importID`)
) ENGINE=MyISAM DEFAULT CHARSET=uft-8;
3.简体转化的繁体。
利用php的iconv.此过程对于linux/unix有效，对于windows无效。
iconv("GB2312","BIG5",$text);
4.因为,charset = "utf-8",数据就都是以utf-8编码方式存在，
添加数据时候,要分别用en/gb/big5来标识语言版本.
INSERT INTO `zz_importer` VALUES (,'', '', 'en');
INSERT INTO `zz_importer` VALUES (,'', '', 'gb');
INSERT INTO `zz_importer` VALUES (,'', '', 'big5');
B.对于用户添加的问题：
1.假设下简体中文下.用户因为页面头为UTF-8.则用户浏览器会以utf-8编码
方式浏览页面。
2.添加的数据库本身以utf-8方式存在。
3.添加数据时候,要分别用gb来标识语言版本
INSERT INTO `zz_importer` VALUES (,'', '', 'gb');
C.对于简体和繁体是单独提供还是转化问题
单独提供 - 比较符合多语言的标准,灵活性大,对ISP没有特别的要求。
转化提供 - 提交速度会受影响,同时要ISP提供iconv的函数支持。
3.用户访问语言统一
A.假设用户简体中文版时候：
<meta http-equiv="content-type" content="text/html;charset=UTF-8">;
所有语言版本都是这样。
B.调用language/gb的语言包。
C.搜索数据库有语言字段为gb的数据，并显示
D.当用户提交信息，参照上面数据库多语言的B问题。