Multilingual website implementation
1, static: that is, for each language are ready to set the page file, or to distinguish between different languages by file extension, or to distinguish between different languages through subdirectories.
Such as the provision for Home files index_en.htm English interface, index_gb.htm available in simplified Chinese interface, index_big.htm provided Traditional Chinese interface, or en / index.htm interface is available in English, gb / index.htm available in simplified Chinese interface, big / index.htm provides Traditional Chinese interface, once the user selects the desired language, automatically jump to the corresponding page, home page links to the other is treated in the same way. From the maintenance point of view, through subdirectories than by file name suffix to distinguish between the different language versions appear to be simple and clear.
2, dynamic: all pages within the site are dynamic page document files (PHP, ASP, etc.) rather than static page file, where it is needed the uniform application of the output language variables to represent language, the language of these variables can select a different language according to the user given different values, thereby enabling the output of different text in different locales.
For example: linguistic variables ln_name, assigned the "Name" when the user selects the language is English, the assignment for the "name" when the user selects the language is simplified Chinese, the output so that you can adapt to different languages.
The advantage of using a static page output directly to the client, does not need to run on a server, the server's footprint is relatively small, more concurrent connections the system can support, the disadvantage is to make a page for each language file, even a lot of content and language-independent storage to be divided into different languages, and therefore take up more storage space.
Advantages and disadvantages of using static and dynamic ways just the opposite, it has the advantage that only a dynamic page document, the text in different languages using the language variables to store, and language-independent content to store only one, take up less storage space, and expand new language easier, shortcomings need to run on the server, and then inputs the result to the client, take up more server resources, fewer number of concurrent connections the system can support.
Dynamic data stored some of the technical issues involved
Due to the growing dynamic applications on the site now, a considerable number of sites will use a file or database to store application information, so if the contents of a file or stored in a database associated with the language, you also need special attention. For information stored in the database can be taken several ways to support multi-language:
1, multi-language support at the database level: the establishment of a separate database for each language, different users of different languages to operate the database.
2, in the table-level multi-language support: the establishment of a separate table for each language, different users in different languages operating table, but they are in the same database.
3, multi-language support at the field level: the establishment of a separate field for each language in the same table, different users in different languages operation field, they are in the same table.
Because the database has a lot of information (such as signs, codes, numbers, etc.) are used for internal processing, language-independent, so at the database level multi-language support will cause great waste of space, in the field-level multi-language support the biggest problem is that once the need to support new language, due to the need to modify the table structure, maintenance is very troublesome, poor scalability.
In contrast, in the table-level multi-language support is better, since not all tables need to support multiple languages, for language-independent table, a common set of users of different languages, and those languages related tables according to language support to establish the type of users of different languages to access different forms of access. This allows easy maintenance, saving storage space, even if an extension is also more convenient, as long as the need to support multi-language table, you can set up a multi.
Also be noted that the problem: some tables in some of the fields are different language versions of the shared table (such as stocks), due to the relative independence between the various languages of the table, making data sharing difficult. There are two solutions:
1, a shared field synchronization tables in different languages: That is, as long as the modification wherein a shared field of a table, the table in other languages, the field may be changed accordingly, in fact, when the different languages of users simultaneously accessing process is quite troublesome and modify the new language when expansion work is relatively large.
2, add a new table: all fields (such as Item Number, origin coding, etc.) language shared by all on the table, the only multi-language support table storage field associated with a variety of languages. Users use different languages in a database, you need to operate the two data tables.
In contrast, the second method is relatively simple, and relatively high efficiency, maintenance is also more convenient.
Select the character set of the application
Located in a country different languages corporate website will inevitably need to provide multilingual versions of the product and sales information to meet their different languages worldwide customers and partners, including French, German, Italian, Portuguese, Spanish, Arabic and so on. But there is a problem but it is highly susceptible to website designers ignored. This is the site's character set problem.
Generally, we are using the Simplified Chinese (GB2312) character set, and multi-language website, the Chinese character set, but may make your hard-earned efforts fall short. The reason is simple: is this unassuming little characters at play.
Computer applications exist in dozens of mutually different character sets, and different language clients when browsing web pages in different languages, often because of the character set used is not compatible with each other and garbled situation. When we visit some foreign websites, often also the case in order to properly see the information on the site and had to switch back and forth between various characters appear.
Imagine: if a site offers Chinese, English, French and German language versions of the content, the content of the whole and the whole design fantastic. We view these non-Chinese version in Chinese coding environment page feel very perfect, now a French customer for your product became interested when he into the French layout a look - garbled lot, even entire pages have a collapse in confused . Big time what is the point of your website then the next it?
So to provide a multi-language version of the site is, Unicode character set should be the best choice. It is a double-byte character set encoding mechanism, whether East or West literal text in Unicode, all with two bytes to represent, it is possible to define at least 65,536 different characters, covering almost all the current world each of the characters common language. So in the design and development of multi-language Web site, be sure to pay attention to first page of non-Chinese character set is defined as "utf-8" format.
This step is very important, because if after doing so on the page and then change the character set, can be said to be a very, very thankless work, and sometimes may need to start all over again, to re-enter the text content of the site.
META tags in HTML:
<META HTTP-EQUIV=“Content-Type” CONTENT=“text/html; CHARSET=字符集">
Do not write, depending on the browser default character set display
charset = gb2312 Simplified Chinese
charset = big5 Traditional Chinese
charset = EUC_KR Korean
charset = Shift_JIS Japanese or EUC_JP
charset = KOI8-R / Windows-1251 Russian
charset = iso-8859-1 Western European languages (Dutch, English, French, German, Italian, Norwegian, Portuguese, Swiss language. and other 18 languages) charset = iso-8859-2 Central European
charset = iso-8859-5 Slavic languages (Bulgarian, Byelorussian, Macedonian, Russian, Serbian, Ukrainian, etc.)
charset = uft-8 unicode multilingual
Create a front-end learning qun438905713, most in the group are zero-based learners, we help each other, answer each other, and also to prepare a lot of learning materials, welcomed the zero-based junior partner to the exchange.
PHP scripting engine concept with page numbers
Since our internal code traditionally used as Big5, GB2312 and unicode is not one to one, so the transition between the two depends codepage (Page) to achieve
Do not write, the default code page automatically resolved in accordance with the server-side parsing engine and returned to the browser.
If crafted web page script different from the default code page WEB server, you must specify the code page:
codepage = 936 Simplified Chinese GBK
Traditional Chinese BIG5 codepage = 950
codepage = 437 US / Canadian English
Japanese codepage = 932
Korean codepage = 949
Russian codepage = 866
codepage = 65001 Unicode UTF-8
