Vysvětlení rozdílu mezi i18n v Angularu při kompilaci a za běhu

Internacionalizace v Angularu může probíhat podle dvou různých modelů – v době kompilace nebo za běhu. Oficiální přístup využívá @angular/localize, což generuje samostatnou sestavu pro každý jazyk. Toto řešení je stabilní a rychlé při běhu, vyžaduje však plánování více nasazení a neumožňuje přepínání jazyků přímo v aplikaci.

K realizaci této funkce označíte text v šablonách a v TypeScriptu, extrahujete překlady do samostatných souborů a poté sestavíte jednu verzi aplikace pro každé jazykové prostředí. Každý jazyk je poskytován z vlastní URL adresy, takže uživatelé přepínají mezi jazyky pomocí navigace, nikoli pomocí přepínače uvnitř aplikace.

Pokud potřebujete dynamické přepínání bez nutnosti znovu načítat stránku, postarají se o to místo toho knihovny běhového prostředí. Mezi oblíbené možnosti patří ngx-translate a angular-i18next. Tyto knihovny načítávají překlady podle potřeby a okamžitě aktualizují uživatelské rozhraní, přičemž se liší v nárocích na nastavení, výkon a podporu SSR.

V tomto článku vysvětlujeme, jak funguje vestavěný pracovní postup internacionalizace (i18n) v Angularu, jak jej nasadit a kdy je vhodnější použít knihovnu pro běhové prostředí.

Jak @angular/localize díla

Integrovaná internacionalizace v Angularu využívá pracovní postup v rámci kompilace. Překlady připravíte ještě před nasazením a poté vydáte jednu zkompilovanou verzi aplikace pro každý jazyk.

V běhu nedochází ke změně jazyka, takže se nastavení zaměřuje na extrakci a konfiguraci sestavení.

Projdeme si celý pracovní postup:

1. Označte text určený k překladu v šablonách a v TypeScriptu. Pro obsah a atributy HTML použijte atribut i18n a použijte $localize v TypeScriptu, takže řetězce jsou zahrnuty do stejného procesu extrakce.
2. Pomocí Angular CLI extrahujte zprávy do překladového souboru. Ve výchozím nastavení se tím vygeneruje soubor ve formátu XLIFF, přičemž v závislosti na vašem nastavení jsou k dispozici i další formáty; soubor obsahuje ID zpráv a zdrojový text.
3. Přeložte extrahovaný soubor a zachovejte identifikátory beze změny. V případě potřeby přidejte vlastní identifikátory, aby aktualizace zdrojového textu nenarušily stávající překlady ani nezpůsobily skryté nesrovnalosti.
4. Vytvořte a nasadte jednu verzi aplikace pro každé jazykové prostředí. Nastavte jazyková prostředí v souboru angular.json a poté vygenerujte jazykově specifické balíčky, které se poskytují prostřednictvím samostatných tras nebo domén.

Při tvorbě množného čísla se používají výrazy ICU. Definujete případy, jako například =0, =1, nebo ostatní, přičemž Angular vybere správnou formu na základě aktuálního jazykového nastavení. Jazyky se liší v tom, kolik forem vyžadují, proto si strukturu zpráv naplánujte v předstihu.

Vnořené výrazy ICU se řídí stejným vzorem, ale zvyšují složitost, proto je třeba dbát na jejich čitelnost a otestovat je v různých jazykových prostředích.

Vývoj a nasazení aplikací Angular s podporou více jazyků

Díky funkci i18n v Angularu, která se provádí při kompilaci, je nasazení přímo závislé na tom, jak nakonfigurujete soubor angular.json. Definujete zdrojové jazykové prostředí a sadu cílových jazykových prostředí, z nichž každé je přiřazeno k překladovému souboru.

Během kompilace Angular aplikaci zkompiluje jednou a poté v rámci následného zpracování provede lokalizované náhrady. To znamená, že neprovádíte úplné kompilace pro každý jazyk, ale přesto nakonec získáte samostatné výstupní balíčky pro každé jazykové prostředí.

Každá lokalita vytváří vlastní verzi aplikace, která je obvykle dostupná z podadresy nebo domény. Běžné nastavení využívá cesty jako například /en/ a /fr/, přičemž každý odkazuje na odpovídající výstup sestavení. Tato struktura je nezbytná, protože přeložený obsah je pevně zakomponován do souborů, a proto změna jazyka znamená načtení jiného sestavení.

