Chcesz dodać angielską wersję strony albo sklepu? Super. Tylko nie zaczynaj od kliknięcia przełącznika z flagą, bo właśnie wtedy często zaczyna się cyfrowy bigos: polskie produkty, angielski nagłówek, koszyk z komunikatem po polsku i adresy, z których trudno wywnioskować, co właściwie oglądamy.
Strona wielojęzyczna WordPress to nie tylko tłumaczenie kilku tekstów. Trzeba zaplanować adresy URL, powiązanie wersji, zakres tłumaczeń, a w sklepie także ceny, waluty, płatności, dostawę, e-maile i feedy produktowe. Poniżej znajdziesz konkretną checklistę, która pomoże poukładać polską i angielską wersję bez późniejszego polowania na brakujące komunikaty.
Na start: drugi język to nie przełącznik z flagą
Najpierw ustal, co naprawdę oznacza angielska wersja. Czasem chodzi tylko o prezentację firmy dla osób anglojęzycznych. Innym razem firma chce sprzedawać na konkretnym rynku. To dwie różne sytuacje, choć na ekranie zaczynają się podobnie.
W pierwszym wariancie potrzebujesz przede wszystkim spójnych treści i wygodnego przełączania między wersjami. W drugim dochodzą kwestie rynku: waluta, ceny, podatki, metody płatności, dostawa i czas realizacji. Nie ma jednego ustawienia, które załatwia wszystko. Zakres zależy od liczby rynków, wielkości katalogu i używanych integracji.
Język strony a rynek sprzedaży
Angielski język nie zawsze oznacza automatycznie sprzedaż do wszystkich anglojęzycznych klientów. Warto więc przed wdrożeniem odpowiedzieć sobie na proste pytanie: czy zmieniamy tylko język, czy również sposób obsługi zamówienia?
W sklepie WooCommerce samo dodanie drugiego języka nie tłumaczy automatycznie produktów ani nie konfiguruje walut. Dlatego plan powinien obejmować nie tylko strony informacyjne, ale też cały proces zakupowy. Jeśli tego nie ustalisz na początku, później każdy brakujący element będzie wyskakiwał jak królik z kapelusza.
Adresy URL: katalog, subdomena czy osobna domena?
Tak — każda wersja językowa powinna mieć własny, bezpośrednio dostępny adres URL. Google rekomenduje różne adresy dla różnych wersji językowych, zamiast opierania całej obsługi na cookies, ustawieniach przeglądarki albo zmianie treści niewidocznej w adresie.
Do wyboru są między innymi trzy modele: katalog językowy, subdomena albo osobna domena. Katalog oznacza język zapisany w ścieżce adresu, subdomena oddziela wersję językową na początku adresu, a osobna domena tworzy dla niej niezależny adres. Każdy wariant może mieć sens, ale wybór powinien wynikać z rynków docelowych, skali projektu i tego, jak łatwo da się później utrzymywać treści.
Jak wybrać strukturę, którą da się utrzymać
Najgorszy wybór to taki, którego nikt nie chce później pilnować. Przed wdrożeniem ustal strukturę adresów i trzymaj się jej dla stron, kategorii oraz produktów. Przełącznik języka powinien prowadzić użytkownika do odpowiadającej podstrony, a nie tylko zmieniać tekst w tym samym, niejasnym adresie.
Warto też zostawić użytkownikowi dostęp do wszystkich wersji. Automatyczne przekierowanie wyłącznie na podstawie języka przeglądarki może utrudniać korzystanie ze strony i dostęp robotów do poszczególnych wersji. Lepiej pozwolić odwiedzającemu wybrać język, niż urządzać mu cyfrową ruletkę.
Hreflang po ludzku: co robi i czego nie załatwia
Hreflang to informacja dla Google, że konkretne adresy są powiązanymi wersjami językowymi albo regionalnymi tej samej strony. Dzięki temu wyszukiwarka łatwiej rozumie, który wariant może pasować do użytkownika. To jednak sygnał, nie gwarancja pozycji ani obietnica wyświetlenia wybranej wersji.
Przy osobnych adresach URL każda wersja powinna wskazywać siebie oraz pozostałe powiązane wersje. Alternatywne adresy muszą być pełnymi URL-ami z protokołem. Informacje hreflang można przekazywać przez HTML, nagłówki HTTP albo mapy witryn. Nie chodzi więc o ręczne wpisywanie jednego magicznego fragmentu kodu za każdym razem, lecz o spójne powiązanie wersji.
Co trzeba sprawdzić przed publikacją
Przed startem przejdź przez odpowiadające sobie strony. Polska strona usługi powinna wskazywać angielską wersję tej samej usługi, a nie stronę główną. Tak samo produkt powinien być powiązany z jego tłumaczeniem, nie z przypadkową kategorią.
- Czy polska wersja wskazuje angielską, a angielska polską?
- Czy wskazane adresy są pełnymi URL-ami?
- Czy przełącznik prowadzi do właściwej, odpowiadającej podstrony?
- Czy wszystkie wersje są dostępne bez wymuszania przekierowania?
Hreflang nie naprawi złego tłumaczenia, pustej strony ani niekompletnego sklepu. Pomaga uporządkować relacje między wersjami, ale reszta nadal musi działać po ludzku.
Plan polsko-angielskiego sklepu WooCommerce
Polska i angielska wersja sklepu wymaga decyzji, czy angielski jest tylko drugim językiem, czy także obsługą konkretnego rynku. Jeśli to drugi rynek, trzeba ustalić jego zasady przed publikacją katalogu. Inaczej klient zobaczy angielski opis, ale nie będzie wiedział, w jakiej walucie zapłaci, ile potrwa dostawa i jakie opcje płatności są dostępne.
Zacznij od powiązania produktów, kategorii, atrybutów i wariantów między wersjami. Potem określ ceny, walutę, podatki, metody płatności, wysyłkę i czas dostawy. Te ustawienia mogą zależeć od rynku, dlatego nie traktuj ich jako automatycznego skutku dodania języka. Kwestie prawne i podatkowe przy sprzedaży zagranicznej wymagają osobnej konsultacji.
Sklep, który działa w dwóch językach
Przydatna będzie zwykła tabela kontrolna. Nie musi wyglądać jak projekt lotu na Marsa. Wystarczy, że przy każdym elemencie pokażesz, co jest gotowe, dla jakiego rynku i kto pilnuje aktualizacji.
| Element | Co ustalić | Status |
|---|---|---|
| Produkt i kategoria | Powiązanie wersji oraz kompletność tłumaczenia | Do uzupełnienia |
| Rynek | Język, waluta, ceny, dostawa i płatności | Do ustalenia |
| Feed produktowy | Czy produkt jest przetłumaczony dla danego języka | Do sprawdzenia |
W feedzie produktowym dla konkretnego rynku mogą pojawić się tylko produkty przetłumaczone na jego język. Niepełny katalog nie jest więc wyłącznie problemem redakcyjnym. Może oznaczać, że część produktów nie trafi do danego feedu. Sprawdź też, czy koszty wysyłki są zgodne z walutą ceny produktu w feedzie.
Co przetłumaczyć poza kartą produktu?
Opis produktu to dopiero początek. Sklep mówi do klienta w wielu miejscach, także wtedy, gdy nikt nie nazywa tego „treścią”. Jeśli przetłumaczysz kartę produktu, ale koszyk i płatność zostaną po polsku, użytkownik szybko zauważy, że zaplecze nie nadążyło za witryną.
Mapa wszystkich miejsc, w których mówi sklep
Przejdź przez sklep tak, jak robi to klient: od menu, przez kategorię i produkt, aż po zakup oraz wiadomość po transakcji. Sprawdź między innymi:
- nazwy, opisy, slugi, adresy URL, kategorie, atrybuty i warianty produktów;
- menu, etykiety przycisków, koszyk i checkout;
- komunikaty błędów, dostępności, płatności i wysyłki;
- regulamin, politykę prywatności oraz informacje o dostawie;
- e-maile transakcyjne i teksty generowane przez motyw oraz dodatki.
Część komunikatów zapisanych wcześniej w ustawieniach WooCommerce, na przykład nazwy metod dostawy lub płatności, może wymagać ręcznego uzupełnienia. Nie zakładaj też, że automatyczne tłumaczenie dobrze odda terminologię branżową, komunikaty błędów i zasady zakupów. Tu warto przejść całą ścieżkę i sprawdzić każdy ekran.
Najczęstsze miny i cyfrowy bigos
Najczęstszy błąd polega na uznaniu projektu za gotowy, gdy działa sam przełącznik języka. To trochę jak otwarcie sklepu z szyldem po angielsku, ale z kasą, paragonem i instrukcją obsługi po polsku.
Problemem bywa też automatyczne przekierowanie według języka przeglądarki. Może utrudniać dostęp do wszystkich wersji użytkownikom i robotom. Kolejna mina to brak wzajemnych powiązań między odpowiadającymi stronami oraz częściowo przetłumaczony katalog.
Błędy, które wychodzą dopiero przy zakupie
Testuj nie tylko stronę główną. Przejdź w obu językach przez kategorię, produkt, koszyk, checkout, płatność, dostawę i e-mail po zakupie. Sprawdź komunikaty błędów oraz informacje o dostępności. W sklepie wielojęzycznym problemy często wychodzą dopiero wtedy, gdy klient próbuje zrobić dokładnie to, po co przyszedł: kupić.
Nie zapomnij o utrzymaniu. Jeśli produkt zmieni cenę, opis albo warianty, trzeba wiedzieć, kto aktualizuje polską i angielską wersję. Bez takiego planu strony zaczną się rozjeżdżać, a cyfrowy bigos będzie tylko większy.
Krótka checklista przed publikacją
Na koniec przejdź przez krótką listę.
Co musi być ustalone przed startem
- Czy każda wersja językowa ma własny, bezpośrednio dostępny adres URL?
- Czy przełącznik prowadzi do odpowiadającej podstrony w drugim języku?
- Czy hreflang jest kompletny, wzajemny i oparty na pełnych adresach URL?
- Czy przetłumaczono produkty, kategorie, atrybuty, menu, checkout, komunikaty, polityki i e-maile?
- Czy ustalono rynek, walutę, ceny, podatki, płatności, wysyłkę i feedy produktowe?
- Czy przetestowano zakup oraz wiadomości wysyłane po transakcji?
- Czy wiadomo, kto aktualizuje obie wersje i sprawdza zgodność używanych rozszerzeń?
Dobrze zaplanowana strona wielojęzyczna WordPress zaczyna się od struktury adresów, zakresu tłumaczeń i decyzji dotyczących rynku, a nie od przypadkowego przełącznika języka. Hreflang pomaga uporządkować powiązania wersji, ale nie zastępuje kompletnego katalogu, sprawnego checkoutu ani testów całej ścieżki zakupowej. Jeśli potraktujesz temat jak projekt do utrzymania, a nie jednorazowe „dodaj angielski”, unikniesz wielu niespodzianek. Masz stronę, sklep albo materiały graficzne, które proszą się o ogarnięcie? Napisz do INB Marketing i zobaczymy, co da się z tym sensownie zrobić.
