Jak przetłumaczyć stronę na dziesięć języków: mój system z WordPress, Polylang, własną wtyczką i dużą ilością AI

Jednym z najprostszych sposobów na zdobycie większego ruchu organicznego jest przetłumaczenie strony.

To logiczne: więcej URL-i, więcej intencji wyszukiwania; jeśli treść jest dobra, przynosi więcej ruchu.

Jasne, zrobienie tego z AI wydaje się łatwe. I takie jest na małych stronach.

Na średnich i dużych stronach sprawa się komplikuje, przynajmniej jeśli próbujesz zrobić to dobrze.

Bo nie chodzi tylko o wzięcie artykułu po hiszpańsku, wklejenie go do ChatGPT i poproszenie o pięć wersji. 

To nadaje się do testu, ale prawdziwa strona ma kategorie, tagi, SEO, obrazy, pola niestandardowe, linki wewnętrzne, menu, strony archiwów, strony główne, slugi, daty, hreflang i strukturę redakcyjną. 

Nie mówiąc już o tym, że w każdym artykule są pogrubienia, listy i kursywy, które najlepiej zachować w tłumaczeniu.

I wszystko musi być przetłumaczone.

To, co zrobiłem w tym tygodniu na mojej stronie, to zbudowanie systemu do przejścia ze strony po hiszpańsku na stronę wielojęzyczną w dziesięciu językach: angielskim, francuskim, portugalskim, włoskim, niemieckim, niderlandzkim, szwedzkim, polskim i norweskim, przy użyciu wtyczki Polylang, własnej wtyczki i kilku spersonalizowanych GPTs.

Efekt jest taki, że mam już stronę w dziesięciu językach, z całą strukturą kategorii i tagów oraz kilkoma opublikowanymi artykułami już przetłumaczonymi.

I z systemem, który dodaje od 5 do 10 minut dodatkowej pracy do każdego artykułu po hiszpańsku, aby mieć go przetłumaczonego na te dziesięć języków, co wydaje mi się więcej niż rozsądne.

Opowiadam cały proces, gdybyś chciał go powtórzyć.

1. Początkowy problem: tłumaczenie artykułów nie wystarczało

Kiedy zacząłem analizować rozwój, odkryłem, że w moim przypadku, poza samymi artykułami, musiałem przetłumaczyć to wszystko:

• Kategorie.
• Tagi.
• Slugi.
• Metaopisy.
• Tytuły SEO.
• Obrazy wyróżniające.
• Teksty alternatywne.
• Pola ACF.
• Bloki wewnętrzne.
• Linki między artykułami.
• Strony archiwów.
• Stałe teksty motywu.
• Moduły strony głównej.
• CTAs.
• Formularze.
• Spisy treści.
• Powiązane artykuły.
• Zachować daty i noty.
• …

Dużo copy w tym wszystkim i zbyt wiele języków, żeby robić to jeden po drugim.

Ale trzeba było to przetłumaczyć, bo jeśli którykolwiek z tych elementów zostaje po hiszpańsku, tłumaczenie zostaje zrobione tylko w połowie.

Dlatego celem nie było „tłumaczenie treści”, ale stworzenie kompletnej i skalowalnej architektury wielojęzycznej, na wypadek gdybym jutro chciał dodać więcej języków.

I tak właśnie się stało: zacząłem tylko od pięciu (angielski, portugalski, francuski, niemiecki i włoski), a pozostałe cztery dodałem po drodze. Przy okazji sprawdziłem, że system pozwala mi skalować tyle, ile potrzebuję.

2. Baza: WordPress, Polylang i kopia lokalna

Projekt wychodzi od strony WordPress z motywem Genesis, własnym projektem w stylu magazynu i kilkoma spersonalizowanymi szablonami.

Ponieważ było to coś o pewnej skali i wymagało wielu testów, pracowałem na lokalnej kopii z użyciem LocalWP. Chodziło o to, żeby móc psuć rzeczy bez strachu, testować importy, sprawdzać taksonomie i zweryfikować, że Polylang dobrze łączy każde tłumaczenie.

Swoją drogą, użyłem tej wtyczki jako bazy, bo już generuje wszystko, co potrzebne do posiadania strony w kilku językach. Na jej podstawie stworzyłem swoją wtyczkę, uzupełniając ją i dostosowując do tego, czego potrzebowałem: szybkiego tworzenia struktury strony i artykułów w kilku językach.