Konfigurace serveru se stává součástí nastavení internacionalizace (i18n). Potřebujete pravidla směrování, která přiřadí příchozí požadavky ke správné jazykové verzi.

Implementace se v závislosti na prostředí značně liší – od přímých přepisovacích pravidel v Nginxu až po několik deklarativních řádků ve Firebase Hosting – ale cíl je stejný. Žádosti musí být nasměrovány ke správnému lokalizovanému balíčku na základě struktury URL nebo logiky přesměrování.

Angular také podporuje automatickou detekci jazyka při použití renderování na straně serveru. Server dokáže načíst z prohlížeče Accept-Language hlavičku a poté přesměruje uživatele na odpovídající cestu pro dané jazykové prostředí. To zlepšuje dojem z první návštěvy, ale při pozdějším přepnutí jazyka stále dochází k načtení celé stránky.

Ve vývojovém prostředí může vývojový server Angularu obsluhovat více jazykových verzí pomocí podadresářů. To usnadňuje testování, avšak přepínání mezi jazyky stále vyžaduje obnovení stránky, protože každá jazyková verze představuje samostatný výstup sestavení.

Tento model má zřejmé dopady na infrastrukturu. Spravujete více artefaktů sestavení, konfigurujete směrování pro každé jazykové prostředí a zpracováváte přesměrování na úrovni serveru. Pipeliny CI musí zohledňovat aktualizace překladů a při změnách obsahu znovu sestavovat lokalizované výstupy.

Alternativní přístup tuto složitost eliminuje. Model reverzního proxy, jako je například Weglot, je umístěn mezi serverem a prohlížečem. Obsah překládá za běhu a poskytuje všechny jazykové verze z jediného nasazení. Tím odpadá nutnost vytvářet více verzí a nastavovat směrovací pravidla. O Weglot si povíme více Weglot !

Porovnání runtime knihoven: ngx-translate, Transloco a angular-i18next

Knihovny spouštěcího prostředí řeší jiný problém než vestavěná funkce i18n v Angularu. Namísto kompilace překladů do aplikace je načtou až při spuštění a aktualizují uživatelské rozhraní bez nutnosti úplného obnovení stránky.

Díky tomu se lépe hodí pro situace, kdy uživatelé potřebují v aplikaci přepínat mezi jazyky nebo když se obsah často mění.

ngx-translate je nejčastěji používanou možností. Umožňuje okamžité přepínání jazyků prostřednictvím trans.use(), s překlady načtenými ze souborů JSON nebo z API. Funguje to dobře v menších aplikacích a je to zde jediná možnost s ověřenou Ionic kompatibilita. SSR je možné použít s TransferState a vlastní načítací moduly, i když to vyžaduje nastavení. V nejnovějších verzích bylo přidáno API založené na poskytovatelích, které lépe ladí se samostatnými komponentami.

Transloco klade důraz na strukturu a škálovatelnost. Nabízí vestavěnou podporu SSR a přehlednější konfiguraci pomocí příkazu `ng add`. Podporuje také překlady v rámci konkrétního rozsahu, což umožňuje odložené načítání jazykových souborů podle jednotlivých funkcí. Tím se zmenšuje velikost balíčku a zachovává se přehlednost údržby i u rozsáhlých aplikací. Přepínání jazyků využívá setActiveLang() a okamžitě aktualizuje uživatelské rozhraní.

angular-i18next obaluje ekosystém i18next. Je užitečný, pokud váš tým již používá i18next v jiných frameworkách a chce zajistit jednotnost napříč projekty. Podporuje pluginy z jádra i18next, včetně práce s ICU. Přepínání jazyků obvykle vyžaduje znovu načtení stránky, což omezuje jeho použití v aplikacích, které očekávají okamžité aktualizace.

Zde je přímější srovnání:

Volba závisí na tom, jak vaše aplikace zpracovává změny jazyka a jak je škálovatelná:

• Pokud potřebujete jednoduché nastavení nebo podporu pro Ionic, použijte ngx-translate.
• Pro SSR nebo rozsáhlé aplikace s potřebou modulárního překladu použijte Transloco.
• Pokud chcete zajistit kompatibilitu s i18next napříč různými platformami, použijte angular-i18next.

