In addition to using multiple data table scenarios, are there other scenarios? All data read from the database is implemented in multiple languages.
Reply content:
In addition to using multiple data table scenarios, are there other scenarios? All data read from the database is implemented in multiple languages.
It is too rare to use multiple sets of data tables, usually in a language file ... The database can be stored only key, and then automatically converted to translate keywords, such as category table
Category.id = 1, category.name = ' demo ', Category.slug = demo, Category.meta = ' It is demo '
The corresponding translation file
Category_id_1_name = ' demo '
Category_id_1_meta = ' This is a demo '
If necessary, you can develop the language file Management page, but generally with a po-like editor on the line.
Of course, there are things that can't be done like documents that require additional language fields rather than new tables. such as the article table will contain ID, language, title, content, etc., when displayed automatically according to the language to filter the different document list out on the line.
Summary is simple translation using language files, complex data to add language fields, different language content is managed by multiple records.
As for "all data read from the database to achieve multi-language", this scheme is too tired, the database pressure is also large, the data maintenance is also large, and lack of flexibility. Often we think of translation as the front end in order to optimize the interaction use of the scheme, rather than the work of the database. A similar problem is currency conversion, number format, date format, do you have to rely on the database? What is the price of a new product in 3 different formats? Feel tired when you think about it.