Five locales without duplicating the site

The language set on this site follows the markets we serve. BotAnswer.ai ships its operator interface in English, Thai, Japanese, Simplified Chinese and Traditional Chinese. A business using the product should be able to learn about the company behind it in the same language.

That gives the parent site a practical requirement: cover the primary language of each market we serve, while keeping the company information consistent. I want to improve a product page once and know exactly which translations need to follow.

Two things have to stay aligned: what the page means and where it lives. Translating the text addresses only part of the problem. Navigation, metadata, fonts and publishing decisions still need a shared contract. Here, each Astro route component describes the page structure once, and a copy catalog supplies the words for its locale.

Give the meaning a stable identifier

Using the visible English sentence as a translation key makes an editorial change look like a new interface element. A punctuation correction can invalidate an otherwise useful translation. Two identical labels can also need different translations when they belong to different contexts.

Our catalog uses semantic identifiers such as home.hero.cta.primary. The identifier describes the role. The text can change without making the template guess whether an old sentence still matches.

The build checks that referenced identifiers exist and that locale catalogs have the expected shape. When an entry is missing, the build names it. I can fix a specific identifier instead of searching the rendered pages for a gap.

Translate a complete unit of meaning

A sentence with a link is still one sentence. Splitting it into disconnected words and fragments makes word order an implementation constraint for the translator.

The page should preserve the relationship between the surrounding sentence and the linked phrase while letting the locale express that relationship naturally. Where markup is involved, the content contract needs to describe the whole translation unit, including the part that remains a link. It should not depend on the translator reconstructing HTML from fragments.

Make incomplete review visible in the workflow

New English copy does not instantly become reviewed Japanese or Thai. Pretending otherwise produces a green build that communicates the wrong editorial state.

We record provenance for locale entries. A changed passage can temporarily carry its English source with a needs-review marker. The translation manifest records exactly what needs attention during editing. The release check now rejects those fallbacks, so a complete set of keys cannot stand in for translated body copy. Machine-authored translations keep their provenance after completion; that does not make them native-speaker reviewed.

This matters most during ordinary edits. A product gains a feature, an availability date changes, or a sentence needs to be clearer. The next translation pass can focus on those identifiers. The rest of the page keeps its existing translation.

Give every language a real address

The language prefix is part of the page’s address. For BotAnswer.ai, the same product page has five routes:

Language	Page path
English	/botanswer/
Japanese	/ja/botanswer/
Thai	/th/botanswer/
Simplified Chinese	/zh-hans/botanswer/
Traditional Chinese	/zh-hant/botanswer/

English uses the root path. The other versions add a locale prefix while keeping the product slug. Someone can share, bookmark or open the Japanese page directly and reach that version without first selecting a language elsewhere.

Each address serves a complete, prerendered HTML document. A crawler can request the page and read its content without operating the language selector. This follows Google’s guidance to use distinct URLs for language versions, rather than making language availability depend on a cookie or browser preference.

The URLs are only part of the SEO work. Each translated page has a self-referencing canonical, and its hreflang links identify the corresponding versions, including itself. The English version also supplies the x-default destination. Our sitemaps describe the same relationships. These signals help search engines discover and associate the versions; they do not guarantee indexing or rankings. Google’s localized-page guidance explains the reciprocal links that make the relationship explicit.

All of those addresses come from the same route manifest. The navigation, canonical tags and sitemaps should not have three separate opinions about where a page lives.

There is one deliberate exception here: the articles are published in English. The Journal index and site navigation are localized, but article links lead to the English original. We do not advertise translated article URLs with no content behind them; their language metadata and sitemap entries reflect what is actually published.

Start with the visitor’s language

A customer should not have to find the language control before they can read the page. On a first visit to an unprefixed address, this site checks the browser’s ordered language preferences and selects the first supported language. Regional variants map to the appropriate catalog: Japanese in Japan still resolves to Japanese; Traditional Chinese preferences resolve separately from Simplified Chinese. Unsupported preferences fall back to English.

That is a starting point, not a decision about someone’s identity or location. An explicit locale URL wins, and a language chosen in the selector is remembered for later visits when browser storage is available. Choosing English stays a valid choice. The route, query parameters and section anchor survive the initial language selection; English-only articles stay in English.

BotAnswer.ai uses the browser’s Accept-Language request header at the edge to choose the initial language. This static parent site reads the same kind of preference through navigator.languages in the browser, then uses its client router to open the localized page. The implementation differs, but the aim is the same: greet the customer in a language they use, and keep the choice easy to change. With JavaScript off, the English entry page and all explicit language links remain available.

Change the language without restarting the page

I want a visitor reading about BotAnswer.ai to be able to choose Thai and continue on the same product page. The URL should change with the language, while the transition feels like part of the same visit.

That is where JavaScript comes in. This site uses Astro’s ClientRouter to handle internal navigation. When someone follows a language link, it fetches the destination’s HTML and updates the DOM—the browser’s document structure—with the new page. It also updates the document language, page title and head metadata, including the canonical and language alternates. Browser history records the destination, so the address bar, Back and Forward stay meaningful.

Language links also opt into prefetching, so hovering over an option can start loading its destination before the click. That reduces the work left at selection time without loading every translated page on arrival.

The visible content and URL change without a full browser-level page reload. The destination is still the same HTML document a direct visitor or crawler would receive. We get a smoother transition while keeping each language version independently addressable.

This is also why the language selector contains ordinary links. With JavaScript disabled, those links still open the correct page through normal navigation. The router improves the experience; reading the content does not depend on it.

Check the transition as well as the destination

A language switch can look convincing while leaving the old URL or metadata behind. Our browser checks verify the target route and document language, and confirm that the selector keeps the visitor on the equivalent page rather than sending them home.

To check for a full reload, a test places a temporary value on window before switching languages. It must survive the transition. A fresh document load would clear it. Separate checks inspect the generated HTML, canonicals, language alternates and sitemaps. The smooth transition and the crawlable documents each need their own evidence.

For this site, those details support the same goal as the five-language product: a business should be able to move from the software to the company behind it without losing its place. Shared templates keep the work maintainable. Locale URLs make the pages reachable. Client-side navigation makes the move feel continuous. Translation review is what makes the words worth arriving at.