Internacjonalizacja i lokalizacja witryn statycznych

Internacjonalizacja i lokalizacja to coś więcej niż pisanie treści w wielu językach. Potrzebujesz strategii, aby określić, jaką lokalizację wysłać, i kodu, aby to zrobić. Musisz być w stanie obsługiwać nie tylko różne języki, ale różne regiony w tym samym języku. Twój interfejs użytkownika musi reagować nie tylko na rozmiar ekranu, ale także na różne języki i tryby pisania. Twoja treść musi być ustrukturyzowana, aż do mikrokopii w interfejsie użytkownika i formatu twoich dat, aby można ją było dostosować do dowolnego języka, który na nią rzucisz. Robienie tego wszystkiego za pomocą statycznego generatora witryn, takiego jak Eleveny, może jeszcze bardziej utrudnić, ponieważ możesz nie mieć bazy danych, a mimo to serwera. To wszystko można jednak zrobić, ale wymaga to planowania.

Tworząc chromeOS.dev, wiedzieliśmy, że musimy udostępnić go globalnej publiczności. Upewnienie się, że nasza baza kodu może obsługiwać wiele lokalizacji (język, region lub kombinację tych dwóch) bez konieczności kodowania każdego z nich, przy jednoczesnym umożliwieniu tłumaczenia przy jak najmniejszej wiedzy tego systemu, miałoby kluczowe znaczenie dla tworzenia to się zdarzyło. Nasi twórcy treści musieli być w stanie skoncentrować się na tworzeniu treści, a nasi tłumacze na tłumaczeniu treści przy jak najmniejszym nakładzie pracy, aby wprowadzić swoją pracę do witryny i wdrożyć. Właściwe załatwienie tych czasami sprzecznych potrzeb jest sednem tego, co jest potrzebne do internacjonalizacji baz kodu i lokalizacji witryn.

Internacjonalizacja (i18n) i lokalizacja (l10n) to dwie strony tego samego medalu. Internacjonalizacja polega na tym, jak w naszym przypadku oprogramowanie jest projektowane tak, aby można je było dostosować do wielu języków i regionów bez konieczności wprowadzania zmian inżynieryjnych. Z drugiej strony lokalizacja polega na faktycznym dostosowaniu oprogramowania do tych języków i regionów. Internacjonalizacja może dotyczyć całego stosu witryn; od HTML, CSS i JS do rozważań projektowych i budowania systemów. Lokalizacja dotyczy głównie tworzenia treści (zarówno długich kopii, jak i mikrokopii) oraz zarządzania.

Uwaga : dla ciekawskich i18n i l10n to rodzaje skrótów znane jako numeronimy. A11y, dla dostępności, jest kolejnym powszechnym numerem w tworzeniu stron internetowych.

Internacjonalizacja (i18n)

Określając internacjonalizację, zazwyczaj należy wziąć pod uwagę trzy kwestie: jak dowiedzieć się, jakiego języka i/lub regionu chce użytkownik, jak upewnić się, że otrzymuje treści w preferowanej lokalizacji oraz jak dostosować witrynę, aby dostosować się do te różnice. Chociaż specyfika implementacji może ulec zmianie w przypadku witryn dynamicznych (które renderują stronę na żądanie użytkownika) i witryn statycznych (w których strony są budowane przed wdrożeniem), podstawowe koncepcje powinny pozostać takie same.

Określanie języka i regionu użytkownika

Pierwszą rzeczą do rozważenia przy ustalaniu internacjonalizacji jest określenie, w jaki sposób użytkownicy mają uzyskiwać dostęp do zlokalizowanej zawartości. Ta decyzja stanie się podstawą konfiguracji innych systemów, dlatego ważne jest, aby podjąć tę decyzję wcześnie i upewnić się, że kompromisy będą działać dobrze dla użytkowników.

Ogólnie rzecz biorąc, istnieją trzy ogólne sposoby określania, jaka lokalizacja ma służyć użytkownikom:

1. Lokalizacja z adresu IP;
2. Accept-Language nagłówek lub navigator.languages ​​;
3. Identyfikator w adresie URL.

Wiele systemów kończy się łączeniem jednego, dwóch lub wszystkich trzech, decydując, jaką lokalizację obsługiwać. Jednak w trakcie sprawdzania wykryliśmy problemy z używaniem adresów IP i nagłówków Accept-Language , które naszym zdaniem były wystarczająco istotne, aby je usunąć z naszych rozważań:

