Wyjaśnienie różnic między i18n w Angularze w fazie kompilacji a w fazie wykonywania

Internacjonalizacja w Angularze może przebiegać według dwóch różnych modeli – w czasie kompilacji lub w czasie wykonywania. Oficjalne podejście wykorzystuje @angular/localize, co powoduje, że dla każdego języka generowana jest osobna kompilacja. Takie rozwiązanie jest stabilne i szybkie w czasie wykonywania, ale wymaga zaplanowania wielu wdrożeń i nie pozwala na zmianę języka w trakcie korzystania z aplikacji.

Aby to zrealizować, należy zaznaczyć tekst w szablonach i kodzie TypeScript, wyodrębnić tłumaczenia do osobnych plików, a następnie skompilować jedną wersję aplikacji dla każdego ustawienia regionalnego. Każdy język jest udostępniany pod własnym adresem URL, więc użytkownicy zmieniają język za pomocą nawigacji, a nie przycisku przełączającego wewnątrz aplikacji.

Jeśli potrzebujesz dynamicznego przełączania bez konieczności ponownego ładowania strony, zadanie to przejmują biblioteki uruchomieniowe. Do popularnych rozwiązań należą ngx-translate i angular-i18next. Biblioteki te ładują tłumaczenia na żądanie i natychmiast aktualizują interfejs użytkownika, przy czym wiążą się z różnymi kompromisami w zakresie konfiguracji, wydajności i obsługi SSR.

W niniejszym artykule wyjaśniamy, jak działa wbudowany proces internacjonalizacji (i18n) w Angularze, jak go wdrożyć oraz w jakich sytuacjach lepszym rozwiązaniem jest biblioteka uruchomieniowa.

Jak @angular/localize dzieła

Wbudowana funkcja internacjonalizacji w Angularze opiera się na procesie kompilacji. Tłumaczenia przygotowuje się przed wdrożeniem, a następnie udostępnia się jedną skompilowaną wersję aplikacji dla każdego języka.

Nie ma możliwości zmiany języka w trakcie działania programu, więc konfiguracja skupia się na ekstrakcji i konfiguracji kompilacji.

Przejrzyjmy cały przebieg pracy:

1. Zaznacz tekst do tłumaczenia w szablonach i w TypeScript. W przypadku treści i atrybutów HTML użyj atrybutu i18n, a także $localize w języku TypeScript, dzięki czemu ciągi znaków są uwzględniane w tym samym procesie ekstrakcji.
2. Wyodrębnij komunikaty do pliku tłumaczeniowego za pomocą Angular CLI. Spowoduje to domyślnie wygenerowanie pliku XLIFF; w zależności od konfiguracji dostępne są również opcje innych formatów. Plik ten zawiera identyfikatory komunikatów oraz tekst źródłowy.
3. Przetłumacz wyodrębniony plik i zachowaj spójność identyfikatorów. W razie potrzeby dodaj niestandardowe identyfikatory, aby aktualizacje tekstu źródłowego nie zakłócały istniejących tłumaczeń ani nie powodowały niewidocznych rozbieżności.
4. Stwórz i wdróż jedną wersję aplikacji dla każdego ustawienia regionalnego. Skonfiguruj ustawienia regionalne w pliku angular.json, a następnie wygeneruj pakiety dostosowane do poszczególnych języków, które będą udostępniane z oddzielnych tras lub domen.

Funkcja tworzenia liczby mnogiej wykorzystuje wyrażenia ICU. Użytkownik definiuje takie przypadki, jak na przykład =0, =1, albo inne, a Angular dobiera odpowiednią formę na podstawie aktualnie ustawionego regionu. Języki różnią się pod względem liczby wymaganych form, dlatego warto z wyprzedzeniem zaplanować strukturę komunikatów.

Wykorzystanie zagnieżdżonych wyrażeń ICU opiera się na tym samym schemacie, ale zwiększa złożoność, dlatego należy zadbać o ich czytelność i przetestować je w różnych ustawieniach regionalnych.

Tworzenie i wdrażanie aplikacji Angular obsługujących wiele ustawień regionalnych

W przypadku i18n realizowanego w czasie kompilacji w Angularze wdrożenie jest bezpośrednio powiązane z konfiguracją pliku angular.json. Należy zdefiniować lokalizację źródłową oraz zestaw lokalizacji docelowych, z których każda jest przypisana do pliku tłumaczenia.

Podczas kompilacji Angular kompiluje aplikację tylko raz, a następnie w ramach etapu przetwarzania końcowego stosuje zlokalizowane zamiany. Oznacza to, że nie przeprowadzasz pełnych kompilacji dla każdego języka, ale mimo to otrzymujesz oddzielne pakiety wyjściowe dla każdej lokalizacji.

Każda lokalizacja tworzy własną wersję aplikacji, udostępnianą zazwyczaj w podścieżce lub domenie. W typowej konfiguracji stosuje się ścieżki takie jak /en/ oraz /fr/, przy czym każdy z nich odsyła do odpowiedniego wyniku kompilacji. Taka struktura jest konieczna, ponieważ przetłumaczona treść jest na stałe wbudowana w pliki, więc zmiana języka oznacza załadowanie innej kompilacji.

