Technical analysis of multi-language web site development

Language is the main obstacle to the dissemination of information.

Multilingual Web sites, as the name implies, can provide information services to users in multiple languages (rather than single languages), allowing users of different languages to get the same information from the same Web site.

Multi-language web site implementation 1, static: is for each language to prepare a set of paging file, either through the file suffix name to distinguish between different languages, or through subdirectories to distinguish between different languages.

For example, for the home file index_en.htm to provide an English interface, index_gb.htm provide Simplified Chinese interface, index_big.htm provide a traditional Chinese interface, or en/index.htm to provide an English interface, gb/ Index.htm provides simplified Chinese interface, Big/index.htm provides the traditional Chinese interface, once the user has selected the required language, automatically jump to the corresponding page, the first page of the following other links are treated in the same way. From a maintenance standpoint, it is straightforward to distinguish between different language versions through subdirectories than by file suffix names.

2, Dynamic: All page files in the site are dynamic paging files (php,asp, etc.) rather than static page files, in the need to output language of the local unified use of language variables to express, these language variables can be based on the user to choose different languages to give different values, In order to achieve in different language environment output different text.

For example: The language variable ln_name, when the user chooses the language is English when the assignment is "name", when the user chooses the language is the simplified Chinese to assign the value "the name", thus may adapt the different language the output.

The advantage of static mode is that the page is directly output to the client, do not need to run on the server, the use of the server less resources, the system can support more concurrent connections, the disadvantage is to create a set of page files for each language, a lot of content even with language-independent also to be stored in different languages, Therefore, more storage space is occupied.

The pros and cons of dynamic and static are just the opposite, its advantage is that the dynamic paging file is only a set, the text of different languages using language variables to store, and language-independent content to store only one, occupy less storage space, and expand the new language is easier, the shortcomings need to run on the server, The results are then entered into the client, which consumes more resources from the server, and the system can support fewer concurrent connections.

Some technical problems involved in Dynamic Data storage

Due to the increasing number of dynamic applications on the Web site, quite a lot of Web sites also use files or databases to store application information, so you need to pay special attention if the content stored in the file or database is language related. For information stored in a database, you can support multiple languages in the following ways:

1, multilingual support at the database level: A separate database is established for each language, and users of different languages operate different databases.

2, multiple languages are supported at the table level: A separate table is created for each language, and users of different languages manipulate different tables, but they are in the same database.

3, multiple languages are supported at the field level: Separate fields are created for each language in the same table, and users in different languages manipulate different fields, which are in the same table.

Because there is a lot of information in the database, such as flags, coding, numbers, etc.) are used for internal processing, language-independent, so supporting multiple languages at the database level can cause great waste of space, and the biggest problem in supporting multiple languages at the field level is that once you need to support a new language, because you need to modify the table structure, Maintenance is very troublesome, scalability is not good.

By contrast, it is good to support multiple languages at the table level, because not all tables need to support multiple languages, for language-independent tables, users of different languages share a set of language-related tables based on the type of support language, and different language users access different tables. This makes maintenance simple, save the storage space, even if it is more convenient to expand, as long as the need to support a multilingual table, to build more than one.

Also note that some of the fields in some tables are shared by different language versions of tables (for example, inventory), which makes data sharing difficult because of the relative independence between tables in various languages. There are two ways to solve this problem:

1, the shared fields of tables in different languages are synchronized: that is, as long as you modify the shared field of one of the tables, the field in the other language table is changed accordingly, in fact, when users of different languages are accessing the same time, it is troublesome to handle it, and the modification work is larger when you

2, add a new table: All Language-shared fields (such as cargo number, origin code, etc.) are all placed on this table, and support for multilingual tables holds only fields related to various languages. Users of different languages need to manipulate two data tables when using a database. Comparatively speaking, the second method is relatively simple, and the efficiency is higher, and maintenance is more convenient.
Selection of applied Character set

A corporate web site located in a different language country is bound to provide multiple language versions of products and sales information to meet customers and partners in different languages around the world, including French, German, Italian, Portuguese, Spanish, Arabic, and so on. But one problem is very easy to be overlooked by web designers. This is the site's character set problem. 9 7 3 1 2 4 8:
Generally we use the Simplified Chinese (GB2312) character set, but for multi-language sites, the Chinese character set may make you work hard failed. The reason is simple: this is the insignificant small character set in the mischief.

In the field of computer application, there are dozens of different character sets, and when users browse different language pages, they tend to have garbled characters when they are not compatible with each other. When we browse some foreign websites, we often have to switch back and forth between the various character sets in order to see the information on the website normally.

Imagine: If a site provides the Chinese, English, French, German and other languages version of the content, full of content, the design of beautiful Huan. We are in the Chinese coding environment to browse these non-Chinese version of the page feel very perfect, now a French customer to your product interest, when he entered the French layout a look-garbled many, or even the entire layout is a collapse of confused. What's the point of doing your website a lot more?

So for a multilingual version of a Web site, the Unicode character set should be the ideal choice. It is a double-byte coding mechanism of the character set, whether Oriental or Western text, in Unicode, all are represented in two bytes, so that at least 65,536 different characters can be defined, almost all of the world's current universal language can cover every single character. So when designing and developing multi-language sites, be sure to first define the character set of non-Chinese pages as "utf-8" format.

This is a very important step because if you change the character set after the page is done, it is a very, very thankless task, and sometimes you may even need to start over again and re-enter the text content of the site.

META tags in HTML:
<meta http-equiv= "Content-type" content= "text/html; charset= Character Set ">
Not written, display according to browser default character set

charset=gb2312 Simplified Chinese
Charset=big5 Traditional Chinese
CHARSET=EUC_KR Korean
Charset=shift_jis or EUC_JP Japanese
charset= Koi8-r/Windows-1251 Russian
CHARSET=ISO-8859-1 Western European (Dutch, English, French, German, Italian, Norwegian, Portuguese, Swiss. etc 18 languages)
Charset=iso-8859-2 Central European language
Charset=iso-8859-5 Slavic languages (Bulgarian, Byelorussian, Macedonian, Russian, Serbian, Ukrainian, etc.)
Charset=uft-8 Unicode Multi-language

The concept of PHP and the script engine page number because our traditional code like big5,gb2312 and Unicode is not one by one corresponding, so the conversion between the two depends on codepage (page number) to achieve
<?php=language=vbscript codepage=xxx?>

Does not write, automatically resolves and returns to the browser according to the default code page of the server-side resolution engine. If you make a Web page script that is different from the default code page on the Web service side, you must indicate the code page: webjx.com

codepage=936 Simplified Chinese
GBK codepage=950 Traditional Chinese
BIG5 codepage=437 American/Canadian English
codepage=932 Japanese codepage=949 [...]