• Preferowany język użytkownika często nie jest powiązany z jego fizyczną lokalizacją, którą zapewnia adres IP. To, że ktoś fizycznie znajduje się na przykład w Ameryce, nie oznacza, że ​​woli treści w języku angielskim.
• Analiza lokalizacji z adresów IP jest trudna, generalnie zawodna i może uniemożliwić indeksowanie witryny przez wyszukiwarki.
• Nagłówki Accept-Language często nigdy nie są jawnie ustawiane i zawierają tylko informacje o języku, a nie o regionie. Ze względu na swoje ograniczenia może to być pomocne przy wstępnym zgadywaniu języka, ale niekoniecznie jest wiarygodne.

Z tych powodów zdecydowaliśmy, że byłoby dla nas lepiej, gdybyśmy nie próbowali wnioskować o języku lub regionie przed przejściem użytkownika do naszej witryny, ale raczej mieli mocne wskaźniki w naszych adresach URL. Posiadanie silnych wskaźników pozwala nam również założyć, że uzyskują witrynę w języku, którego chcą, z samego adresu URL dostępu, zapewnia łatwy sposób bezpośredniego udostępniania zlokalizowanej treści bez obawy o przekierowanie i zapewnia czysty sposób, abyśmy mogli pozwolić użytkownicy zmieniają preferowany język.

Istnieją trzy typowe wzorce budowania identyfikatorów w adresach URL:

