How do I get my website translated?
The short answer
Translation is the smallest part. What decides whether it works is where the second language lives, whether the layout supports it, who keeps it current, and whether a machine can tell the two versions apart. Get those four wrong and a professionally translated site still fails — usually by going stale within a season, which is worse than never having translated it.
On this page
The four decisions that matter more than the words
Most people asking this question are thinking about who translates. That is a real decision and it is the fourth most important one.
1. Where the second language lives. On the same domain, as a language section, always. Not a separate domain, not a separate site. A separate domain throws away every bit of authority the first has built and doubles the maintenance for ever — this is the most expensive mistake available here and it is covered in can I have two websites for one business.
2. Whether the layout supports the language. For a left-to-right pair like English and French this is mostly about text expansion — German and Arabic-to-English can run considerably longer or shorter, and a design that assumed one length breaks. For Arabic it is a much bigger job, because the whole layout has to mirror rather than the text simply being swapped. That is its own article: how do I add Arabic to my website.
3. Who keeps it current. The one that kills most translations, and the subject of half this page.
4. Who translates. Genuinely important, and still fourth.
Why machine translation is the wrong default
Not because it is bad. It is remarkably good, and for understanding a page it is fine.
It is the wrong default for a business site for two specific reasons.
It gets the commercially important things wrong most often. Prices, terms, guarantees, cancellation policies, anything legal. These are exactly the sentences where a subtly wrong word creates a dispute, and exactly the sentences a translation engine has least context for.
It reads as translated. Native speakers can tell within a paragraph, and what it signals is that this version was an afterthought — which is precisely the impression you added the language to avoid.
The workable middle for most businesses: a person translates the pages that sell and the pages that commit you, and you leave the rest in one language rather than machine-translating it badly. A site that is honestly bilingual on the pages that matter beats one that is superficially bilingual everywhere.
The maintenance problem, which is the real one
Here is what actually happens to translated sites.
The translation project completes. Both languages are correct on launch day. Then a price changes, and the person who updates it updates the language they speak. Three months later the hours change, same thing. A service is added and only appears in one language.
By the end of the year the second language is a partially accurate version of a business that has moved on — and it is being read by exactly the customers you added it for. A stale second language does not merely fail to help. It actively misinforms, and it tells that audience they are the secondary one.
This is not a discipline failure. It is a structural one. If updating the second language is a separate task, in a separate place, requiring somebody else, it will not happen at the same time as the first — and anything that does not happen at the same time eventually does not happen.
So the question to ask is not "who translates"
It is: when I change a price, do both languages change in the same action?
If the answer is no — two files, two systems, a translator to email, a developer to deploy — then the site will drift, and the only question is how fast.
That single test predicts the outcome better than translation quality does. A slightly clunky translation that is always accurate beats an elegant one that is six months out of date, because the first costs you a little polish and the second costs you the customer.
What this looks like in Helm
Helm's answer to that question is the reason it is built the way it is.
Each piece of text carries its languages together. You write the English and the Arabic in the same screen, on the same field, and press Go Live once. There is no second file, no separate workflow and no way for one to be updated without the other being right there in front of you. That is the whole mechanism, and it is what makes the difference between a bilingual site and a site that used to be bilingual.
The layout is built for both directions, not translated into one. Arabic mirrors properly — navigation, columns, form fields, arrows — with correct numerals and typography chosen for the script rather than inherited from the Latin.
Nothing is machine-translated on your behalf. Deliberately. If you have not written the Arabic, the field is empty and you can see that it is empty, which is a better failure than a confidently wrong price.
The company is London and Beirut, which is the practical reason this ended up built in rather than offered as an add-on.
The short version
Put the second language on the same domain as a section. Check the layout supports it before anyone translates. Have a person translate the pages that sell and the pages that commit you. And above all, make sure both languages change in the same action when something changes — because the translation you pay for is not the cost, the drift is.