Sklep wielojęzyczny WordPress brzmi jak jedna wtyczka do zainstalowania i tydzień roboty - to najdroższe złudzenie w całym temacie. Właściciel widzi na stronie producenta zrzut z flagami w menu, dolicza tłumaczenie produktów i planuje, że za miesiąc sprzedaje w Niemczech. Potem okazuje się, że produkty faktycznie są po niemiecku, ale mail z potwierdzeniem zamówienia przychodzi po polsku, w checkoucie dalej stoi pole „Numer NIP”, a regulamin to plik, którego nikt nie tknął.
Drugi język w sklepie to nie warstwa tłumaczeniowa położona na wierzchu. To druga wersja całej ścieżki zakupowej: od karty produktu, przez koszyk, płatność i wysyłkę, po maila po zakupie i formularz zwrotu. Wtyczka załatwia mniejszą część tej roboty. Reszta to decyzje, których żaden kreator za Ciebie nie podejmie.
W tym wpisie przechodzę przez cztery rzeczy, o które pytają mnie klienci wchodzący na drugi rynek: którą wtyczkę wybrać do sklepu, a nie do bloga, co naprawdę trzeba przetłumaczyć, jak ugryźć waluty, podatki i wysyłkę za granicę, oraz ile to kosztuje nie we wdrożeniu, tylko w utrzymaniu. Na koniec mówię wprost, kiedy drugiego języka bym nie robił.
Sklep wielojęzyczny na WordPressie - WPML, Polylang czy Weglot i dlaczego sklep to nie blog
Na rynku są cztery rozwiązania, które realnie widuję u klientów, i dzielą się na dwie rodziny.
WPML i Polylang trzymają tłumaczenia w bazie WordPressa. Każdy produkt po niemiecku to osobny wpis powiązany z polskim oryginałem. Zaleta: wszystko, co czyta bazę, widzi te produkty - eksport do pliku, integracja z ERP, wtyczka kurierska, feed do porównywarki. Wada: baza puchnie, a każdy produkt trzeba świadomie utworzyć w drugim języku. Przy WooCommerce obie wymagają dodatku sklepowego (WPML ma WooCommerce Multilingual, Polylang osobną płatną wersję pod Woo) i bez niego tłumaczenie zatrzymuje się na treściach, a rozsypuje na koszyku.
TranslatePress i Weglot działają inaczej: przechwytują to, co strona wyrenderowała, i podmieniają teksty. Wdrożenie jest szybkie, bo nie duplikujesz wpisów, a tłumaczyć można klikając po żywej stronie. Weglot dodatkowo trzyma tłumaczenia u siebie, w abonamencie rozliczanym od liczby słów. Wada przy sklepie jest konkretna: treści nie ma w bazie, więc integracje i eksporty nadal widzą tylko język oryginalny, a przy rezygnacji z abonamentu wielojęzyczność znika.
Stąd bierze się moja zasada i tytułowe „sklep to nie blog”. Blog ma teksty i obrazki, więc nadpisanie warstwy renderującej wystarcza. Wielojęzyczny sklep WooCommerce ma atrybuty, warianty, ceny, statusy zamówień i dokumenty - to dane, nie tylko treść. Jeśli katalog jest duży albo sklep wisi na integracjach, wybieram rodzinę z tłumaczeniami w bazie. Jeśli produktów jest kilkadziesiąt, a drugi język ma być tanim testem rynku, rozwiązanie nakładkowe jest uczciwym wyborem.
W pytaniu „WPML czy Polylang” różnica jest mniejsza, niż sugerują fora. WPML jest dojrzalszy w obsłudze WooCommerce i ma lepsze narzędzia do zarządzania tłumaczeniami w kolejce. Polylang bywa lżejszy i czytelniejszy w panelu. Obu trzeba pilnować przy aktualizacjach, bo obie wchodzą głęboko w sklep.
Co pomaga: zanim wybierzesz wtyczkę, odpowiedz na jedno pytanie operacyjne - kto w firmie wpisze niemiecki opis do produktu numer trzysta i kiedy. Jeśli nie ma odpowiedzi, wybór wtyczki jest najmniejszym problemem.
Co naprawdę trzeba przetłumaczyć - checkout, maile, atrybuty, dokumenty
To jest miejsce, w którym wdrożenia się sypią. Lista jest dłuższa, niż wygląda z panelu:
- Produkty i kategorie - nazwy, opisy, opisy skrócone, a także adresy (slugi) kategorii i produktów.
- Atrybuty i ich wartości - nie wystarczy przetłumaczyć etykiety „Kolor”. Wartości „Czerwony”, „Granatowy” też są osobnymi wpisami i bez nich filtry pokazują klientowi polskie słowa.
- Warianty - produkt wariantowy ma własne nazwy kombinacji, które lubią zostać po polsku w koszyku.
- Maile transakcyjne - potwierdzenie zamówienia, zmiana statusu, wysyłka, zwrot, reset hasła. Klient dostaje je w momencie największego napięcia, a to zwykle ostatnia rzecz, którą ktoś sprawdza.
- Checkout i komunikaty walidacji - etykiety pól, teksty błędów, nazwy metod płatności i dostawy, zgody pod przyciskiem zakupu.
- Teksty z motywu i wtyczek - „Dodaj do koszyka”, „Brak w magazynie”, nazwy z wtyczki kurierskiej i fakturowej. Tłumaczy się je jako ciągi tekstowe, osobnym narzędziem niż treści.
- Dokumenty - regulamin, polityka prywatności, zwroty i reklamacje, informacja o cookies. To nie jest kopiuj-wklej z translatora, bo dotyczą praw konsumenta w konkretnym kraju. Piszę to jako praktyk od stron, nie prawnik - treść dokumentów potwierdź u prawnika obsługującego ten rynek.
Praktyczna sztuczka przy dużym katalogu: nie tłumacz produktów w panelu jeden po drugim. Wyeksportuj je do pliku, przetłumacz w arkuszu albo w narzędziu tłumaczeniowym i wgraj z powrotem - dokładnie tak, jak opisuję przy imporcie i eksporcie produktów w WooCommerce. Godziny klikania zamieniają się w jeden przebieg importu.
Co pomaga: zrób zakup testowy w drugim języku, za realne pieniądze, na telefonie. Przejdź całą drogę do maila z potwierdzeniem i do faktury. Polskie zdanie wyskoczy tam, gdzie się go nie spodziewasz.
Waluty, VAT OSS, wysyłka i płatności pod drugi rynek
Język to połowa sprawy. Druga połowa to pieniądze i logistyka, a tego żadna wtyczka tłumaczeniowa sama nie ogarnia.
Waluty. Sklep WooCommerce ustawiony na sprzedaż za granicę potrzebuje albo drugiej waluty, albo świadomej decyzji, że zostaje przy jednej. Przeliczanie po kursie z automatu wygląda wygodnie, ale daje ceny z groszówkami, które w drugim kraju wyglądają przypadkowo. Wolę ręcznie ustawione ceny w euro, zaokrąglone jak u lokalnej konkurencji. Wtedy cena jest decyzją handlową, a nie wynikiem tabeli kursów.
Podatki. Przy sprzedaży do konsumentów w Unii po przekroczeniu unijnego progu sprzedaży na odległość rozlicza się VAT według stawki kraju odbiorcy, w procedurze OSS. Po stronie sklepu oznacza to stawki podatku per kraj i pilnowanie, czy cena jest brutto czy netto w każdej z nich. To nie jest porada podatkowa - konfigurację stawek i samą rejestrację w OSS ustal ze swoją księgową, ja odpowiadam za to, żeby sklep policzył to tak, jak ona każe.
Wysyłka. Drugi kraj to osobna strefa, osobne progi darmowej dostawy i inni kurierzy, bo lokalny przewoźnik bywa tam tańszy i lepiej postrzegany. Mechanika jest ta sama co przy sklepie krajowym, opisałem ją przy strefach wysyłki i progach darmowej dostawy, tylko liczby i przewoźnicy inni. Do tego adres zwrotny w tym kraju albo jasna informacja, że zwrot idzie do Polski - to realnie wpływa na decyzję o zakupie.
Płatności. BLIK w Niemczech nie znaczy nic. Tam liczy się przelew natychmiastowy, zakup z odroczoną płatnością i karta; w Holandii bez iDEAL po prostu nie sprzedajesz. Metody płatności dobiera się pod rynek, nie pod przyzwyczajenie z Polski.
Jeśli patrzysz na tę listę i widzisz więcej niż weekend roboty - dobrze widzisz. Tak wygląda uczciwe wejście na drugi rynek i dlatego przy budowie sklepów na WooCommerce traktuję drugi język jako osobny etap projektu, a nie jako opcję w konfiguracji.
Osobna rzecz, której tu celowo nie rozwijam, to hreflang i SEO wersji językowych: struktura adresów, znaczniki mówiące wyszukiwarce, która wersja komu się należy, i unikanie sytuacji, w której dwie wersje biją się o to samo zapytanie. To materiał na osobny wpis, a podstawy widoczności sklepu zebrałem w tekście o pozycjonowaniu sklepu internetowego.
Ile kosztuje wdrożenie i utrzymanie, co robię inaczej
Koszt wdrożenia składa się z czterech pozycji i tylko jedna z nich jest widoczna od razu.
Pierwsza to licencje. Wtyczka wielojęzyczna dla sklepu to zwykle licencja roczna, w wyższym pakiecie niż wersja blogowa, plus często druga licencja na moduł walutowy. Odnawia się co rok, a bez odnowienia zostają aktualizacje, których nie dostajesz - przy wtyczce siedzącej w koszyku to nie jest ryzyko, które bym podejmował. Aktualne ceny sprawdzaj na stronie producenta w dniu zakupu, bo pakiety się zmieniają. Szerzej o tym, jak takie roczne opłaty składają się w budżet sklepu, piszę w tekście o realnych kosztach wtyczek w WooCommerce.
Druga to tłumaczenie treści. Maszynowe z korektą człowieka jest sensownym kompromisem przy opisach produktów. Przy stronach sprzedażowych, dokumentach i mailach transakcyjnych biorę tłumacza, bo tam brzmi się albo wiarygodnie, albo jak spam.
Trzecia to praca wdrożeniowa - konfiguracja, przepięcie atrybutów, ciągi tekstowe z motywu, stawki podatku, strefy wysyłki, testy zakupowe w obu językach.
Czwarta, najczęściej przeoczona, to utrzymanie. Od dnia uruchomienia każdy nowy produkt to dwa wpisy zamiast jednego. Każda promocja to dwa opisy. Każda zmiana w regulaminie to dwie wersje. Każda większa aktualizacja WooCommerce potrafi rozjechać ciągi tekstowe i trzeba je przejrzeć. Do tego dochodzi obsługa klienta w drugim języku, bo ktoś odpisze na maila po niemiecku. To nie jest koszt jednorazowy, tylko stały narzut na całą operację sklepu.
Co robię inaczej niż większość wdrożeń, które potem naprawiam: zaczynam od listy rzeczy do przetłumaczenia i od pytania, kto będzie je utrzymywał, a wtyczkę wybieram dopiero pod tę odpowiedź. Nie tłumaczę bloga na starcie, tylko ścieżkę zakupową, bo to ona sprzedaje. I uruchamiam drugi język na wąskim wycinku katalogu zamiast na całości - jeśli rynek odpowie, rozszerzam.
Co pomaga: policz utrzymanie zanim policzysz wdrożenie. Jeśli utrzymanie drugiego języka nie mieści się w Twoim miesiącu, wdrożenie było najtańszą częścią problemu.
Kiedy drugi język się nie opłaca
Powiem to wprost, bo rzadko kto to mówi: w części sklepów, które oglądam, drugiego języka bym nie robił.
Nie robiłbym go, kiedy nie ma żadnego sygnału popytu z tego rynku - ani zapytań, ani ruchu, ani zamówień, które już jakoś przychodzą mimo polskiej wersji. Wielojęzyczność nie tworzy popytu, tylko obsługuje istniejący. Nie robiłbym go też, kiedy nie ma kto odpisywać na maile w tym języku, bo pierwsza reklamacja obnaża to w jeden dzień. I nie robiłbym go, kiedy marża nie wytrzymuje kosztu wysyłki i zwrotu za granicę, bo wtedy każde zamówienie z sukcesu robi problem.
Tańszy test jest zwykle pod ręką. Jedna dobrze napisana strona po angielsku z formularzem zapytania pokazuje, czy ktokolwiek pyta, i kosztuje ułamek pełnej wielojęzyczności. Sprzedaż przez lokalny marketplace weryfikuje popyt bez ruszania sklepu. Dopiero gdy zaczynają spływać zamówienia, budowanie drugiej wersji sklepu przestaje być zakładem, a staje się obsługą tego, co już jest.
Jest jeszcze pytanie, który język wybrać. Angielski jest wygodny, bo obsługuje wiele rynków naraz, ale w Niemczech, Francji i Czechach konwertuje wyraźnie gorzej niż język lokalny. Jeden dobrze zrobiony język lokalny zwykle bije trzy zrobione po łebkach.
Podsumowanie
Sklep wielojęzyczny na WordPressie to nie wtyczka, tylko druga wersja całej ścieżki zakupowej: produkty, atrybuty, checkout, maile, dokumenty, waluty, podatki i wysyłka. Przy dużym katalogu i integracjach wybieram rozwiązanie trzymające tłumaczenia w bazie, czyli WPML albo Polylang z dodatkiem sklepowym; przy małym katalogu i teście rynku nakładka typu Weglot czy TranslatePress jest uczciwym skrótem. Największy koszt nie siedzi w licencji ani we wdrożeniu, tylko w utrzymaniu dwóch wersji każdej treści przez kolejne lata.
Jeśli zastanawiasz się nad drugim językiem i nie wiesz, czy Twój sklep jest na to gotowy - podeślij mi adres i rynek, na który celujesz. Przejrzę sklep, powiem, które elementy wymagają tłumaczenia, a które przebudowy, i czy w Twoim przypadku drugi język to dobry ruch, czy przedwczesny.
Najczęstsze pytania
WPML czy Polylang do sklepu na WooCommerce? Oba trzymają tłumaczenia w bazie i oba wymagają dodatku pod WooCommerce. WPML jest dojrzalszy w obsłudze sklepu i wygodniejszy przy dużej liczbie produktów, Polylang bywa lżejszy i prostszy w panelu. Przy katalogu liczonym w setkach produktów i przy integracjach z ERP wybieram WPML, przy niewielkim sklepie Polylang w zupełności wystarcza.
Czy mogę przetłumaczyć sklep maszynowo? Opisy produktów tak, pod warunkiem że ktoś to po tłumaczu przeczyta. Maile transakcyjne, checkout, strony sprzedażowe i dokumenty prawne zostawiam człowiekowi, bo to teksty, na których klient ocenia, czy sklep jest poważny. Surowy translator w regulaminie jest widoczny od pierwszego zdania.
Czy potrzebuję osobnej domeny na drugi kraj? Zwykle nie. Podkatalog w tej samej domenie jest najprostszy w utrzymaniu i korzysta z tego, co domena już wypracowała. Osobna domena krajowa ma sens, kiedy budujesz w tym kraju oddzielną markę albo wymaga tego lokalne zaufanie, ale kosztuje osobne SEO od zera.
Ile trwa wdrożenie drugiego języka? Liczy się to w tygodniach, nie w dniach, i decyduje o tym wielkość katalogu oraz liczba wtyczek wpinających się w koszyk. Samo włączenie wtyczki to godziny. Przetłumaczenie katalogu, ciągów z motywu, maili i dokumentów oraz przetestowanie zakupu w obu językach to gros pracy i to ona wyznacza termin.
Masz sklep, w którym coś nie działa tak, jak powinno? Buduję i przebudowuję sklepy internetowe na WooCommerce - od pojedynczej naprawy po przebudowę całej sprzedaży. Opisz, z czym się mierzysz, a odeślę wycenę z zakresem i terminem.