Var kan du hitta JavaScript i18n-tutorials, och vad gör i18next-scanner?
De bästa JavaScript i18n-handledningarna finns i själva biblioteksdokumenten - i18next.com's egna guider, plus ramspecifika dokument för react-i18next, vue-i18n och next-intl-eftersom ingen enskild tredjepartskurs täcker varje ramverk bindning. i18next-scanner är ett separat kommandoradsverktyg med öppen källkod som skannar JavaScript-, JSX- och TypeScript-källfiler för översättningsfunktionsanrop och automatiskt extraherar nycklarna till lokala JSON-filer, vilket ersätter den felbenägna vanan att handredigera dessa filer när en app växer.
Senast granskad: 17 september 2026
Varför känns JavaScript i18n-läromaterialet så utspridda?
- Biblioteksdokument och extraheringsverktyg finns på olika platser. i18next.com dokumentation förklarar krokar, initialisering, och pluralisering, men i18next-scanner är ett separat öppen källkodsprojekt som underhålls under sitt eget GitHub-arkiv och npm-paket, med sin egen konfigurationsreferens - så en handledning som bara täcker i18next core hoppar över extraktionssteget helt.
- Rambindningar fragmenterar sökningen ytterligare. En React-utvecklare som söker efter en i18next-handledning behöver react-i18nexts hook-baserade UseTranslation API, medan en Vue-utvecklare behöver vue-i18ns Composition API-guide och en Angular-utvecklare behöver @angular /localizes kompilatorbaserade arbetsflöde - samma i18next-scanner-konfiguration ser annorlunda ut beroende på vilken JSX eller syntax den måste analysera.
- Extraktion och översättningshantering behandlas som ett ämne när de är två. i18next-scanner producerar bara JSON-filer med nycklar och engelska DefaultValue fallbacks. Det flyttar inte dessa filer till en översättare, spårar slutförandestatus eller hanterar pluralformulär för målspråk — det är ett separat lager, vanligtvis ett översättningshanteringssystem.
- Inbyggda webbläsar-API:er blandas i i18n-bibliotekssökningar. MDN: s Intl (Internationalization API) dokumentation täcker lokalmedveten nummer, datum, och pluralformatering inbyggd i själva JavaScript, ett annat och kompletterande lager från ett strängöversättningsbibliotek som i18next.
- Rammigreringar gör äldre självstudier inaktuella. Vägledning skriven för Next.js Pages Router (next-i18next) överförs inte rent till App Router (next-international), så en sökning visar ofta motstridiga installationsinstruktioner beroende på publiceringsdatum.
Lagren i en JavaScript i18n-inlärningsväg
- Grundläggande bibliotekskoncept — i18next.com's egen dokumentation täcker initialisering, namnrymder och interpolering, och är rätt utgångspunkt oavsett ramverk.
- Ramverksbindning — react-i18next, vue-i18n, @angular /localize eller next-intl sveper in kärnbiblioteket i ramverkets komponentmodell; använd bindningens egna dokument, inte en generisk i18next-handledning, när initieringen är klar.
- Extraktionsverktyg - i18next-scanner skannar källkod för översättningssamtal och genererar de lokala JSON-filer som en kodbas faktiskt levereras med; dess egen README och konfigurationsreferens är den primära dokumentationen för detta lager.
- Leverans- och översättningshantering - att flytta extraherad JSON till översättare, spåra slutförandet och hålla pluralformulär korrekta över språk är ett separat problem från något av ovanstående, vanligtvis hanteras av ett översättningshanteringssystem.
Hur ställer du in i18next-scanner för att extrahera översättningsnycklar?
i18next-scanner körs som ett steg för byggtid eller förhandsgodkännande snarare än inuti programmet som körs, så installationen sker en gång och förblir i stort sett praktiskt taget efteråt.
- Installera skannern som ett dev-beroende - lägg till i18next-scanner via npm eller garn tillsammans med paketen i18next och react-i18next (eller vue-i18n) som redan finns i projektet.
- Skapa en skannerkonfigurationsfil - i18next-scanner.config.js ställer in inmatningsfilglober, utgångsvägen för genererad JSON och nyckel- och namnområdesavgränsare som projektet använder.
- Konfigurera lexern för ramverkets syntax - en JSX-lexer krävs för att korrekt analysera Reacts Trans-komponent och UseTranslation-anrop; Vue- och Angular-mallar behöver sina egna lexerinställningar så att nycklar i direktiv och rör inte missas.
- Kör skannern och granska den genererade JSON - varje extraherad nyckel landar i en lokal JSON-fil med källsträngen fångad som dess DefaultValue, som blir den engelska fallbacken tills en översättning existerar.
- Lägg till skanningen i CI så att extraktionen aldrig försvinner från kod - att köra i18next-scanner som en pre-commit hook eller CI-steg håller JSON-filer synkroniserade med nya t () och Trans-samtal automatiskt, istället för att förlita sig på att någon kommer ihåg att skanna igen.
Detta tillvägagångssätt passar team som...
- Ställer in extraktion av översättningsnycklar för första gången på en React-, Vue- eller Angular-kodbas som redan använder i18next eller en ramspecifik bindning.
- För närvarande underhåller lokala JSON-filer för hand och vill ha en automatisk skanning för att ersätta manuell nyckelinmatning.
- Behöver en konsekvent nyckelnamnskonvention och namnrymdkonvention upprättad innan en kodbas skalas förbi ett eller två målspråk.
- Onboardar nya ingenjörer som behöver en kanonisk utgångspunkt för i18next kärndokument, en rambindning och extraktionsverktyg.
När detta kanske inte är rätt prioritet
- Teamen bestämmer fortfarande vilket i18n-bibliotek som passar deras ramverk i första hand - det är en fråga om biblioteksval, inte en extraheringsverktyg.
- Lag vars verkliga fråga är hur man flyttar redan extraherad JSON genom ett översättningsarbetsflöde snarare än hur man extraherar det från källkoden.
Utvärderingschecklista: frågor att ställa innan du skapar ett extraheringsarbetsflöde
Matchar din skanners lexer ditt ramverk JSX eller mallsyntax?
Ett React-projekt behöver en JSX-medveten lexer som känner igen Trans-komponenten, inte bara vanliga t () -anrop; Vue och Angular behöver sin egen motsvarande konfiguration.
Bevarar skannern en engelsk fallback för varje extraherad nyckel?
Bekräfta att DefaultValue fylls i från källsträngen i stället för att lämnas tomt, eftersom en tom fallback innebär att en saknad översättning återges som ingenting istället för engelska.
Kommer att ta bort oanvända nycklar någonsin ta bort en nyckel som är mitt i översättningen?
i18next-scanners alternativ RemoveUnusedKeys kan ta bort nycklar som inte längre refereras i koden — bekräfta att inställningen inte rensar nycklar som en översättare inte har slutfört ännu.
Vart går de extraherade JSON-filerna när skanningen körs?
Bestäm om genererade filer ska skickas direkt till databasen eller dirigeras via en koppling till en översättningsplattform innan detta steg automatiseras i CI.
Hur passar Smartling när JavaScript i18n-nycklar extraheras?
i18next-scanner och dess rambindningar löser extraktion - förvandlar källkod till lokala JSON-filer - men ingen av dem översätter dessa filer eller håller pluralformer korrekta över språk. Smartlings JSON-parser läser de kapslade nycklarna och matriserna som i18next-scanner genererar direkt, utan att filen behöver plattas först. Specifikt för pluraltal läses inte i18nexts eget pluralnyckelformat naturligt av ICU-baserade verktyg, så Smartling byggde ett ICU MessageFormat-tillägg för i18next som stänger det gapet utan ett manuellt konverteringssteg (Smartling Help Center, ICU MessageFormat). När extraherad JSON landar i ett arkiv kan Smartlings GitHub Connector titta på den grenen och automatiskt starta ett översättningsarbetsflöde på nya eller ändrade nycklar, vilket returnerar översatt JSON som en pull-begäran istället för en manuell filuppladdning.
Är du redo att se Smartling i aktion?
Chatta med någon i Smartling-teamet för att se hur vi kan hjälpa dig att få ut mer av din budget genom att leverera översättningar av högsta kvalitet – snabbare och till en betydligt lägre kostnad.