A Russian and Uzbek website: translation, development and acceptance checklist

A bilingual site starts with an offer that is equally understandable to both audiences. Translated navigation does not help if delivery terms, form errors or a manager’s reply remain in another language. First list everything a person sees before and after submitting a request. Then agree which materials exist in each language, who checks translation and how both versions are updated. This involves content, interface and the business team together, rather than only adding a language button to the header.

1. Map language coverage

Include services, products, contacts, terms, articles, form messages and notifications. Record source text, translator, reviewer and status for each item. Do not promise an Uzbek website if the catalogue remains Russian-only. Name acceptable exceptions beforehand and make them understandable to visitors. Decide how Latin, Cyrillic, terminology and brand names will be handled. Catalogue search should work with the names actually used. Changing the alphabet mechanically is not the same as editing meaning or checking that customers understand a product.

2. Create a stable URL structure

Give each published language version a permanent URL. Switching should retain the user’s intent: a service page leads to the same service in the other language rather than always returning to the homepage. Sitemaps and language annotations should describe genuinely published versions. Hreflang connects alternatives but does not supply their translation. Do not automatically point every translated page’s canonical to the Russian original. Before launch, request a mapping table and an explanation of what happens when a translation is absent.

3. Translate meaning and commercial conditions

Machine-generated drafts can help if a person checks terminology, negatives, numbers and promises. Compare “from”, “included”, “charged separately” and delivery limitations carefully. Uzbek needs natural writing rather than Russian sentence construction with substituted words. Prepare a short glossary and tone examples for recurring terms. If commercial offers differ between audiences, that difference must be intentional and confirmed, rather than caused by an accidental currency conversion. Review the offer as a whole, not only individual sentences in isolation.

4. Check the request journey in both languages

Translate labels, consent text, errors, submission confirmation and the next step. Include the chosen language with the enquiry so the manager knows the customer’s preference. Test long labels on a narrow screen, name, address and phone input, and server errors without mixed-language messages. Contacts and the expected reply time must remain clear. If bilingual support is unavailable, do not imply it through the interface. Agree an actual enquiry-handling process before publishing and test who receives each request.

5. Keep updates from diverging

Give each published page an owner. A change to price, service scope or address creates work for every affected version. A CMS can expose editorial dates and translation status; an agreed register may be enough for a small site. Updating one text must not silently leave old conditions in another. Before translating everything, try the process on one service and one form. This reveals omissions that would otherwise repeat throughout the site and clarifies who approves a new source text before translators begin.

6. Acceptance: content, links and interface

1. Open each important page directly in both languages.
2. Switch language and stay on the equivalent page.
3. Compare prices, terms, FAQ, contacts and main sections.
4. Complete a successful enquiry and agreed error paths.
5. Check titles, descriptions, canonical and language connections.
6. Edit a sample item and demonstrate translation updates.

Choose an Uzbek editorial approver and a technical reviewer in advance. Automated checks find a missing URL or annotation but may miss unnatural wording or a changed promise. Acceptance needs both kinds of review. Discuss the bilingual structure at https://samsa.agency/en/services/web-development and ongoing changes at https://samsa.agency/en/services/website-support.

7. Separate translation from additional work

Separate source preparation, translation, editing, content entry and technical changes in the estimate. Another language does not automatically include photography, new pages, expanded search or operator replies. Estimate materials and workflows rather than counting menu items alone. Agree who corrects translations after source changes and what happens to an untranslated new page. Publishing in several languages makes information more accessible, but does not by itself guarantee traffic or a search position. Keep these expectations explicit when approving the budget.

Official sources checked on 14 October 2026: language alternatives and hreflang — https://developers.google.com/search/docs/specialty/international/localized-versions ; multilingual site organisation — https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites . Editorial checks and ownership above describe the project-preparation process.