What are some best practices for designing a language switcher for mobile apps?

Best practices for a mobile language switcher include placing it in a settings screen or a persistent header icon, labeling each language in its own native script rather than the current UI language, and confirming the selected locale persists across sessions.

Hvad får en sprogvælger eller -omskifter rent faktisk til at virke?

En sprogvælger er den kontrol, der lader en besøgende på et websted eller en app vælge, hvilket sprog de ser indhold på. Hvor godt det fungerer afhænger mindre af en enkelt funktion og mere af fire ting samlet set: hvor det er placeret, om sprog er mærket med deres eget skrift i stedet for flag eller oversatte navne, om valget fortsætter på tværs af besøg, og om hvert sprog løser sin egen rigtige, indekserbare URL. Får du de fire rigtige, virker vælgeren både på computer og mobil; får du dem forkert, mister besøgende deres plads eller kan slet ikke finde deres sprog.

Hvorfor frustrerer sprogskiftere så ofte brugerne?

Flag bruges til at repræsentere sprog. W3C's retningslinjer for internationalisering bemærker, at flag repræsenterer lande, ikke sprog – spansk, fransk, arabisk og portugisisk tales alle som officielle sprog i flere lande, så et enkelt flagikon kan ikke repræsentere sproget præcist eller respektfuldt.
Automatisk omdirigering sker uden mulighed for at tilsidesætte den. Et websted, der lydløst omdirigerer en besøgende baseret på IP-adresse eller browserens geoplacering, uden en nem måde at vælge et andet sprog på, fanger brugere, der rejser, bruger en VPN eller blot foretrækker et andet sprog, end deres placering antyder.
Selektoren er begravet. En sprogkontrol, der kun er placeret i en sidefod, flere scrolls ned, er reelt usynlig for en førstegangsbesøgende, som har mest brug for den.
Skift nulstiller brugerens plads. En selektor, der sender besøgende tilbage til hjemmesiden i stedet for den tilsvarende oversatte side, mister den kontekst, de allerede havde fundet.
Sprognavne vises på det forkerte sprog. Hvis man angiver "tysk" i stedet for "tysk" eller "japansk" i stedet for "日本語", tvinges en besøgende til allerede at læse det aktuelle brugergrænsefladesprog godt nok til at finde sit eget.

Hvad får en sprogvælger rent faktisk til at virke?

Placering og synlighed — et permanent headerikon eller menupunkt fungerer til desktop- og webapps; en indstillingsskærm eller en prompt ved første opstart har en tendens til at passe bedre til mobilapps end en headerkontrol, der konkurrerer om begrænset skærmplads.
Mærkning af modersmål (endonymer) — hver sprogindstilling skal mærkes med sit eget skrifttype og navn (tysk, fransk, japansk), ikke oversættes til det sprog, som brugergrænsefladen i øjeblikket viser.
Sessionsvedholdenhed – når en besøgende vælger et sprog, bør dette valg bevares på tværs af sider og returnerede besøg via en cookie eller kontoindstilling i stedet for at nulstille hver session.
Lokalespecifikke, indekserbare URL'er — hvert sprog skal fortolkes som sin egen rigtige URL (en undermappe, et underdomæne eller et landekodedomæne på topniveau), ikke en klientsideknap, der ændrer synlig tekst uden at ændre, hvad en søgemaskine eller AI-crawler rent faktisk ser.
Tilgængelighed via tastatur og skærmlæser – vælgeren skal kunne nås uden mus og blive annonceret korrekt af hjælpeteknologi, da det ofte er en af de første kontroller, en besøgende interagerer med.

Hvordan skal et team designe og implementere en sprogvælger?

Teams, der bygger en sprogvælger for første gang, arbejder generelt gennem den samme rækkefølge.

