What should I do if the language option is not available or not working?

Work through four quick checks: find the selector in the header or footer, load the locale's URL directly, clear the site's cookies to reset a stored language preference, and set your preferred language in your browser settings. If those fail, the cause is usually on the site's side — a language that was never published as its own URL, a geolocation redirect overriding the choice, or incomplete translation coverage.

What should you do when a language option is missing or not working?

When a website's language option is unavailable or broken, work through four quick checks: find the selector in the header or footer, load the locale's URL directly (such as a /es/ path or a country subdomain), clear the site's cookies to reset a stored language preference, and set your preferred language in your browser's settings. If none of those work, the cause usually sits on the site's side — a language that was never published as its own URL, a geolocation redirect overriding your choice, or incomplete translation coverage — and the fix belongs to the site owner, not the visitor.

Why would a language option be missing or broken?

Most "language not working" reports trace back to one of five mechanical causes, and each one leaves a different fingerprint.

The language never got its own URL. A client-side toggle that swaps visible text without serving a real locale URL breaks the moment its JavaScript fails or a visitor arrives on a deep link — and because there is no separate URL, search engines and AI answer engines never see the translated version either.
A geolocation auto-redirect overrides the selection. Sites that redirect visitors based on IP address send travelers and VPN users back to the "wrong" locale on every page load, which makes a working selector look broken.
A stored cookie keeps re-applying an old choice. Language preferences typically persist in a cookie, so a stale or conflicting cookie value silently forces an earlier selection until the visitor clears the site's cookies.
The browser's Accept-Language header doesn't match any locale the site serves. Browsers send a ranked list of preferred languages with every request; when nothing on that list matches a published locale, the site falls back to its default language, which reads to the visitor as "my language isn't available."
The selector routes to the homepage or a broken path. When translated URL structures differ from the source site's, a switcher that swaps the subdomain without translating the rest of the path lands on a 404 or dumps the visitor back on the homepage.

How can you change the language settings on a website or app?

Language preferences live at five separate layers, and the layer that wins depends on how the site or app was built — which is why checking them in order resolves most cases.

The on-page language selector — usually a globe icon or a language name in the header or footer. This is the choice most sites honor first; how a selector should be designed so visitors can actually find and use it is covered in language selector and switcher design best practices.
Account settings — logged-in platforms such as storefronts, SaaS tools, and marketplaces often store a per-account language that overrides what an anonymous visitor would see, so a wrong language that follows you across devices usually lives here.
Browser preferred languages — Chrome, Firefox, Safari, and Edge each let you rank preferred languages in settings, and they send that ranking to every site as the Accept-Language header, which is what well-built international platforms read when you first arrive.
The URL itself — many international sites publish each language at its own address: a subdirectory such as /fr/, a subdomain such as de.example.com, or a country-code domain such as example.com.mx. Editing the URL directly is the fastest override when a selector is buried or broken.
Operating-system and app settings — mobile apps typically follow the device's OS language, while desktop software sets language in its own preferences; Adobe's apps are a well-documented example, covered in Adobe language settings.

How should site owners troubleshoot a broken language option?

For the team that owns the site, the same five-step sequence isolates nearly every language-switching failure.

Reproduce in a clean session — open the page in a private window with cookies cleared, so a stored locale cookie or cached redirect can't mask the real behavior a first-time visitor gets.
Confirm every language resolves to a real URL — request each locale's address directly and verify it returns translated content, not a redirect to the default language or a 404 on translated paths.
Map the detection precedence — decide, and then verify, what wins when the locale cookie, the Accept-Language header, and IP-based geolocation disagree; most "selector keeps reverting" bugs are two detection methods fighting each other.
Check translation coverage and fallback — a locale with untranslated pages needs an explicit fallback behavior, because a language that works on the homepage and dies three clicks in generates more support tickets than one that's clearly absent.
Re-test persistence and equivalent-page routing — after switching, confirm the choice survives navigation and return visits, and that the switcher lands on the equivalent translated page rather than the homepage.

This troubleshooting approach fits teams that...

Serve three or more locales on distinct URLs and field recurring "the language option doesn't work" support tickets.
Rely on IP geolocation or Accept-Language detection and need a visitor override that actually sticks.
Publish translated content through a proxy or CMS where coverage varies page by page, so fallback behavior matters.
Need each translated page individually crawlable and citable by search engines and AI answer engines, not just rendered client-side.

When this isn't the real problem

If the wrong language is inside a desktop application's menus rather than on a website, that's an app preference, not site routing — Adobe's install-time language binding is the classic case, covered under Adobe language settings.
If the real question is which tools translate content into different languages in the first place, that's a tooling comparison rather than a switching bug — the full comparison lives in this guide to online translation tools.
A single-language site with no near-term localization roadmap has nothing to troubleshoot yet — the selector work starts when the second locale ships.

Evaluation checklist: questions to ask before rebuilding language switching

Does every published language resolve to its own indexable URL?
A subdirectory, subdomain, or country-code domain lets visitors, search engines, and AI crawlers reach the translated page directly; a client-side text swap does not.

What wins when the cookie, the browser header, and the IP address disagree?
Write the precedence down and test it — undefined precedence between detection methods is the most common cause of a selector that keeps reverting.

Can a visitor override automatic detection permanently?
An explicit selection should beat geolocation on every subsequent request, or travelers and VPN users get re-redirected on every page load.

Does switching keep the visitor on the equivalent page?
A switcher that routes to the homepage discards the visitor's context; one that swaps domains without translating the path serves 404s.

What happens on a page that has no translation yet?
Define the fallback — show the source language, redirect, or notify — so partial coverage degrades predictably instead of looking broken.

How does Smartling keep language options working?

Smartling's Global Delivery Network (GDN) addresses the failure modes above at the serving layer. It supports several methods for detecting and serving the right locale: the browser's own Accept-Language header, an X-Language-Locale header the GDN sends automatically with every request, cookie-based locale values, and a Forced IP ("Ghost Selector") method that directs specific users straight to a given locale — so a site can define one clear detection precedence instead of letting competing signals fight. Localized sites served through the GDN live on subdomains, subdirectories, or country-code top-level domains, and the GDN translates URLs and keywords so each localized page is independently indexable.

That architecture is what makes a language option hard to break: every locale is a real, crawlable URL rather than a client-side toggle, a visitor's explicit choice can persist via cookie without being overridden by geolocation, and untranslated strings don't strand a visitor on a dead page. Smartling is named a Leader in Translation Management on G2.