Förklaring av Angular i18n: byggtid kontra körningstid

Internationalisering i Angular kan ske enligt två olika modeller – vid kompilering eller vid körning. Den officiella metoden använder @angular/localize, vilket genererar en separat version för varje språk. Denna lösning är stabil och snabb vid körning, men kräver planering för flera distributioner och möjliggör inte språkbyte inom appen.

För att implementera detta markerar man text i mallar och TypeScript, extraherar översättningarna till filer och bygger sedan en version av appen per språkversion. Varje språk levereras via en egen URL, så användarna byter språk via navigeringen istället för via en växlingsknapp inuti appen.

Om du behöver dynamisk växling utan omladdning sköts det istället av runtime-bibliotek. Populära alternativ är bland annat ngx-translate och angular-i18next. Dessa laddar översättningar vid behov och uppdaterar användargränssnittet omedelbart, med olika avvägningar när det gäller konfiguration, prestanda och stöd för SSR.

I den här artikeln förklarar vi hur det inbyggda arbetsflödet för internationalisering (i18n) i Angular fungerar, hur man implementerar det och när ett runtime-bibliotek är ett bättre alternativ.

Hur @angular/localize verk

Angulars inbyggda internationaliseringsfunktion bygger på ett arbetsflöde vid kompilering. Man förbereder översättningarna innan distributionen och levererar sedan en kompilerad version av appen per språk.

Det sker inget byte av språk under körning, så installationen fokuserar på extrahering och byggkonfiguration.

Låt oss gå igenom hela arbetsflödet:

1. Markera text som ska översättas i mallar och TypeScript. Använd attributet i18n för HTML-innehåll och HTML-attribut, och använd $localize i TypeScript, så att strängar ingår i samma extraheringsprocess.
2. Extrahera meddelanden till en översättningsfil med hjälp av Angular CLI. Detta genererar som standard en XLIFF-fil, med alternativ för andra format beroende på din konfiguration, som innehåller meddelande-ID:n och källtexten.
3. Översätt den extraherade filen och behåll identifierarna oförändrade. Lägg till anpassade ID:n där det behövs så att uppdateringar av källtexten inte förstör befintliga översättningar eller orsakar dolda avvikelser.
4. Skapa och distribuera en version av appen per språkversion. Konfigurera språkversionerna i angular.json och generera sedan språkspecifika paket som levereras via separata rutter eller domäner.

Pluraliseringen använder ICU-uttryck. Du definierar fall som till exempel =0, =1, eller annat, och Angular väljer rätt form beroende på den aktiva språkinställningen. Olika språk kräver olika många former, så planera meddelandestrukturen i god tid.

Inbäddade ICU-uttryck följer samma mönster men ökar komplexiteten, så se till att de är läsbara och testa dem i olika språkversioner.

Att bygga och driftsätta Angular-appar för flera språkversioner

Med Angulars i18n vid kompilering är driftsättningen direkt kopplad till hur du konfigurerar angular.json. Du definierar en källspråkinställning och en uppsättning målspråkinställningar, som var och en är kopplad till en översättningsfil.

Under kompileringen kompilerar Angular appen en gång och tillämpar sedan lokaliserade ersättningar som ett efterbearbetningssteg. Det innebär att du inte kör fullständiga kompileringar för varje språk, men ändå får separata utdatapaket för varje språkversion.

Varje språkversion genererar sin egen version av appen, som vanligtvis tillhandahålls via en underkatalog eller domän. En vanlig konfiguration använder sökvägar som /sv/ och /fr/, där varje länk pekar på motsvarande byggutdata. Denna struktur är nödvändig eftersom det översatta innehållet är inbakat i filerna, vilket innebär att ett språkbyte kräver att en annan byggversion laddas in.

Serverkonfigurationen blir en del av i18n-inställningarna. Du behöver routningsregler som kopplar inkommande förfrågningar till rätt språkversion.

Implementeringen varierar kraftigt beroende på miljö – rena omskrivningsregler i Nginx jämfört med några få deklarativa rader i Firebase Hosting – men målet är detsamma. Förfrågningarna måste leda till rätt lokaliserat paket utifrån URL-strukturen eller omdirigeringslogiken.

Angular stöder även automatisk språkidentifiering vid serverbaserad rendering. Servern kan läsa webbläsarens Accept-Language header, och omdirigera sedan användarna till den motsvarande språkversionen. Detta förbättrar upplevelsen vid det första besöket, men innebär ändå att hela sidan måste laddas om man byter språk senare.

Under utvecklingen kan Angular-utvecklingsservern hantera flera språkversioner med hjälp av underkataloger. Detta underlättar testningen, men för att växla mellan språk krävs fortfarande en uppdatering eftersom varje språkversion är en separat byggutgång.

Denna modell har tydliga konsekvenser för infrastrukturen. Man hanterar flera byggartefakter, konfigurerar vidarebefordran för varje språkversion och hanterar omdirigeringar på servernivå. CI-pipelines måste ta hänsyn till översättningsuppdateringar och bygga om de lokaliserade resultaten när innehållet ändras.

Ett alternativt tillvägagångssätt undviker denna komplexitet. En omvänd proxymodell, såsom Weglot, placeras mellan servern och webbläsaren. Den översätter innehållet i realtid och levererar alla språk från en enda installation. Detta eliminerar behovet av flera versioner och vidarebefordringsregler. Mer om Weglot !

Jämförelse av runtime-bibliotek: ngx-translate, Transloco och angular-i18next

Körningsbibliotek löser ett annat problem än Angulars inbyggda i18n. Istället för att kompilera översättningarna in i appen laddar de dem vid körning och uppdaterar användargränssnittet utan att appen behöver laddas om helt.

