i18n vs l10n: jaka jest różnica?

Podobnie jak słynne *sekretne* menu In-N-Out Burger, każda nisza w branży ma swój tajny język, który po jego opanowaniu sprawi, że poczujesz się częścią wyjątkowej grupy. Nie inaczej jest w branży tłumaczeń i lokalizacji. Ponieważ zawsze czuliśmy się nieco gorzej od naszych kolegów matematyków, nasza branża postanowiła umieścić liczby w środku naszych słów kluczowych: i18n i l10n.

Brzmi technicznie i groźnie, prawda?

Okazuje się, że jest to po prostu skrót od internacjonalizacji i lokalizacji .

Internacjonalizacja , czyli i18n (wym. „eye-eighteen-en”), odnosi się do prac inżynieryjnych mających na celu przygotowanie oprogramowania do uruchomienia w dowolnym języku. Odbywa się to poprzez wyciąganie ciągów tekstowych z kodu, obsługę kodowania znaków i tworzenie elastycznego formatowania dat, walut i jednostek. i18n to techniczna praca wykonywana w tle w ramach przygotowań do lokalizacji (l10n), która jest wykonywana dla każdej lokalizacji, dla każdego rynku.

Większość stron wyjaśniających, jakie widzę, jest nieco niejasna, ponieważ traktują one i18n i l10n jako dwa warianty tego samego zadania, a resztę artykułu poświęcają omówieniu bibliotek kodu. To nie jest to samo zadanie. Międzynarodowość to zadanie, które Twój zespół inżynierów wykona, miejmy nadzieję, że tylko raz! Lokalizacja, z drugiej strony, to to, co dzieje się z Twoją witryną za każdym razem, gdy dodajesz rynek, i to ona decyduje, czy wielojęzyczny użytkownik poczuje się mile widziany podczas wizyty, czy też poczuje się, jakby wkroczył w nieznaną dolinę niepokoju, tzn. coś jest nie tak, ale po prostu nie potrafi tego określić.

To rozróżnienie nie jest tylko wynikiem mojej pedantycznej postawy (to na pewno, ale w tym przypadku ma znaczenie dla zespołów zajmujących się lokalizacją!). Stronę internetową można w pełni zinternacjonalizować, a mimo to nadal czytać ją jako „niedostępną” w języku docelowym. Twój zespół starannie zaprojektował przyciski, które można rozszerzyć, aby dostosować je do rozszerzonego tekstu w języku niemieckim, metki cenowe z właściwym symbolem waluty i daty nadrukowane w formacie zrozumiałym dla czytelnika. To już i18n! A co ze zdaniem znajdującym się obok przycisku? Czy brzmi to tak, jakby tekst został napisany przez kogoś, kto rozumie rynek, czy jakby został przepuszczony przez aplikację do tłumaczeń i od razu wrzucony na stronę? To jest zadanie lokalizacji i to ona jest czynnikiem decydującym o tym, czy użytkownik kliknie dalej, czy też postanowi opuścić witrynę.

Co właściwie oznacza i18n

Mówiłem to już wcześniej, ale warto to podkreślić (gra słów zamierzona): internacjonalizacja jest numeronimem. Weź pierwszą literę (i), ostatnią literę (n), policz 18 liter między nimi i voilà , otrzymasz i18n. Ten skrót przyjął się, ponieważ programiści chcieli mieć możliwość wpisania tego słowa bez konieczności powtarzania go pięćdziesiąt razy podczas przeglądu kodu. Stąd l10n dla lokalizacji i a11y dla dostępności, itd.

Ale skrót jest nudną częścią. Ważne jest to, co i18n faktycznie robi.

Proces ten polega na ustrukturyzowaniu bazy kodu w taki sposób, aby obsługiwała dowolny język lub ustawienia regionalne bez konieczności przepisywania:

• Ciągi tekstowe wyciągane z kodu do plików zewnętrznych zamiast zakodowanych na stałe
• Kodowanie UTF-8, dzięki czemu znaki akcentowane i skrypty niełacińskie są wyświetlane poprawnie
• Układ, który nie zakłada, że tekst zawsze czyta się od lewej do prawej
• Formaty daty, liczby i waluty traktowane są jako zmienne, a nie jako stałe założenia

Dobrze zrobione, i18n jest jak woda dla złotej rybki – niewidzialne i niezauważalne (w najlepszym tego słowa znaczeniu).

