How to Add a Website Translator to Your Website

Two quite different problems get solved with the same phrase. One is a visitor who has landed on your site and cannot read it. The other is being found by someone searching in another language. A translator widget solves the first one well and the second one not at all, and most of the disappointment in this area comes from expecting both.

That distinction is the spine of this guide. The first half is about doing machine translation properly, which is worth doing and takes about an hour. The second is about what to do when you actually need to reach a market rather than accommodate a reader.

Along the way: choosing languages, the layout problems translation causes, what should never be machine translated, and the settings that decide whether the feature helps or irritates.

What a Widget Actually Does

A translator widget adds a language selector to your page. When a visitor chooses a language, a script sends your text to a translation service and swaps the words in place, in the browser.

Three consequences follow, and they explain everything else in this guide.

• There is no new page. The address does not change, so nothing exists for a search engine to index or for anyone to link to in that language.
• It happens after loading. The visitor sees the original briefly, then the translation appears.
• It covers text, not everything. Words in images, in PDFs and in some interface components are usually left as they were, which produces a half translated page unless you plan for it.

None of that makes it a bad tool. It makes it a specific tool: a way to let someone already on your site read it. For a local business with international visitors, a support section, an internal site or a small business whose content changes daily, that is exactly the right answer.

The SEO Reality

This is where the category has a credibility problem, so it is worth being exact.

To rank in another language you need pages in that language, each at its own address, discoverable by a crawler, and connected to their equivalents so search engines understand the relationship. Google's documentation on managing localised versions of a page sets out how those connections are declared.

A widget provides none of that. The translated text exists only in one visitor's browser for the duration of their visit. There is nothing to crawl, nothing to link to and nothing to rank.

So if the goal is customers in another country finding you through search, budget for real translated pages, and treat that as a project rather than a plugin. If the goal is that the Portuguese speaking visitor who found your English page can read it, the widget does that today for very little effort. The mistake is buying one and expecting the other, and the fastest way to check which you need is to look at whether your problem is people arriving or people not arriving. The wider technical groundwork for the first case is in our technical SEO basics.

Choosing Which Languages to Offer

The instinct is to offer everything the service supports. Resist it, because a list of forty languages is a menu nobody reads and a signal that nothing was considered.

1. Look at your analytics. Country and browser language of real visitors, over a few months. This usually surprises people and it settles the question.
2. Ask where your enquiries come from. A handful of countries usually account for most of them, and those are the languages worth having.
3. Consider the languages of your area, not only of your visitors. A shop, clinic or restaurant serves the people nearby, which may include communities your analytics do not distinguish.
4. Cap the visible list at four or five, with the rest available in a longer menu if the tool offers one.
5. Name languages in their own language. A visitor looking for Deutsch is not scanning for German.

One extra consideration: right to left languages such as Arabic and Hebrew change the direction of the entire layout, not just the words. If those are on your list, test the pages properly rather than assuming the widget handles it.

Where the Switcher Goes

People look for a language control in two places and nowhere else: the top right of the page, and the footer.

• Top of the page for a site with a real international audience. If a good share of your visitors need it, it belongs where they will see it without scrolling.
• Footer for occasional need. Perfectly acceptable, and it keeps the header uncluttered. People who need it will scroll.
• Not hidden behind an icon alone. A globe icon with no text is ambiguous, and flags are worse: a flag is a country, not a language, and choosing one to represent Spanish or Arabic manages to be both inaccurate and impolitic.
• Remember the choice. A visitor who selected a language and finds every subsequent page back in the original will not select it again.
• Keep it in the same place on every page. Including in the mobile menu, where language controls are frequently dropped.

What Translation Does to Your Layout

Text changes length when translated, often substantially, and designs built around English string lengths break in predictable places.

• Buttons. A one word English label can become three words elsewhere. Fixed width buttons either clip or wrap awkwardly.
• Navigation. The first thing to break, because a horizontal menu has no room to grow.
• Headlines in constrained spaces, such as hero sections and cards, where a longer translation collides with the design.
• Tables and forms, where labels can outgrow their column.
• Anything in an image. It will not be translated at all, so a page can end up with English headings inside pictures and translated text around them.

