URL structure for internationalized websites

[xfq]

It might be useful to write an article about how to design a URL structure for an internationalized website. We can explain the pros and cons of each approach and let the content authors judge for themselves. There's some relevant stuff in Monolingual vs. multilingual Web sites, but it didn't mention URLs.

Some of the common URL structures for internationalized websites include:

Different domains

In rare cases, companies use entirely different domains, like douyin.com in China and tiktok.com for the rest of the world. This is more of a branding/legal strategy than a typical i18n approach.

ccTLDs (including IDN ccTLDs)

This approach involves using a separate, country-specific domain for each target market.

Examples:

• google.co.jp
• apple.com.cn
• amazon.co.jp
• philips.com.hk

Using this approach requires spending money to buy register new domain names, but you can use different servers for different regions.

Subdomains

This approach uses a different third-level domain for each language or region.

Examples:

• zh.wikipedia.org
• hk.yahoo.com
• uk.norton.com

It's technically straightforward to create new subdomains.

Folders

Create a folder within the main site for each language or locale.

Examples:

• https://www.samsung.com/hk/
• https://www.apple.com/jp/
• https://support.zoom.us/hc/en-us
• https://www.adobe.com/hk_en/

Query string

This method appends the language/locale to the URL using a ? parameter.

Examples:

• https://www.office.com/?omkt=zh-CN
• https://developers.google.com/?hl=zh-cn
• https://www.linkedin.com/help/linkedin?lang=ro-RO

Change the file name

Example:

https://www.w3.org/International/questions/qa-site-conneg.sv.html

No change to the URL

Examples:

• Facebook (main site, the support pages use query strings)
• LinkedIn (main site, the support pages use query strings)
• https://web.dev/

[aphillips]

This might be a useful article, although please note that the various URL elements you cite are doing different things. In some cases they convey locale variation. In other cases they refer to region-specific sites or region-specific content. Language negotiation and preference management might be a good subset: I seem to have written that down multiple times of late...

[himorin]

For change the file name one, this was a commonly used multiple file extensions' option, which was a part of mod_mime.c. And there was no defined order among multiple file extensions, so both .<lang>.<ext> and .<ext>.<lang> were handled as the same. (in some special case, when a file extension is tighten to specific data handler, order has some mean, although...)
e.g. switched case at https://www.debian.org/releases/stretch/arm64/apbs04.html.ja

[r12a]

Note that .<lang>.<ext> and .<ext>.<lang> are not interchangeable if you're not reading the resource via a server. That's why our articles always use .<lang>.<ext>. In fact, there are advantages to the latter when serving over a server, too, in that it's (marginally) easier to type ...es than ...html.es.