skip to content

How would you choose among a path segment, a hostname per locale, and a stored preference for a product shipping in eight languages?

level: principalimportance: should knowfreq 40%

answer

  1. is the locale part of the identity
  2. public and shareable means the URL
  3. hostnames for separate businesses
  4. preference only behind a login
  5. language and country are different dimensions

basics

~20 s

Decide by what the locale really is. A path segment is the default for public, linkable, cacheable pages; a hostname per locale only when locales are separate country businesses; a stored preference only behind a login, where nothing is shared or indexed.

solid answer

~50 s

Start from whether the locale is part of the resource identity. For public pages it is: a path segment gives each language its own address, so links, prerendering and shared caching all work without extra machinery, and it costs one prefix on every internal link. A hostname per locale buys hard separation — distinct origins, separate cookie scopes, the option to run each from different infrastructure — and pays for it in certificates, DNS, per-host configuration and a cross-origin language switch; it is honest when the locales are really different country businesses with their own content, pricing and owners, not translations of one site. A stored preference with one shared URL is defensible only where nothing is linked, shared, indexed or cached across users, which in practice means the signed-in surface. Most large products end up with a hybrid: a segment on the public site, a preference inside the application, and hostnames only where a market genuinely stands alone.

go deeper

for a junior

Know the three shapes exist — locale in the path, locale in the hostname, locale as a stored preference — and that only the first two give a translation its own address.

for a middle

Explain the concrete consequences of each: prerenderability, shared-cache safety, link sharing, cookie scope, and what each costs to operate.

for a senior

Argue from the product's actual surfaces — which pages are shared, indexed and cached — and show that the entry-point decision and the language switch both stay correct under the shape you pick.

for a principal

Own it as a reversible-at-a-price commitment: separate the language and market dimensions up front, state the boundary where a hybrid changes shape, and know what a later migration costs in permanent redirects.

This is a commitment about **what a URL means** in your product, and it is expensive to reverse. The three shapes are not interchangeable styles; each encodes a different claim about the relationship between locales. ## What each shape claims - **A path segment** claims: these are one site in several languages. Same host, same cookies, same infrastructure, same analytics property, one deployment. - **A hostname per locale** claims: these are related but separable sites. Different origins, different cookie scopes, potentially different hosting, different teams, sometimes different legal owners. - **A stored preference on one URL** claims: the locale is a property of the viewer, not of the page. There is no address for a translation at all. ## The axes that decide it | Axis | Segment | Hostname | Stored preference | |---|---|---|---| | Link and share fidelity | preserved | preserved | lost | | Prerenderable per locale | yes | yes | not as one artifact per path | | Shared-cache safety | free | free | needs explicit request-dependence | | Indexable per locale | yes | yes | effectively one locale | | Operational cost | one prefix everywhere | certificates, DNS, per-host config | none | | Cookie and session scope | shared | separated per host | shared | | Per-market divergence | awkward | natural | none | | Switch cost for the user | same-origin navigation | cross-origin navigation | in-place change | ## Where each genuinely wins **Segment.** The default for marketing pages, documentation, catalogues, anything public. It keeps one deployment and one cache story, and the only real tax is that every internal address must carry the prefix — which is a link-helper problem, not an architecture problem. **Hostname.** Reach for it when the locales have stopped being translations: separate pricing, separate legal text, separate catalogues, separate owners, or a regulatory reason to serve and store data in a particular region. Separate origins also mean the deployments can genuinely diverge, which is an advantage when markets ship on different schedules and a liability when they should not drift. **Stored preference.** Sound behind a login, where pages are not shared, not indexed, and not cached across users. It avoids duplicating every internal address for a surface where nobody links to anything. Its weakness is that the moment one of those pages becomes shareable, it starts showing the wrong language to the recipient. ## Traps worth naming 1. **Language and country are not the same dimension.** One language can span many markets with different prices and rules. If you conflate them, you will discover the split later, at the worst possible time — when a market needs its own content and there is nowhere to put it. 2. **Hostname chosen for imagined ranking benefit.** The reason to split hosts is organisational and operational separation, not a hope about search results. 3. **Mixing shapes inconsistently.** A segment on some sections and a preference on others produces sessions where half the screen changes language and half does not. 4. **Forgetting the entry point.** Whatever the shape, an arriving visitor with no locale in the address still needs a decision, and that decision must stay out of any shared cache. 5. **Underestimating the migration.** Changing shape later means redirecting every old address permanently and keeping those redirects effectively forever. ## The hybrid most products land on A segment on the public, indexable surface; a stored preference inside the signed-in application, where the segment would only duplicate addresses nobody shares; and hostnames reserved for markets that are actually separate businesses. If that is the destination, build the locale resolution as one function of the request and its address from the start, so which shape feeds it is a swappable input rather than a rewrite. ## How to argue it in an interview Name the decision criterion before naming a preference: *is the locale part of the resource identity here?* Public and shareable means yes, and a segment is the cheapest way to say yes. Then say what would change your mind — per-market divergence, regional data requirements, or separate teams pushing you to hostnames; a purely private surface pulling you to a stored preference. The answer that only names a favourite shape is the weak one.

  • What makes migrating from a stored preference to a locale segment expensive later?
    Every internal address changes shape, so every link, redirect, canonical reference, analytics path and stored deep link must be updated, and the old single-URL addresses need permanent redirects to a locale that has to be guessed per visitor. You also inherit years of external links pointing at addresses that no longer identify a language.
  • Why is treating language and country as one dimension a trap?
    They vary independently: one language serves several markets with different pricing, legal text and availability, and one market may need several languages. Collapsing them into a single segment value works until the first market needs its own content, at which point there is no dimension left to express it and the URL shape has to change.
  • Is a hybrid — segment on public pages, stored preference in the app — inconsistent?
    Not if the boundary is principled. Public pages are shared, indexed and cached, so the locale belongs in the address; the signed-in surface is none of those things, so a preference avoids duplicating addresses nobody links to. The requirement is that both sides resolve the locale through the same logic, so a session never shows two languages at once.

saying these in an interview costs you the question

  • Picks a shape before asking whether locales are shared or indexed
  • Chooses separate hostnames expecting a search-ranking advantage
  • Treats language and country as a single dimension
  • Uses a stored preference for public, linkable pages
  • Ignores the permanent redirects a later shape change would require
  • Mixes shapes across one product with no stated boundary