Guides

Sådan tilføjer du flere sprog til din app eller hjemmeside

For at tilføje flere sprog til en app skal al grænsefladetekst flyttes over i oversættelsesfiler (én pr. sprog), indlæses med et i18n-bibliotek, og du tilføjer en sprogvælger, der husker valget. Til offentlige sider, du vil findes via søgning, giver du hvert sprog sin egen URL, f.eks. /fr/, og forbinder versionerne med hreflang-tags. Derefter skal du håndtere de ting, folk typisk glemmer: datoer, tal og valutaer, længere tekst på nogle sprog, højre-mod-venstre-skrift og indhold gemt i din database.

Ord du vil støde på

  • Internationalisering (i18n): at gøre koden klar til ethvert sprog, uden hårdkodede strenge, sprogtilpasset formatering og fleksible layouts. Tallet "18" er antallet af bogstaver mellem i og n.
  • Lokalisering (l10n): at tilpasse appen til et bestemt sprog eller marked, mest oversættelse, nogle gange også valuta, billeder og juridisk tekst.
  • Locale: et sprog og eventuelt et område, f.eks. da-DK eller pt-BR.

Gør i18n én gang, så bliver det at tilføje hvert nyt sprog stort set kun oversættelsesarbejde.

Muligheder og afvejninger

TilgangSådan virker denGodt tilAfvejning
i18n-bibliotek + oversættelsesfiler (f.eks. react-i18next, next-intl, vue-i18n)Tekst ligger i JSON-filer pr. locale; komponenter slår nøgler opDe fleste appsIndledende refaktorering; oversættelser der skal vedligeholdes
Oversættelsesstyringssystem (f.eks. Crowdin, Lokalise, Phrase)Hostet editor til oversættere, synkroniseret med dine filerMange sprog, flere oversættereBetalt; endnu et værktøj at sætte op
Maskin- eller AI-oversættelse under buildGenerér udkast med en API, og gennemgå dem derefterHurtigt at nå mange sprogKvaliteten skal kontrolleres; API-omkostninger
Browser- eller widget-autooversættelseBesøgendes browser oversætter siden i fartenIntet du kan styreIngen kvalitetskontrol; oversatte sider indekseres ikke som dine
Separate sites pr. sprogEt duplikeret site pr. markedMeget forskellige markederAlt vedligeholdes to gange

Til de fleste apps er et almindeligt i18n-bibliotek med oversættelsesfiler det rigtige udgangspunkt. Lav gerne udkast med maskin- eller AI-oversættelse, og lad derefter flydende talere gennemgå det, kunderne ser mest.

Delene i en flersproget app

Oversættelsesfiler

I stedet for <h1>Velkommen tilbage</h1> står der i koden t('dashboard.welcome'), og hvert locale har en fil med teksten:

{
  "dashboard": {
    "welcome": "Velkommen tilbage, {{name}}",
    "items_one": "{{count}} element",
    "items_other": "{{count}} elementer"
  }
}

Brug pladsholdere til variable i stedet for at sætte sætningsfragmenter sammen, for ordstillingen er forskellig fra sprog til sprog. Og brug bibliotekets regler for flertal: dansk har to former (1 element, 2 elementer), men nogle sprog har tre, fire eller flere.

Formatering af datoer, tal og penge

Formatér ikke disse ting i hånden. Browserens indbyggede Intl-API formaterer for ethvert locale: 1.234,5 på dansk er 1,234.5 på engelsk; datoer skifter mellem dag-først og måned-først; valutasymboler flytter sig. Gem datoer i UTC og beløb som tal med en valutakode, og formatér først ved visning.

Layout der strækker sig

Oversat tekst er ofte længere end engelsk, især tysk og finsk. Undgå knapper med fast bredde og afkortede labels, og test med dit længste sprog.

Højre-mod-venstre-sprog

Arabisk, hebraisk, persisk og urdu læses fra højre mod venstre. Sæt dir="rtl" på siden for disse locales, og brug CSS-logiske egenskaber (margin-inline-start i stedet for margin-left; i Tailwind ms-4 i stedet for ml-4), så layoutet spejler sig selv. Ikoner der angiver retning, som pile, skal også vendes.

