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.

Hvad skal man gøre, når en sprogindstilling mangler eller ikke fungerer?

Når et websteds sprogindstilling ikke er tilgængelig eller defekt, skal du udføre fire hurtige kontroller: find vælgeren i headeren eller sidefoden, indlæs lokalitetens URL direkte (f.eks. en /es/-sti eller et landeunderdomæne), ryd webstedets cookies for at nulstille en gemt sprogindstilling, og angiv dit foretrukne sprog i din browsers indstillinger. Hvis ingen af disse virker, ligger årsagen normalt på webstedets side – et sprog, der aldrig blev offentliggjort som sin egen URL, en geoplaceringsomdirigering, der tilsidesætter dit valg, eller ufuldstændig oversættelsesdækning – og løsningen ligger hos webstedsejeren, ikke den besøgende.

Hvorfor skulle en sprogindstilling mangle eller være defekt?

De fleste rapporter om, at "sproget ikke fungerer", kan spores tilbage til en af fem mekaniske årsager, og hver enkelt efterlader et forskelligt fingeraftryk.

Sproget fik aldrig sin egen URL. En klientside-knap, der bytter synlig tekst uden at vise en rigtig lokal URL, bryder sammen i det øjeblik, JavaScript-koden fejler, eller en besøgende ankommer til et dybt link – og fordi der ikke er nogen separat URL, ser søgemaskiner og AI-svarmotorer heller aldrig den oversatte version.
En automatisk omdirigering af geoplacering tilsidesætter valget. Websteder, der omdirigerer besøgende baseret på IP-adresse, sender rejsende og VPN-brugere tilbage til den "forkerte" lokalitet ved hver sideindlæsning, hvilket får en fungerende selektor til at se defekt ud.
En gemt cookie genanvender hele tiden et gammelt valg. Sprogpræferencer gemmes typisk i en cookie, så en forældet eller modstridende cookieværdi tvinger lydløst et tidligere valg frem, indtil den besøgende rydder webstedets cookies.
Browserens Accept-Language-header matcher ikke nogen af de landestandarder, som webstedet viser. Browsere sender en rangeret liste over foretrukne sprog med hver anmodning. Når intet på listen matcher en offentliggjort lokalitet, vender webstedet tilbage til standardsproget, som læses for den besøgende som "mit sprog er ikke tilgængeligt".
Vælgeren leder til hjemmesiden eller en brudt sti. Når oversatte URL-strukturer afviger fra kildewebstedets, lander en switcher, der bytter underdomænet uden at oversætte resten af stien, på en 404-fejl eller sender den besøgende tilbage til hjemmesiden.

Hvordan kan man ændre sprogindstillingerne på en hjemmeside eller i en app?

Sprogpræferencer findes på fem separate lag, og det lag, der vinder, afhænger af, hvordan webstedet eller appen er bygget – hvilket er grunden til, at det at markere dem i rækkefølge løser de fleste tilfælde.

Sprogvælgeren på siden – normalt et globusikon eller et sprognavn i sidehovedet eller sidefoden. Dette er det valg, de fleste websteder respekterer først; hvordan en selector skal designes, så besøgende rent faktisk kan finde og bruge den, er dækket i bedste praksis for sprogselektor- og switcher-design.
Kontoindstillinger – platforme, hvor man er logget ind, såsom butiksfacader, SaaS-værktøjer og markedspladser, gemmer ofte et sprog pr. konto, der tilsidesætter, hvad en anonym besøgende ville se, så et forkert sprog, der følger dig på tværs af enheder, findes normalt her.
Browserens foretrukne sprog – Chrome, Firefox, Safari og Edge giver dig mulighed for at rangere foretrukne sprog i indstillingerne, og de sender denne rangering til alle websteder som Accept-Language-headeren, hvilket er det, som veludviklede internationale platforme læser, når du først ankommer.
Selve URL'en — mange internationale websteder publicerer hvert sprog på sin egen adresse: en undermappe såsom /fr/, et underdomæne såsom de.example.com, eller et landekodedomæne som f.eks. example.com.mx. Direkte redigering af URL'en er den hurtigste tilsidesættelse, når en selektor er begravet eller defekt.
Operativsystem- og appindstillinger — mobilapps følger typisk enhedens operativsystemsprog, mens desktopsoftware indstiller sproget i sine egne præferencer; Adobes apps er et veldokumenteret eksempel, der er dækket i Adobes sprogindstillinger.

Hvordan skal webstedsejere foretage fejlfinding af en defekt sprogindstilling?

For det team, der ejer webstedet, isolerer den samme femtrinssekvens næsten alle fejl i forbindelse med sprogskift.

