Guider

Så lägger du till flera språk i din app eller webbplats

För att lägga till flera språk i en app flyttar du all gränssnittstext till översättningsfiler (en per språk), laddar dem med ett i18n-bibliotek och lägger till en språkväxlare som minns valet. För publika sidor du vill ska hittas i sökningar ger du varje språk en egen webbadress, till exempel /fr/, och länkar versionerna med hreflang-taggar. Sedan hanterar du de delar som folk ofta glömmer: datum, siffror och valutor, längre text på vissa språk, höger-till-vänster-skrift och innehåll som ligger i databasen.

Ord du kommer att höra

  • Internationalisering (i18n): att förbereda koden för att stödja vilket språk som helst, inga hårdkodade strängar, formatering som följer språkinställningen och flexibla layouter. Siffran "18" är antalet bokstäver mellan i och n.
  • Lokalisering (l10n): att anpassa appen för ett visst språk eller en viss marknad, mest översättning, ibland även valuta, bilder och juridisk text.
  • Språkinställning (locale): ett språk och eventuellt en region, till exempel en-GB eller pt-BR.

Gör i18n en gång, så blir det att lägga till varje nytt språk mestadels översättningsarbete.

Alternativ och avvägningar

MetodSå fungerar denBra förAvvägning
i18n-bibliotek + översättningsfiler (t.ex. react-i18next, next-intl, vue-i18n)Texten ligger i JSON-filer per språkinställning; komponenter slår upp nycklarDe flesta apparInitial omstrukturering; översättningar att underhålla
System för översättningshantering (t.ex. Crowdin, Lokalise, Phrase)Webbaserad redigerare för översättare, synkad med dina filerMånga språk, flera översättareBetalt; ytterligare ett verktyg att sätta upp
Maskin- eller AI-översättning vid byggetGenererar utkast med ett API, som sedan granskasAtt snabbt nå många språkKvaliteten måste kontrolleras; API-kostnader
Webbläsar- eller widget-översättningBesökarens webbläsare översätter sidan direktInget som du kontrollerarIngen kvalitetskontroll; översatta sidor indexeras inte som dina
Separata webbplatser per språkDubbel webbplats per marknadMycket olika marknaderAllt underhålls två gånger

För de flesta appar är ett vanligt i18n-bibliotek med översättningsfiler rätt grund. Gör utkast med maskin- eller AI-översättning om du vill, och låt sedan flytande talare granska det kunderna ser mest.

Delarna i en flerspråkig app

Översättningsfiler

I stället för <h1>Välkommen tillbaka</h1> skriver koden t('dashboard.welcome'), och varje språkinställning har en fil med texten:

{
  "dashboard": {
    "welcome": "Välkommen tillbaka, {{name}}",
    "items_one": "{{count}} objekt",
    "items_other": "{{count}} objekt"
  }
}

Använd platshållare för variabler i stället för att slå ihop meningsfragment, eftersom ordföljden skiljer sig mellan språk. Och använd bibliotekets pluralregler: engelskan har två former (1 item, 2 items), men vissa språk har tre, fyra eller fler.

Formatera datum, siffror och pengar

Formatera inte dessa för hand. Webbläsarens inbyggda Intl-API formaterar för vilken språkinställning som helst: 1,234.5 på engelska blir 1.234,5 på tyska; datum byter mellan dag-först och månad-först; valutasymboler flyttar sig. Lagra datum i UTC och pengar som tal med en valutakod, och formatera först när det visas.

Layout som tål att sträckas

Översatt text är ofta längre än engelska, särskilt tyska och finska ord. Undvik knappar med fast bredd och avkortade etiketter, och testa med ditt längsta språk.

Höger-till-vänster-språk

Arabiska, hebreiska, persiska och urdu läses från höger till vänster. Sätt dir="rtl" på sidan för de språkinställningarna och använd CSS-logiska egenskaper (margin-inline-start i stället för margin-left; i Tailwind ms-4 i stället för ml-4) så att layouten speglar sig själv. Ikoner som anger riktning, till exempel pilar, behöver också vändas.