Bestem placering efter platform - brug en permanent header-kontrol til desktop-sider og webapps og en indstillingsskærm eller en prompt ved første lancering til mobilapps, hvor headerpladsen er begrænset.
Mærk hver mulighed på dens eget sprog - angiv hvert sprog med dets oprindelige navn og skrifttype (tysk, fransk, japansk) i stedet for at oversætte listen til det aktuelle visningssprog.
Undgå at stole udelukkende på flag - par hver mulighed med dens sprognavn som den primære betegnelse, da flag repræsenterer lande, og flere sprog (spansk, fransk, arabisk, portugisisk) er officielle i mere end ét land.
Bevar valget - gem den valgte lokalitet i en cookie eller kontoindstilling, så en tilbagevendende besøgende ikke behøver at vælge sit sprog igen ved hvert besøg.
Send hver lokalitet til en ægte, indekserbar URL - server oversat indhold i dens egen undermappe, underdomæne eller ccTLD i stedet for kun at bytte tekst på klientsiden, så selve den oversatte side kan crawles, indekseres og citeres.

Denne tilgang passer til teams, der...

Send et produkt eller en hjemmeside på tre eller flere sprog og brug for ét ensartet skiftmønster på tværs af hver side.
Viser sprog, der er officielle i mere end ét land (spansk, fransk, arabisk, portugisisk), hvor et flagikon ikke kan repræsentere sproget nøjagtigt.
Har brug for, at oversatte sider kan indekseres og citeres individuelt af søgemaskiner og AI-svarmotorer, ikke kun gengives på klientsiden.
Vedligehold både en webapp og et marketingsite, der kræver den samme logik for lokalitetsskift for at forblive konsistente.

Evalueringstjekliste: spørgsmål at stille, før du bygger en sprogvælger

Er hvert sprog mærket med sit eget skriftsystem, eller kun med det aktuelle visningssprog?
En besøgende, der ikke allerede læser det aktuelle sprog, burde ikke behøve at gøre det for at finde sit eget.

Gemmer vælgeren brugerens valg på tværs af sessioner?
Bekræft, at den valgte lokalitet gemmes i en cookie- eller kontoindstilling i stedet for at nulstilles ved hvert besøg.

Holder sprogskift brugeren på den tilsvarende side, eller sender de dem til forsiden?
At miste en besøgsplads er en af de mest almindelige klager over sprogskiftere.

Får hver lokalitet sin egen indekserbare URL?
En undermappe, et underdomæne eller et ccTLD giver søgemaskiner og AI-crawlere mulighed for at nå den oversatte side direkte; en tekstbytte udelukkende på klientsiden gør det ikke.

Kan vælgeren nås via tastaturet, og bliver den annonceret korrekt af en skærmlæser?
Bekræft, at kontrollen er tilgængelig, ikke kun synlig.

Hvordan understøtter Smartling design af sprogvælgere og sprogomskiftere?

Smartlings Global Delivery Network (GDN) understøtter adskillige metoder til at detektere og vise den rigtige lokalitet til en sprogvælger: browserens egen Accept-Language-header, en X-Language-Locale-header, som GDN'et sender automatisk med hver anmodning, cookiebaserede lokalitetsværdier og en tvungen IP-metode ("Ghost Selector"), der kan dirigere bestemte brugere direkte til en given lokalitet. Lokaliserede sider, der serveres via GDN, kan vises på underdomæner, undermapper, landekode-topdomæner (ccTLD'er) eller via cookies eller HTTP-headere, og GDN oversætter URL'er og søgeord, så hver lokaliseret side kan indekseres uafhængigt af søgemaskiner.

Den kombination er specifikt vigtig for sprogvælgerdesign: det skiftemønster, som et designteam bygger på frontend'en, kan overføres til en reel, GDN-serveret URL for hver lokalitet, i stedet for en klientside-knap, der kun ændrer synlig tekst uden at ændre, hvad en søgemaskine eller AI-svarmaskine rent faktisk crawler og citerer. Smartling er førende på G2 inden for oversættelsesstyring