Guider

Slik legger du til flere språk i appen eller nettsiden

For å legge til flere språk i en app må du flytte all tekst i grensesnittet over i oversettelsesfiler (én fil per språk), laste dem inn med et i18n-bibliotek og legge til en språkvelger som husker valget. For offentlige sider du vil finne i søk, gir du hvert språk en egen nettadresse, for eksempel /fr/, og kobler versjonene sammen med hreflang-tagger. Deretter må du håndtere det folk ofte glemmer: datoer, tall og valuta, lengre tekst i enkelte språk, høyre-mot-venstre-skrift og innhold som ligger i databasen.

Begreper du vil møte

  • Internasjonalisering (i18n): å forberede koden slik at den kan støtte alle språk: ingen hardkodet tekst, språkavhengig formatering og fleksible oppsett. Tallet «18» er antall bokstaver mellom i og n.
  • Lokalisering (l10n): å tilpasse appen til et bestemt språk eller marked. Det er først og fremst oversettelse, men noen ganger også valuta, bilder og juridisk tekst.
  • Locale: et språk og eventuelt en region, for eksempel en-GB eller pt-BR.

Gjør i18n én gang, så blir det å legge til et nytt språk stort sett oversettelsesarbeid.

Alternativer og avveininger

TilnærmingSlik fungerer denPasser tilAvveining
i18n-bibliotek + oversettelsesfiler (f.eks. react-i18next, next-intl, vue-i18n)Teksten ligger i JSON-filer per språk, og komponentene slår opp nøklerDe fleste apperInnledende refaktorering; oversettelser som må vedlikeholdes
System for oversettelsesadministrasjon (f.eks. Crowdin, Lokalise, Phrase)Vertsbasert editor for oversettere, synkronisert med filene dineMange språk og flere oversettereBetalt; et verktøy til å sette opp
Maskin- eller KI-oversettelse under byggingGenerer utkast med et API og gå gjennom demÅ komme raskt til mange språkKvaliteten må kontrolleres; API-kostnader
Auto-oversettelse i nettleser eller widgetBesøkendes nettleser oversetter siden fortløpendeIngenting du kan kontrollereIngen kvalitetskontroll; oversatte sider blir ikke indeksert som dine
Egne nettsteder per språkDupliser nettstedet for hvert markedSvært ulike markederAlt må vedlikeholdes to ganger

For de fleste apper er et standard i18n-bibliotek med oversettelsesfiler det riktige utgangspunktet. Lag utkast med maskin- eller KI-oversettelse hvis du vil, og la en flytende språkbruker gå gjennom det kundene ser mest.

Delene i en flerspråklig app

Oversettelsesfiler

I stedet for <h1>Velkommen tilbake</h1> skriver koden t('dashboard.welcome'), og hver språkfil har teksten:

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

Bruk plassholdere for variabler i stedet for å sette sammen setningsfragmenter, fordi ordstillingen er ulik mellom språk. Bruk også bibliotekets regler for flertall: engelsk har to former (1 item, 2 items), men noen språk har tre, fire eller flere.

Formatering av datoer, tall og penger

Ikke formater disse manuelt. Nettleserens innebygde Intl-API formaterer for alle lokaler: 1,234.5 på engelsk er 1.234,5 på tysk og 1 234,5 på norsk; datoer skifter mellom dag først og måned først; valutategn flyttes. Lagre datoer i UTC og beløp som tall med en valutakode, og formater bare når det skal vises.

Oppsett som tåler lengre tekst

Oversatt tekst er ofte lengre enn engelsk, særlig tysk og finsk. Unngå knapper med fast bredde og avkortede etiketter, og test med det lengste språket ditt.

Høyre-mot-venstre-språk

Arabisk, hebraisk, persisk og urdu leses fra høyre mot venstre. Sett dir="rtl" på siden for disse lokalene, og bruk CSS-logiske egenskaper (margin-inline-start i stedet for margin-left; i Tailwind ms-4 i stedet for ml-4) slik at oppsettet speiler seg selv. Ikoner som viser retning, som piler, må også snus.

Språkvelger og språkgjenkjenning

