 Cześć! Mam na imię Ewa i pracuję w zespole Google Developer Relations, który zajmuje się edukacją i propagowaniem dobrych praktyk w aplikacjach internetowych. Aby uczcić Międzynarodowy Dzień Języka Ojczystego, staram się nagrać to wideo w całości po polsku. Trzymajcie za mnie kciuki. W tym wideo chcę Wam pokazać jak dodaliśmy funkcję tłumaczenia zawartości strony web.dev na różne języki. Na web.dev możecie znaleźć wiele artykułów i narzędzi, które są pomocne w budowaniu wysokiej jakości interfejsów internetowych. Artykuły, które zamieszczamy na web.dev, są czytane przez programistów z wielu stron świata. Często w trakcie globalnych konferencji lub warsztatów, gdzie omawialiśmy opisywane przez nas zagadnienia, słyszeliśmy pytania i prośby o udostępnienie tych treści także w lokalnym języku. Dzięki temu więcej osób może skorzystać z przekazywanej wiedzy, a osoby niemówiące płynnie po angielsku mogą skupić się na zagadnieniach technologicznych bez pokonywania bariery językowej. Na początek musieliśmy zdecydować, na których językach skupić się w pierwszej kolejności. Wzięliśmy pod uwagę cztery czynniki. Przede wszystkim dane o naszych odwiedzających dostarczane przez Google Analytics. Następnie sprawdziliśmy English Proficiency Index dla interesujących nas krajów. Wzięliśmy też pod uwagę sygnały od naszych społeczności oraz nasze cele biznesowe. Najpierw oczywiście spojrzeliśmy na dane z Google Analytics, aby zobaczyć z jakich krajów i obszarów językowych mamy najwięcej odwiedzających. W Analytics, w zakładce Audiences, Geo Language można wyświetlić i posortować liczbę użytkowników pod względem języka jaki mają ustawiony w przeglądarce. Co ciekawe, przy porównywaniu języków warto wziąć pod uwagę warianty językowe. W naszym przykładzie na pierwszy rzut oka najliczniej reprezentowanym językiem po języku angielskim był język rosyjski. Kiedy jednak wzięliśmy pod uwagę oba warianty języka hiszpańskiego E-S-E-S i E-S 419, to okazało się, że to jednak on dominuje nad rosyjskim. Kolejnym kryterium był English Proficiency Index publikowany przez Organizację Education First. Pokazuje on, w jakim stopniu mieszkańcy danego obszaru są w stanie komunikować się po angielsku. Kraje, gdzie ten wskaźnik był niższy, znalazły się wyżej na liście naszych priorytetów, ponieważ bariera językowa jest tam wyższa niż w obszarach, gdzie co prawda dominuje język inny niż angielski, ale relatywnie dużo osób jest w stanie zrozumieć także teksty napisane po angielsku. Oczywiście wzięliśmy także pod uwagę sygnały płynące od naszych społeczności. Dziękujemy Wam za wszystkie sugestie zgłaszane podczas konferencji i spotkań, a zwłaszcza wszystkim ekspertom Google, który włączyli się w dyskusję o potrzebie internacjonalizacji web.dev. Ostatni z kryteriów to dostosowanie listy języków do naszych celów strategicznych. Stara prawda mówi, że jeżeli zależy ci, aby dotrzeć do jakiejś grupy odbiorczej, postaraj się mówić jej językiem. Kiedy już wybraliśmy kilka języków, na których chcieliśmy się skupić, przyszła pora na implementację techniczną. Wymagała ona dostosowania wszystkich trzech warstw. Etapu build, czyli kompilacji strony, serw, czyli strony serverowej oraz części UI, czyli dodania elementów interfejsu użytkownika. Przede wszystkim musieliśmy zapewnić możliwość wyboru języka przez użytkownika. Wykorzystaliśmy do tego kilka elementów. Użyliśmy na główka accept language wysyłanego przez przeglądarkę. Zawiera on listę języków w kolejności, jaką ustawił użytkownik w ustawieniach przeglądarki. Dzięki temu, jeśli użytkownik ustawy język szpański jako preferowany, możemy automatycznie wysłać mu stronę w tym właśnie języku. Jednak nie wszyscy użytkownicy korzystają z takich ustawień przeglądarki. Dlatego na stronie oferujemy menu do ręcznej zmiany języka. Jest to bardzo prosty custom element na bazie elementu select, który zapisuje preferencję użytkownika za pomocą ciasteczka i przekierowuje go na odpowiednią stronę. Trzecia opcja to uwzględnienie języka bezpośrednio w URL-u danej strony. Na przykład poprzez dodanie ukośnik i18n ukośnik.es możemy wymusić pobranie strony w języku hiszpańskim. Ta opcja jest przydatna, kiedy chcemy się podzielić linkiem do strony w konkretnym języku, niezależnie od ustawień docelowego użytkownika. Na przykład we wpisie na Twitterze. Kolejną częścią infrastruktury było serwowanie treści. Ponieważ korzystamy z hostingu strony opartego o Firebase, ta część układanki była wyjątkowo prosta. Firebase ma wbudowaną obsługę stron w wielu językach. Może odczytać automatycznie język ustawiony w nagłówku accept language lub specjalnym ciasteczku i przekierować użytkownika do odpowiedniego pliku. Tak wygląda przykładowa konfiguracja. Dzięki temu po odpowiednim dostosowaniu naszej struktury plików mogliśmy korzystać z językowych przekierowań Firebase z automatu. No właśnie, kluczem do sukcesu była odpowiednia struktura plików. Była to też najtrudniejsza część do rozwiązania. Cała strona zbudowana jest w oparciu o architekturę Jamstack i w głównej mierze opiera się o generator stron statycznych Eleventy. To znaczy, że treść artykułów jest zapisana w plikach z rozszerzeniem .md, czyli w formacie markdown. Jest to z reguły treść unikalna. Z kolei słowa zawarte w szablonie strony, np. w nagłówku lub w stopce, są powtarzalne i zapisane są w plikach .enjotka, czyli templateach nunchucks. Także słowa pojawiające się w dynamicznych elementach strony, czyli w naszych customowych komponentach webowych, są powtarzalne i zapisane w plikach z JavaScriptem. Każdy z tych rodzajów treści wymagał innego potraktowania. Jeśli chodzi o treść artykułów, to utworzyliśmy osobny folder dla każdego z języków, zgodnie z wymaganiami Firebase. Dzięki temu możemy korzystać z automatycznych przekierowań skonfigurowanych w pliku Firebase.json. Aby przetłumaczyć słowa w templateach nunchucks, utworzyliśmy nową strukturę danych w folderze data. Eleventy wykorzystuje ten folder, aby pobierać dane do budowy strony w czasie kompilacji. Każdy komponent, używany przez Eleventy, dostał swój plik yaml z umieszczonymi w nim tłumaczeniami stringów, używanych przez ten komponent. Następnie w folderze filters umieściliśmy filtr, który integruje informacje zawarte w plikach yaml i pozwala na odczytanie dostępnych tłumaczeń za pomocą klucza. W plikach nunchucks, zamiast nagich stringów, używamy połączenia klucza i parametru lokale, aby uzyskać różne wersje językowe komponentu, umieszczane na docelowych stronach. Dzięki temu, że nasz filtr jest uniwersalny, używamy go analogicznie w naszych komponentach łebowych w JavaScriptie. W ten sposób jesteśmy w stanie wygenerować stronę w każdym z wybranych języków. Jeżeli jakaś treść nie jest dostępna w danym języku, stosujemy zastępczo treść w języku domyślnym, czyli angielskim. Dzięki temu, nawet jeśli nie mamy kompletu tłumaczeń, strona może funkcjonować bez problemu. Jest to ważne zwłaszcza dziś, gdy jest wiele narzędzi do automatycznego tłumaczenia stron. Naszym zdaniem lepiej jest wyświetlić treść po angielsku, którą użytkownik może ewentualnie przetłumaczyć ręcznie używając np. Google Translate, niż nie wyświetlić niczego. Te trzy elementy, komponenty, interfejsy użytkownika, przekierowania za pomocą Firebase oraz system generowania stron oparty o Eleventy stanowią nasz zintegrowany system do wielojęzykowej obsługi strony web.dev. Mamy nadzieję, że nasz zakres obsługiwanych języków i zasięg tłumaczeń będzie się stale rozwijał i przynosił korzyści coraz większej ilości programistów na całym świecie. Jeśli zainteresowałcie nasz projekt, możesz nas znaleźć na GitHubie lub porozmawiać z nami na Twitterze. Zapraszamy. Pozdrawiam serdecznie!