Localisation 5 August 2026
Multilingual URL Structure and the Locale Gateway: What Does the Address Bar Give Away?
Two letters in the address bar decide which version a visitor lands on. On a multilingual site, the address scheme is a decision that has to be taken before translation.
The first thing you notice when you arrive on a multilingual site may not be the text. A small addition in the address bar tells you which version you have landed on. That addition is not merely a technical detail; it is a shared signpost for the user, for the search engine and for the maintenance team.
Contents
Multilingual URL structure is one of the matters that has to be settled before translation in a localisation project. The source notes that the locale marker can sit inside the address, and that a folder and file arrangement has to be set up for each new language at the preparation stage (Jiménez-Crespo 2024, pp. 178, 184-185).
Below we set out how the address scheme is built, what a mirror structure means, how links are redirected and what the locale gateway is for. Most of these decisions are hard to reverse, which is why they should be discussed from the outset.
Why is the address a localisation matter?
The address is the sole identifier of a web resource. It appears at the top of the browser, it is shared, it is bookmarked and it is listed in search results. When a page’s address changes, every link that points to it is affected. The address scheme is therefore one of the most permanent components of a site.
In localisation the address serves two functions. The first is separation: it shows which content belongs to which language. The second is routing: the server uses this information to pass an incoming request to the right version. If either of them fails to work properly, the user lands on a page in the wrong language.
There is a third dimension as well: readability. An address whose meaning is clear both reassures the user and carries information when it is used as link text. Addresses made up of meaningless character strings lose that advantage.
The locale marker in a multilingual URL structure
The locale marker is a short code that carries the language and, where needed, the country information inside the address. The source gives examples showing that this marker can sit inside the address, that the short language code is used for English, and that a combination of language and country is used in cases such as Mexican Spanish (Jiménez-Crespo 2024, p. 178).
If you are opening up to a single language, the language code on its own is usually enough. If the same language is to have different versions in different countries, language and country are written together. This distinction is meaningful where there are differences in price, delivery or regulation; otherwise it only creates a maintenance burden.
What matters is consistency. If the language code appears as a folder in one section and as a parameter at the end of the address in another, both the user and the indexer become confused. Setting the pattern down in writing at the start of the project costs less than the bulk corrections that would otherwise follow.
Address pattern options
A few common patterns are seen in practice. None of them is superior in every case; the choice depends on the number of markets, on technical capacity and on maintenance resources. The table below compares the patterns and their effects on localisation.
| Pattern | How it looks | Effect on localisation |
|---|---|---|
| Subdirectory | The language code comes after the domain name | Managed on a single infrastructure; the easiest route to set up and maintain |
| Subdomain | The language code is added in front of the domain name | The versions are more independent; separate configuration is required |
| Country-code domain | A separate extension for each country | Local trust perception is high; the greatest cost and maintenance burden |
| Parameter | A language variable is added to the end of the address | Readability is low; giving out permanent links becomes harder |
Two questions help when the decision is taken. Is it only the language that changes between versions, or do the price and the product range differ as well? Will a single team take on maintenance, or will each market have its own team? If the answer to the second question is “each market has its own team”, the more independent patterns start to make sense.
What do dynamic addresses give away?
Addresses today are largely dynamic. The site is pulled from the server as a template and the content is filled into that template. The source notes that on active or dynamic pages the address contains characters such as the question mark and the ampersand (Jiménez-Crespo 2024, p. 178).
Seeing these characters gives you a quick sense of how the site works. If the content comes from a database, the scope of the translation is measured not by the number of files but by the number of records. Drawing that distinction at the quotation stage prevents surprises over volume later on.
Most modern infrastructures make the address shown to the user readable. Even when a parameter is running in the background, the name of the page appears in the address. These names have to be localised too; English folder names left in place on Turkish pages are a common oversight.
The question of who will decide the address names also has to be answered from the outset. If the translator chooses page names freely, the pattern can break down; if the developer decides alone, the names can feel foreign to the local user. The healthiest arrangement is to deliver the address names in a separate column of the translation package.
Mirror structure: the skeleton of the new language
The first step of the preparation stage is setting up a parallel or mirror structure of the target site. Folders and files are created for each new language and the source files are transferred under their new locale names (Jiménez-Crespo 2024, pp. 184-185). If a management system or a plugin is in use, this work is largely automatic.
The value of the mirror structure emerges at the maintenance stage. When the two versions sit on the same skeleton, it is immediately visible which page has no counterpart. When the skeletons diverge, a content gap grows quietly between the languages, and past a certain point that gap can no longer be closed.
When the mirror structure is being set up, it is recommended that similar components be gathered into homogeneous packages: texts, scripts, frames, pop-up windows, page titles, audio files and images with embedded text. This grouping clarifies the order of translation and the division of responsibility.
Link routing and broken links
Once the new structure is in place, internal and external links have to be rebuilt or redirected. Links are readdressed inside HTML, scripts and other files (Jiménez-Crespo 2024, p. 185). Done by hand, this is one of the steps that produces the most errors.
The source counts link errors among the typical error types specific to web localisation. Sections left in the wrong language, broken syntax caused by concatenation and missing image descriptions appear in the same list. What these errors have in common is that they do not show up in a check that looks only at the text.
The practical solution is to run an automated link scan before going live. The scan lists broken links and redirects that lead to the wrong language. Repeating the same check after every content update stops the problem from building up.
External links call for a separate decision. If an external link on the source site goes to a page that has no counterpart in the target market, carrying the link across as it stands drops the user into a void. Replacing such links with local equivalents or removing them altogether should be noted separately in the scope document.
What is the locale gateway for?
Sites can display the local version dynamically according to the location they are accessed from. In some cases a locale or global home page, that is, a gateway, is created (Jiménez-Crespo 2024, p. 185). The gateway is the intermediate page on which the visitor makes their country and language choice.
Automatic redirection carries a risk of its own. A user connecting from abroad can land on a page in a language they did not want simply because of their location. A gateway, or a visible language selector, offers the user a way out in that situation. Remembering the choice also improves the user experience noticeably.
How the language selector is labelled matters too. Showing languages with flags is a widespread but problematic habit; a flag denotes a country, not a language. Writing language names in their own languages is in most cases the clearer solution.
Setting up a gateway has a price as well: the user takes an extra step before reaching the content they are after. Most sites therefore use automatic redirection together with a visible language selector. Which solution to choose is decided by looking at the number of markets and at where the visitors come from.
The Türkiye context
With Turkish addresses the first issue is characters. Because circumflexed and dotless letters can cause trouble inside an address, the standard practice is to convert them into their basic Latin equivalents. The conversion rule has to be the same across the whole site; otherwise the same word is written differently on different pages.
The second issue is length. Because Turkish is agglutinative, page names tend to be longer than their English equivalents. Moving the key phrase to the front and dropping unnecessary suffixes is a common way of shortening the address.
The third is the choice of country extension. Using a local extension can have a positive effect on trust perception in Türkiye; but in a structure that opens up to several markets, maintaining separate domain names means extra cost. The decision is taken between marketing expectations and maintenance capacity.
What does this mean for you?
The address scheme is one of the most expensive decisions to change after the fact. Completing the sequence below before you order translation makes the bulk corrections of the future unnecessary.
- Determine which markets you will open up to and whether each market needs a language-country distinction.
- Choose the address pattern and fix it in writing with a sample page.
- Tie the Turkish character conversion rule to a single table.
- Prepare a redirect list for the old addresses that will change.
- Decide where the language selector will sit and how it will be labelled.
These five items keep the developer and the translation team on the same page. You can find our service scopes on our translation services page, and fill in the quotation form for your project plan.
Frequently asked questions
Where in the address should the language code go?
The common practice is to put the language or locale code as a folder immediately after the domain name. The source notes that the locale marker frequently appears in the address in this form. What matters is consistency rather than position: the same pattern should be applied across the whole site without breaking down.
Is the language code alone enough?
If you are opening up to a single market, it usually is. If the same language is to have different versions in different countries, language and country are written together. Where there are differences in price, delivery or regulation, a country distinction is needed; otherwise an unnecessary maintenance burden arises.
What happens to the old addresses?
If the source site’s addresses change when a new language version is opened, the old addresses have to be redirected to the new ones. Otherwise the links in search results lead nowhere. The source counts link errors among the typical error types specific to web localisation.
Is a locale gateway compulsory?
It is not compulsory, but on multi-market sites it makes things easier. A gateway is an intermediate page on which the visitor makes their country and language choice. Where automatic redirection can guess wrong, it offers the user a clear choice.
Sources
- Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 178, 184-186.
- Yunker, J. (2004). Beyond Borders: Web Globalization Strategies. New Riders, p. 128.
- W3C. Technical notes on internationalisation and language tags.