l10n: część, która nigdy się nie kończy

Jeśli i18n oznacza samochód, to l10n oznacza paliwo. Jeśli zdecydujesz się dodać język francuski, musisz go zlokalizować. Po dodaniu języka japońskiego następuje ponowna lokalizacja. Nie jest to faza, którą wykonujesz, ale powtarzalny proces, dlatego lokalizacja wymaga własnego przepływu pracy, właściciela i zestawu narzędzi, oddzielonych od inżynierii.

Zespół może stworzyć naprawdę zinternacjonalizowany produkt, a mimo to nie sprostać wymaganiom lokalizacji, ponieważ lokalizacja to nie tylko zamiana słów. Może to również obejmować idiom i formalność, a także zamianę obrazów, a nawet subtelne zmiany kolorów!

Gdzie różnica jest widoczna na stronie na żywo

Problemy z formatem to najprostszy sposób, aby zobaczyć i18n i l10n działające oddzielnie.

Weźmy na przykład liczby. W USA tysiąc dolarów i pięćdziesiąt centów zapisuje się jako 1,000.50. W większości krajów europejskich zapisuje się tę samą wartość jako 1.000,50, zamieniając przecinek z kropką. Po przeciwnych stronach pola waluty znajduje się symbol 99.00 dolarów w USA i 99,00 euro w Niemczech. Daty są jeszcze bardziej podzielone. 03/04/2026 oznacza 4th marca w USA i 3rd kwietnia w większości pozostałych krajów, dlatego też stworzono normę ISO 8601 (RRRR-MM-DD), aby uniknąć niejasności, zamiast kłócić się o to w poszczególnych krajach. Kody języków również podlegają pewnemu standardowi: norma ISO 639-1 przypisuje dwuliterowe kody, takie jak de, ja i pt, dzięki czemu system lokalny ma stabilny identyfikator, na podstawie którego może pracować, zamiast zgadywać na podstawie nazwy kraju.

Rozszerzanie tekstu to kwestia, którą zespoły inżynieryjne niedoceniają najbardziej. Własna dokumentacja Phrase'a i18n używa rozmiaru buta jako czytelnej ilustracji: rozmiar brytyjski 10 jest rozmiarem europejskim 38, a rozmiar amerykański 38 to zupełnie inny rozmiar unijny 6. Teraz przetłumacz w ten sam sposób etykietę interfejsu użytkownika, a otrzymasz ten sam rodzaj niezgodności długości słowa. Tekst w języku niemieckim i fińskim jest standardowo o 20 –35 procent dłuższy niż tekst źródłowy w języku angielskim, dlatego przycisk oznaczony „Prześlij” pasuje idealnie, a „Zur Kasse gehen” nie, chyba że układ tekstu został stworzony z elastycznych kontenerów. W przypadku języków arabskiego i hebrajskiego, jako języków RTL (od prawej do lewej), pojawia się zupełnie inny problem: cały układ tekstu jest lustrzany, a nie tylko jego kierunek.

Żadnego z tych problemów nie udało się odpowiednio rozwiązać w czasie tłumaczenia. Powinno to zostać rozwiązane w kodzie, stąd moja determinacja, aby wykonać i18n poprawnie przed rozpoczęciem l10n .

Przebieg pracy: zbuduj swój dom na solidnym fundamencie

W zdrowym środowisku internacjonalizacja ma miejsce raz, a lokalizacja powtarza się w nieskończoność. Wystarczy wyodrębnić ciągi znaków, ustawić kodowanie i utworzyć elastyczne układy za jednym razem. Następnie należy zlokalizować tekst na język francuski. Później lokalizujesz na język japoński. Później pojawił się język arabski, ale już bez ingerencji w podstawową architekturę, ponieważ architektura ta została od początku zaprojektowana tak, aby obsługiwać dowolną lokalizację.

Najczęstszym problemem zespołów jest pominięcie pierwszego kroku i próba dokończenia go w drugim etapie. Wtedy pojawiają się zakodowane na stałe ciągi znaków ukryte na głębokości trzech komponentów oraz selektory dat, które rozumieją tylko formaty MM/DD/RRRR. Ostatecznie projekt tłumaczenia przeradza się w refaktoryzację, której nikt nie planował.

Czy musimy odbudować nasz stos?