Sprogvælger og registrering

Vis en sprogvælger på hver side, mærket med hvert sprogs eget navn ("Deutsch", "Français", "العربية") i stedet for flag, for flag repræsenterer lande, ikke sprog. Registrér browserens foretrukne sprog ved første besøg for at foreslå en version, men lad besøgendes eksplicitte valg vinde og husk det.

URL'er og SEO

Til sider du vil have med i søgeresultaterne, skal hvert sprog have sin egen URL. Fra september 2026 lyder Googles vejledning for flersprogede sites således:

  • Separate URL'er pr. sprog — underkataloger (example.com/fr/) er det enkleste; subdomæner og landedomæner virker også. URL-parametre (?lang=fr) anbefales ikke.
  • Skift ikke sprog kun via cookie eller browserindstilling; Googles crawler ser måske aldrig de andre versioner.
  • Omdirigér ikke automatisk efter sprog; link i stedet mellem versionerne.
  • Brug hreflang for at fortælle Google, hvilke sider der er oversættelser af hinanden. Hver version skal angive sig selv og alle de andre, ellers kan annoteringerne blive ignoreret. Tilføj x-default for fallback-siden.
  • Google finder en sides sprog ud fra det synlige indhold, ikke ud fra lang eller hreflang — så oversæt hele siden, ikke kun menuen.

Sæt stadig <html lang="fr"> på hver version: skærmlæsere bruger det til at vælge den rigtige udtale, og det er et krav om tilgængelighed.

Login-skærme i appen behøver ikke at blive indekseret, så for dem er det fint at gemme sproget i brugerens profil. Se SEO til AI-byggede hjemmesider for, hvordan offentlige sider bliver crawlet.

Indhold i din database

Grænsefladetekst ligger i filer; indhold som produktnavne, blogindlæg og kategorier ligger i databasen. To almindelige mønstre:

  • En oversættelsestabel: product_translations (product_id, locale, name, description). Ren og skalerbar til mange sprog.
  • En JSON-kolonne pr. felt: name: {"en": "...", "fr": "..."}. Enklere til få sprog.

Beslut hvad der sker, når en oversættelse mangler — typisk falder du tilbage til standardsproget i stedet for at vise tomt rum.

E-mails og notifikationer

Gem hver brugers sprog, og brug det også til e-mails, notifikationer og PDF'er. Det er let at oversætte appen og glemme, at velkomstmailen stadig kommer på engelsk.

Prompts der virker

Tilføj internationalisering med react-i18next. Flyt al tekst brugeren ser over i locales/en.json med navngivne nøgler, brug interpolation og flertalsregler i stedet for strengsammensætning, og formatér datoer, tal og priser med Intl ud fra det aktuelle locale. Ændr ikke ordlyden endnu.

Tilføj fransk og tysk. Offentlige markedsføringssider får præfikset /fr/ og /de/ med engelsk ved roden, hreflang-links på hver side (inklusive selvreference og x-default), og html lang sat pr. side. Tilføj en sprogvælger, der viser hvert sprogs eget navn. Til sider for indloggede brugere gemmes sproget på brugerens profil.

Tilføj arabisk med højre-mod-venstre-understøttelse: sæt dir="rtl" for arabisk, erstat venstre/højre margin og padding med logiske egenskaber, spejl retningsikoner, og kontroller at formularer og tabeller stadig læses rigtigt.

Trin for trin

  1. Vælg dit første ekstra sprog ud fra reel efterspørgsel — hvor dine besøgende eller kunder er.
  2. Gør koden internationaliseret: flyt strenge over i filer, tilføj flertalsregler og Intl-formatering. Udrul det med kun engelsk, og kontrollér at intet har ændret sig.
  3. Beslut URL-strukturen for offentlige sider, og tilføj hreflang.
  4. Oversæt: lav udkast med maskin- eller AI-oversættelse, og gennemgå derefter med en flydende taler. Giv oversætterne kontekst — et ord som "Book" er et navneord på én skærm og et udsagnsord på en anden.
  5. Oversæt databaseindhold og sæt fallbacks.
  6. Lokalisér resten: e-mails, fejlmeddelelser, juridiske sider, billeder med tekst i.
  7. Test hvert sprog i telefonbredde, og med højre-mod-venstre hvis relevant.
  8. Opsæt en proces, så nye funktioner udgives med oversættelser, ikke måneder senere.