Detta gör dem mer lämpliga när användarna behöver byta språk i appen eller när innehållet ändras ofta.

ngx-translate är det vanligaste alternativet. Det stöder omedelbar språkväxling genom trans.use(), med översättningar som hämtas från JSON-filer eller API:er. Det fungerar bra i mindre appar och är det enda alternativet här med bekräftad Ionic kompatibilitet. SSR är möjligt med Övergångstillstånd och anpassade laddare, även om det kräver en viss konfiguration. I de senaste versionerna har ett leverantörsbaserat API lagts till, vilket passar bättre ihop med fristående komponenter.

Transloco fokuserar på struktur och skalbarhet. Det erbjuder inbyggt stöd för SSR och en smidigare installation med `ng add`. Det stöder även översättningar med omfattningsbegränsning, vilket gör att du kan ladda språkfiler efter behov för varje funktion. Detta minskar paketstorleken och gör det enklare att underhålla stora appar. Språkbyte sker med hjälp av setActiveLang() och uppdaterar användargränssnittet omedelbart.

angular-i18next bygger vidare på i18next-ekosystemet. Det är användbart om ditt team redan använder i18next i andra ramverk och vill uppnå enhetlighet mellan olika projekt. Det stöder plugins från i18next-kärnan, inklusive hantering av ICU. Språkbyte kräver vanligtvis en omladdning, vilket begränsar användningen i appar som förväntar sig omedelbara uppdateringar.

Här är en mer direkt jämförelse:

Valet beror på hur din app hanterar språkbyten och skalbarhet:

• Använd ngx-translate om du behöver en enkel installation eller stöd för Ionic.
• Använd Transloco för SSR eller stora appar med behov av modulär översättning.
• Använd angular-i18next om du vill säkerställa kompatibilitet med i18next på flera plattformar.

💡 Om det inte krävs byte av runtime och du föredrar så lite klientlogik som möjligt är Angulars inbyggda i18n fortfarande det bästa alternativet.

Översättning av Angular-appar utan kodändringar

Det finns ett tredje alternativ utöver Angulars inbyggda i18n- och runtime-bibliotek: externa verktyg för webbplatsöversättning. Dessa verktyg finns utanför Angular-appen och översätter det renderade resultatet istället för strängarna i kodbasen.

Som nämnts Weglot en omvänd proxymodell. Den placeras mellan servern och webbläsaren, identifierar HTML-svaret och levererar sedan översatta versioner till besökarna. Det innebär att du inte behöver märka strängar med i18n, hantera JSON-översättningsfiler eller bygga om appen för varje språkversion. Installationen går snabbare eftersom översättningslagret hanteras utanför Angular.

Denna metod förändrar också var översättningsarbetet utförs. Istället för att redigera filer i projektet använder översättarna en visuell kontrollpanel. De kan granska sidor och tillämpa ordlisteregler utan att behöva röra mallarna eller TypeScript. För innehållsrika marknadsföringswebbplatser kan detta minska behovet av utvecklare.

Det går också smidigare att byta språk. Weglot en JavaScript-baserad språkväljare som uppdaterar det synliga språket utan att det krävs en fullständig ombyggnad i Angular. Det gör det enklare att snabbt publicera flerspråkigt innehåll.

Nackdelen är kontrollen. Eftersom översättningen sker efter att Angular har renderat sidan hanterar den här modellen inte applogik som är beroende av språket inuti TypeScript. Den passar inte heller särskilt bra för Ionic-appar och offline-first-appar, där innehållet måste finnas inuti själva applikationen snarare än bakom en proxy.

SEO beror också på hur systemet är konfigurerat. Översättning via omvänd proxy kan stödja indexerbara översatta sidor, men ett enkelt snippet skapar inte SEO-vänliga lokaliserade URL:er. Det är viktigt om organisk söktrafik ingår i målsättningen.

Den här modellen passar bäst för team som vill ha flerspråkiga sidor utan att behöva ändra applikationskoden. Den är mindre lämplig när språket påverkar routningen eller affärslogiken. Den kräver dessutom ett aktivt abonnemang, eftersom det översatta innehållet förblir knutet till tjänsten.

Att välja rätt strategi för Angular i18n

Hur man bäst går tillväga med internationalisering i Angular beror på hur din app hanterar språk i praktiken.

Internationell anpassning vid kompilering prioriterar prestanda och stabilitet, medan bibliotek för körning fokuserar på flexibilitet i användargränssnittet. Externa verktyg eliminerar större delen av implementeringsarbetet, men flyttar kontrollen utanför kodbasen.

Välj @angular/localize när prestandan vid körning är avgörande och ditt team är vana vid att hantera separata lokaliserade versioner i CI. Det passar bäst när man kan byta språk via navigeringen snarare än inuti appen.

Välj ngx-translate när användarna behöver byta språk utan att behöva ladda om sidan och du vill ha ett driftsmiljöalternativ som är allmänt utbrett. Det är det bästa valet här för Ionic-projekt och mindre Angular-appar.

Välj Transloco när du behöver möjlighet att byta språk under körning samt en stabilare struktur för större appar. Det passar utmärkt för SSR-konfigurationer och för team som vill ha översättningsfiler med begränsad räckvidd och som laddas vid behov.

Välj Weglot målet är en flerspråkig webbplats utan att behöva lägga till översättningslogik i Angular-kodbasen. Det passar bäst för innehållsleverans och snabb lansering, inte för appar där TypeScript-beteendet måste anpassas efter språket.

{{demo-banner}}