Konfiguracja serwera staje się częścią procesu wdrażania i18n. Potrzebne są reguły routingu, które przypisują przychodzące żądania do odpowiedniej wersji językowej.

Sposób realizacji różni się znacznie w zależności od środowiska – od surowych reguł przepisywania w Nginx po kilka deklaratywnych wierszy w Firebase Hosting – ale cel pozostaje ten sam. Żądania muszą być kierowane do właściwego, zlokalizowanego pakietu na podstawie struktury adresu URL lub logiki przekierowań.

Angular obsługuje również automatyczne wykrywanie języka podczas renderowania po stronie serwera. Serwer może odczytać ustawienia przeglądarki Accept-Language nagłówek, a następnie przekierować użytkowników do ścieżki odpowiadającej wybranej lokalizacji. Poprawia to wrażenia z pierwszej wizyty, ale nadal powoduje pełne załadowanie strony przy późniejszej zmianie języka.

W trakcie tworzenia aplikacji serwer deweloperski Angular może obsługiwać wiele ustawień regionalnych za pomocą podścieżek. Ułatwia to testowanie, jednak przełączanie się między językami nadal wymaga odświeżenia strony, ponieważ każde ustawienie regionalne stanowi oddzielny wynik kompilacji.

Model ten ma wyraźne konsekwencje dla infrastruktury. Zarządzasz wieloma artefaktami kompilacji, konfigurujesz routing dla każdego ustawienia regionalnego i obsługujesz przekierowania na poziomie serwera. Potoki CI muszą uwzględniać aktualizacje tłumaczeń i ponownie kompilować zlokalizowane wyniki w przypadku zmian treści.

Alternatywne podejście pozwala uniknąć tej złożoności. Model odwrotnego proxy, taki jak Weglot, znajduje się pomiędzy serwerem a przeglądarką. Tłumaczy treści w locie i udostępnia wszystkie wersje językowe z jednego wdrożenia. Eliminuje to konieczność tworzenia wielu kompilacji i reguł routingu. Więcej o Weglot – Weglot !

Porównanie bibliotek uruchomieniowych: ngx-translate, Transloco i angular-i18next

Biblioteki uruchomieniowe rozwiązują inny problem niż wbudowana funkcja i18n w Angularze. Zamiast kompilować tłumaczenia do aplikacji, ładują je w czasie wykonywania i aktualizują interfejs użytkownika bez konieczności pełnego odświeżania strony.

Dzięki temu lepiej sprawdzają się w sytuacjach, gdy użytkownicy muszą zmieniać język w aplikacji lub gdy treść ulega częstym zmianom.

ngx-translate jest najczęściej wybieraną opcją. Umożliwia natychmiastową zmianę języka poprzez trans.use(), z tłumaczeniami ładowanymi z plików JSON lub interfejsów API. Rozwiązanie to sprawdza się dobrze w mniejszych aplikacjach i jest jedyną opcją w tym przypadku, której skuteczność została potwierdzona Jonowy kompatybilność. Sterowanie SSR jest możliwe w przypadku TransferState oraz niestandardowe moduły ładujące, choć wymaga to konfiguracji. W najnowszych wersjach dodano interfejs API oparty na dostawcach, który lepiej współgra z komponentami samodzielnymi.

Transloco koncentruje się na strukturze i skalowalności. Zapewnia wbudowaną obsługę SSR oraz prostszą konfigurację za pomocą polecenia `ng add`. Obsługuje również tłumaczenia w zakresie, co pozwala na opóźnione ładowanie plików językowych w zależności od funkcji. Zmniejsza to rozmiar pakietu i ułatwia utrzymanie dużych aplikacji. Przełączanie języków odbywa się za pomocą setActiveLang() i natychmiast aktualizuje interfejs użytkownika.

angular-i18next stanowi nakładkę na ekosystem i18next. Jest to przydatne rozwiązanie, jeśli Twój zespół korzysta już z i18next w innych frameworkach i zależy mu na spójności między projektami. Obsługuje wtyczki z rdzenia i18next, w tym obsługę biblioteki ICU. Zmiana języka zazwyczaj wymaga ponownego załadowania strony, co ogranicza jego zastosowanie w aplikacjach wymagających natychmiastowych aktualizacji.

A oto bardziej bezpośrednie porównanie:

Wybór zależy od tego, w jaki sposób Twoja aplikacja radzi sobie ze zmianami języka i skalowalnością:

• Jeśli potrzebujesz prostej konfiguracji lub obsługi Ionic, skorzystaj z ngx-translate.
• Wykorzystaj Transloco do obsługi SSR lub dużych aplikacji wymagających modułowego tłumaczenia.
• Jeśli chcesz zapewnić spójność z i18next na wielu platformach, skorzystaj z biblioteki angular-i18next.

💡 Jeśli przełączanie w czasie wykonywania nie jest konieczne, a wolisz minimalną logikę po stronie klienta, wbudowana funkcja i18n w Angularze pozostaje lepszym rozwiązaniem.