💡 Pokud není nutné přepínání za běhu a dáváte přednost minimální logice na straně klienta, zůstává vestavěná funkce i18n v Angularu lepší volbou.

Překlad aplikací Angular bez změn v kódu

Kromě vestavěných knihoven Angularu pro internacionalizaci (i18n) a běhové knihovny existuje ještě třetí možnost: externí nástroje pro překlad webových stránek. Tyto nástroje fungují mimo aplikaci Angular a překládají vykreslený výstup, nikoli řetězce v kódu.

Jak již bylo zmíněno, Weglot model reverzního proxy. Je umístěn mezi serverem a prohlížečem, detekuje HTML odpověď a následně návštěvníkům poskytuje přeložené verze. To znamená, že nemusíte označovat řetězce pomocí i18n, spravovat překladové soubory JSON ani znovu kompilovat aplikaci pro každé jazykové prostředí. Nastavení je rychlejší, protože překladová vrstva je zpracovávána mimo Angular.

Tento přístup také mění způsob, jakým se překladatelská práce provádí. Místo úpravy souborů v projektu používají překladatelé vizuální ovládací panel. Mohou kontrolovat stránky a uplatňovat pravidla glosáře, aniž by museli zasahovat do šablon nebo do TypeScriptu. U marketingových webů s velkým množstvím obsahu to může snížit zapojení vývojářů.

Přepínání jazyků může být také plynulejší. Weglot přepínač založený na JavaScriptu, který aktualizuje zobrazený jazyk, aniž by bylo nutné provádět úplnou rekompilaci v Angularu. Díky tomu je snazší rychle spustit vícejazyčný obsah.

Nevýhodou je omezená kontrola. Jelikož k překladu dochází až poté, co Angular stránku vykreslí, tento model nezvládá logiku aplikace, která závisí na jazyku v rámci TypeScriptu. Také se nehodí ideálně pro aplikace Ionic a aplikace typu „offline-first“, kde musí být obsah uložen přímo v samotné aplikaci, nikoli za proxy serverem.

SEO závisí také na nastavení. Překlad pomocí reverzního proxy může podporovat indexovatelné přeložené stránky, ale snippet jednoduchý snippet kódu JavaScriptu nevytvoří lokalizované URL adresy optimalizované pro SEO. To je důležité, pokud je součástí cíle organická návštěvnost z vyhledávačů.

Tento model je nejvhodnější pro týmy, které chtějí mít vícejazyčné stránky, aniž by musely měnit kód aplikace. Je méně vhodný v případech, kdy jazyk ovlivňuje směrování nebo obchodní logiku. Vyžaduje také aktivní předplatné, protože přeložený obsah zůstává vázán na tuto službu.

Výběr správného přístupu k internacionalizaci v Angularu

Správný přístup k internacionalizaci v Angularu závisí na tom, jak vaše aplikace v praxi zachází s jazyky.

Mezinárodní lokalizace (i18n) v rámci kompilace upřednostňuje výkon a stabilitu, zatímco knihovny pro běhové prostředí se zaměřují na flexibilitu v rámci uživatelského rozhraní. Externí nástroje sice odstraňují většinu implementační práce, ale přesouvají kontrolu mimo kódovou základnu.

Vyberte si @angular/localize když je výkon při běhu aplikace klíčový a váš tým si bez problémů poradí se správou samostatných lokalizovaných verzí v rámci CI. Nejlépe se hodí v případech, kdy k přepínání jazyků dochází spíše prostřednictvím navigace než přímo uvnitř aplikace.

Zvolte ngx-translate, pokud uživatelé potřebují přepínat mezi jazyky bez nutnosti znovu načíst stránku a vy hledáte široce používanou možnost pro běhové prostředí. V tomto případě se nejlépe hodí pro projekty v Ionicu a menší aplikace v Angularu.

Zvolte Transloco, pokud potřebujete přepínání za běhu a zároveň robustnější strukturu pro rozsáhlejší aplikace. Je to vhodná volba pro konfigurace SSR a pro týmy, které chtějí překladové soubory s omezeným rozsahem a odloženým načítáním.

Zvolte Weglot je vaším cílem vytvořit vícejazyčný web, aniž byste do kódu Angularu přidávali překladovou logiku. Hodí se zejména pro poskytování obsahu a rychlé nasazení, nikoli však pro aplikace, kde je třeba přizpůsobit chování TypeScriptu podle jazyka.

{{demo-banner}}