Uczestniczyłem w wystarczającej liczbie rozmów handlowych, aby wiedzieć, czego obawia się większość zespołów: „czy musimy odbudować cały nasz stos, aby wykonać to dobrze?” Założenie jest takie, że jeśli witryna nie była od początku zinternacjonalizowana, to właściwa lokalizacja oznaczałaby jej całkowite zniszczenie i przebudowę. W większości przypadków odpowiedź brzmi NIE.

Jeśli warstwa lokalizacji działa na istniejącej witrynie, a nie w jej bazie kodu, wówczas nie ma potrzeby ponownej instalacji. Może trochę zdradzam szczegóły, ale tak właśnie działa Bablic. W większości przypadków w przeglądarce odwiedzającego uruchamia się lekki fragment kodu JavaScript, który w momencie żądania podmienia przetłumaczony tekst na odpowiedni dla danego ustawienia regionalnego, bez konieczności indeksowania ani ponownego tworzenia witryny źródłowej (serwera, na którym faktycznie znajduje się strona).

Obawy dotyczące wydajności, które zwykle pojawiają się w przypadku korzystania z przeglądarki, wiążą się z koniecznością ładowania całego korpusu tłumaczeń przy każdym wyświetleniu strony. Jeśli jest to dla Ciebie naprawdę problematyczne, wybierz narzędzie oferujące buforowanie przed tłumaczeniem, które przechowuje wcześniej przetłumaczony tekst. Dzięki temu przeglądarka nie musi od razu łączyć się z interfejsem API tłumaczeń przy każdym żądaniu.

Pewnie mówisz sobie: „ale mój produkt to natywna aplikacja z głęboko zagnieżdżoną logiką warunkową i bez żadnego rozdziału między ciągami znaków i kodem”... bla, bla, bla. Cóż, to jest problem inżynieryjny, którego nie rozwiąże żadna warstwa po stronie przeglądarki! W takim przypadku należy poszukać rozwiązania z zestawem SDK. Jednak w przypadku witryn marketingowych i sklepów internetowych, których strony były kiedyś tworzone w jednym języku, a teraz muszą obsługiwać pięć rynków, założenie o konieczności przebudowy architektury jest generalnie błędne.

Nie tłumacz bez kontekstu

Strona internetowa może przejść wszystkie i18n kontroli (poprawność waluty i formatu daty), a mimo to nadal wydawać się obca osobie, do której jest adresowana. Klienci potrafią rozpoznać, kiedy przekaz nie trafia w sedno lub jest nieznacznie nietrafiony, a osoby, które to zauważą, nie dokonują konwersji. To jest ta dolina niepokoju, o której wspominałem wcześniej i która naprawdę zabija konwersję.

Zrozumienie i egzekwowanie kontekstu może pomóc rozwiązać ten problem. Po pierwsze, dzięki kontroli nad konkretnymi terminami, takimi jak nazwa Twojej marki czy nazwy własne Twojego produktu, możesz mieć pewność, że kluczowe frazy będą za każdym razem tłumaczone w ten sam sposób, niezależnie od ustawień domyślnych wyszukiwarki. Słownik, który pozwala Ci podejmować takie decyzje, sprawia, że przetłumaczona strona brzmi jak Twoja marka, a nie jak ogólna wersja skierowana do nikogo konkretnego.

Drugą możliwością jest faktyczne przyjrzenie się przetłumaczonej stronie i poprawienie błędów na miejscu, bez konieczności biegłej znajomości języka docelowego, aby wychwycić niezręczną frazę. Edytor kontekstowy pokazuje przetłumaczoną stronę na żywo i umożliwia bezpośrednią edycję, co oznacza, że hiszpańskojęzyczny kolega może w ciągu kilku minut sprawdzić tekst, zamiast aby tłumacz powtarzał wszystko w arkuszu kalkulacyjnym.

W przypadku większości stron tłumaczenie maszynowe (MT) stanowi rozsądny punkt wyjścia. Domyślnymi silnikami Bablic są Google Tłumacz i DeepL, które przetwarzają pierwszy szkic z szybkością, jakiej nie osiągnie żaden zespół ludzki. W przypadku większości firm, z którymi rozmawiamy, te wyszukiwarki, w połączeniu ze słownikiem i wyrywkową kontrolą za pomocą edytora kontekstowego, wystarczą, aby mieć pewność, że witryna jest naprawdę zlokalizowana.

Często zadawane pytania