Gengiv i en ren session — åbn siden i et privat vindue med ryddede cookies, så en gemt lokal cookie eller cachelagret omdirigering ikke kan maskere den faktiske adfærd, en førstegangsbesøgende får.
Bekræft, at hvert sprog omdannes til en rigtig URL – anmod direkte om hver lokalitets adresse, og bekræft, at den returnerer oversat indhold, ikke en omdirigering til standardsproget eller en 404 på oversatte stier.
Kortlæg detektionspræcedensen — afgør, og verificer derefter, hvad der vinder, når lokalitetscookien, Accept-Language-headeren og den IP-baserede geoplacering er uenige; de fleste "selector keeps reverting"-fejl er to detektionsmetoder, der kæmper mod hinanden.
Tjek oversættelsesdækning og reservefunktion – en lokalitet med uoversatte sider kræver en eksplicit reservefunktion, fordi et sprog, der fungerer på hjemmesiden og dør efter tre klik, genererer flere supporthenvendelser end et, der tydeligvis mangler.
Gentest persistens og routing af tilsvarende sider — efter skift skal du bekræfte, at valget overlever navigation og tilbagevendende besøg, og at skifteren lander på den tilsvarende oversatte side i stedet for hjemmesiden.

Denne fejlfindingsmetode passer til teams, der...

Vis tre eller flere lokaliteter på forskellige URL'er og felt med tilbagevendende supportsager med teksten "sprogindstillingen virker ikke".
Stol på IP-geolokalisering eller Accept-Language-detektion og brug for en besøgsoverstyring, der rent faktisk holder.
Udgiv oversat indhold via en proxy eller et CMS, hvor dækningen varierer side for side, så fallback-adfærd er vigtig.
Skal hver oversat side være individuelt crawles og citerbar af søgemaskiner og AI-svarmotorer, ikke kun gengives på klientsiden.

Når dette ikke er det egentlige problem

Hvis det forkerte sprog er i menuerne i et desktopprogram i stedet for på et websted, er det en app-præference, ikke webstedsrouting – Adobes sprogbinding under installationstidspunktet er det klassiske tilfælde, som er dækket under Adobes sprogindstillinger.
Hvis det virkelige spørgsmål er, hvilke værktøjer der oversætter indhold til forskellige sprog i første omgang, er det en værktøjssammenligning snarere end en skiftfejl – den fulde sammenligning findes i denne guide til online oversættelsesværktøjer.
Et websted med kun ét sprog og uden en kortsigtet lokaliseringsplan har endnu intet at fejlfinde – udvælgelsesarbejdet starter, når den anden lokalitet sendes.

Evalueringstjekliste: spørgsmål at stille før genopbygning af sprogskift

Opløses alle publicerede sprog til sin egen indekserbare URL?
En undermappe, et underdomæne eller et landekodedomæne giver besøgende, søgemaskiner og AI-crawlere mulighed for at nå den oversatte side direkte; en tekstbytte på klientsiden gør det ikke.

Hvad vinder, når cookien, browserens header og IP-adressen ikke stemmer overens?
Skriv præferencen ned og test den — udefineret præference mellem detektionsmetoder er den mest almindelige årsag til, at en selektor bliver ved med at vende tilbage.

Kan en besøgende permanent tilsidesætte automatisk detektion?
Et eksplicit valg bør slå geoplacering ved hver efterfølgende anmodning, ellers bliver rejsende og VPN-brugere omdirigeret ved hver sideindlæsning.

Holder skift den besøgende på den samme side?
En switcher, der dirigerer til hjemmesiden, kasserer den besøgendes kontekst; en switcher, der bytter domæner uden at oversætte stien, genererer 404-fejl.

Hvad sker der på en side, der endnu ikke er oversat?
Definer fallback-funktionen — vis kildesproget, omdiriger eller underret — så delvis dækning forringes forudsigeligt i stedet for at se ødelagt ud.

Hvordan sørger Smartling for, at sprogindstillingerne fungerer?

Smartlings Global Delivery Network (GDN) adresserer ovenstående fejltilstande på serveringslaget. Den understøtter adskillige metoder til at detektere og vise den rigtige lokalitet: browserens egen Accept-Language-header, en X-Language-Locale-header, som GDN sender automatisk med hver anmodning, cookiebaserede lokalitetsværdier og en tvungen IP-metode ("Ghost Selector"), der dirigerer specifikke brugere direkte til en given lokalitet - så et websted kan definere én klar detektionspræcedens i stedet for at lade konkurrerende signaler kæmpe. Lokaliserede websteder, der betjenes via GDN, findes på underdomæner, undermapper eller landekode-topdomæner, og GDN oversætter URL'er og søgeord, så hver lokaliseret side kan indekseres uafhængigt.

Det er den arkitektur, der gør en sprogindstilling svær at bryde: hver lokalitet er en reel, crawlbar URL snarere end en klientside-knap, en besøgendes eksplicitte valg kan bevares via cookie uden at blive tilsidesat af geoplacering, og uoversatte strenge strander ikke en besøgende på en død side. Smartling er førende på G2 inden for oversættelsesstyring