How do the fields and tags correspond between the Chinese and English stations?
The Chinese site and English site share a content model, and the fields and tags should be matched in the order of 'define structure first, then language': first use a custom content model to define the fields needed for both bilinguals, then use the keyword library to maintain Chinese-English matching words, deliver the finished draft to full-page HTML translation, and the switching and isolation between sites are undertaken by multi-site management. Conversely, doing it the other way around - translating the page first and then adding structure - is the main source of confusion in the later stage of bilingual sites.
Determine the structure first, then the language
The content model defines what fields this type of content has, which is unrelated to language. What fields are needed for each type of content such as products, cases, documents, and news should be determined before writing in both languages. Because fields determine the information structure, not the expression method.
AnQiCMS supports custom content models and custom fields, the same model can be reused under multi-language site configurations; the system also supports multi-language site configuration and switching, and can perform full-page HTML translation. This means that the structure layer is maintained only once, and the language layer is presented separately according to the site, and the two will not interfere with each other.
| Hierarchy | Maintain objects | Key points for processing bilingual sites |
|---|---|---|
| Structure layer | Content model and custom fields | Field names are defined according to business meaning, not according to language |
| Term layer | Keyword library and tags | Maintain Chinese-English in pairs to avoid independent growth |
| Draft layer | Main text and page copywriting | Full-page translation output, reviewed by a person for terminology |
| Site layer | Multi-site configuration and switching | Language and domain isolation with category tree |
Three common mistakes in field mapping
The first one is to write the display text into the field definition. For example, the button text such as 'Buy Now' is directly solidified in the field name or default value, and a separate model needs to be built for the English site. The method is: the field only carries data, and the display text is placed in the template and language configuration layer.
The second one is to create two fields with the same meaning. The Chinese site built 「Applicable Industry」, and the English site built 「Industry」, resulting in data misalignment on both sides. It will cause half-empty fields during later summary or batch processing. The solution is to build the model only once, share the field definitions between two languages, and fill in the values separately.
The third one is to neglect the difference between required and optional fields. The main text of a bilingual site can be supplemented later, but fields used for filtering and display (such as titles, abstracts, cover images, specifications) cannot be empty. It is necessary to define the required items clearly to avoid widespread empty values on the English site after going online.
How to correspond the tags and keyword library
The label out of control is the most common technical debt in bilingual stations: Chinese labels are manually input, and English labels are produced through translation, and the quantity and meaning of both sides gradually diverge, and finally the same topic points to different label pages on the two stations.
The controllable approach is to put the correspondence relationship into a keyword library for centralized management. AnQiCMS's keyword library is used to centrally manage SEO keywords, and bilingual stations can maintain a ternary structure of 'Chinese word-English word-whether enabled,' and new labels must be stored in the library before use, and both operation and translation are not free to create words.
The label correspondence suggestion follows three rules: one word, one meaning, avoid the same English word corresponding to multiple Chinese labels; less is more, cover the core theme first and then expand; the corresponding relationship can be fallback, if a word pair is really not suitable, change the mapping instead of creating a new approximate label.
The internal links are managed by the anchor text, and a bilingual site needs to be configured separately: Chinese anchor text points to Chinese pages, English anchor text points to English pages, do not mix languages. This is both a user experience issue and a crawling path issue - cross-language anchor text will guide the crawling to a page that does not match the language.
Who is responsible for updating the full-page translation?
Full-page HTML translation can significantly reduce initial production costs, but it does not solve the 'versioning' issue. When the Chinese site changes the parameter table, the English site will not synchronize automatically, and a clear versioning process is needed.
It is recommended to assign responsibilities according to the type of change. Structural changes (field additions/deletions, column adjustments) should be made by the site manager on both sides, as the structure must be consistent; content changes (main text paragraphs, case data) can be translated asynchronously, but there should be a to-do list and a timeline; expressive changes (wording, terminology, compliance statements) can be handled by the translation side, provided that the terminology in the keyword library is updated first.
It is important to distinguish between 'translation' and 'localization'. Parameters, units, date formats, and contact information rules are not suitable for direct translation, and parts involving local expressions should be reviewed by people before being published. AnQiCMS's timed release capability (time factor) can exactly schedule the reviewed manuscripts for release at the specified time, avoiding the direct exposure of unreviewed content.
Common questions
Can we only produce Chinese content, and rely on automatic page translation for the English site?
It can be a starting point, but it is not suitable for the long term. Consistency of terminology, local expressions, and compliance descriptions all require manual review. It is easy to make mistakes on key pages after automatic output without verification.
Whether to separate the database for two sites?
Determine it according to the multi-site management method, one backend can manage multiple independent sites to meet the isolation requirements, and there is no need to split the data artificially for language, otherwise the maintenance cost will double.
Who maintains the label correspondence table?
Maintained by the content负责人, the translation side only submits an application. Dispersed maintenance will inevitably lead to synonym expansion, which is even harder to deal with than mistranslation.