October 08, 2026
A multilingual website should be one site: one set of templates, one database, one deployment, where every piece of text comes from a language file or a language column, every URL says which language it is in, and every page tells Google about its siblings in the other languages. That is how we built the website for Asia Pacific Ceramic, a tile exporter, in seven languages including a fully mirrored right to left Arabic edition, with an e-catalogue, packing details and a coverage calculator working in all of them.
The alternative, seven copies of the site or a translation plugin bolted onto one, is how most multilingual sites in India end up: out of date in six languages, broken in Arabic and invisible in every Google except the English one. This article goes through the build decision by decision, so you know what to ask for.
Separate the words from the templates, then make the language a property of the request rather than a copy of the site.
In practice, for a custom PHP and MySQL site, that means three things. Every fixed string on the site (menu labels, button text, form labels, headings that do not change per product) lives in a language file, one per language, and the template asks for a string by key rather than typing it. Every piece of content that comes from the database (product names, descriptions, packing notes, article bodies) has a field per language, or a translations table keyed by language, with a fallback to the main language when a translation is missing. And the code reads the language once, from the URL, and hands it to every template, query and helper on the page.
Once that is in place, adding a language is a new language file, a new set of translated content rows and a new hreflang line. No new templates, no new deployment, no second site to keep in step. When the tile exporter changes a packing table, it changes in every language at once, and only the translated text needs a translator.
The mistake to avoid is starting with the English site and translating "later". Strings typed straight into templates, images with English text baked in, layouts that assume left to right and short German words that turn out to be twice as long in the menu: each of these is cheap to handle at design time and a rebuild afterwards. Decide the languages before the first screen is drawn.
A subfolder per language on one domain, unless you have a strong reason otherwise.
The three options are a folder such as /ar/ on the main domain, a subdomain such as ar.example.com, or a separate country domain such as example.ae. Folders keep every language under one domain's authority, one hosting account, one certificate and one Search Console property, and Google treats them as the same site, so links earned by the English pages help the Arabic ones. Subdomains split that authority for no gain. Separate domains make sense only when you run genuinely different businesses per country with local offices, local pricing and local marketing budgets, because each domain has to earn its own links from scratch.
Whichever you choose, the rules are the same. The language must be in the URL, so /ar/tiles/ and /fr/tiles/ are different addresses that a buyer can bookmark and Google can index separately. Never switch language by a cookie alone with the same URL, because Google will only ever see one version. And do not redirect a visitor automatically based on their IP address or browser language: a Gujarati buyer visiting from Dubai does not want to be forced into Arabic, and Googlebot crawling from the United States will only ever see English. Offer the switch; do not impose it.
The switcher itself should take the visitor to the same page in the other language, not to the home page. That sounds obvious and is missed on most multilingual sites we audit.
Hreflang is a set of tags in each page's head that lists every language version of that page and its URL, so Google shows the Arabic page to an Arabic searcher and the French page to a French one, rather than guessing or treating them as duplicates.
Each page carries one line per language, including itself, plus an x-default line pointing at the version to show when no language matches. Every version of the page has to list every other version, or Google ignores the set. The same information can go in the XML sitemap instead of the page head, which is easier to generate and check on a site with hundreds of product pages, and is what we do when the page count is high.
Skip it and three things happen. Google may index the wrong language for a country, so a buyer in Riyadh sees the English page and bounces. It may treat translated pages as near duplicates and drop some from the index. And the seven language versions compete with each other for the same query instead of each serving its own market. On a one codebase build the hreflang set is generated from the same list of languages the templates use, so it cannot drift out of date; on a site assembled from copies it is nearly always wrong within a year.
Mirroring the whole layout, not only the text.
An Arabic reader starts at the top right. So the logo sits on the right, the navigation runs right to left, the sidebar swaps sides, tables read from the right column, form labels sit to the right of their fields, icons that imply direction (arrows, chevrons, "next" and "back") flip, and slideshows advance leftwards. Numbers stay left to right within the text, which is the part that catches developers out. On the tile exporter's site the entire edition is mirrored, including the catalogue, the packing tables and the coverage calculator.
Technically, this is done once, in the CSS, rather than as a second stylesheet. The html element gets dir="rtl" and lang="ar" for the Arabic edition, and the layout is written with logical properties (margin-inline-start rather than margin-left, padding-inline-end rather than padding-right) so the browser flips it. Anything written with physical left and right values has to be found and rewritten, which is why an Arabic edition added to a finished site costs almost as much as the original build.
Then the details. Arabic needs a typeface that carries the script well and is loaded only on the Arabic edition, at sizes that read comfortably, because Arabic at the same pixel size as Latin text looks smaller. Line height goes up. Text in images has to come out of the images. Animations that slide in from the left slide in from the right. And every one of these has to be tested by someone who reads Arabic, on a phone, because a mirrored layout that looks right to an English speaker can still put the enquiry button in the wrong place for the person who needs it.
From a professional translator with a glossary, checked by a native speaker in the trade, and it takes longer than the code.
Machine translation is good enough for a first pass on descriptive text and is unusable for technical vocabulary. "Glazed vitrified tile", "water absorption", "rectified edge", "pieces per box": each has a settled term in the tile trade in each language, and a translator who does not know it produces a page a buyer trusts less than the English one. So the first job is a glossary of the trade terms the site uses, agreed with the client, which every translator works from. The second is the string count: a site's fixed strings usually run to a few hundred entries and the product content to many thousand words, and the client needs to know the total before choosing seven languages over four.
The workflow we use is an export of every string and every content field into a sheet, one column per language, sent to the translators, reviewed by a native speaker (often the client's own agent or distributor in that market, who knows how buyers there talk), and imported back into the language files and the database. Then a full read through of every page in that language, on a phone, by the reviewer. Budget more time for this than for the build itself, and plan the launch language by language rather than waiting for all seven.
They have to work in every language, including the numbers.
The e-catalogue on the tile exporter's site is generated from the same product data as the pages, so a translated product record produces a translated catalogue without a designer laying out seven PDFs. Packing tables are mostly numbers, but the headers, the units and the notes are text, and the numbers themselves need care: decimal and thousand separators differ by language, and Arabic can display either Eastern Arabic or Western digits depending on the market, which the client has to decide.
The coverage calculator is the hardest piece. It takes an area, a tile size and a wastage allowance and returns boxes, pallets and containers. Every label, every unit and every error message goes through the language file, the input fields mirror in Arabic, and the output has to format numbers for the language. It is a small tool, and it is the one importers use most, so it gets tested in every edition before launch.
The Asia Pacific Ceramic site is the one we can show in full: seven languages from one codebase, a fully mirrored Arabic edition, catalogue, packing and calculator working in each. The case study on our site carries the screens, including the three phone responsive build image with the editions side by side.
When you look at any multilingual site as an example, including ours, check these things rather than the home page:
A site that passes those six is built properly. Most that look multilingual on the home page fail at least two.
Take the cost of the site in one language and add the languages, the translation and, for Arabic, the mirroring.
In India today a 5 to 10 page business website runs roughly 10,000 to 40,000 rupees from a freelancer, roughly 40,000 to 1,50,000 from a small studio, and roughly 1,50,000 to 5,00,000 and above from an agency that also does strategy and writes the content. A multilingual export site is bigger than 10 pages to begin with, and each language adds translated content, review time and testing, so it sits at the top of the band or above it.
What moves the number: how many languages; whether one of them is right to left, which affects the design and the CSS across the whole site; how much content there is to translate (a 20 product catalogue is very different from a 300 product one); whether the client's own people can review translations or the studio has to source reviewers; and whether the catalogue and calculators are generated from data or laid out by hand. Translation itself is usually billed separately by the translator, per word or per language, and should appear as its own line in any quote.
The one codebase approach costs more up front than a plugin and far less over three years, because every content change is made once. The site is built on custom PHP and MySQL, the client owns the code, the design files and every credential at handover, and adding an eighth language later is a language file and a translation job rather than a project.
If it was built with strings in language files and content fields per language, yes, cheaply. If English is typed into the templates and images, each language is effectively a rebuild, and a right to left language is a rebuild of the layout as well.
It lets each edition rank in its own language's search results, which an English only site cannot do. The condition is that every edition has its own URL, correct hreflang and real translated content. Machine translated pages published unchecked usually do more harm than good.
No. A folder on the main domain, built from the same code with dir set to rtl and a mirrored layout, keeps one site to maintain and shares the domain's authority. A separate site doubles the work and splits the ranking signals.
The ones your best buyers read. For exporters out of Morbi that is most often Arabic first, then the European languages of your main markets. Launch the main language first and add the others one at a time rather than holding the site for all of them.
Sign in with Google to join the conversation. We use it for your display name and nothing else, and your email address is never shown.
No comments yet. Sign in above to write the first one.