Angular i18n byggetid vs. kjøretid forklart

Internasjonalisering i Angular kan følge to forskjellige modeller – byggetid eller kjøretid. Den offisielle tilnærmingen bruker @angular/lokalisere, som genererer en separat versjon for hvert språk. Dette oppsettet er stabilt og raskt under kjøring, men det krever planlegging for flere distribusjoner og ingen språkbytte i appen.

For å implementere det, markerer du tekst i maler og TypeScript, pakker ut oversettelser til filer, og bygger deretter én versjon av appen per språk. Hvert språk serveres fra sin egen URL, slik at brukerne bytter språk gjennom navigasjon i stedet for en veksleknapp inne i appen.

Hvis du trenger dynamisk bytte uten omlasting, håndterer runtime-biblioteker det i stedet. Populære alternativer inkluderer ngx-translate og angular-i18next. Disse laster inn oversettelser på forespørsel og oppdaterer brukergrensesnittet umiddelbart, med ulike avveininger rundt oppsett, ytelse og SSR-støtte.

I denne artikkelen forklarer vi hvordan den innebygde arbeidsflyten for Angular Internationalization (i18n) fungerer, hvordan den distribueres, og når et runtime-bibliotek er bedre egnet.

Hvordan @angular/lokalisere verk

Angulars innebygde internasjonalisering bruker en arbeidsflyt under bygging. Du forbereder oversettelser før utrulling, og sender deretter én kompilert versjon av appen per språk.

Det er ikke noe bytte av kjøretidsspråk, så oppsettet fokuserer på utvinning og byggekonfigurasjon.

La oss gå gjennom hele arbeidsflyten :

1. Merk tekst for oversettelse i maler og TypeScript. Bruk i18n-attributtet for HTML-innhold og -attributter, og bruk $lokalisere i TypeScript slik at strenger inkluderes i samme utvinningsprosess.
2. Pakk ut meldinger til en oversettelsesfil ved hjelp av Angular CLI. Dette genererer en XLIFF-fil som standard, med alternativer for andre formater basert på oppsettet ditt, som inneholder meldings-ID-er og kildetekst.
3. Oversett den utpakkede filen og hold identifikatorene stabile. Legg til tilpassede ID-er der det er nødvendig, slik at oppdateringer av kildeteksten ikke ødelegger eksisterende oversettelser eller forårsaker stille avvik.
4. Bygg og distribuer én versjon av appen per språkinnstillinger. Konfigurer språkinnstillinger i angular.json , og generer deretter språkspesifikke pakker som serveres fra separate ruter eller domener.

Pluralisering bruker ICU-uttrykk. Du definerer tilfeller som =0, =1, eller annen, og Angular velger riktig form basert på den aktive språkinnstillingen. Språk varierer i hvor mange former de krever, så planlegg meldingsstrukturen tidlig.

Nestede ICU-uttrykk følger samme mønster, men øker kompleksiteten, så sørg for at de er lesbare og test på tvers av språkinnstillinger.

Bygge og distribuere Angular-apper med flere språk

Med Angulars byggetids-i18n er utrullingen direkte knyttet til hvordan du konfigurerer angular.json . Du definerer en kilde-lokalitet og et sett med mål-lokaliteter, som hver er tilordnet en oversettelsesfil.

Under byggingen kompilerer Angular appen én gang, og bruker deretter lokaliserte erstatninger som et etterbehandlingstrinn. Dette betyr at du ikke kjører fullstendige bygg per språk, men du ender fortsatt opp med separate utdatapakker for hver språkinnstilling.

Hvert språkområde produserer sin egen versjon av appen, vanligvis servert fra en underbane eller et domene. Et vanlig oppsett bruker baner som /no/ og /fr/, hvor hver peker til tilhørende byggeutdata. Denne strukturen er nødvendig fordi det oversatte innholdet er bakt inn i filene, så å bytte språk betyr å laste inn et annet byggeprogram.

Serverkonfigurasjon blir en del av i18n-oppsettet. Du trenger rutingsregler som tilordner innkommende forespørsler til riktig språkversjon.

Implementeringen varierer mye avhengig av miljøet – rå omskrivingsregler i Nginx kontra noen få deklarative linjer i Firebase Hosting – men målet er det samme. Forespørsler må løses til riktig lokalisert bunt basert på URL-struktur eller omdirigeringslogikk.

Angular støtter også automatisk språkgjenkjenning når serversidegjengivelse brukes. Serveren kan lese nettleserens Godta språk header, og deretter omdirigere brukere til den samsvarende språkbanen. Dette forbedrer opplevelsen ved første besøk, men det resulterer fortsatt i full sideinnlasting når du bytter språk senere.

Under utvikling kan Angular-utviklerserveren betjene flere språkinnstillinger ved hjelp av underbaner. Dette hjelper med testing, men bytting mellom språk krever fortsatt en oppdatering fordi hver språkinnstillinger er en separat byggeutdata.

Denne modellen har klare implikasjoner for infrastruktur. Du administrerer flere byggeartefakter, konfigurerer ruting for hver lokalitet og håndterer omdirigeringer på servernivå. CI-pipelines må ta hensyn til oversettelsesoppdateringer og gjenoppbygge lokaliserte utganger når innhold endres.

En alternativ tilnærming unngår denne kompleksiteten. En omvendt proxy-modell, som Weglot , sitter mellom serveren og nettleseren. Den oversetter innhold på farten og betjener alle språk fra én enkelt distribusjon. Dette fjerner behovet for flere bygg og rutingsregler. Mer om Weglot senere!

Sammenligning av runtime-biblioteker: ngx-translate, Transloco og angular-i18next