Språkväxlare och identifiering

Visa en växlare på varje sida, märkt med varje språks eget namn ("Deutsch", "Français", "العربية") i stället för flaggor, eftersom flaggor representerar länder, inte språk. Identifiera webbläsarens föredragna språk vid första besöket för att föreslå en version, men låt besökarens uttryckliga val gälla och kom ihåg det.

Webbadresser och SEO

För sidor du vill ska synas i sökresultat behöver varje språk en egen webbadress. Från och med september 2026 är Googles riktlinjer för flerspråkiga webbplatser:

  • Separata webbadresser per språk: underkataloger (example.com/fr/) är enklast; subdomäner och landsdomäner fungerar också. URL-parametrar (?lang=fr) rekommenderas inte.
  • Byt inte språk enbart med en cookie eller webbläsarinställning; Googles crawler kanske aldrig ser de andra versionerna.
  • Omdirigera inte automatiskt efter språk; länka i stället mellan versionerna.
  • Använd hreflang för att tala om för Google vilka sidor som är översättningar av varandra. Varje version måste lista sig själv och alla andra, annars kan annoteringarna ignoreras. Lägg till x-default för reservsidan.
  • Google identifierar en sidas språk utifrån det synliga innehållet, inte från lang eller hreflang, så översätt hela sidan, inte bara menyn.

Sätt ändå <html lang="fr"> på varje version: skärmläsare använder det för att välja rätt uttal, vilket är ett krav för tillgänglighet.

Inloggade appskärmar behöver inte indexeras, så för dem är det bra att lagra språket i användarens profil. Se SEO för AI-byggda webbplatser för hur publika sidor blir genomsökta från början.

Innehåll i din databas

Gränssnittstext ligger i filer; innehåll som produktnamn, blogginlägg och kategorier ligger i databasen. Två vanliga mönster:

  • En översättningstabell: product_translations (product_id, locale, name, description). Ren och skalbar för många språk.
  • En JSON-kolumn per fält: name: {"en": "...", "fr": "..."}. Enklare för några få språk.

Bestäm vad som händer när en översättning saknas: normalt faller du tillbaka till standardspråket i stället för att visa tomma ytor.

E-post och notiser

Lagra varje användares språk och använd det även för e-post, notiser och PDF-filer. Det är lätt att översätta appen och glömma att välkomstmejlet fortfarande kommer på engelska.

Prompter som fungerar

Lägg till internationalisering med react-i18next. Flytta all text som användare ser till locales/en.json med namnrymdsnycklar, använd platshållare och pluralregler i stället för strängsammanfogning, och formatera datum, siffror och priser med Intl efter den aktuella språkinställningen. Ändra ingen formulering ännu.

Lägg till franska och tyska. Publika marknadsföringssidor får prefixen /fr/ och /de/ med engelska i roten, hreflang-länkar på varje sida (inklusive självreferens och x-default) och html lang satt per sida. Lägg till en språkväxlare som visar varje språks eget namn. För inloggade sidor sparas språket i användarens profil.

Lägg till arabiska med stöd för höger-till-vänster: sätt dir="rtl" för arabiska, ersätt vänster- och högermarginaler och utfyllnader med logiska egenskaper, spegla riktningsikoner och kontrollera att formulär och tabeller fortfarande läses korrekt.

Steg för steg

  1. Välj ditt första extra språk utifrån verklig efterfrågan, var dina besökare eller kunder finns.
  2. Internationalisera koden: flytta strängar till filer, lägg till pluralformer och Intl-formatering. Släpp detta med enbart engelska och kontrollera att inget har ändrats.
  3. Bestäm webbadressstrukturen för publika sidor och lägg till hreflang.
  4. Översätt: gör utkast med maskin- eller AI-översättning och granska sedan med en flytande talare. Ge översättarna sammanhang: ett ord som "Boka" är ett substantiv på en skärm och ett verb på en annan.
  5. Översätt databasinnehåll och ange reservvärden.
  6. Lokalisera resten: e-post, felmeddelanden, juridiska sidor, bilder med text i.
  7. Testa varje språk i telefonbredd, och med höger-till-vänster om det är relevant.
  8. Inför en process så att nya funktioner levereras med översättningar, inte månader senare.

