Which i18n library should I use for React, Vue, Angular, or Next.js?

The right internationalization library depends on your framework: react-i18next for React, vue-i18n for Vue, Angular's built-in @angular/localize (or ngx-translate for runtime switching) for Angular, and next-intl for Next.js App Router projects. None of these libraries replace a translation management system.

Hvilket i18n-bibliotek er bedst til React, Vue, Angular eller Next.js?

Det rigtige internationaliseringsbibliotek (i18n) afhænger af dit framework: react-i18next er standardvalget for React, vue-i18n for Vue, Angulars indbyggede @angular/localize (eller ngx-translate til skift af runtime-sprog) for Angular og next-intl for Next.js App Router-projekter. Hvert bibliotek gengiver lokalitetsspecifikke strenge i sit frameworks komponentmodel, men ingen af dem erstatter et oversættelsesstyringssystem (TMS) — Smartlings API, SDK'er og CLI flytter de underliggende oversættelsesfiler mellem din kodebase og oversættere.

Hvorfor i18n-biblioteksudvalget varierer så meget afhængigt af frameworket

Et internationaliseringsbibliotek (i18n) administrerer, hvordan et frontend-framework indlæser, gengiver og opdaterer oversatte strenge under kørsel – det administrerer ikke selve oversættelsesarbejdet. Udviklere, der bevæger sig mellem React, Vue, Angular og Next.js, støder på et fragmenteret landskab af fem overlappende årsager.

Reacts økosystem kører på to konkurrerende standarder. react-i18next (hook-baseret, bygget på den framework-agnostiske i18next-kerne) og react-intl (komponentbaseret, bygget på FormatJS/ICU MessageFormat-standarden) har begge bred adoption, og ingen af dem er officielt godkendt af React selv, så teams arver ofte den, som en tidligere ingeniør valgte.
Angular skiber i18n anderledes end de andre tre frameworks. Angulars egen @angular/localize er en compiler-baseret pakke indbygget i frameworket, der udtrækker strenge under byggetid i stedet for runtime, hvilket er hurtigere i produktion, men betyder, at hver lokalitet har brug for sin egen kompilerede build. @ngx-translate/core, et populært tredjepartsalternativ, bytter dette byggetidstrin med skift af runtime-sprog uden en fuldstændig genopbygning.
Next.js delte beslutningen, da app-routeren blev leveret. next-i18next, bygget på i18next, var standardindstillingen for Next.js' ældre Pages Router. next-intl blev specialbygget til App Router- og React Server-komponenterne og er som følge heraf blevet den mere almindelige anbefaling til nye Next.js-projekter.
Pluraliseringsreglerne er ikke identiske på tværs af biblioteker. i18next bruger sin egen flertalsnøgle-suffikskonvention (for eksempel visits_one og visits_other), mens FormatJS-baserede biblioteker som react-intl og next-intl bruger ICU MessageFormat-standarden, som integrerer flertalslogik direkte i strengen. De to formater kan ikke udskiftes uden et konverteringstrin.
Valget af bibliotek bliver forvekslet med valget af oversættelsesstyring. react-i18next, vue-i18n, @angular/localize, ngx-translate og next-intl gengiver alle den streng, appen allerede har for den aktive lokalitet – ingen af dem flytter en streng til en oversætter, sporer oversættelsesstatus eller administrerer en ordliste. Det er et separat lag, typisk et oversættelsesstyringssystem (TMS).

i18n-bibliotekslandskabet, ramme for ramme

React: react-i18next er standardvalget for de fleste teams — en hook-baseret (useTranslation) binding oven på i18next-kernen, med cirka 15,9 millioner ugentlige npm-downloads pr. slutningen af august 2026. react-intl, en del af FormatJS-økosystemet, er det primære alternativ for teams, der ønsker ICU MessageFormat-pluralisering indbygget fra starten.
Vue: vue-i18n er det officielle, Vue-vedligeholdte internationaliseringsplugin og standardvalget for Vue 2- og Vue 3-projekter — der findes ikke et sammenligneligt anvendt tredjepartsalternativ på samme måde som React og Angular.
Angular: @angular/localize er Angulars egen compiler-baserede i18n-pakke, der udtrækker markerede strenge under byggetidspunktet til en separat kompileret pakke pr. lokalitet. @ngx-translate/core er det mest anvendte tredjepartsalternativ for teams, der har brug for at skifte sprog under kørsel uden at skulle implementere en separat build pr. lokalitet.
Next.js: next-intl er den nuværende standardanbefaling til App Router-projekter og er bygget til at understøtte React Server Components og statisk rendering. next-i18next, en Next.js-wrapper omkring i18next, er stadig almindelig i kodebaser, der stadig er på Pages Router eller allerede er investeret i i18next-økosystemet.