Vis en språkvelger på alle sider, merket med hvert språks eget navn («Deutsch», «Français», «العربية») i stedet for flagg. Flagg representerer land, ikke språk. Oppdag nettleserens foretrukne språk ved første besøk for å foreslå en versjon, men la den besøkendes eksplisitte valg vinne og husk det.

Nettadresser og SEO

For sider du vil ha med i søkeresultatene, må hvert språk ha en egen nettadresse. Fra september 2026 er Googles veiledning for flerspråklige nettsteder dette:

  • Egne nettadresser per språk: underkataloger (example.com/fr/) er enklest. Underdomener og landsdomener fungerer også. URL-parametere (?lang=fr) anbefales ikke.
  • Ikke bytt språk bare via informasjonskapsel eller nettleserinnstilling. Googles crawler kan aldri se de andre versjonene.
  • Ikke send brukere videre automatisk basert på språk. Lenk heller mellom versjonene.
  • Bruk hreflang for å fortelle Google hvilke sider som er oversettelser av hverandre. Hver versjon må liste seg selv og alle de andre, ellers kan annotasjonene bli ignorert. Legg til x-default for reservesiden.
  • Google finner ut en sides språk fra synlig innhold, ikke fra lang eller hreflang. Oversett derfor hele siden, ikke bare menyen.

Sett likevel <html lang="fr"> på hver versjon. Skjermlesere bruker det til å velge riktig uttale, og det er et krav om tilgjengelighet.

Innloggede sider i appen trenger ikke å bli indeksert, så for dem er det greit å lagre språket i brukerprofilen. Se SEO for nettsteder bygget med KI for hvordan offentlige sider blir crawlet i utgangspunktet.

Innhold i databasen

Grensesnittekst ligger i filer, mens innhold som produktnavn, blogginnlegg og kategorier ligger i databasen. To vanlige mønstre:

  • En oversettelsestabell: product_translations (product_id, locale, name, description). Ryddig og skalerer til mange språk.
  • En JSON-kolonne per felt: name: {"en": "...", "fr": "..."}. Enklere for noen få språk.

Bestem hva som skjer når en oversettelse mangler. Vanligvis faller du tilbake til standardspråket i stedet for å vise tomt rom.

E-post og varsler

Lagre hver brukers språk, og bruk det også til e-post, varsler og PDF-filer. Det er lett å oversette appen og glemme at velkomst-e-posten fortsatt kommer på engelsk.

Ledetekster som fungerer

Legg til internasjonalisering med react-i18next. Flytt all tekst brukeren ser over i locales/en.json med navnerom på nøklene. Bruk interpolering og regler for flertall i stedet for sammensetting av strenger, og formater datoer, tall og priser med Intl og gjeldende lokale. Ikke endre ordlyden ennå.

Legg til fransk og tysk. Offentlige markedsføringssider får /fr/- og /de/-prefikser i nettadressen, med engelsk på rotnivå. Sett hreflang-lenker på hver side (inkludert selvreferanse og x-default) og html lang per side. Legg til en språkvelger som viser hvert språks eget navn. For innloggede sider lagrer du språket i brukerprofilen.

Legg til arabisk med støtte for høyre-mot-venstre. Sett dir="rtl" for arabisk, erstatt venstre- og høyremarginer og -utfyllinger med logiske egenskaper, speil retningsikoner, og sjekk at skjemaer og tabeller fortsatt leses riktig.

Steg for steg

  1. Velg ditt første ekstra språk basert på reell etterspørsel: hvor besøkende eller kunder er.
  2. Gjør koden internasjonaliserbar: flytt tekst til filer, og legg til flertallsregler og Intl-formatering. Lever dette med bare engelsk, og kontroller at ingenting har endret seg.
  3. Bestem nettadressestrukturen for offentlige sider, og legg til hreflang.
  4. Oversett: lag utkast med maskin- eller KI-oversettelse, og gå gjennom det med en flytende språkbruker. Gi oversetterne kontekst. Et ord som «Book» kan være et substantiv på én skjerm og et verb på en annen.
  5. Oversett databaseinnhold og sett reserver.
  6. Lokaliser resten: e-post, feilmeldinger, juridiske sider og bilder med tekst.
  7. Test hvert språk i telefonbredde, og med høyre-mot-venstre hvis det er relevant.
  8. Sett opp en prosess slik at nye funksjoner leveres med oversettelser, ikke måneder senere.

