Jak dodać wielojęzyczność na stronie. Wybór sposobu (cz. 1. case study)
Marcin Tabaka i Piotr Zieliński
08.01.2020
Planujesz dodać kolejne wersje językowe Twojej strony WWW? Dowiedz się, jak zrobić to krok po kroku. Na przykładzie realnego projektu, którego część, z okazji świąt, wykonaliśmy pro bono na rzecz organizacji charytatywnej.
Dwie wersje językowe serwisu rejestracji na Onkobieg – wersja angielska jeszcze w fazie testów.
Z kolejnych artykułów dowiesz się:
Jak wybrać sposób wdrożenia wielojęzyczności (poniżej).
Zanim zaczniesz dodawać tłumaczenie, zastanów się, jaka metoda najlepiej sprawdzi się na Twojej stronie.
Rozważaliśmy 3 sposoby wdrożenia wielojęzyczności w istniejącym systemie CMS (Systemie Zarządzania Treścią) serwisu rejestracji na Onkobieg. Poznaj zalety i wady każdego z nich.
A. Kopia całej strony
Przebieg:
Skopiowanie kodu źródłowego i bazy danych. Uruchomienie kopii pod innym adresem, a następnie podmiana wszystkich tekstów na inny język.
Zalety:
Prostota. Rozwiązanie najprostsze i najszybsze do wprowadzenia.
Zero zmian w bazie danych. Nie trzeba modyfikować bazy danych – wystarczy wykonać jej kopię.
Łatwość modyfikacji tekstów zaszytych w szablonach (np. informacji w stopce strony). Wystarczy edycja – nie trzeba używać narzędzi do obsługi wielojęzyczności w szablonach.
Zróżnicowana zawartość. Wersje językowe tej samej strony mogą się od siebie różnić – niektóre mogą być bardziej rozbudowane, inne mniej.
Wady:
Oddzielne bazy danych. Bez dodatkowej synchronizacji nie można współdzielić danych między wersjami językowymi. Przykład: konto użytkownika. Jeśli użytkownik założy konto w polskiej wersji strony, to po zmianie języka na angielski, będzie musiał założyć drugie.
Brak powiązania podstron. Utrudnione przełączanie między wersjami językowymi danego zasobu. Przykład: powrót na stronę główną z podstrony. Jeśli użytkownik przegląda jakąś podstronę po polsku, to po zmianie języka na angielski, nie zostanie odesłany do tłumaczenia tej podstrony, tylko na stronę główną (home).
Wyższy koszt utrzymania. Zmiany w systemie (m.in. zmiany w szablonie, zmiany w bazie danych, dodanie nowej funkcji) wykonuje się oddzielnie dla każdej wersji językowej.
B. Tłumaczenia poszczególnych zasobów
Przebieg:
Dodanie nowych pól w bazie dla kolejnych języków (np. tytuł artykułu EN, opis artykułu EN itd.). Tłumaczenie strony poprzez uzupełnianie tych dodatkowych pól treściami w innych językach.
Zalety:
Niewielka ingerencja w architekturę systemu. Zmiana wersji językowej jest możliwa przez dodanie np. jednego globalnego parametru w adresie URL.
Łatwe przełączanie między wersjami językowymi. Każdy zasób w systemie występuje we wszystkich wersjach językowych. To znaczy, że znajomość ID zasobu wystarczy, by pobrać jego dane w innym języku.
Wspólna baza danych. Wszystkie wersje językowe korzystają z jednej bazy danych.
Niższy koszt utrzymania. Każda zmiana w szablonie jest od razu widoczna we wszystkich wersjach językowych.
Wady:
Identyczna zawartość stron. Wersje językowe strony nie mogą się od siebie różnić. To oznacza, że każdy zasób musi zostać przetłumaczony na wszystkie języki.
Utrudniona modyfikacja tekstów zaszytych w szablonach. Należy wydzielić je do plików językowych.
Ograniczona skalowalność. Każda kolejna wersja językowa wymaga dodania kolejnych pól dla każdego zasobu do uzupełniania w panelu administracyjnym.
C. Jeden system obsługujący wiele wersji witryny
Przebieg:
Stworzenie oddzielnych witryn z wersjami językowymi w ramach jednego systemu. Podpięcie każdej z witryn pod osobną domenę, subdomenę lub katalog w domenie głównej. Przypisanie poszczególnych zasobów (np. podstron czy artykułów na blogu) do witryny w danym języku.
Zalety:
Skalowalność. Raz wdrożone rozwiązanie znacznie ułatwia dodawanie kolejnych wersji językowych.
Zróżnicowana zawartość. Wersje językowe tej samej strony mogą się od siebie różnić – niektóre mogą być bardziej rozbudowane, inne mniej. Nie trzeba tłumaczyć całej zawartości strony (w tym np. archiwalnych artykułów na blogu).
Łatwe przełączanie między wersjami językowymi. Baza danych jest współdzielona. Wszystkie wersje językowe danej podstrony mają wspólny identyfikator.
Wspólna baza danych. Wszystkie wersje językowe korzystają z jednej bazy danych.
Niższy koszt utrzymania. Każda zmiana w szablonie jest od razu widoczna we wszystkich wersjach językowych.
Wady:
Znaczna ingerencja w architekturę systemu. Należy przerobić każdy moduł, by jego zasoby były przypisane do konkretnej witryny.
Utrudniona modyfikacja tekstów zaszytych w szablonach. Należy wydzielić je do plików językowych.
Nasz wybór
Onkobieg to serwis rejestracji na wydarzenie biegowe. Pozwala m.in. założyć konto użytkownika, dokonać płatności online i wygenerować kartę startową do druku. Charakter serwisu uniemożliwia uruchomienie jego anglojęzycznej wersji za pomocą oddzielnej bazy danych (sposób A.).
Ostatecznie do wdrożenia wielojęzyczności wykorzystaliśmy rozwiązanie C. – choć bardziej pracochłonne, to skalowalne i niewymagające tłumaczenia strony w 100% (w tym np. archiwalnych wpisów).
Potrzebowaliśmy jeszcze narzędzia do przetłumaczenia treści osadzonych w kodzie źródłowym (np. treści w szablonach, powiadomieniach, komunikatach o błędach). Ponieważ serwis Onkobieg jest napisany we frameworku Laravel, to do tłumaczenia tych treści użyliśmy zestawu funkcji do translacji, wbudowanego w ten framework.
W efekcie rosnąca grupa uczestników Onkobiegu spoza Polski zyska możliwość rejestracji na bieg w języku angielskim. Dzięki wdrożonemu rozwiązaniu, organizator wydarzenia będzie mógł w dowolnym momencie dość łatwo dodawać kolejne wersje językowe.
„Trudno znaleźć tak zaangażowanego partnera jak Sidnet. Znaczną część tłumaczenia strony wykonali bez kosztów, w ramach prezentu świątecznego dla Stowarzyszenia. Jesteśmy za to bardzo wdzięczni!”