Tłumaczenie aplikacji Angular bez wprowadzania zmian w kodzie

Oprócz wbudowanych bibliotek i18n i bibliotek uruchomieniowych Angulara istnieje jeszcze trzecia opcja: zewnętrzne narzędzia do tłumaczenia stron internetowych. Narzędzia te działają poza aplikacją Angular i tłumaczą wyrenderowaną treść, a nie ciągi znaków zawarte w kodzie źródłowym.

Jak już wspomniano, Weglot modelu odwrotnego proxy. Usługa ta znajduje się pomiędzy serwerem a przeglądarką, wykrywa odpowiedź HTML, a następnie dostarcza odwiedzającym przetłumaczone wersje. Oznacza to, że nie trzeba oznaczać ciągów znaków za pomocą i18n, zarządzać plikami tłumaczeń JSON ani przebudowywać aplikacji dla każdego ustawienia regionalnego. Konfiguracja przebiega szybciej, ponieważ warstwa tłumaczeń jest obsługiwana poza środowiskiem Angular.

Takie podejście zmienia również miejsce, w którym odbywa się tłumaczenie. Zamiast edytować pliki w projekcie, tłumacze korzystają z wizualnego panelu kontrolnego. Mogą przeglądać strony i stosować reguły słownika terminologicznego bez ingerowania w szablony czy kod TypeScript. W przypadku stron marketingowych zawierających duże ilości treści może to ograniczyć zaangażowanie programistów.

Zmiana języka może również przebiegać płynniej. Weglot przełącznik oparty na JavaScript, który aktualizuje wyświetlany język bez konieczności przeprowadzania pełnego procesu odbudowy aplikacji w Angularze. Ułatwia to szybkie udostępnianie treści wielojęzycznych.

W zamian za to traci się kontrolę. Ponieważ tłumaczenie odbywa się po wyrenderowaniu strony przez Angular, model ten nie obsługuje logiki aplikacji zależnej od języka w ramach TypeScript. Nie jest to również idealne rozwiązanie dla aplikacji Ionic oraz aplikacji działających w trybie „offline-first”, w których treść musi znajdować się wewnątrz samej aplikacji, a nie za serwerem proxy.

SEO zależy również od konfiguracji. Tłumaczenie za pomocą serwera proxy odwrotnego może zapewnić indeksowalność przetłumaczonych stron, ale snippet prosty snippet kodu JavaScript nie wystarczy do utworzenia zoptymalizowanych pod kątem SEO zlokalizowanych adresów URL. Ma to znaczenie, jeśli jednym z celów jest pozyskanie ruchu z bezpłatnych wyników wyszukiwania.

Ten model najlepiej sprawdza się w przypadku zespołów, które chcą tworzyć wielojęzyczne strony bez konieczności wprowadzania zmian w kodzie aplikacji. Jest on mniej odpowiedni, gdy język ma wpływ na routing lub logikę biznesową. Wymaga on również aktywnej subskrypcji, ponieważ przetłumaczone treści pozostają powiązane z usługą.

Wybór odpowiedniego podejścia do lokalizacji w Angularze

Właściwe podejście do internacjonalizacji w Angularze zależy od tego, w jaki sposób Twoja aplikacja obsługuje języki w praktyce.

Międzyjęzykowość (i18n) na etapie kompilacji kładzie nacisk na wydajność i stabilność, podczas gdy biblioteki uruchomieniowe skupiają się na elastyczności w ramach interfejsu użytkownika. Narzędzia zewnętrzne eliminują większość pracy związanej z implementacją, ale przenoszą kontrolę poza kod źródłowy.

Wybierz @angular/localize gdy wydajność działania aplikacji ma kluczowe znaczenie, a Twój zespół ma doświadczenie w zarządzaniu oddzielnymi, zlokalizowanymi kompilacjami w ramach ciągłego wdrażania (CI). Rozwiązanie to sprawdza się najlepiej, gdy zmiana języka odbywa się poprzez nawigację, a nie wewnątrz samej aplikacji.

Wybierz ngx-translate, jeśli użytkownicy muszą zmieniać język bez konieczności odświeżania strony, a Ty szukasz powszechnie stosowanego rozwiązania po stronie serwera. Jest to najlepsze rozwiązanie w tym przypadku dla projektów Ionic oraz mniejszych aplikacji Angular.

Wybierz Transloco, jeśli potrzebujesz możliwości zmiany języka w czasie wykonywania oraz solidniejszej struktury dla większych aplikacji. To dobre rozwiązanie dla konfiguracji SSR oraz dla zespołów, które chcą korzystać z plików tłumaczeń o ograniczonym zakresie i ładowanych w trybie leniwym.

Wybierz Weglot chcesz stworzyć wielojęzyczną stronę internetową bez konieczności dodawania logiki tłumaczenia do kodu Angular. Rozwiązanie to najlepiej sprawdza się w przypadku udostępniania treści i szybkiego wdrażania, a nie w aplikacjach, w których zachowanie TypeScriptu musi się zmieniać w zależności od języka.

{{baner demonstracyjny}}