Vanliga misstag

  • Att sammanfoga meningar ("Du har " + n + " meddelanden"), vilket går sönder på andra språk.
  • Hårdkodad text kvar i komponenter, felmeddelanden och valideringssträngar.
  • Att formatera datum och priser för hand.
  • Flaggor för språk, och automatiska omdirigeringar som fångar folk i fel version.
  • En webbadress för alla språk på sidor du vill ska indexeras.
  • Saknade hreflang-returlänkar, så att Google ignorerar annoteringarna.
  • Att översätta gränssnittet men inte innehållet, eller tvärtom.
  • Ogranskad maskinöversättning på pris-, juridiska och betalningssidor.

Checklista för flerspråkighet

  • Inga hårdkodade strängar som användare ser; pluralregler och platshållare används
  • Datum, siffror och valutor formateras med Intl
  • Språkväxlare med inhemska namn på varje sida; valet kommer ihåg
  • Separata webbadresser per språk för publika sidor; inga tvingande omdirigeringar
  • hreflang på varje version, inklusive självreferens och x-default
  • html lang (och dir="rtl" där det behövs) satt per sida
  • Databasinnehåll översatt med rimliga reservvärden
  • E-post och notiser skickas på användarens språk
  • Text som kunder ser granskad av en flytande talare

Flera språk på Mythex

På Mythex lägger du till språk genom att be om det i chatten. Det finns ingen separat översättningspanel, så prompterna ovan fungerar som de står. Gör internationaliseringssteget först och kontrollera det i förhandsgranskningen innan du lägger till språk. Det är en stor omstrukturering, och en chattcheckpoint ger dig en punkt att återgå till om något går sönder (chatt och checkpoints). Om du vill att appen ska översätta innehåll automatiskt med ett AI- eller översättnings-API använder du din egen API-nyckel, sparad i projektinställningarna (miljövariabler och hemligheter). Så använder du LLM-API:er förklarar kostnaderna. Publicera igen när de nya språken är klara.

Frågor

Vad är skillnaden mellan i18n och lokalisering?

Internationalisering (i18n) är att förbereda koden så att den kan stödja många språk: ingen hårdkodad text, datum och siffror som anpassas till språkinställningen och layouter som klarar längre ord och höger-till-vänster-skrift. Lokalisering (l10n) är arbetet med att anpassa den för ett språk eller en marknad, främst översättning.

Kan jag bara använda maskinöversättning eller AI för att översätta min app?

För ett första utkast, ja. Modern maskin- och AI-översättning är bra på gränssnittstext. Låt en flytande talare granska allt som kunden ser, särskilt juridisk text, priser och marknadsföring, eftersom ton och små fel spelar roll där.

Ska varje språk ha sin egen webbadress?

För publika sidor som du vill ska synas i sökresultat, ja. Google rekommenderar separata webbadresser per språk, till exempel /fr/ och /de/, i stället för att byta språk med en cookie eller webbläsarinställning, eftersom crawlern annars kanske bara ser en version.

Ska jag omdirigera besökare utifrån webbläsarens språk?

Föreslå, tvinga inte. Google avråder från automatiska språkomdirigeringar eftersom de kan hindra människor och crawlers från att nå andra versioner. Visa en liten uppmaning med det matchande språket och en synlig växlare på varje sida.

Mythex · Pricing · Bygg vad som helst med AI · Mallar för webbplatser och appar · Mythex jämfört · Ordlista för apputveckling med AI · Gratis verktyg för apputveckling med AI · 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 မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)