Two practical rules cover most of it. Let containers grow with their content rather than fixing their size, and keep important words out of images. Then check the two or three languages you offer on a phone, since narrow screens are where the collisions actually appear.

What Should Never Be Machine Translated

Machine translation is good and it is not accountable. Some content needs a person who can be.

• Legal text. Terms, privacy notices, contracts. A machine translated obligation is still an obligation, and an inaccurate one is a problem you own.
• Safety and medical information. The one category where an error can hurt somebody.
• Prices, tax and shipping terms. Numbers survive translation and the words around them may not, which is how a conditional offer becomes an unconditional promise.
• Your core sales message. The paragraph you spent a week on does not survive a machine, and it is the paragraph doing the work.
• Anything idiomatic or humorous. The reliable way to be accidentally strange in another language.
• Names, addresses and instructions to type something exactly. These should be excluded from translation explicitly, since a translated code or street name is actively wrong.

Most decent tools let you mark sections to leave alone. Use it on the categories above, and consider a short human translated version of your key page as the one piece of real localisation worth paying for early.

Machine Translation Against Real Localisation

The last row is the decision. If you are trying to serve people who arrive anyway, the widget is proportionate and the translated pages are overkill. If you are trying to win customers in a country, the widget is not a step toward that and the pages are the only route.

A sensible middle path exists and is underused: translate two or three pages properly, the ones that carry your offer and your contact route, and let the widget handle the rest. It costs a fraction of a full localisation and covers the moments that matter. If those visitors are far away, the loading speed of the pages matters too, which is where serving content across geographies becomes relevant.

Who Genuinely Benefits From a Widget

Some sites should add one this afternoon and others are better off spending the effort elsewhere. The difference is usually who is already arriving.

• Local businesses in mixed language areas. A clinic, a garage, a letting agent or a restaurant serving a neighbourhood where several languages are spoken. The visitor is local, the need is immediate, and comprehension is the entire job.
• Tourism and hospitality. Visitors arriving from anywhere, mostly on phones, mostly looking for opening times, prices and directions. A widget answers all three.
• Support and documentation. High volume, changes often, and the cost of a slightly awkward sentence is low while the cost of not understanding at all is high.
• Internal sites and intranets. No search consideration whatsoever, and a genuinely multilingual workforce.
• Anything that changes daily. News, listings, availability. Human translation cannot keep pace and does not need to.

Where it helps least: a marketing site trying to enter a market, a product whose value depends on precise wording, and any site whose international traffic is negligible. In the last case the honest answer is that nobody is being turned away, and the effort belongs on the audience you do have.

The quickest way to decide is to look at how many visitors already come from countries where your language is not the first one. If the number is meaningful, the widget pays for itself in an afternoon. If it is a rounding error, adding one is a change nobody will experience.

Details That Make It Feel Considered

Small things that separate a thought through implementation from a script someone pasted in.

• Declare the page language in your markup, which helps browsers, screen readers and translation tools alike.
• Exclude your brand name from translation, along with product names and codes.
• Check your fonts have the characters. A font missing accented or non Latin characters produces boxes or an abrupt fallback that looks broken.
• Think about dates and numbers. A translated page with a date format from your country will still confuse, and machine translation does not usually reformat them.
• Translate your form errors and buttons too, not only the prose. A translated page with an English validation message is where the illusion collapses.
• Say what the translation is. One quiet line noting that translations are automatic sets the right expectation and buys goodwill when something reads oddly.

If You Decide to Translate Properly

At some point a widget stops being enough, and the transition is easier if you know what it involves before you start.

Each language needs its own addresses. Either a folder per language, a subdomain, or a separate domain per country. A folder is the simplest to run and the usual choice for a small site.

The versions must be connected. Each page needs to declare its equivalents in the other languages, so search engines show the right one to the right person rather than treating them as duplicates.

Every page needs a decision. Not all of them need translating. Your offer, your contact route and your two or three most read pages usually justify it, and a hundred blog posts usually do not.

