How to make a multilingual b2b website

Multilingual b2b website implementation plan

1. Static: It is to prepare a set of page files for each language, either to distinguish different languages ​​by file suffix name, or to distinguish different languages ​​by subdirectories.

2. Dynamic: All page files in the site are dynamic page files (PHP, ASP, etc.) instead of static page files. Where language output is required, language variables are used to represent these language variables. These language variables can be selected in different languages ​​according to the user. Different values ​​are assigned, so that different characters can be output in different language environments.

The advantage of using the static method is that the page is directly output to the client, and does not need to be run on the server. It takes up less server resources and the system can support more concurrent connections. The disadvantage is that a set of page files is created for each language. Many contents are stored in different languages ​​even if they are not related to languages, so they take up more storage space.

The advantages and disadvantages of using dynamic and static methods are exactly the opposite. Its advantage is that there is only one set of dynamic page files. Text in different languages ​​is stored using language variables. Only language-independent content is stored in one copy, which takes up less storage space. And it is easier to extend the new language. The shortcomings need to run on the server, and then input the results to the client, occupying more server resources, 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 website, a considerable number of websites will also use files or databases to store application information, so if the content stored in the files or databases is language-dependent, special attention is also required. For the information stored in the database, the following methods can be adopted to support multiple languages:

1. Support multiple languages ​​at the database level: Establish an independent database for each language, and users of different languages ​​operate different databases.

2. Multi-language support at the table level: create separate tables for each language, users of different languages ​​operate different tables, but they are in the same database.

3. Multi-language support at the field level: Create separate fields for each language in the same table. Users of different languages ​​operate on different fields and they are in the same table.

Since there is a large amount of information in the database (such as logos, codes, numbers, etc.) for internal processing, it is language-independent, so supporting multiple languages ​​at the database level will result in a huge waste of space, and supporting multiple languages ​​at the field level The biggest problem is that once you need to support a new language, due to the need to modify the table structure, it is very troublesome to maintain and has poor scalability.

In contrast, it is better 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. Those language-related tables are based on the supported language. To create different types, users in different languages ​​can access different forms. This makes maintenance simple and saves storage space. Even expansion is more convenient, as long as you need to build a set of tables that need to support multiple languages.

The issues that need to be noted are: some fields in some tables are shared by different language versions of the table (for example, inventory). Due to the relative independence between the tables in various languages, data sharing is difficult. There are two solutions:

1. The shared fields of tables in different languages ​​are synchronized: that is to say, as long as the shared field of one of the tables is modified, the field in other languages ​​is also changed accordingly. In fact, when users in different languages ​​access it at the same time, the processing is still more troublesome , And the modification work is relatively large when expanding the new language.

2. Add a new table: put all the fields shared by all languages ​​(such as cargo number, origin code, etc.) in this table. The multi-language table only stores fields related to various languages. Users of different languages ​​need to operate two data tables when using the database.

In comparison, the second method is simpler, more efficient, and easier to maintain.