Również w tej pierwszej fazie zoptymalizowałem LocalWP bo na początku środowisko działało zbyt wolno i potrzebowałem miejsca, w którym mogłem płynnie eksportować, importować, usuwać, powtarzać i walidować..

3. System: własna wtyczka plus GPTs

Mógłbym użyć standardowego rozwiązania do automatycznego tłumaczenia, ale cel był inny.

Proste tłumaczenie każdego posta

W tłumaczeniu postów byłem BARDZO ambitny, bo chciałem systemu, w którym GPTs stworzone do tego tłumaczyłyby treść każdego posta, zachowując:

• Mój styl osobisty.
• Tę samą strukturę oryginalnego artykułu.
• Oficjalne tytuły filmów, seriali lub książek w każdym języku (czyli jeśli dzieło jest po hiszpańsku, tłumaczenie miało użyć tytułu, pod którym ukazało się na przykład we Włoszech.
• Czyste slugi.
• Alt obrazów przetłumaczone.
• Yoast z w pełni przetłumaczonymi polami, w tym description.
• Niestandardowe pola ACF, tak abym mógł wybrać, czy są eksportowane czy nie, czy są tłumaczone, czy zostają takie, jakie były (jak na przykład ocena, którą daję każdemu dziełu w moich recenzjach).
• Fragmenty HTML bez ich psucia: listy, pogrubienia, bloki kodu… żeby pozostały i żeby potrzebne części zostały nieprzetłumaczone (jak skrypty kodu).
• Linki wewnętrzne artykułów: żeby wskazywały na URL każdego języka, a nie zawsze na oryginał.
• Data publikacji: trzeba zachować oryginalną datę posta po hiszpańsku.

Jak widzisz, logika za tym wszystkim to nie „przetłumaczyć i już”. Za tym stoi dużo testów, a nawet kilka odrzuceń, jak schema które na razie jest tylko po hiszpańsku.

I dodatkowo chciałem, żeby to był darmowy system, z użyciem GPTs zamiast API OpenAI lub Claude. Bardziej ręczny, ale tańszy.

Rozwiązanie, które przyjąłem, obejmuje te kroki:

1. Publikuję artykuł po hiszpańsku w zwykły sposób.
2. Używam mojej wtyczki do eksportu ustrukturyzowanego JSON, który zawiera całą treść posta podzieloną do tłumaczenia.
3. GPT tłumaczy ten JSON na dziewięć języków, zwracając mi dziewięć JSON-ów (po jednym na język).
4. Wtyczka importuje dziewięć przetłumaczonych JSON-ów.
5. Polylang łączy każde tłumaczenie z oryginałem.
6. Artykuły są generowane jako szkice.
7. Sprawdzam i/lub publikuję.
8. Naprawiam linki wewnętrzne (automatycznie), jeśli to konieczne.

Dodatkowo był pierwszy krok: stworzenie struktury w kilku językach. Robi się to tylko za pierwszym razem, gdy pojawiają się nowe języki, co w moim przypadku zdarzyło się dwa razy: najpierw dla pięciu początkowych języków, a potem dla pozostałych czterech.

Jeśli pominiemy to pierwsze zadanie jednorazowy, proces, który zaprojektowałem, dodaje około pięciu minut więcej do przygotowania każdego posta tylko tyle, jednocześnie mnożąc użyteczną treść mojej strony przez dziewięć.

Nieźle.

Struktura wielojęzyczna

Zobaczmy:

• Strona maksymalnie spersonalizowana.
• Z copy interfejsu.
• Strona główna, która przechowywała prawie wszystkie swoje teksty w kodzie.
• 23 kategorie i podkategorie, z nagłówkami modułów, wieloma copy w polach na miarę i zmiennymi SEO.
• 24 tagi o podobnych cechach.
• Kilka modułów na miarę.
• Wtyczki, które domyślnie nie pozwalają na wielojęzyczność.

I nie wiem, czy czegoś jeszcze nie pomijam.

To wszystko trzeba było przetłumaczyć raz na każdy język. I zajęłoby mi to, nie wiem, co najmniej cztery godziny w każdym przypadku. I to zakładając, że znałbym wszystkie te języki, a tak nie jest.

Nie ma mowy.

Co zrobiłem?

No więc taki proces:

1. Dostosować wszystkie copy do zmiennych, w kodzie i w custom fields ACF..
2. Stworzyć funkcję we wtyczce, która eksportuje wszystkie te zmienne każdej kategorii lub tagu do JSON.
3. Stworzyć GPT, który tłumaczy ten JSON na język, którego potrzebuję.
4. Dodać importer we wtyczce, który pobiera przetłumaczony JSON i tworzy pełną strukturę taksonomii w nowym języku.
5. Powtórzyć proces z każdym językiem.
6. Zmienić teksty, które zostały do zrobienia.

Było kilka punktów, które dały mi w kość, jak slugi w taksonomiach, ponieważ podstawowy Polylang nie pozwala tworzyć dwóch takich samych slugów (tylko Pro).

Czyli tag “comic” po hiszpańsku nie mógł być utworzony jako “comic” po angielsku, tylko musiał być “comic-en” albo podobnie.

Rozwinąłem wtyczkę tak, aby na to pozwalała, zachowując dominio.com/comic po hiszpańsku i dominio.com/en/comic po angielsku.

Yaarp (wtyczka, której używałem do powiązanych artykułów) też sprawiała problemy, więc ją wyłączyłem, bo polecała artykuły w innych językach. Prawdopodobnie w przyszłości stworzę jej funkcję, która będzie priorytetowo traktować język nad resztą zmiennych w rekomendacjach.

Tę subskrypcję listy w innych językach też odrzuciłem na start. Być może w przyszłości zdecyduję się wysyłać mój newsletter przetłumaczony, ale na razie nie będę tego robił, więc nie utworzyłem nowych list w Acumbamail.

4. Już istniejąca treść: krok po kroku

Wszystko, co ci opowiedziałem, działa świetnie dla nowych artykułów, ale co z ponad dwustoma, które mam już opublikowane?

Chciałbym powiedzieć, że stworzyłem funkcję, która automatyzuje ich tłumaczenie, ale tak nie jest.

Najdalej doszedłem do stworzenia funkcji, która generuje mi JSON eksportowane w partiach po kilka artykułów, ale gdy próbowałem tłumaczyć kilka artykułów naraz na dziewięć języków, GPT radzi sobie gorzej. Więc na razie jeden po drugim.

Biorąc pod uwagę, że zajmuje mi to około trzech minut na artykuł, dość łatwo mogę przetłumaczyć dziesięć dziennie, co sprawiłoby, że w mniej niż miesiąc miałbym całą stronę w dziesięciu językach.

To mi pasuje.

Myślałem też o postawieniu sobie Hermes i sprawdzeniu, czy zrobi to ręcznie, ale ponieważ na razie mi się nie spieszy i to nie daje mi pieniędzy, wolę nie wydawać na tokeny więcej niż trzeba.

Rezultat

Na razie jestem zadowolony. Mam już ponad dziesięć artykułów przetłumaczonych na dziesięć języków. To znaczy, że moja strona urosła o 33% w tydzień.

Na razie nie wymuszam żadnej indeksacji. Chcę poczekać, aż będę miał co najmniej 50 albo 60 artykułów. Ale jeśli się zaindeksują, też mnie to nie martwi. To jest długoterminowe.

To, co mogę ci powiedzieć, to że jestem zadowolony z rezultatu. 

Myślę, że system, który zbudowałem, jest całkiem solidny — z prawdopodobnymi ulepszeniami, jasne — ale nawet w najśmielszych snach sprzed około roku nie wyobrażałem sobie, że będę zarządzał wielojęzyczną stroną z taką ilością treści.

Teraz, jak zawsze mówię, zobaczymy, dokąd mnie to wszystko zaprowadzi.

Wnioski z procesu i podsumowanie

Główny wniosek — którego już się spodziewałem — jest taki, że tłumaczenie strony z AI nie polega na „tłumaczeniu tekstów”, tylko na zaprojektowaniu systemu.

AI jest super przydatna, jeśli dostaje czyste dane wejściowe i zwraca kontrolowane wyniki. Ale jeśli dasz jej ogromny blok, bez struktury i bez reguł, zwróci coś ładnego, ale nienadającego się do importu.

Uwierz mi, zdarzało mi się to często na początku.

Kluczem było zbudowanie systemu, w którym każda część robi to, co ma robić:

• WordPress jest sercem wszystkiego.
• Polylang wiąże treści.
• Wtyczka eksportuje i importuje.
• GPT tłumaczy.
• Ja podejmuję decyzje redakcyjne.

Jasne określenie, gdzie pasuje każdy element i dlaczego robi właśnie to, a nie coś więcej, pozwoliło mi stworzyć realny system do skalowania strony przy użyciu tłumaczenia z AI jako dźwigni.

Jeśli spodobał ci się mój system i chcesz, żebym wyjaśnił jakiś punkt, zostaw pytania w komentarzu, a odpowiem.