It is maintenance, not a project. Every future edit exists in each language. Sites abandon localisation at this step more than at any other, which leaves versions that contradict each other.

Somebody has to own it. Preferably somebody who reads the language, even part time.

The practical order that works: widget first, so nobody is stranded today, then a handful of properly translated pages, then more only if those pages produce something. Doing it in the opposite order, starting with a full translation of everything, is how organisations end up maintaining three stale copies of a website.

Accessibility

Language and accessibility are more entangled than most people realise, and a translator widget touches both.

Screen readers choose a voice from the declared language. If your page says it is in English and the visible text is now Spanish, the result is unintelligible. Tools that update the language declaration when they translate are doing something important.

The switcher must be usable by keyboard, and must announce itself as a language selector rather than as an unlabelled dropdown.

Do not remove the original. Some readers are more comfortable with your original language than with an automatic rendering of their own, so switching back must always be possible.

Watch contrast in the translated state, particularly where longer text now wraps over an image.

Do not trap focus in the language menu, which is a common fault in dropdown implementations and makes the whole page unusable for a keyboard user.

Checking the Translation Is Not Embarrassing

Nobody on your team reads all the languages you are about to publish in, which is exactly why a short check is worth doing rather than skipping.

1. Take your five most important sentences and have them checked by someone who speaks the language. Not the whole site, five sentences: your headline, your offer, your main button, your contact instruction and your price line.
2. Translate back. Running the output through translation in the opposite direction is crude and it reliably catches sentences that have inverted their meaning.
3. Look at the buttons and the menu, which is where nonsense hides because nobody reads them as sentences.
4. Check anything with a negative in it. Negations are where machine translation errs most visibly, and where the consequences are worst.
5. Ask a customer. If you have a client or supplier who speaks the language, two minutes of their time is worth more than any tool.

What you are looking for is not elegance, which machine translation will not give you. It is the sentence that says the opposite of what you meant, or the one that is unintentionally rude. Those are rare and they are the only ones that do damage.

Repeat the check when you change your key pages, since the translation follows your source text and a new headline is a new translation nobody has ever read.

Problems and Their Fixes

• Half the page translated. The untranslated parts are images, PDFs or content loaded after the script ran. Move important words out of images.
• The layout breaks in one language. Text expansion meeting a fixed width. Let the container grow.
• The page flashes the original first. Inherent to translating in the browser. It can be reduced, not eliminated, which is a reason to keep the switcher visible so people know what happened.
• Visitors keep landing in the wrong language. Automatic switching based on location. Suggest instead of switching, and remember the choice.
• Your brand name got translated. Add it to the exclusion list, along with product names.
• A translated price reads as an offer you did not make. Take prices and terms out of machine translation entirely.
• Nothing appears in search for the translated languages. Expected, and it is the point of the SEO section above.
• The switcher vanished on mobile. It was in the header and the header collapsed. Check the mobile menu contains it, since this is where language controls are lost most often.
• Text in one language runs off the screen. A long compound word with nowhere to break. Allow wrapping inside long words for that language rather than shrinking the whole page.

The pattern behind most of this list: translation exposes assumptions your design made about how long words are, where text lives, and which language things are in. None of the fixes are difficult, and all of them are invisible until you look at the site in another language, which is why the twenty minute check after setting it up is the highest value part of the whole job.

Getting Started

The short path. Check your analytics and pick three or four languages rather than forty. Put the switcher top right or in the footer, name languages in their own language, avoid flags, and remember the visitor's choice. Exclude your brand, your prices and your legal text from automatic translation, and get the two pages that carry your offer translated by a person. Then look at every page in each language on a phone.

If you want the switcher without building anything, a website translator widget adds it to any site with one embed, and leaves you to spend the effort on the handful of pages that deserve a human translator.

Keep the expectation honest with yourself as well as with visitors. This is a hospitality feature: it makes your site usable by someone who found you anyway, and it is a good thing to do for that reason. Reaching people who have not found you yet is a different piece of work, and knowing which one you are doing is most of getting it right.

An international audience usually brings a second question with it, which is when anyone is available. A world clock on your contact page answers that one, in the visitor's own time.