Runtime-biblioteker løser et annet problem enn Angulars innebygde i18n. I stedet for å kompilere oversettelser inn i appen, laster de dem inn under kjøring og oppdaterer brukergrensesnittet uten en fullstendig omlasting.

Dette gjør dem bedre egnet når brukere trenger å bytte språk i appen eller når innholdet endres ofte.

ngx-oversett er det mest brukte alternativet. Det støtter umiddelbar språkbytte gjennom oversett.bruk(), med oversettelser lastet inn fra JSON-filer eller API-er. Det fungerer bra i mindre apper og er det eneste alternativet her med bekreftet Ionisk kompatibilitet. SSR er mulig med Overføringsstatus og tilpassede lastere, men det krever oppsett. Nyere versjoner har lagt til et leverandørbasert API, som er bedre tilpasset frittstående komponenter.

Transloco fokuserer på struktur og skalerbarhet. Den tilbyr innebygd SSR-støtte og et ryddigere oppsett med ng add. Den støtter også omfangsrike oversettelser, som lar deg laste språkfiler per funksjon uten å måtte bruke den. Dette reduserer pakkestørrelsen og gjør store apper enkle å vedlikeholde. Språkbytte bruker settAktivtLang() og oppdaterer brukergrensesnittet umiddelbart.

angular-i18next omslutter i18next -økosystemet. Det er nyttig hvis teamet ditt allerede bruker i18next i andre rammeverk og ønsker konsistens på tvers av prosjekter. Det støtter plugins fra i18next-kjernen, inkludert ICU-håndtering. Språkbytte krever vanligvis en ny innlasting, noe som begrenser bruken i apper som forventer umiddelbare oppdateringer.

Her er en mer direkte sammenligning:

Valget avhenger av hvordan appen din håndterer språkendringer og skalering:

• Bruk ngx-translate hvis du trenger et enkelt oppsett eller Ionic-støtte.
• Bruk Transloco for SSR eller store apper med behov for modulære oversettelser.
• Bruk angular-i18next hvis du ønsker justering med i18next på tvers av flere plattformer.

💡 Hvis runtime-svitsjing ikke er nødvendig og du foretrekker minimal klientlogikk, er Angulars innebygde i18n fortsatt det beste alternativet.

Oversettelse av Angular-apper uten kodeendringer

Det finnes et tredje alternativ i tillegg til Angulars innebygde i18n- og runtime-biblioteker: eksterne verktøy for nettstedsoversettelse. Disse verktøyene ligger utenfor Angular-appen og oversetter den gjengitte utdataene i stedet for strenger inne i kodebasen.

Som nevnt, Weglot bruker en omvendt proxy-modell. Den sitter mellom serveren og nettleseren, oppdager HTML-svaret og serverer deretter oversatte versjoner til besøkende. Dette betyr at du ikke merker strenger med i18n, administrerer JSON-oversettelsesfiler eller gjenoppbygger appen for hver språkinnstilling. Oppsettet er raskere fordi oversettelseslaget håndteres utenfor Angular.

Denne tilnærmingen endrer også hvor oversettelsesarbeidet skjer. I stedet for å redigere filer i prosjektet, bruker oversetterne et visuelt dashbord. De kan gjennomgå sider og bruke ordlisteregler uten å berøre maler eller TypeScript. For innholdstunge markedsføringssider kan dette redusere utviklernes involvering.

Språkbytte kan også føles smidigere. Weglot støtter en JavaScript-basert switcher som oppdaterer det synlige språket uten å kreve en fullstendig Angular-gjenoppbyggingsprosess. Det gjør det enklere å lansere flerspråklig innhold raskt.

Avveiningen er kontroll. Fordi oversettelse skjer etter at Angular har gjengitt siden, håndterer ikke denne modellen applogikk som er avhengig av språket i TypeScript. Den er også mindre ideell for Ionic-apper og apper som først og fremst er offline, der innholdet må ligge i selve applikasjonen i stedet for bak en proxy.

SEO avhenger også av oppsettet. Omvendt proxy-oversettelse kan støtte indekserbare oversatte sider, men et enkelt JavaScript snippet alene skaper ikke SEO-vennlige lokaliserte URL-er. Det er viktig hvis organisk søketrafikk er en del av målet.

Denne modellen passer best for team som ønsker flerspråklige sider uten å endre applikasjonskoden. Den er mindre egnet når språk påvirker ruting eller forretningslogikk. Den krever også et aktivt abonnement, siden oversatt innhold forblir knyttet til tjenesten.

Velge riktig Angular i18n-tilnærming

Den riktige tilnærmingen til Angular-internasjonalisering avhenger av hvordan appen din håndterer språk i praksis.

Byggetidsbasert i18n prioriterer ytelse og stabilitet, mens runtime-biblioteker fokuserer på fleksibilitet i brukergrensesnittet. Eksterne verktøy fjerner mesteparten av implementeringsarbeidet, men flytter kontrollen utenfor kodebasen.

Velge @angular/lokalisere når kjøretidsytelse er avgjørende og teamet ditt er komfortabelt med å administrere separate lokaliserte bygg i CI. Det passer best når språkbytte kan skje via navigasjon i stedet for inne i appen.

Velg ngx-translate når brukere trenger å bytte språk uten å måtte laste inn på nytt, og du ønsker et bredt brukt runtime-alternativ. Det passer best her for Ionic-prosjekter og mindre Angular-apper.

Velg Transloco når du trenger runtime-svitsjing pluss en sterkere struktur for større apper. Det passer godt for SSR-oppsett og for team som ønsker begrensede oversettelsesfiler med lav innlasting.

Velge Weglot når målet er et flerspråklig nettsted uten å legge til oversettelseslogikk i Angular-kodebasen. Det er best for innholdslevering og rask utrulling, ikke for apper der TypeScript-oppførselen må endres etter språk.

{{demo-banner}}