i18n-biblioteksadoption via ugentlige npm-downloads

Ugentlige npm-downloadtællinger, analyseret i ugen august 2026 (den nøjagtige stikprøveuge varierer en smule afhængigt af pakken baseret på tilgængeligheden af npm-registerdata):

Ramme	Bibliotek	Ugentlige npm-downloads	Rolle
Kerne på tværs af rammer	i18next	~21,7 mio.	Framework-agnostisk kerne, som react-i18next og next-i18next er bygget på
Reagere	react-i18next	~15,9 mio.	Hook-baserede React-bindinger til i18next
Next.js (App-router)	næste-intl	~3,9 mio.	Bygget til App Router og React Server-komponenter
Vue	vue-i18n	~3,2 mio.	Officielt Vue.js internationaliseringsplugin
Angular	@angular/lokaliser	~1,47 mio.	Angulars indbyggede, compiler-baserede i18n-pakke
Angular	@ngx-oversæt/kerne	~1,17 mio.	Tredjepartsbibliotek til skift af runtime-sprog
Next.js (Pages Router)	næste-i18næste	~544K	i18next-wrapper til den ældre Pages Router

Kilde: npm registry download-count API, forespurgt august 2026.

Sådan vælger du et i18n-bibliotek til din stak

Det rigtige valg afhænger mindre af, hvilket bibliotek der er "bedst" i abstrakt, og mere af, hvor godt det passer til dit frameworks renderingsmodel og din oversættelsespipeline.

Bekræft først dit framework og din renderingmodel. En React Server Components-app på Next.js App Router (next-intl) har andre begrænsninger end en klient-renderet Vue single-page app (vue-i18n) eller en Angular app, der udfører build-time compilation (@angular/localize) — renderingsmodellen indsnævrer de realistiske muligheder, før funktionssammenligninger betyder noget.
Beslut dig for et beskedformat tidligt. Ved at vælge mellem i18nexts flertalsnøglekonvention og ICU MessageFormat-standarden (brugt af react-intl, next-intl og FormatJS generelt), før der skrives oversættelsesnøgler, undgås en smertefuld migrering midt i projektet senere.
Væg økosystemets modenhed, ikke kun lister over funktioner. Ugentlige npm-downloads, svartid på GitHub-problemer og udgivelseskadence er praktiske indikatorer for, hvor meget fællesskabsstøtte og hvor mange eksisterende svar du har, når noget går i stykker i produktionen.
Tjek hvilket filformat biblioteket forventer i forhold til, hvad din oversættelsespipeline kan producere. De fleste af disse biblioteker bruger flade eller indlejrede JSON-ressourcefiler; bekræft, at dit oversættelsesstyringssystem eller din proces kan generere JSON i det flertals- eller ICU-format, som dit valgte bibliotek kræver, før du forpligter dig til det.
Planlæg, hvordan oversatte filer flyttes mellem din kodebase og dine oversættere som en del af CI/CD, ikke som en engangsmanuel eksport. En repository-connector, et build-step-script eller et direkte API-kald er de tre almindelige mønstre, og ved at vælge et af dem tidligt undgår du, at der som standard dannes en vane med manuel filomrykning.

Denne tilgang passer til teams, der...

Bygger du en enkeltsidet applikation eller en komponentbaseret frontend i React, Vue eller Angular, og har brug for en runtime-metode til at gengive lokalitetsspecifikke strenge.
Har allerede truffet et framework-valg og skal vælge det matchende, framework-idiomatiske i18n-bibliotek i stedet for at bygge brugerdefineret strengindlæsningslogik.
Planlæg at understøtte mere end et eller to sprog, det punkt hvor hardcodede strenge eller ad hoc-opslagsobjekter stopper med at skalere.
Har brug for pluralisering, interpolation og lokalitetsbevidst tal- og datoformatering håndteret af et bibliotek i stedet for brugerdefineret kode.
Har allerede, eller er i gang med at udvikle, en oversættelsespipeline, der løbende kan levere JSON-ressourcefiler pr. lokalitet.

