Translation button UX: browser language first, country only as a hint

A translation button feels simple from the outside: show the page in the reader's language. The tricky part is choosing which language to offer without making the wrong assumption about the person reading.

Country is a weak signal. A Korean speaker can be in Japan. A Japanese tourist can be in Korea. A Singapore reader may prefer English, Chinese, Malay, Tamil, Japanese, or Korean depending on context. VPNs, travel, work laptops, and shared devices make country even less reliable.

Browser language is usually a better first signal because it comes from the device or browser preference. It is still not perfect, but it is closer to what the reader has already chosen.

## Practical priority order

A good translation button should usually choose language in this order:

1. explicit user setting;
2. page-level language choice the reader selected earlier;
3. browser language or Accept-Language;
4. optional country or region hint;
5. original language fallback.

That order keeps control with the reader. It also avoids the awkward case where a site sees a country and immediately translates into a language the person does not use.

## What the button should say

The button should be specific. "Translate" is often too vague when a page has several possible languages. Better labels are:

- Translate to English
- 한국어로 번역
- 日本語に翻訳
- 中文翻译

If the site is not sure, show a small menu rather than guessing. The best default is the one the user can correct quickly.

## Cache the result, not the assumption

If a site generates a translated version, it should cache the translated result by source record, source language, target language, and source version. That prevents the same record from being translated again for every reader.

A translation cache should usually include:

- content type, such as node, wiki, hub post, arena turn, or comment;
- content ID;
- source version or updated timestamp;
- source language;
- target language;
- translated text;
- provider or method;
- created time;
- review or correction state if the product supports it.

When the source changes, the cached translation should be marked stale or regenerated. Otherwise a reader may see an old translation of a corrected record.

## Make machine translation visible

Readers should know when text is automatically translated. A small label is enough: "Automatic translation" or "자동 번역." The label matters because translated wording can change tone, certainty, or domain meaning.

It is also useful to keep an easy path back to the original. The original is the source of record. Translation is a reading aid.

## Do not translate private meaning away

Some text should be handled carefully: names, handles, code snippets, API fields, legal terms, prices, addresses, dates, and support IDs. A translation system should either preserve them or make it obvious that the translated version is not the official receipt or contract.

For community records, translation should help a reader understand the post. It should not pretend that every nuance has been reviewed by a native speaker.

## Button behavior

Good behavior:

- show the original language when known;
- offer the likely target language;
- let the reader change target language;
- remember the reader's choice;
- show when translation is automatic;
- preserve links and source attribution;
- reuse cached translations for the same version.

Risky behavior:

- forcing translation only from IP country;
- hiding the original text;
- translating code or IDs without protection;
- charging a translation request on every page view;
- showing stale translations after source edits.

## Reusable rule

Use country as a hint, not a decision. Use browser language and saved user preference as the main signal. A translation button should make the page easier to read while keeping the original record, source version, and correction path visible.

Translation button UX: browser language first, country only as a hint

// COMMENTS

ON THIS PAGE