Multilingual website for selling abroad: what to prepare beyond translation

Translating a website is the easy part, and the least decisive one. A version in another language generates requests only if there's someone on the other end who responds in that language, with terms that apply to that market, and a real ability to deliver or provide service. This guide helps you decide which versions to actually launch, and what to prepare before publishing them.

The most concrete risk isn't translating badly. It's launching five languages and not being able to follow up on the requests coming in from three of them.

Start from the requests you've already received

Before choosing a market on paper, look at what has already happened. The information is almost always there, and no one has ever put it together.

• Which countries unsolicited requests have come from in recent years, and what they were asking for.
• Which of those requests turned into orders and which stalled — and what they stalled on: price, shipping, language, certifications, lead times.
• Where you already have a presence in some other way: a reseller, an agent, a trade fair you attend, a customer who in turn exports.
• What your product is called in that country. If the technical name is different, search there runs through that word, not a literal translation of yours.

A market where nothing has ever come in and where you know no one isn't necessarily off the table, but it's a sales investment, not a translation.

A language is not a market

The two get confused constantly, leading to the wrong structure. German covers countries with different sales terms, competitors, and expectations. English isn't the English market: it's the language of people who don't speak yours and look for you anyway. Latin American Spanish isn't the Spanish of Madrid.

Two practical decisions follow from this: whether you need a version per language or per country, and what changes between two versions of the same language. Usually what changes is the references, the contacts, the delivery terms, and the cases shown — not the entire text.

What gets adapted, beyond the words

• Examples and references. A case told with an Italian client and an Italian regulation doesn't speak to a foreign reader: it's a good piece of writing that proves the wrong point.
• Terminology. It needs to be fixed once, in a list shared with whoever translates: what your product is called, what shouldn't be translated — model names, trademarks, abbreviations — and how technical terms are rendered.
• Units and formats: measurements, currencies, dates, sizes, voltages, number formats. These are the details that let a technical reader tell in two seconds that this site isn't for them.
• The contact path. A form that asks for an Italian province, a phone number without an international prefix, hours that don't say which time zone: each one of these stops a foreign request.
• Certifications and terms. If a market requires documents you have, showing them is half the sales work; if you don't have them, that market isn't ready to be opened.

The market, language, service, owner matrix

A single table settles most discussions, because it forces you to write a name next to every row. The one below is an illustrative example, for a company that manufactures components and also sells support.

The most useful row is the last one. Stating in writing that a market isn't open prevents someone from translating the site "just to have a presence" and requests coming in that no one can answer.

Who keeps the versions aligned

A multilingual site ages unevenly: the main version gets updated because everyone uses it, the others stay frozen. After a year, products, terms, and contact people are different from one language to another, and no one knows it.

1. Establish which version is the reference one: changes go there first, always.
2. Decide what needs to be translated right away — products, terms, contacts — and what can stay in the main language only, such as news and in-depth content.
3. Name who reviews the translation before publishing: someone who knows the business, not just the language. A good translator who doesn't know what you do produces a text that's correct and useless.
4. Set a fixed, recurring check where the versions are compared and whatever's fallen behind gets closed out.

A version that can't be kept up to date is worse than a missing one. If you can't maintain it, it's more honest to publish just one page in that language explaining what you do and how to contact you, and leave the rest in the main language.

When the first foreign request arrives

The moment that reveals whether the project succeeded or was pointless is the first message in a language no one in the office speaks well. It's worth deciding this in advance: who reads it, how fast you respond, in what language, and what you do if the request concerns something you can't supply in that country.

Foreign requests need to be kept separate in your counting too. Mixed in with Italian ones, they disappear, and after a year no one can say whether a given version has produced anything. One extra field in the form or a dedicated email address per version is enough.

What this guide doesn't cover

This guide covers the international company website: which versions to launch, what to adapt, who keeps them alive. Actually selling abroad with an online store — shipping, duties, returns, local payments, per-country pricing — is a different matter with its own dedicated guide. How to structure the URLs of the language versions also needs to be decided together with whoever handles search engine visibility.