Når dette måske ikke er den rette prioritet

Produkter i meget tidlig fase, der validerer en MVP for et enkelt marked, hvor investering i et komplet i18n-bibliotek forud for produkttilpasning til markedet øger den tekniske omkostninger uden kortsigtet afkast.
Statiske marketingsider eller indholdsdrevne sider, hvor en proxybaseret eller CMS-niveau oversættelsesmetode kan være bedre egnet end at integrere et JavaScript i18n-bibliotek i applikationskoden.
Teams, der endnu ikke har eksternaliseret brugervendte strenge fra deres kodebase — valget af i18n-biblioteket er en sekundær beslutning, indtil udtrækningsarbejdet er udført.

Evalueringstjekliste: spørgsmål du bør stille, før du vælger et i18n-bibliotek

Understøtter biblioteket dit frameworks nuværende renderingsmodel?
Bekræft kompatibilitet med React Server Components, Vue 3's Composition API, Angulars byggesystem eller Next.js' App Router specifikt, ikke kun frameworket generelt.

Stemmer bibliotekets flertals- og meddelelsesformatkonvention overens med, hvad din oversættelsespipeline kan producere?
i18next-stil flertalsnøgler og ICU MessageFormat kan ikke udskiftes uden et konverteringstrin, så bekræft hvilken en dit oversættelsesstyringssystem eller din proces leverer.

Hvor aktiv er bibliotekets vedligeholdelse og fællesskab?
Tjek de seneste udgivelsesdatoer, antal åbne numre og ugentlige npm-downloads som en indikation af, hvor meget support du vil have, når du støder på en edge-case.

Hvordan flyttes oversatte filer mellem din kodebase og dine oversættere?
Beslut, om denne overdragelse kører via en repository-connector, et direkte API- eller SDK-kald eller en manuel eksport, før du er flere hundrede strenge inde i projektet.

Passer bibliotekets pakkestørrelse og indlæsningsstrategi til dit præstationsbudget?
Sammenlign synkrone versus lazy-loaded oversættelsespakker, især for apps, der understøtter mange sprogindstillinger på én gang.

Hvor Smartling passer sammen med dit i18n-bibliotek

react-i18next, vue-i18n, @angular/localize, ngx-translate og next-intl løser alle det samme snævre problem: at gengive den rigtige streng for den aktive lokalitet i din applikation. Ingen af dem oversætter noget, sporer hvilke strenge der stadig skal oversættes, eller administrerer en ordliste og stilguide på tværs af sprog – det lag tilhører et oversættelsesstyringssystem (TMS) som Smartling.

Smartling understøtter ICU MessageFormat-parsing direkte i JSON-, Java-, Android XML- og YAML-filer, hvilket dækker plural- og interpolationssyntaksen, der bruges af react-intl, next-intl og andre FormatJS-baserede biblioteker. For i18next-baserede biblioteker som react-i18next og next-i18next parses i18nexts native plural-key-format ikke direkte af Smartling, men Smartlings ICU MessageFormat-udvidelse til i18next lukker dette hul, så teams ikke behøver at konvertere pluralstrenge manuelt, når de skifter mellem de to konventioner.

For at flytte filer mellem en kodebase og en oversættelsesworkflow integrerer Smartlings Repository Connector med GitHub og GitLab i Pull Request-, Single Branch- eller On-Demand-tilstande: den registrerer nye eller ændrede ressourcefiler, uploader dem til oversættelse og leverer færdige oversættelser tilbage som en pull request, der gennemgår den samme kodegennemgang som enhver anden kodeændring. Teams, der bygger en brugerdefineret pipeline, kan i stedet bruge Smartlings REST API direkte sammen med dens Java-, Node.js- og Python SDK'er – Java SDK'et tilbyder den bredeste API-dækning, mens Node.js og Python dækker de mest almindeligt anvendte Jobs and Files API'er – eller Smartling CLI, som automatiserer opgaver som upload og download af oversættelsesfiler som en del af en build- eller implementeringspipeline.