1. Podaj różne domeny (zwykle TLD lub subdomeny dla różnych regionów i języków (np. example.com i example.de , en.example.org i de.example.org );
2. Mieć zlokalizowane podkatalogi dla treści (np. example.com/en i example.com/de );
3. Wyświetlaj zlokalizowane treści na podstawie parametrów adresu URL (np. example.com?loc=en i example.com?loc=de ).

Chociaż parametry adresu URL są powszechnie używane, generalnie nie są zalecane, ponieważ użytkownikom trudno jest rozpoznać lokalizację (wraz z szeregiem problemów z analizą i zarządzaniem). Uznaliśmy również, że różne domeny nie są dla nas dobrym rozwiązaniem; nasza witryna jest progresywną aplikacją internetową, a każda domena, w tym domeny TLD i subdomeny, są uważane za inne pochodzenie, co w praktyce wymaga oddzielnego PWA dla każdej lokalizacji.

Zdecydowaliśmy się użyć podkatalogów, co zapewniło nam możliwość lokalizacji tylko na język ( example.com/en ) lub język i region ( example.com/en-US i example.com/en-GB ) w razie potrzeby utrzymywanie jednego PWA. Zdecydowaliśmy również, że każda lokalizacja naszej witryny będzie znajdować się w podkatalogu, dzięki czemu jeden język nie będzie wyższy niż inny, oraz że wszystkie adresy URL, z wyjątkiem podkatalogu, będą identyczne we wszystkich lokalizacjach w oparciu o język tworzenia, umożliwiając użytkownikom łatwą zmianę lokalizacje bez konieczności tłumaczenia adresów URL.

Udostępnianie zlokalizowanej treści

Po ustaleniu strategii określania języka i regionu użytkownika potrzebny jest sposób na niezawodne dostarczanie mu odpowiedniej treści. Będzie to wymagało co najmniej jakiejś formy przechowywanych informacji, czy to w pliku cookie, jakiejś lokalnej pamięci, czy jako część niestandardowej logiki aplikacji. Możliwość zachowania preferencji lokalizacyjnych użytkownika jest ważną częścią doświadczenia użytkownika i18n; jeśli użytkownik stwierdził, że chce treści w języku niemieckim i trafia na treści w języku angielskim, powinieneś być w stanie zidentyfikować preferowany język i odpowiednio go przekierować. Można to zrobić na serwerze, ale rozwiązanie, które wybraliśmy dla chromeOS.dev, jest niezależne od hostingu i konfiguracji serwera: użyliśmy pracowników usług. Podróż użytkownika wygląda następująco:

• Użytkownik wchodzi na naszą stronę po raz pierwszy. Nasz pracownik serwisu nie jest zainstalowany.
• Niezależnie od lokalizacji, na której się znajdą, ustawiamy jako preferowany język w IndexedDB. W tym celu zakładamy, że trafiają tam za pośrednictwem mediów społecznościowych, odesłań lub wyszukiwania, które skierowały ich na podstawie innych kontekstów lokalizacji, których nie mamy. Jeśli użytkownik wyląduje bez ustawionej lokalizacji, ustawiamy ją na angielski, ponieważ jest to podstawowy język naszej witryny. W stopce mamy również przełącznik języka, aby umożliwić użytkownikowi zmianę języka. W tym momencie powinien zostać zainstalowany nasz pracownik serwisu.
• Po zainstalowaniu usługi Service Worker przechwytujemy wszystkie żądania adresów URL w celu nawigacji w witrynie. Ponieważ nasze lokalizacje są oparte na podkatalogach, możemy łatwo zidentyfikować żądaną lokalizację. Po zidentyfikowaniu sprawdzamy, czy żądana strona znajduje się w zlokalizowanym podkatalogu, czy zlokalizowany podkatalog znajduje się na liście obsługiwanych lokalizacji oraz czy zlokalizowany podkatalog odpowiada ich preferencjom przechowywanym w IndexedDB. Jeśli nie znajduje się w zlokalizowanym podkatalogu lub zlokalizowany podkatalog odpowiada ich preferencjom, obsługujemy stronę; w przeciwnym razie wykonujemy przekierowanie 302 od naszego pracownika serwisu w celu uzyskania właściwej lokalizacji.

Dołączyliśmy nasze rozwiązanie do wtyczki Workbox, Service Worker Internationalization Redirect. Wtyczkę, wraz z jej podmodułem preferencji, można łączyć, aby ustawić i uzyskać preferencje językowe użytkownika oraz zarządzać przekierowaniami w połączeniu z metodą registerRoute Workboksa i filtrowaniem żądań na request.mode === 'navigate' .

Pełny, minimalny przykład wygląda tak:

Kod klienta

 import { preferences } from 'service-worker-i18n-redirect/preferences'; window.addEventListener('DOMContentLoaded', async () => { const language = await preferences.get('lang'); if (language === undefined) { preferences.set('lang', lang.value); // Language determined from localization user landed on } });

Kod pracownika serwisu

 import { StaleWhileRevalidate } from 'workbox-strategies'; import { CacheableResponsePlugin } from 'workbox-cacheable-response'; import { i18nHandler } from 'service-worker-i18n-redirect'; import { preferences } from 'service-worker-i18n-redirect/preferences'; import { registerRoute } from 'workbox-routing'; // Create a caching strategy const htmlCachingStrategy = new StaleWhileRevalidate({ cacheName: 'pages-cache', plugins: [ new CacheableResponsePlugin({ statuses: [200], }), ], }); // Array of supported localizations const languages = ['en', 'es', 'fr', 'de', 'ko']; // Use it for navigations registerRoute( ({ request }) => request.mode === 'navigate', i18nHandler(languages, preferences, htmlCachingStrategy), );

Dzięki połączeniu kodu po stronie klienta i kodu Service Worker preferowana lokalizacja użytkownika zostanie automatycznie ustawiona, gdy po raz pierwszy trafią na witrynę, a jeśli przejdą do adresu URL, który nie znajduje się w ich preferowanej lokalizacji, zostaną przekierowany.

Dostosowywanie interfejsu użytkownika witryny

Prawidłowe dostosowanie interfejsów użytkownika wymaga wiele, więc chociaż nie wszystko zostanie tutaj omówione, istnieje kilka bardziej subtelnych rzeczy, którymi można i należy zarządzać programowo.

Cytaty blokowe

Powszechnym wzorcem projektowym jest umieszczanie cudzysłowów w cudzysłowie, ale czy wiesz, co jest używane dla tych cudzysłowów, zależy od lokalizacji? Zamiast sztywno kodować, użyj open-quote i close-quote , aby upewnić się, że używane są prawidłowe cytaty dla właściwego języka.

Format daty i liczby

Zarówno daty, jak i liczby mają metodę .toLocaleString , która umożliwia formatowanie na podstawie lokalizacji (języka i/lub regionu). Przeglądarki obsługujące te są dostarczane ze wszystkimi dostępnymi lokalizacjami, dzięki czemu można z nich łatwo korzystać, ale Node.js tego nie robi. Na szczęście moduł full-icu dla Node pozwala na wykorzystanie wszystkich dostępnych danych lokalizacyjnych. W tym celu po zainstalowaniu modułu uruchom swój kod ze zmienną środowiskową NODE_ICU_DATA ustawioną na ścieżkę do modułu, np NODE_ICU_DATA=node_modules/full-icu .

Informacje meta HTML

Istnieją trzy obszary w tagu HTML i nagłówkach, które należy aktualizować w każdej lokalizacji:

• język strony,
• kierunek pisania,
• Alternatywne języki, w których dostępna jest strona.

Jako pierwszy przechodzi do elementu html z odpowiednio właściwościami dir i lang , np. <html lang="en" dir-"ltr"> dla angielskiego amerykańskiego. Właściwe ich ustawienie zapewni przepływ treści we właściwym kierunku i pozwoli przeglądarkom zrozumieć, w jakim języku jest strona, umożliwiając dodatkowe funkcje, takie jak tłumaczenie treści. Powinieneś również dołączyć linki rel="alternate" , aby wyszukiwarki wiedziały, że strona została w pełni przetłumaczona, więc umieszczenie <link href="/es" rel="alternate" hreflang="es"> na naszej angielskiej stronie docelowej niech wyszukiwarki wiedzą, że to ma tłumaczenie, którego powinny szukać.

Wewnętrzny projekt

Lokalizacja treści może stanowić wyzwanie projektowe, ponieważ różne tłumaczenia będą zajmować różną ilość miejsca na stronie. Niektóre języki, takie jak niemiecki, mają dłuższe słowa, wymagające większej przestrzeni w poziomie lub bardziej wyrozumiałego zawijania tekstu. Inne języki, takie jak arabski, mają wyższe kroje pisma, które wymagają więcej miejsca w pionie. Na szczęście istnieje wiele narzędzi CSS, dzięki którym odstępy i układ są responsywne nie tylko na rozmiar widocznego obszaru, ale także na zawartość, co oznacza, że ​​lepiej dostosowują się do wielu języków.

Istnieje wiele jednostek CSS zaprojektowanych specjalnie do pracy z treścią. Istnieją jednostki em i rem reprezentujące odpowiednio obliczony rozmiar czcionki i główny rozmiar czcionki. Zamiana wartości w px o stałym rozmiarze dla tych jednostek może znacznie poprawić reakcję witryny na jej treść. Następnie jest jednostka ch , reprezentująca rozmiar w wierszu glifu 0 (zero) w czcionce. Pozwala to na powiązanie takich rzeczy, jak na przykład width , bezpośrednio z treścią, którą zawiera.

Jednostki te można następnie połączyć z istniejącymi, potężnymi narzędziami CSS do tworzenia układu, w szczególności flexboxem i siatką, z komponentami, które dostosowują się do ich rozmiaru, a układy dostosowują się do ich zawartości. Ulepszenie tych, które mają logiczne właściwości dla granic, marginesów i dopełnienia zamiast fizycznych właściwości fizycznych, sprawia, że ​​te układy i komponenty automatycznie dostosowują się również do trybu pisania. Siła wewnętrznego projektowania stron internetowych (stworzona przez Jen Simmons, jednostki zorientowane na treść i właściwości logiczne) pozwalają na projektowanie i budowanie interfejsów tak, aby można je było dostosować do dowolnego języka, a nie tylko do dowolnego rozmiaru ekranu.

Lokalizacja (l10n)

Najbardziej oczywistą formą lokalizacji jest tłumaczenie treści z jednego języka na inny. W bardziej subtelnych formach tłumaczenia odbywają się nie tylko według języka, ale regionu, w którym się mówi, na przykład angielski używany w języku amerykańskim w porównaniu z angielskim używanym w Wielkiej Brytanii, Afryce Południowej lub Australii. Aby odnieść sukces tutaj, zrozumienie, co przetłumaczyć i jak ustrukturyzować treść do tłumaczenia, ma kluczowe znaczenie dla sukcesu.

Strategia treści

Niektóre części projektu oprogramowania są ważne do zlokalizowania, a inne nie. Nazwy klas CSS, zmienne JavaScript i inne miejsca w bazie kodu, które są strukturalne, ale nie są skierowane do użytkownika, prawdopodobnie nie muszą być zlokalizowane. Ustalenie, co należy zlokalizować i jak to ustrukturyzować, sprowadza się do strategii treści.

Strategia treści ma wiele definicji, ale w tym przypadku chodzi o strukturę treści, mikrokopie (słowa i frazy użyte w całym projekcie niezwiązane z konkretną treścią) oraz ich powiązania. Aby uzyskać bardziej szczegółowe informacje na temat strategii treści, polecam Content Strategy for Mobile autorstwa Karen McGrane oraz Designing Connected Content autorstwa Carrie Hane i Mike'a Athertona.

W przypadku chromeOS.dev skończyliśmy skodyfikować modele treści, które opisują strukturę naszych treści. Modele treści nie są przeznaczone tylko do długich treści podobnych do artykułów; model treści powinien istnieć dla każdego podmiotu, którego użytkownik może chcieć od Ciebie, takiego jak autor, dokument, a nawet zasoby multimedialne wielokrotnego użytku. Dobre modele zawartości obejmują fragmenty lub fragmenty, które można indywidualnie adresować, większego fragmentu koncepcyjnego, z wyłączeniem fragmentów, które są stycznie powiązane lub do których można się odwoływać z innego modelu zawartości. Na przykład model treści dla posta na blogu może zawierać tytuł, tablicę tagów, odniesienie do autora, datę publikacji i treść posta, ale nie powinien zawierać ciągu znaków oznaczającego bułkę tartą ani nazwisko i zdjęcie autora, które powinno być jego własnym modelem treści. Modele treści nie zmieniają się z lokalizacji na lokalizację; są strukturą witryny. Instancja modelu treści jest powiązana z lokalizacją i te instancje można zlokalizować.

Modele treści obejmują jednak tylko część tego, co należy zlokalizować. Reszta — przyciski „Czytaj więcej”, tytuł „Menu”, tekst wyłączenia odpowiedzialności — to wszystko jest mikrokopia. Mikrokopia też potrzebuje struktury. Chociaż tworzenie modeli treści może wydawać się naturalne, zwłaszcza w przypadku witryn opartych na szablonach, modele mikrokopiowania są zwykle mniej oczywiste i często są przypadkowo pomijane, zapisując to, co jest potrzebne bezpośrednio w szablonie.

Tworząc modele treści i mikrokopii oraz egzekwując je — za pomocą systemu zarządzania treścią, lintingu lub recenzji — możesz upewnić się, że lokalizacja może skoncentrować się na lokalizacji.

Lokalizuj wartości, a nie klucze

Modele zawartości i mikrokopii zwykle generują struktury podobne do obiektów w bazie kodu; czy to wpisy bazy danych, obiekt JSON, YAML czy Front Matter. Nie lokalizuj kluczy obiektowych! Jeśli Twoja mikrokopia wyszukiwania tekstu znajduje się w obiekcie microcopy pod adresem microcopy.search.text , nie umieszczaj jej w obiekcie microcopie pod adresem microcopie.chercher.texte . Klucze w modułach powinny być traktowane jako identyfikatory niezależne od lokalizacji, dzięki czemu można ich niezawodnie używać w szablonach wielokrotnego użytku i można na nich polegać w całej bazie kodu. Oznacza to również, że klucze obiektów nie powinny być wyświetlane użytkownikom końcowym jako zawartość lub mikrokopia.

Konfiguracja strony statycznej

W przypadku chromeOS.dev jako generatora statycznych witryn użyliśmy Eleventy (11ty) z Nunjucks, ale te zalecenia dotyczące konfigurowania statycznego generatora witryn powinny mieć zastosowanie do większości statycznych generatorów witryn. Jeśli coś jest konkretne, zostanie wywołane.

Struktura folderów

Statyczne generatory witryn, które kompilują się w oparciu o strukturę folderów, są szczególnie dobre w obsłudze metody podkatalogów i18n. 11ty obsługuje również kaskadę danych z danymi globalnymi i sposób generowania stron z danych poprzez paginację, więc połączenie tych trzech koncepcji daje podstawową strukturę folderów, która wygląda następująco:

 . └── pages ├── _data ├── _generated └── {{locale-code}} ├── {{locale-code}}.11tydata.js ├── _data └── [...content]

Na najwyższym poziomie znajduje się katalog do przechowywania stron witryny, zwany tutaj pages . Wewnątrz znajduje się folder _data zawierający globalne pliki danych. Ten folder jest ważny, gdy mowa o pomocnikach w następnej kolejności. Następnie jest folder _generated . Mamy wiele stron, które zamiast mieć własną treść, są generowane z istniejącej treści, niewielkich ilości mikrokopii lub kombinacji obu. Pomyśl o stronie głównej, stronie wyszukiwania lub stronie docelowej sekcji bloga. Ponieważ te strony są wysoce szablonowe, przechowujemy szablony w folderze _generated i budujemy je z tego miejsca, zamiast mieć dla każdego osobne pliki HTML lub Markdown. Te foldery są poprzedzone podkreśleniem, aby wskazać, że nie wyświetlają stron bezpośrednio pod nimi, ale raczej służą do tworzenia stron w innym miejscu.

Następnie podkatalogi l10n! Każdy katalog powinien mieć nazwę odpowiadającą znacznikowi językowemu BCP47 (częściej kodowi regionalnemu) dla lokalizacji, którą zawiera: na przykład en dla angielskiego lub en-US dla amerykańskiego angielskiego. W bazie kodu chromeOS.dev często określamy je również jako locales . Te foldery staną się podkatalogami lokalizacji, segmentując zawartość do lokalizacji. Kaskada danych 11ty pozwala na dostęp do danych dla każdego pliku w katalogu i jego dzieci, jeśli plik znajduje się w katalogu głównym i ma taką samą nazwę jak katalog (nazywane plikami danych katalogu). 11ty używa obiektu zwróconego z tego pliku lub funkcji, która zwraca obiekt i wstrzykuje go do zmiennych udostępnionych do tworzenia szablonów, dzięki czemu mamy tutaj dostęp do danych dla całej zawartości tej lokalizacji.

Aby pomóc w utrzymaniu tych plików, napisaliśmy pomocnika o nazwie l10n-data , część naszego rusztowania dla witryny statycznej, która wykorzystuje tę strukturę folderów do budowania kaskady zlokalizowanych danych, co pozwala na fragmentaryczną lokalizację danych. Robi to poprzez przechowywanie danych w katalogu danych specyficznym dla ustawień regionalnych, w katalogu _data (ładowanym do pliku danych katalogu). Jeśli na przykład zajrzysz do naszego katalogu danych lokalizacji w języku angielskim, zobaczysz modele mikrokopii, takie jak locale.json , które definiują kod języka i kierunek pisania, które zostaną następnie wyrenderowane do naszego kodu HTML, newsletter.yml , który definiuje mikrokopię wymaganą dla naszego subskrypcję biuletynu oraz plik microcopy.yml , który zawiera ogólną mikrokopię używaną w wielu miejscach w witrynie, która nie pasuje do bardziej szczegółowego pliku. Wszędzie, gdzie jakakolwiek z tych mikrokopii zostanie wykorzystana, wyciągamy ją z danych udostępnionych przez 11-tysięczne wstrzykiwanie zmiennych danych do naszych szablonów w celu użycia.

Mikrokopia wydaje się być najtrudniejsza do zarządzania, podczas gdy reszta treści jest w większości prosta. Umieść swoją zawartość, często pliki Markdown lub HTML, w zlokalizowanym podfolderze. W przypadku generatorów witryn statycznych, które działają ze strukturą folderów, nazwa pliku i struktura folderów zawartości zazwyczaj mapują 1:1 na końcowy adres URL dla tej zawartości, więc plik Markdown pod adresem en/web/pwas.md będzie wyprowadzany na adres URL en/web/pwa . Kierując się naszą zasadą lokalizacji „wartości, a nie klucze”, zdecydowaliśmy, że nie będziemy lokalizować nazw plików treści (a tym samym ścieżek), co ułatwi nam śledzenie stanu lokalizacji tego samego pliku w różnych lokalizacjach i ułatwi użytkownikom śledzenie znajdują się na właściwej stronie między różnymi lokalizacjami.

Pomocnicy I18n

Oprócz treści i mikrokopii stwierdziliśmy, że musimy napisać szereg modułów pomocniczych, aby ułatwić pracę ze zlokalizowaną treścią. 11ty ma koncepcję zwaną filtrem, która umożliwia modyfikowanie treści przed renderowaniem. Skończyło się na zbudowaniu czterech z nich, aby pomóc w szablonowaniu i18n.

Pierwszy to filtr dat. Ustandaryzowaliśmy, aby wszystkie daty w naszej treści były zapisywane jako wartości daty YAML, ponieważ zapisujemy je głównie w YAML i stają się one dostępne w naszych szablonach jako pełny znacznik czasu UTC. W przypadku korzystania z modułu full-icu i konfiguracji ciąg daty (zmieniana treść) wraz z kodem ustawień regionalnych renderowanej treści można przekazać bezpośrednio do Date.toLocaleString (z opcjonalnymi opcjami formatowania) w celu renderowania zlokalizowanej daty. Date.toLocaleDateString można opcjonalnie użyć zamiast tego, jeśli chcesz tylko część daty, gdy nie są przekazywane żadne opcje formatowania, zamiast pełnej zlokalizowanej daty i godziny.

Drugi filtr to coś, co nazwaliśmy localURL . Pobiera lokalny adres URL (treść jest zmieniana) i ustawienia regionalne, w których powinien znajdować się adres URL, i zamienia je. Zmienia na przykład /en/linux na /es/linux .

Ostatnie dwa filtry dotyczą pobierania zlokalizowanych informacji z samego kodu ustawień regionalnych. Trzeci wykorzystuje moduł iso-639-10 do przekształcenia kodu lokalizacji na nazwę języka w języku ojczystym. Używamy tego głównie w naszym selektorze języka. Czwarty używa modułu iso-i18n-countries do pobrania listy krajów w tym języku. Używamy go głównie do tworzenia formularzy z listami krajów.

Oprócz filtrów, 11ty posiada koncepcję o nazwie kolekcje, która jest grupowaniem treści. 11ty domyślnie udostępnia pewną liczbę kolekcji, a nawet może budować kolekcje z tagów. W wielojęzycznej witrynie stwierdziliśmy, że chcemy tworzyć niestandardowe kolekcje. Skończyło się na budowaniu szeregu funkcji pomocniczych do budowania kolekcji opartych na lokalizacji. Pozwala nam to na wykonywanie takich czynności, jak posiadanie kolekcji tagów specyficznych dla lokalizacji lub kolekcji sekcji witryny bez konieczności filtrowania w naszych szablonach całej zawartości naszej witryny.

Naszym ostatnim i najważniejszym pomocnikiem były globalne dane naszej witryny. Opierając się na strukturze podkatalogów opartej na kodzie lokalnym, ta funkcja dynamicznie określa, jakie lokalizacje obsługuje witryna. Tworzy zmienną globalną site , która zawiera właściwość l10n , zawierającą całą zawartość mikrokopii i specyficzną dla lokalizacji z {{locale-code}}.11tydata.js . Zawiera również właściwość languages zawierającą listę wszystkich dostępnych ustawień regionalnych w postaci tablicy. Na koniec funkcja wyprowadza plik JavaScript szczegółowo opisujący, jakie języki są obsługiwane przez witrynę i poszczególne pliki dla każdego wpisu w {{locale-code}}.11tydata.js , z kluczem według lokalizacji, wszystkie zaprojektowane do importowania przez nasze skrypty przeglądarki. Ciężkie obciążenie tego pliku wiąże naszą statyczną witrynę z naszym front-endowym JavaScriptem, a jedynym źródłem prawdy są informacje o lokalizacji, których już potrzebujemy. Pozwala nam również programowo generować strony na podstawie naszych lokalizacji przez pętlę przez site.l10n . To, w połączeniu z naszymi kolekcjami specyficznymi dla lokalizacji, pozwala nam używać paginacji 11ty do tworzenia zlokalizowanych stron głównych i stron docelowych wiadomości bez konieczności utrzymywania osobnych stron HTML dla każdej z nich.

Wniosek

Uzyskanie właściwej internacjonalizacji i lokalizacji może być trudne; zrozumienie, w jaki sposób różne strategie i wpływają na złożoność, ma kluczowe znaczenie dla ułatwienia. Wybierz strategię i18n, która jest naturalnie dopasowana do statycznych witryn i podkatalogów, a następnie zbuduj na jej podstawie narzędzia do automatyzacji części i18n i i10n z tworzonej treści. Twórz solidne modele treści i mikrokopii. Wykorzystaj pracowników serwisu do lokalizacji niezależnej od serwera. Połącz to wszystko w projekt, który reaguje nie tylko na rozmiar ekranu, ale także na zawartość. W końcu będziesz mieć witrynę, którą pokochają Twoi użytkownicy we wszystkich lokalizacjach, którą autorzy i tłumacze mogą prowadzić tak, jakby była to prosta witryna z jedną lokalizacją.