Someone is reading a service description, finds the paragraph they need, and decides to switch to a language they feel more comfortable with. If the switcher sends them back to the homepage, they get a new search rather than a translation. For us, this is the key test of a multilingual website: does the conversation with the visitor continue after the language changes?
Start with a map of corresponding pages
Before translating, it is worth listing the pages and identifying their counterparts. The versions of a single service, article, or page about the studio should form clear groups. A shared content identifier is more useful than guessing from similar headings: a title may change noticeably when it is adapted naturally.
A simple check starts in the journal archive: open a specific article, change the language, and make sure the topic has stayed the same, not just the design. Then follow the route back. It is a small scenario, but it reveals missing counterparts better than counting flags in the header.
Translation does not end with the main text
A heading and a few paragraphs do not yet make a page a complete language version. Image captions, buttons, form messages, section names, explanations of the sound toggle, and the wording for closing a dialog are part of the conversation too. When they suddenly change language, visitors have to piece the interface together themselves.
We divide the editorial checklist into content and interface states. For the first, we check meaning, terminology, and tone. For the second, we open the menu, trigger an error, and inspect the gallery and supporting elements. For forms, our separate discussion of messages that help people correct an error is useful. These short lines need translating too, rather than being left for later.
The language name matters more than a decorative symbol
A flag can be a familiar visual cue, but it represents a country, not an entire language community. That is why it needs a language name alongside it, preferably written in the language itself. The current selection should be visible without hovering, and the list should also open from the keyboard.
We test long names on a narrow screen without squeezing them into unreadable abbreviations. If the list does not fit, it is better to give it controlled scrolling than let it cover important buttons. You can read more about this approach to testing in our article on keyboard navigation and visible focus.
Two technical markers with different jobs
W3C recommends declaring the main language through the lang attribute on the html element and marking passages in other languages separately. This describes the language of the content.
According to Google's guidance, each language version points to itself and its counterparts using full URLs; the links between versions should be reciprocal.
We check these settings separately from the human experience: a correct technical list will not fix a button that leads to the wrong place. Equally, a convenient switcher is no substitute for consistent URLs and metadata. This is not a promise of indexing or any particular search ranking.
A content update applies to every version
After launch, it is important not to let the website split into several editions that differ in how up to date they are. When a service description, contact detail, or important explanation changes, a short checklist of language versions is needed for review. An update date should reflect actual editing, not simply another build.
Our practical sequence is simple: first agree on the content, then update every counterpart, check the transitions, and only then publish the complete package. That way, translation remains part of working on the website rather than a decorative layer. A good result feels seamless: someone chooses another language and picks up where they left off.