Vanlige feil

  • Sammensetting av setninger ("Du har " + n + " meldinger"), som brytes i andre språk.
  • Hardkodet tekst igjen i komponenter, feilmeldinger og valideringsstrenger.
  • Formatering av datoer og priser for hånd.
  • Flagg for språk, og automatiske videresendinger som låser folk fast i feil versjon.
  • Én nettadresse for alle språk på sider du vil ha indeksert.
  • Manglende hreflang-returlenker, så Google ignorerer annotasjonene.
  • Oversatt grensesnittet, men ikke innholdet, eller omvendt.
  • Ukorrekturlest maskinoversettelse på pris-, juridiske og kassesider.

Sjekkliste for flerspråklighet

  • Ingen hardkodet tekst som brukeren ser; flertallsregler og plassholdere brukt
  • Datoer, tall og valuta formatert med Intl
  • Språkvelger med hvert språks navn på alle sider; valget huskes
  • Egne nettadresser per språk for offentlige sider; ingen tvungne videresendinger
  • hreflang på hver versjon, inkludert selv og x-default
  • html lang (og dir="rtl" der det trengs) satt per side
  • Databaseinnhold oversatt med fornuftige reserver
  • E-post og varsler sendt på brukerens språk
  • Tekst for kunder gjennomgått av en flytende språkbruker

Flere språk på Mythex

På Mythex legger du til språk ved å be om det i chatten. Det finnes ingen egen oversettelsespanel, så ledetekstene over fungerer slik de er skrevet. Gjør internasjonaliseringssteget først, og sjekk det i forhåndsvisningen før du legger til språk. Det er en stor refaktorering, og et sjekkpunkt i chatten gir deg et punkt å gå tilbake til hvis noe ryker (chat og sjekkpunkter). Hvis du vil at appen skal oversette innhold automatisk med en KI- eller oversettelses-API, bruker det din egen API-nøkkel, lagret i prosjektinnstillingene (miljøvariabler og hemmeligheter). Slik bruker du LLM-API-er forklarer kostnadene. Publiser på nytt når de nye språkene er klare.

Spørsmål

Hva er forskjellen på i18n og lokalisering?

Internasjonalisering (i18n) er å forberede koden slik at den kan støtte mange språk: ingen hardkodet tekst, språkavhengige datoer og tall, og oppsett som tåler lengre ord og høyre-mot-venstre-skrift. Lokalisering (l10n) er arbeidet med å tilpasse appen til ett språk eller ett marked, og først og fremst er det oversettelse.

Kan jeg bare bruke maskinoversettelse eller KI til å oversette appen?

Som et første utkast, ja. Moderne maskin- og KI-oversettelse er god på grensesnittstekst. La en flytende språkbruker gå gjennom alt som kunder ser, særlig juridisk tekst, priser og markedsføringstekst, fordi tone og små feil betyr mye der.

Bør hvert språk ha sin egen nettadresse?

For offentlige sider du vil ha med i søkeresultatene, ja. Google anbefaler egne nettadresser per språk, for eksempel /fr/ og /de/, i stedet for å bytte språk via informasjonskapsel eller nettleserinnstilling. Ellers kan crawleren bare få se én versjon.

Bør jeg sende besøkende videre basert på nettleserens språk?

Foreslå, ikke tving. Google advarer mot automatiske språkvideresendinger, fordi de kan hindre folk og crawlere i å nå andre versjoner. Vis heller en liten melding som tilbyr riktig språk, og en synlig språkvelger på hver side.

Mythex · Pricing · Bygg hva som helst med KI · Maler for nettsider og apper · Mythex sammenlignet · Ordliste for app-bygging med KI · Gratis verktøy for app-bygging med KI · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk 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 မြန်မာ 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 简体中文 繁體中文(香港) 繁體中文(台灣)