Almindelige fejl

  • At sætte sætninger sammen ("Du har " + n + " beskeder"), hvilket går i stykker på andre sprog.
  • Hårdkodet tekst tilbage i komponenter, fejlmeddelelser og valideringsstrenge.
  • Datoer og priser formateret i hånden.
  • Flag som sprogsymboler, og automatiske omdirigeringer, der fanger folk i den forkerte version.
  • Én URL til alle sprog på sider du vil have indekseret.
  • Manglende hreflang-returlinks, så Google ignorerer annoteringerne.
  • Oversat grænsefladen men ikke indholdet, eller omvendt.
  • Ugennemgået maskinoversættelse på priser, juridiske sider og betalingssider.

Tjekliste for flersprog

  • Ingen hårdkodede tekster brugeren ser; flertalsregler og pladsholdere er brugt
  • Datoer, tal og valutaer formateret med Intl
  • Sprogvælger med egne navne på hver side; valget huskes
  • Separate URL'er pr. sprog for offentlige sider; ingen tvungne omdirigeringer
  • hreflang på hver version, inklusive selv og x-default
  • html lang (og dir="rtl" hvor nødvendigt) sat pr. side
  • Databaseindhold oversat med fornuftige fallbacks
  • E-mails og notifikationer sendes på brugerens sprog
  • Tekst til kunder gennemgået af en flydende taler

Flere sprog på Mythex

På Mythex tilføjer du sprog ved at bede om det i chatten — der er ingen separat oversættelsespanel — så prompts ovenfor virker som de er skrevet. Lav internationaliseringstrinnet først, og kontrollér det i Preview, før du tilføjer sprog; det er en stor refaktorering, og et chat-checkpoint giver dig et sted at vende tilbage til, hvis noget går i stykker (chat og checkpoints). Hvis du vil have appen til at oversætte indhold automatisk med en AI- eller oversættelses-API, bruger det din egen API-nøgle, gemt i projektindstillingerne (miljøvariabler og hemmeligheder); sådan bruger du LLM-API'er forklarer omkostningerne. Udgiv igen, når de nye sprog er klar.

Spørgsmål

Hvad er forskellen på i18n og lokalisering?

Internationalisering (i18n) er at gøre koden klar til at understøtte mange sprog: ingen hårdkodet tekst, datoer og tal der følger sprogindstillingen, og layouts der kan håndtere længere ord og højre-mod-venstre-skrift. Lokalisering (l10n) er arbejdet med at tilpasse appen til ét sprog eller marked, primært oversættelse.

Kan jeg bare bruge maskinoversættelse eller AI til at oversætte min app?

Til et første udkast, ja. Moderne maskin- og AI-oversættelse er god til grænsefladetekst. Lad en flydende taler gennemgå alt, der vender mod kunderne, især juridisk tekst, priser og markedsføringstekst, for tone og små fejl betyder noget der.

Skal hvert sprog have sin egen URL?

For offentlige sider, du vil have med i søgeresultaterne, ja. Google anbefaler separate URL'er pr. sprog, f.eks. /fr/ og /de/, frem for at skifte sprog via cookie eller browserindstilling, for crawleren ser ellers måske kun én version.

Skal jeg omdirigere besøgende ud fra deres browsersprog?

Foreslå, tving ikke. Google fraråder automatiske sprogomdirigeringer, fordi de kan forhindre mennesker og crawlere i at nå de andre versioner. Vis en lille besked med det matchende sprog og en synlig sprogvælger på hver side.

Mythex · Pricing · Byg hvad som helst med AI · Skabeloner til websites og apps · Mythex sammenlignet · Ordliste for app-bygning med AI · Gratis værktøjer til app-bygning med AI · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)