How to organise two language versions so that content, terms and enquiries remain consistent.
It helps to plan the Russian and Kazakh versions of a website as two linked editions of the same material. When translation is commissioned only after the screens are finished, forms, error messages, documents, and future updates to terms are easily forgotten. The main texts end up ready while part of the customer journey remains in another language.
For a company in Kazakhstan, the starting point is visitors' actual needs and the team's ability to maintain the content. Here we cover preparing materials and a working process for updates. The structure itself can be chosen with the help of a comparison of landing pages and multi-page websites.
Define the purpose of each language version
List what a person should be able to do: understand a service, compare options, download a document or submit a request. Alongside this, note the materials and staff involved in that journey. Translating an enquiry page loses some of its value if visitors cannot understand the field labels or what happens next.
Agree on the scope of the first launch. Which pages are ready in both languages and which need more preparation? If coverage is not yet complete, plan the language switcher and links to content separately. Do not suggest that a version is ready when visitors will get an empty screen. Decisions about languages and pages should follow the project’s task, not assumptions about what every business needs.
Map all the materials
List content beyond headings and service descriptions. Create a row for each page with the source text, language version, owner, and status. It is useful to include the following in the map:
- Main sections, section titles, buttons, and link labels.
- Form fields, hints, input errors and submission confirmation.
- Product names, specifications, units of measurement, and available variants.
- Image captions, text within illustrations, subtitles, and voiceover.
- The page title, search description and names of downloadable documents.
- Messages the customer receives after making an enquiry, if these are included in the project.
State where the current original is stored. A photograph with embedded text and an editable text block require different source files. It is better to discover this during preparation than when accepting finished screens.
Agree terminology before translating at scale
Create a short glossary: service names, product terms, brands, abbreviations, and recurring actions. Record the agreed usage for each and, where necessary, its context. The same word can mean different things in a product description and on a form button; the translator needs that context.
Submit one representative excerpt for review: a service description together with short interface text. A fluent speaker of the relevant language checks naturalness and meaning, while a company representative checks the accuracy of promises and terminology. Once agreed, apply these decisions consistently. An automatically prepared version can serve as a draft, but everyone involved should understand its status.
Examine the change using an illustrative example
Imagine a company that makes partitions. In both language versions, visitors choose an option and send dimensions for discussion. The company changes its process: a room photograph is now required before preparing a proposal. This is a hypothetical example, not a description of a GIFS client.
This kind of change affects stage descriptions, form hints, and the message after submission. If only the main text on one page is updated, a customer using another version may prepare an incomplete request. In the change record, list every affected location, assign reviewers, and agree on the publication time. Testing must follow the actual inquiry journey in each language. Translation is then considered alongside the service's operation, rather than as a separate file delivered once.
Define the procedure for future updates
A short record is enough for each change: what changed, where the verified source is, which versions are affected, who translates, who reviews and when it may be published. Distinguish “prepared”, “reviewed” and “published”. Otherwise, “the translation is ready” may mean different stages to different people.
Discuss urgent corrections. When a condition no longer applies, the responsible person needs a clear way to correct the affected versions or temporarily remove disputed information. Do not set the same review frequency for every piece of content: company descriptions and changing terms need different attention. Define the events that make a review mandatory within your workflow.
Agree on URLs and language switching
Discuss the technical setup with the developer before adding content. Google recommends separate addresses for language versions and indicating their relationship through hreflang. Google identifies a page's language from its visible content. Translating the menu while leaving the main text unchanged is therefore not equivalent to a full language version. These recommendations are provided in Google’s official guide to multilingual websites.
Check practical details for the user: is the language selector visible, does it open the corresponding material, and can a direct link be shared? Agree on what happens where a translation is not yet available. If the site already has requests and saved links, account for them when changing URLs. Choose the specific solution after reviewing the existing structure.
Check the versions and hand them to the responsible people
Open each version on a phone and a computer. Follow the entire inquiry journey: service selection, form completion, input error, successful submission, and the next message. Check line wrapping, clipped text, character preservation, and accidental language mixing. Record language review and interface testing separately: a convenient button can still contain inaccurate wording.
Give the team a content map, glossary, list of owners and change procedure. Note any materials still untranslated and the agreed way to display them. This is a concrete deliverable that helps maintain both versions after launch.
You can discuss this type of project in the section GIFS website development. Send the list of required pages, available source materials and details of who will approve the Russian and Kazakh text.