# Tłumaczenie WordPressa z pomocą AI: szybko, tanio i bez frustracji z WPML – nasz kompletny workflow > URL: https://4eck-media.de/pl/blog/tlumaczenie-wordpressa-z-pomoca-ai-szybko-tanio-i-bez-frustracji-z-wpml-nasz-kompletny-workflow/ > Language: pl > Description: WordPress obsługuje około 41 procent wszystkich stron internetowych na świecie. A mimo to w roku 2026 na CMS-ie numer jeden nie ma sposobu na przetłumaczenie strony, który nie kos… --- WordPress obsługuje około 41 procent wszystkich stron internetowych na świecie. A mimo to w roku 2026 na CMS-ie numer jeden nie ma sposobu na przetłumaczenie strony, który nie kosztowałby albo tygodni pracy, albo małej fortuny – lub po drodze po cichu nie gubiłby tłumaczeń. Wiemy to, bo przeszliśmy przez wszystkie trzy warianty. Artykuł liczący ponad 10 000 słów, przetłumaczony w edytorze WPML, zaznaczone haczyki, zapisane – a na stronie na żywo: niemiecki. Nie wszędzie, bo to dałoby się łatwo wykryć. Tylko w 1247 z 1725 pól. Ten artykuł to protokół tego, jak rozwiązaliśmy ten problem u siebie. Dowiesz się, dlaczego tłumaczenia w WordPressie tak często zawodzą i które błędy WPML kosztowały nas najwięcej nerwów. Zobaczysz nasze rozwiązanie w szczegółach: dozbrojenie liczące około 300 linii kodu, które Claude Code napisał w dziesięć minut, oraz workflow tłumaczeniowy, który artykuł liczący 10 000 słów tłumaczy, sprawdza i wgrywa w 3 do 5 minut – w sposób dający się udowodnić jako kompletny. A na końcu otrzymasz dwa prompty, dzięki którym odtworzysz całość u siebie: jeden dla Twojego programisty względnie Claude Code, drugi do samej pracy tłumaczeniowej. Jedno na wstępie, żeby oczekiwania były właściwe: to nie jest artykuł w stylu „AI robi wszystko”. U nas AI wykonuje rutynę – niezawodnie, w sposób weryfikowalny i za ułamek dotychczasowych kosztów. Odpowiedzialność spoczywa na procesie z wbudowanymi kontrolami. Jak on wygląda, przeczytasz teraz. ![Treści WordPressa są automatycznie tłumaczone z pomocą AI na wiele języków i sprawdzane](https://4eck-media.de/wp-content/uploads/2026/07/wordpress-wpml-claude-cover-safe-layout-source.avif) ## Dlaczego wielojęzyczność nie jest już dodatkiem mile widzianym Krótka odpowiedź: bo Twoje następne zapytanie nie musi już koniecznie pochodzić z sąsiedniej miejscowości, lecz z Zurychu, Wiednia – albo Tokio. Kto prowadzi swoją stronę tylko po niemiecku, czyni język przeszkodą w sprzedaży. I to na rynku, który tę właśnie przeszkodę już dawno zniósł. ### Co ma z tym wspólnego rynek wewnętrzny UE? Rynek wewnętrzny w dużej mierze zniósł cła, granice i biurokrację między państwami członkowskimi. Agencja w Görlitz może pracować dla klienta w Lizbonie, sklep w Grazu dostarczać towar do Helsinek – prawnie i logistycznie to codzienność. Ostatnią prawdziwą granicą, która pozostaje, jest język. Kto oferuje stronę tylko w jednym języku, na nowo stawia granicę, którą rynek właśnie zniósł. Presja ekonomiczna jest więc realna: Twoi konkurenci to już nie trzej dostawcy w okolicy, lecz każdy, kto mówi językiem klienta. ### Skąd wiemy, że rynek jest naprawdę globalny? Z własnej skrzynki odbiorczej. Docierają do nas teraz zapytania ze Szwajcarii, z Austrii, z Japonii, Kanady i USA. Powód jest godny uwagi: asystenci AI polecają nas, gdy ktoś pyta o „najlepszą agencję WordPress” albo szuka wsparcia w SEO, marketingu i integracji AI. Jak trafić do tych rekomendacji, opisaliśmy szczegółowo w naszym [artykule o GEO](https://4eck-media.de/pl/blog/framework-geo-4eck-dla-widocznosci-ai-i-rekomendacji-ai/) – tu liczy się tylko konsekwencja: klient szuka w swoim języku, jego asystent AI odpowiada w jego języku, a jeśli Twojej strony tam nie ma, to dla tego klienta nie istniejesz. To zmienia rachunek. Kiedyś angielska wersja była „miła dla zagranicznych odwiedzających”. Dziś decyduje o tym, czy w ogóle pojawiasz się w maszynach udzielających odpowiedzi. I nikt nie potrafi już przewidzieć, w jakim języku nadejdzie następne zapytanie – u nas ostatnio był to japoński. Wyciągnęliśmy z tego konsekwencję i założyliśmy w WPML dziesięć języków. Nie dlatego, że chcemy otwierać biura na dziesięciu rynkach, lecz dlatego, że nie potrafimy już zdecydować, gdzie następny klient prowadzi swoje poszukiwania. ### Dlaczego cena i tempo to kwestia strategiczna? Bo wielojęzyczność nie jest jednorazowym projektem, lecz stanem trwałym. Każdy nowy artykuł na blogu, każda realizacja, każda strona usługowa musi zostać zaktualizowana – inaczej obcojęzyczna wersja zamienia się w ruinę z przestarzałymi treściami. I tu deklaracja intencji rozchodzi się z praktyką: jeśli jedna runda tłumaczeń trwa tygodnie albo kosztuje czterocyfrową kwotę za język, to w końcu się jej zaniecha. Nie ze złej woli, lecz dlatego, że w codziennej pracy zawsze czeka coś pilniejszego. Właśnie dlatego kosztów i szybkości tłumaczeń nie traktujemy jako operacyjnego detalu, lecz jako strategicznego parametru: to one decydują, czy wielojęzyczność jest realnie pielęgnowana, czy kurzy się na liście „kiedyś tam”. Jak opanowaliśmy jedno i drugie, pokazują kolejne rozdziały. Dlaczego rynek nie jest już lokalny - Rynek wewnętrzny UE zniósł niemal wszystkie granice – język jest ostatnią, a stoi ona na Twojej stronie - Nasze zapytania płyną teraz ze Szwajcarii, Austrii, Japonii, Kanady i USA - Asystenci AI polecają nas na zapytania w rodzaju „najlepsza agencja WordPress” oraz w kwestiach SEO, marketingu i integracji AI - Kto oferuje tylko jeden język, po prostu nie istnieje w obcojęzycznych odpowiedziach AI - Cena i szybkość tłumaczeń decydują o tym, czy wielojęzyczność jest trwale pielęgnowana ### Częste pytania o wielojęzyczność Czy wielojęzyczność opłaca się także małym firmom? Właśnie wtedy. Duzi dostawcy stać na biura tłumaczeń, mali tracą zagraniczne zapytania bez walki. Gdy tłumaczenia stają się szybkie i tanie, znika jedyny racjonalny argument przeciwko nim – a rynek, który możesz obsłużyć, rośnie, choć nie uruchamiasz ani jednej reklamy. Od którego języka zacząć? Od tego, z którego już płyną zapytania albo w którym Twoi docelowi klienci prowadzą poszukiwania. Angielski to zwykle pierwszy krok, bo jest wykorzystywany także przez asystentów AI jako język pomostowy. Później decyduje Twój rynek, a nie przeczucie. Czy nie wystarczy automatyczny tłumacz w przeglądarce odwiedzającego? Nie. Tłumaczenie w przeglądarce zadziała dopiero wtedy, gdy odwiedzający jest już na Twojej stronie. Decydujący moment jest wcześniej: w wyszukiwaniu i w rekomendacji AI, które odbywają się w języku użytkownika. Tam liczy się tylko to, co faktycznie leży przetłumaczone w Twojej domenie. ## Jak działają tłumaczenia w WordPressie – i na czym się wykładają Jeśli chcesz zrozumieć, dlaczego tłumaczenia stron są tak żmudne i drogie, potrzebujesz tylko jednego spostrzeżenia: WordPress nie zapisuje artykułu jako jednego tekstu. Zapisuje go jako setki małych pól – i każde z nich musi przejść przez tłumaczenie. ### Dlaczego artykuł to nie „jeden tekst”? To, co w przeglądarce wygląda jak ciągły artykuł, w bazie danych leży rozłożone na części: nagłówek to jedno pole, każdy akapit to pole, każdy pojedynczy punkt listy, każdy podpis pod obrazem, każdy śródtytuł. Do tego dochodzą niewidoczne części, których nie czyta żaden odwiedzający, ale czyta każda wyszukiwarka: tytuł SEO, meta opis, slug URL. Konkretny przykład z naszego własnego bloga: nasz największy artykuł, framework GEO, składa się z 1599 bloków i rozpada się na 1725 segmentów tłumaczeniowych. Ponad 10 000 słów rozłożonych na ponad 1700 pól formularza. To przypadek skrajny, przyznajemy – ale pokazuje, w jakim rzędzie wielkości gra jeden ambitny artykuł fachowy. Wtyczki tłumaczeniowe odwzorowują dokładnie tę strukturę. WPML jest liderem rynku, Polylang i TranslatePress to najbardziej znane alternatywy – zasada jest wszędzie taka sama: wtyczka zakłada dla każdego języka kopię struktury pól i przeprowadza każde pole osobno przez tłumaczenie. To nie błąd konstrukcyjny, lecz konieczność, by układ, linki i formatowanie przetrwały tłumaczenie. Ale to wyjaśnia, dlaczego „przetłumacz no szybko tę stronę” nie jest małą prośbą. Zasadniczo istnieją trzy sposoby wypełnienia tych pól – i każdy boli na swój sposób. ### Sposób 1: Ręcznie w edytorze tłumaczeń Edytor tłumaczeń pokazuje po lewej pole niemieckie, po prawej puste pole docelowe. Tłumaczysz, klikasz dalej, tłumaczysz, klikasz dalej. Przy stronie kontaktowej z dwudziestoma polami jest to wykonalne. Przy artykule liczącym 10 000 słów z ponad 1700 polami to wielodniowa praca taśmowa – i to na każdy język z osobna. A jest to najbardziej wyczerpujący rodzaj pracy: dość monotonny, by produkować błędy, ale zbyt wymagający, by oddać go osobom bez przygotowania. Kto po polu 900 traci koncentrację, nie zauważa tego – zauważa to wynik. Założyliśmy w WPML dziesięć języków; kto raz uczciwie doprowadzi ten rachunek do końca, bardzo szybko odkłada kalkulator z powrotem. ![Edytor tłumaczeń WPML z długą listą pól dużego artykułu, wiele pól na wpis](https://4eck-media.de/wp-content/uploads/2026/07/Bild-2-wpml.avif) ### Sposób 2: Biuro tłumaczeń Klasyczna droga: wyeksportować tekst, oddać do biura, wynik wprowadzić z powrotem. Jakościowo często dobrze – ale rozliczenie podlega bezlitosnej formule: cena za słowo × objętość × liczba języków. Przy stronie takiej jak nasza, ze 116 artykułami na blogu, 53 realizacjami i 199 stronami kompetencyjnymi, z tego mnożenia wychodzi kwota, której żaden budżet marketingowy nie wyłoży dobrowolnie. Do tego dochodzi droga powrotna: ktoś musi dostarczone teksty z powrotem posegregować do setek pól – dzięki czemu część sposobu 1 dostajesz gratis w pakiecie. ### Sposób 3: Automatyczne tłumaczenie za pomocą kredytów WPML WPML ma wbudowaną automatykę: na jedno kliknięcie DeepL, Google lub Microsoft tłumaczą treści, a rozliczenie odbywa się poprzez kredyty. To najwygodniejsza droga – i ma dwa haczyki. Po pierwsze rozliczenie: za słowo i za język. Przełożenie jednego artykułu na jeden język jest tanie; przełożenie 116 artykułów na kilka języków już nie. Kto publikuje regularnie, płaci regularnie. Po drugie, i to waży więcej: automatyka tłumaczy bez kontekstu projektu. Nie zna Twojej marki, Twoich nazw produktów, Twojej terminologii – widzi zawsze tylko pojedynczy segment, który akurat jest na tapecie. Więc wesoło tłumaczy też nazwy marek, a terminy fachowe skaczą między stronami: na jednej stronie brzmią tak, na następnej inaczej, a czytelnik zastanawia się, czy to dwie różne rzeczy. Wynik rzadko bywa błędny, ale niezawodnie przeciętny. Dla strony wizytówkowej może to wystarczyć. Dla bloga, który ma dowodzić kompetencji – i który chce być przywoływany przez asystentów AI jako źródło -, „niezawodnie przeciętny” to zły cel jakościowy. Podsumujmy: drogo, wolno albo przeciętnie – wybierz sobie jedno. Właśnie w tym miejscu wchodzi nasz workflow. Wcześniej musimy jednak porozmawiać o czymś bardziej nieprzyjemnym: o miejscach, w których WPML jest nie tylko żmudny, lecz po prostu zepsuty. Trzy drogi – drogo, wolno albo przeciętnie - Artykuł WordPress to nie tekst, lecz setki pól: nasz największy rozpada się na 1725 segmentów przy ponad 10 000 słów - Sposób 1, ręcznie w edytorze: ponad 1700 pól na język – wielodniowa praca taśmowa - Sposób 2, biuro tłumaczeń: cena za słowo × objętość × języki – przy 116 artykułach nie do opłacenia - Sposób 3, kredyty WPML: wygodnie, ale rozliczenie za słowo i język – i bez kontekstu projektu marki są tłumaczone razem z resztą - Wszystkie trzy drogi źle się skalują: drogo, wolno albo przeciętnie ### Częste pytania o tłumaczenia w WordPressie Dlaczego nie mogę po prostu skopiować całego artykułu i wkleić go przetłumaczonego? Bo przy tym gubi się struktura: bloki, formatowania, linki wewnętrzne i metadane SEO są przypisane do poszczególnych pól. Wtyczki tłumaczeniowe właśnie dlatego rozkładają treść na segmenty – tylko tak strona po tłumaczeniu pozostaje technicznie identyczna z oryginałem. Czy WPML to właściwy wybór, czy raczej Polylang lub TranslatePress? Dla stron ze złożonymi treściami (pola ACF, bloki Gutenberga, metadane SEO) WPML jest najgłębiej zintegrowany i dlatego jest liderem rynku. Polylang i TranslatePress to lżejsze alternatywy dla prostszych konfiguracji. Kto już tkwi głęboko w WPML, powinien wiedzieć: migracja jest zwykle droższa niż naprawa problemów. Czy automatyczne tłumaczenie WPML nie wystarczy na początek? Dla pojedynczych stron: tak, jak najbardziej. Problem zaczyna się przy ilości i wymaganiach – wiele artykułów razy kilka języków robi się drogie, a bez glosariusza i kontekstu cierpi spójność. Dla strony wizytówkowej w porządku, dla bloga fachowego za mało. Ile segmentów ma normalna strona? To ogromnie się waha. Krótka strona usługowa obywa się kilkoma dziesiątkami pól, nasz największy artykuł na blogu dobija do 1725 segmentów. Właśnie ta rozpiętość sprawia, że ogólne twierdzenia o nakładzie pracy przy tłumaczeniu są tak zawodne – licz segmenty, nie strony. ## Błędy WPML, których nauczyliśmy się po trudnej stronie Na wstępie, żeby nie powstało fałszywe wrażenie: kochamy WordPressa. Obsługuje on około 41 procent wszystkich stron i trzyma niecałe 60 procent rynku CMS – budujemy na nim nasz biznes. Właśnie dlatego się złościmy. To, co teraz nastąpi, to nie rozprawa hejterów, lecz protokół użytkowników, którzy WPML wykorzystują produkcyjnie i przy tym znaleźli rzeczy, o których nie przeczytasz w żadnym opisie produktu. ### Cichy ubytek danych: max_input_vars Najgorszy błąd to ten, który nie wyrzuca żadnego komunikatu o błędzie. Nasz artykuł o frameworku GEO ma 1599 bloków, które w edytorze tłumaczeń stają się ponad 1700 polami formularza. PHP ma jednak standardowe ograniczenie, ile pól formularza serwer przyjmuje na jedno żądanie: max_input_vars, fabrycznie 1000. Wszystko powyżej jest przy zapisie po cichu odrzucane. Żadnego błędu, żadnego ostrzeżenia – edytor melduje sukces, a nadmiarowe pola po prostu znikają. Wynik u nas: 1247 z 1725 segmentów utknęło. W edytorze porządnie przetłumaczone, zaznaczony haczyk „Translation is complete” – ale tłumaczenia nigdy nie dotarły na stronę na żywo. Pracowało się całymi dniami, system potwierdza pracę, a odwiedzający przetłumaczoną stronę i tak czyta niemiecki. Podstępne jest w tym to, że błąd wygląda jak błąd obsługi. Czy ktoś zapomniał zapisać? Trafił na zły język? Kto nie wie, czego ma szukać, tygodniami szuka błędu u siebie samego – podczas gdy przyczyną jest stała serwera, o której większość redaktorów nigdy nie słyszała. ### Zielone haczyki na pustych polach Jeszcze perfidniej: znaleźliśmy tłumaczenia, przy których haczyk „Translation is complete” był zaznaczony – na pustych polach. Status mówi gotowe, pole nie mówi nic. Dla systemu tłumaczeniowego to katastrofa najwyższego stopnia, bo status jest jedyną rzeczą, na której opierają się planowanie i odbiór. Nasza konsekwencja tkwi od tego czasu w każdej instrukcji roboczej: haczykom statusu nie wolno wierzyć. Kontroluje się na wyeksportowanej treści, nigdy na pulpicie. ![Edytor WPML: kilka pustych pól docelowych z zaznaczonym haczykiem „Translation is complete” przy 1 procencie postępu](https://4eck-media.de/wp-content/uploads/2026/07/bild-03-wpml-complete-leer.avif) ### Translation Memory zapomina Translation Memory to właściwie najmocniejsza funkcja WPML: co raz zostało przetłumaczone, przy następnym razie jest wstępnie uzupełniane. Przy naszym dużym artykule dostarczyło jednak 462 z 1725 segmentów gotowych – niemal ćwierć podarowanej pracy, to bierzemy chętnie. Ale ma słabość: gdy artykuł się zmienia i WPML na nowo segmentuje treści, gubią się przy tym segmenty, które właściwie były już przetłumaczone. Płaci się wtedy za to samo tłumaczenie po raz drugi – albo, co gorsza, przeoczy się, że go brakuje, bo przecież „właściwie wszystko już raz było przetłumaczone”. Na pamięci, która zapomina przy przewracaniu strony, nie buduje się planowania. ### A na to wszystko dochodzi jeszcze cache Załóżmy, że znalazłeś to wszystko i zaimportowałeś poprawki. Wtedy między Tobą a odwiedzającym siedzi jeszcze cache strony: w jednym przypadku poprawka była dawno w systemie, ale odwiedzający jeszcze przez 24 godziny widzieli starą, błędną wersję. Dla kontroli jakości oznacza to: nawet spojrzenie na stronę na żywo niczego nie dowodzi, dopóki nie wiadomo, kiedy cache był ostatnio czyszczony. Szukanie błędów staje się tak modelem warstwowym – edytor, baza danych, cache, a każda warstwa może opowiadać inną prawdę. ### Drobiazgi, które kosztują godziny Dwa znaleziska z kategorii „kosztuje tylko nerwy”: eksport zawsze dostarcza XML – całkowicie niezależnie od tego, jakie rozszerzenie pliku się zażąda. Kto zbudował swoje narzędzia na innym formacie, może je przebudowywać. A REST API nie widzi ukrytych języków: dopóki język nie jest jeszcze publicznie włączony, przez interfejs po prostu nie da się go odpytać – akurat w tej fazie, w której najpilniej chce się automatycznie sprawdzać. ### Dlaczego mimo to nie zmieniamy Można by teraz zawołać: precz z WPML! My widzimy to inaczej, z dwóch powodów. Po pierwsze WPML jest głęboko zintegrowany z naszą stroną – ACF, Gutenberg, metadane SEO. Migracja byłaby droższa niż naprawa. Po drugie, i to jest ważniejszy punkt: pod maską jest wszystko. Eksport i import XLIFF, Translation Memory, wewnętrzne API – maszyna działa. Zepsuta jest tylko warstwa formularza w przeglądarce, czyli dokładnie ta warstwa, z którą pracują ludzie. I ustalmy: to nie są błędy obsługi. Szukaliśmy dostatecznie długo w drugim kierunku, by móc to powiedzieć z pewną dozą pewności. To są problemy systemowe narzędzia z ponad milionem instalacji. Gdy formularz przy dużych artykułach po cichu odrzuca dane, a haczyk statusu stoi na pustych polach, to dotyka to każdego, kto na poważnie publikuje wielojęzycznie – większość tylko tego nie zauważa, bo nikt nie czyta polskiej wersji własnego bloga pole po polu. Dobra wiadomość: właśnie dlatego, że funkcje podbudowy są nienaruszone, można zepsutą warstwę formularza obejść, zamiast ją naprawiać. Jak – pokazuje następny rozdział. Pułapki WPML, które kosztowały nas nerwy - max_input_vars (standardowo: 1000 pól) po cichu ucina formularz edytora przy dużych artykułach – 1599 bloków, ponad 1700 pól, żadnego komunikatu o błędzie - Skutek u nas: 1247 z 1725 segmentów przetłumaczonych i oznaczonych jako „complete”, ale nigdy nie dotarły na stronę na żywo - Haczyk „Translation is complete” znaleźliśmy także na całkowicie pustych polach – statusowi nie można ufać - Translation Memory traci przy ponownej segmentacji już przetłumaczone segmenty; cache pokazywał odwiedzającym przez 24 godziny starą wersję - Drobiazgi: eksport zawsze dostarcza XML, REST API nie widzi ukrytych języków - Wniosek: problemy systemowe, nie błędy obsługi – ale podbudowa (XLIFF, TM, wewnętrzne API) działa ### Częste pytania o problemy z WPML Po czym poznam, że dotyczy mnie błąd max_input_vars? Po sprzeczności między statusem a stroną na żywo: edytor melduje „complete”, ale na przetłumaczonej stronie dalej stoi niemiecki tekst albo pola pozostają puste. Dotknięte są przede wszystkim długie artykuły z wieloma blokami. Wyeksportuj tłumaczenie i poszukaj w treści docelowej pustych segmentów oraz języka źródłowego – samemu haczykowi nie wolno ufać. Czy wystarczy podnieść max_input_vars na serwerze? Rozbraja to ten jeden błąd, owszem – o ile Twój hosting w ogóle pozwala zmienić tę wartość. Pozostałe problemy zostają: fałszywe statusy „complete”, utraty segmentów w Translation Memory, opóźnienia cache. Dlatego zdecydowaliśmy się całkowicie obejść formularz i importować przez XLIFF – jedna operacja, żadnego limitu pól. Czy z powodu tych błędów powinniśmy migrować z WPML? W większości przypadków: nie. Przy głębokiej integracji z ACF, Gutenbergiem i metadanymi SEO migracja jest droższa niż naprawa, a funkcje rdzeniowe WPML są nienaruszone. Zepsuta jest warstwa formularza w przeglądarce – a ją da się obejść, zamiast wymieniać cały system. Jak zapewniamy, że tłumaczenia naprawdę są na żywo? Kontrolą na treści zamiast na statusie: tłumaczenie po imporcie ponownie wyeksportować i porównać, czy wszystko dotarło; na stronie na żywo wyrywkowo szukać języka źródłowego; a po poprawkach mieć na oku cache. U nas ten kontrolny eksport jest stałym elementem każdego cyklu tłumaczeniowego. ## Naprawiać zamiast zmieniać: nasza decyzja Zostaliśmy przy WPML – a zamiast tego zbudowaliśmy drogę obok zepsutego formularza. Ta decyzja nie zapadła z nostalgii, lecz po trzeźwym rachunku: WPML tkwi u nas głęboko w projekcie. Pola ACF, bloki Gutenberga, metadane SEO – wszystko przechodzi przez WPML, na przestrzeni dziesięciu języków. Migracja na inną wtyczkę tłumaczeniową oznaczałaby zbudowanie tego okablowania na nowo przy 116 artykułach na blogu, 53 realizacjach i 199 stronach kompetencyjnych. Byłoby to droższe niż naprawa. Znacznie droższe. Do tego doszła obserwacja, która wszystko zmieniła. Gdy zajrzeliśmy pod maskę, nic tam nie było zepsute. WPML ma eksport i import XLIFF. WPML ma Translation Memory, które zapamiętuje każdy kiedykolwiek przetłumaczony fragment. WPML ma wewnętrzne API, które to wszystko czysto obsługują. Maszynownia działa. Zepsuta jest tylko kondygnacja użytkownika: formularz przeglądarki w edytorze tłumaczeń, który przy dużych artykułach wysyła więcej pól, niż serwer przyjmuje – a nadmiarowe po cichu odrzuca. Zmiana wtyczki oznaczałaby więc wyrzucenie razem z nią działającej maszynowni, tylko po to, by pozbyć się wadliwego interfejsu. A na dodatek Translation Memory: każde już opłacone, już odebrane tłumaczenie z dziesięciu języków. Tego kapitału nikt nie oddaje dobrowolnie. Kto z powodu wadliwej kondygnacji wyburza cały dom, ma problem budżetowy. Racjonalna odpowiedź brzmi: bierzemy schody. Konkretnie oznacza to poprowadzenie cyklu wyprowadzania, tłumaczenia i wgrywania całkowicie obok formularza – bezpośrednio poprzez funkcje, które WPML i tak ze sobą niesie. Żadnego forka, żadnego zamiennika, żadnej równoległej pracy dwóch wtyczek. Tylko objazd wokół tego jednego miejsca, które nie utrzymuje. I właśnie tu wchodzi AI. Nie jako magiczny przycisk z napisem „tłumacz”, który się naciska i ma nadzieję – takie przyciski dopiero co zafundowały nam puste pola z zielonymi haczykami. Lecz jako pracownik, któremu można przekazać dwa bardzo konkretne zlecenia. Po pierwsze: samo dozbrojenie – napisać kod, który otwiera objazd. Po drugie: tłumaczenie – właściwą mrówczą pracę, segment po segmencie, z kontrolami przed i po. Oba to zadania z jasnymi regułami i mierzalnym wynikiem. Dokładnie ten rodzaj pracy, w którym AI dziś dostarcza niezawodnie – i przy którym człowiek jako recenzent i tak zachowuje ostatnie słowo. Jak wygląda to dozbrojenie, jak długo naprawdę trwało i dlaczego z zepsutego edytora robi przelotowy workflow tłumaczeniowy – o tym są następne dwa rozdziały. ## Dozbrojenie: mini-plugin z czterema trasami, który Claude Code napisał w dziesięć minut Cała naprawa to jeden jedyny mu-plugin: około 300 do 400 linii PHP, które otwierają cztery trasy HTTP do funkcji, które WPML dawno posiada. Plugin niczego nie tłumaczy, niczego nie tworzy, niczego nie usuwa. To drzwi – nic więcej. Kod napisał Claude Code według specyfikacji technicznej, nasz programista zrecenzował i wdrożył. Samo generowanie było zadaniem na dziesięć minut. ![Architektura mini-pluginu geo-helper: środowisko AI, trasy REST, funkcje WPML i baza danych](https://4eck-media.de/wp-content/uploads/2026/07/bild-04-plugin-architektur.avif) ### Co dokładnie robi plugin? Udostępnia pięć endpointów, cztery z nich niosą właściwą pracę: - **/status** – co jest przetłumaczone, a co nie. Odpowiedź, którą w backendzie WPML trzeba by mozolnie wyklikać, jako jedno zapytanie. - **/requeue** – ustawić treść na nowo w kolejce tłumaczeń. WPML buduje w odpowiedzi zadanie i wstępnie uzupełnia z Translation Memory wszystko, co kiedykolwiek zostało przetłumaczone. - **/export** – wyprowadzić kompletną treść jako plik XLIFF, segmenty parami: niemieckie źródło, pole w języku docelowym. - **/import** – wgrać gotowy plik XLIFF z powrotem, jako jedna operacja. Do tego dochodzi **/ping** do diagnostyki: czy instalacja w ogóle odpowiada, zanim uruchomi się przebieg? Decydujące jest to, czego plugin *nie* robi. Nie wymyśla nowej logiki tłumaczenia, żadnego własnego edytora, żadnego równoległego modelu danych. Każda trasa to czysty wrapper wokół wewnętrznej funkcji WPML – te same mechanizmy, których używa też oficjalny workflow XLIFF w WPML. Nie dokonaliśmy żadnej przebudowy, lecz nadaliśmy czterem istniejącym zdolnościom adres, do którego dociera się bez przeglądarki. ### Jak to powstało? Opowiadamy przejrzyście, bo właśnie ta część interesuje wielu kierowników projektu: na początku nie był kod, lecz specyfikacja techniczna – które trasy, jakie parametry, jakie zachowanie w razie błędu, co jest wyraźnie zabronione. Tę specyfikację opracowaliśmy z Claude Code, a potem oddaliśmy z powrotem jako zlecenie: napisz mu-plugin dokładnie według tego dokumentu. ![Specyfikacja techniczna pięciu tras REST pluginu geo-helper](https://4eck-media.de/wp-content/uploads/2026/07/bild-05-spezifikation-routen.avif) Generowanie kodu trwało około dziesięciu minut. I tu pozostajemy szczerzy, bo sama liczba dziesięciu minut malowałaby krzywy obraz: recenzja przez naszego programistę, ustawienie IP-allowlisty i wdrożenie zajęły wieczór. Człowiek przeczytał każdą linię, zanim trafiła na środowisko produkcyjne. To nie brak zaufania do AI, lecz po prostu podział pracy, który zastosowalibyśmy do każdego kodu na środowisku klienta – niezależnie od tego, kto go napisał. Rachunek i tak wychodzi jasno na plus: jeden wieczór nakładu za narzędzie, które od tego czasu niesie każdy cykl tłumaczeniowy. ### Czy to bezpieczne? To pytanie padło wewnętrznie jako pierwsze i jest uzasadnione: cztery otwarte trasy HTTP na produkcyjnej stronie brzmią początkowo jak powierzchnia ataku. Nasza odpowiedź składa się z trzech poziomów. Po pierwsze: IP-allowlista zamiast tokenów. Tylko stałe wyjściowe adresy IP środowiska AI mogą w ogóle zwracać się do tras; każde inne żądanie odbija się. Dzięki temu w kodzie nie leżą też żadne tokeny, które mogłyby wygasnąć, wyciec lub przypadkiem zostać zacommitowane. Po drugie: plugin nie może niczego usunąć. Ta zdolność po prostu nie istnieje w kodzie – najgorszy możliwy przypadek to nieudany import, a nie utracona treść. Po trzecie: nie tworzy żadnych treści. Żadnych nowych wpisów, żadnych stron, żadnych użytkowników. Przemieszcza wyłącznie dane tłumaczeniowe kanałami, które WPML sam definiuje. ### Dlaczego to gamechanger? Bo zmienia się dzięki temu, *kto* może prowadzić cykl. Wcześniej „wyprowadzić → przetłumaczyć → wgrać” wisiało na przeglądarce: zalogować się, klikać, czekać – i przy zapisie dużych artykułów wpaść dokładnie w pułapkę max_input_vars, którą sekcjonowaliśmy w poprzednich rozdziałach. Agent AI nie uratuje formularza przeglądarki, który serwer ucina po stronie serwera. Z czterema trasami ten sam cykl działa bez przeglądarki. A to znaczy: agent AI może go całkowicie przejąć. Odpytuje status, ustawia artykuł na nowo w kolejce, pobiera plik XLIFF, tłumaczy, sprawdza, wgrywa z powrotem i porównuje – i nie wykłada się przy tym na formularzu, który nigdy nie był zbudowany dla 1700 pól. Z narzędzia, które musi obsługiwać człowiek i które zawodzi przy dużych treściach, powstaje interfejs, który maszyna może obsługiwać niezawodnie. Następny fragment pokazuje ten przebieg krok po kroku na największym artykule naszej strony. Plugin pomocniczy w pięciu punktach - Jeden mu-plugin, ok. 300–400 linii PHP – czyste wrappery wokół istniejących funkcji WPML - 4 trasy robocze (/status, /requeue, /export, /import) plus /ping do diagnostyki - Generowanie kodu przez Claude Code: ~10 minut; recenzja, IP-allowlista i wdrożenie przez programistę: jeden wieczór - Bezpieczeństwo: IP-allowlista zamiast tokenów, brak możliwości usuwania, nie tworzy treści - Efekt: cykl „wyprowadzić → przetłumaczyć → wgrać” działa bez przeglądarki – agent AI może go całkowicie przejąć ### Częste pytania o dozbrojenie Czy mini-plugin zastępuje WPML? Nie. Uzupełnia WPML o cztery osiągalne z zewnątrz trasy do funkcji, które WPML już ze sobą niesie: eksport XLIFF, import XLIFF, kolejka, odpytanie statusu. Tłumaczy się nadal w strukturach danych WPML – łącznie z Translation Memory. Czy plugin sam tłumaczy? Nie, ani jednej linii. Wyprowadza treści jako XLIFF i wgrywa z powrotem gotowe pliki XLIFF. Tłumaczenie odbywa się na zewnątrz – u nas przez agentów AI, ale równie dobrze na drugim końcu mogłoby siedzieć ludzkie biuro tłumaczeń. Dlaczego IP-allowlista, a nie tokeny API? Bo środowisko AI ma stałe wyjściowe adresy IP i dzięki temu redukujemy powierzchnię ataku do minimum, nie zarządzając sekretami w kodzie. Brak tokena oznacza: nic, co mogłoby wygasnąć, wyciec lub przypadkiem trafić do repozytorium. Czy taki plugin może uszkodzić stronę? Potencjał szkód jest świadomie utrzymany na niskim poziomie: plugin nie może usuwać treści ani ich tworzyć, przemieszcza tylko dane tłumaczeniowe przez mechanizmy własne WPML. Do tego dochodzi kontrolny eksport po każdym imporcie, który sprawdza, czy naprawdę dotarło to, co miało dotrzeć. ## Tak wygląda tłumaczenie dzisiaj: workflow krok po kroku Wynik na wstępie, na najtwardszym przykładzie naszej strony: nasz największy artykuł – framework GEO, 1725 segmentów tłumaczeniowych, ponad 10 000 słów – został tym workflow przetłumaczony w 3 do 5 minut. 1215 segmentów świeżo przetłumaczonych, automatycznie sprawdzonych, zaimportowanych i potwierdzonych kontrolnym eksportem. Ten sam artykuł, przy którym wcześniej 1247 segmentów utknęło w zepsutym edytorze. Oto przebieg, krok po kroku. ![Kolejka tłumaczeń WPML z wieloma treściami w kilku językach, wszystkie w statusie do przetłumaczenia](https://4eck-media.de/wp-content/uploads/2026/07/bild-10-wpml-queue.avif) ### Krok 1: requeue – WPML nakrywa do stołu Agent wywołuje trasę /requeue, WPML buduje zadanie tłumaczeniowe i wstępnie uzupełnia z Translation Memory wszystko, co kiedykolwiek zostało przetłumaczone. Przy naszym artykule TM dostarczyło 462 z 1725 segmentów gotowych – dobra ćwiartka pracy była zrobiona, zanim ktokolwiek przetłumaczył choćby słowo. To moment, w którym opłaca się każde wcześniej zapisane tłumaczenie, także to z ery WPML sprzed dozbrojenia. ### Krok 2: Export – cały artykuł jako jeden plik Przez /export wychodzi kompletny artykuł jako jeden jedyny plik XLIFF: wszystkie segmenty parami, niemieckie źródło obok pola w języku docelowym. Jeden plik, jeden stan, jeden punkt prawdy – zamiast 1700 pól formularza, z których serwer przyjmuje tylko pierwsze 1000. ### Krótko wyjaśnione: czym jest plik XLIFF? XLIFF to skrót od „XML Localization Interchange File Format” – ustanowiony od lat standard branżowy dla tłumaczeń. Można go sobie wyobrazić jako znormalizowany kontener: plik XLIFF zawiera tekst czysto rozłożony na segmenty, a do każdego segmentu należy pole źródłowe (oryginał) i pole docelowe (tłumaczenie). Formatowanie, tagi i kolejność pozostają przy tym zachowane. Urok tego polega na tym: niemal każde poważne narzędzie tłumaczeniowe mówi w XLIFF – także WPML eksportuje i importuje w tym formacie. Zamiast wciskać tekst przez ciasne pola formularza, podaje się jeden jedyny, sprawdzalny plik. Właśnie to wykorzystujemy: WPML wydaje artykuł jako XLIFF, AI wypełnia pola docelowe, a WPML wczytuje gotowy plik z powrotem – bez tego, by po drodze coś się gubiło. ### Krok 3: Sortowanie – nie wszystko należy tłumaczyć Skrypt dzieli segmenty na trzy stosy: **tłumaczyć**, **nie dotykać** (nazwy marek, URL-e, ustawienia ACF – wszystko, co w każdym języku musi pozostać identyczne) i **już gotowe** (462 trafienia z TM). Ten krok wydaje się niepozorny, ale zapobiega dwóm klasycznym błędom tłumaczenia maszynowego: temu, że ktoś „przetłumaczy” URL, albo że techniczne pole ustawień skończy w pięknej prozie języka docelowego. ### Krok 4: Równoległe agenty AI – 14 batchy, jeden glosariusz Pozostałe segmenty idą w 14 batchach po około 85 segmentów do równoległych agentów AI. Aby czternastu tłumaczy nie wybrało czternastu słówek na ten sam termin fachowy, wszyscy pracują ze wspólnym glosariuszem terminologicznym, zbudowanym wcześniej z istniejących tłumaczeń. Spójność powstaje tu nie dzięki nadziei, lecz dzięki wspólnej liście słów. Równoległość jest powodem, dla którego z artykułu liczącego 10 000 słów nie robi się zadanie na tydzień: 14 pracowników, jednocześnie, z identycznymi regułami. ![Log pipeline'u: 14 batchy, kontrole i potwierdzenie importu tłumaczenia AI](https://4eck-media.de/wp-content/uploads/2026/07/bild-06-pipeline-log.avif) ### Krok 5: Kontrole przed importem – maszyna kontroluje maszynę Zanim cokolwiek popłynie z powrotem do WordPressa, każdy przetłumaczony plik przechodzi przez automatyczne kontrole: czy XML jest poprawny? Czy wszystkie tagi HTML są kompletne? Czy listy mają tyle samo punktów co w oryginale? Czy linki są nietknięte? I: czy w tekście docelowym stoją jeszcze niemieckie pozostałości słów? Do ostatniej kontroli jest whitelista z nazwami własnymi – „Deutsche Gesellschaft für …” nazywa się tak w każdym języku i nie może zostać odrzucona jako błąd tłumaczenia. Jeśli batch nie przejdzie, zostaje poprawiony, zanim ruszy dalej. Nic nie dociera do importu niesprawdzone. ### Krok 6: Import – jedna operacja, obok formularza Sprawdzony plik XLIFF idzie przez /import z powrotem – jako jedna jedyna operacja, bezpośrednio przez wewnętrzne funkcje WPML. Żadnego formularza przeglądarki, żadnego limitu max_input_vars, żadnego cichego odrzucania pól. Dokładnie to miejsce, w którym łamała się stara droga, w tej drodze po prostu nie istnieje. ### Krok 7: Kontrolny eksport – zaufanie jest dobre, porównanie to obowiązek Na koniec wyprowadzamy ten sam artykuł jeszcze raz i porównujemy: czy w każdym polu docelowym naprawdę stoi to, co zostało zaimportowane? Tę paranoję wyćwiczyliśmy sobie przy pustych polach z haczykiem „Translation is complete”. Haczykowi statusu od tego czasu już nie wierzymy – porównaniu eksportu owszem. [Miejsce na zrzut ekranu: strona artykułu przed/po – puste tłumaczenie z haczykiem „complete” vs. w pełni przetłumaczona strona na żywo] ### Co to znaczy w liczbach? 1215 segmentów świeżo przetłumaczonych, sprawdzonych i zaimportowanych – w 3 do 5 minut. Dla porównania stary rachunek dla tego samego artykułu: tydzień pracy tłumacza, plus kolejny tydzień na wyszukanie tego, co edytor zgubił przy zapisie. A workflow się skaluje: dla angielskiego zrobiliśmy w jeden dzień 638 segmentów obejmujących 50 realizacji, jeden artykuł na blogu i 4 strony; francuski stoi przy 53 realizacjach kompletnie z 401 przetłumaczonymi i poprawionymi segmentami. Dziś EN, FR i PL są w 100 procentach complete – blog, realizacje, strony. Hiszpański działa właśnie autonomicznie, według pisemnej instrukcji roboczej. Człowiek w łańcuchu nie zniknął. Przeszedł tylko od przepisywania do odbioru. Workflow na przykładzie naszego największego artykułu - 1725 segmentów, ponad 10 000 słów – największy artykuł strony - Translation Memory dostarczyło 462 segmenty gotowe - 14 równoległych agentów AI, batche po ~85 segmentów, wspólny glosariusz terminologiczny - 5 automatycznych kontroli przed importem: XML, tagi HTML, punkty list, linki, niemieckie pozostałości słów - Wynik: 1215 segmentów przetłumaczonych, sprawdzonych i zaimportowanych w 3 do 5 minut - Stara droga: tydzień tłumaczenia plus tydzień szukania tego, co nie zostało zapisane ### Częste pytania o workflow Dlaczego artykuł jest eksportowany jako jeden jedyny plik XLIFF? Bo jeden plik to spójny stan: źródło i cel leżą parami obok siebie, nic nie jest ucinane przez serwer, a import przebiega później z powrotem jako jedna operacja. Właśnie tego formularz przeglądarki przy dużych artykułach nie potrafi – tam proces się urywał. Jak zapewniacie, że 14 równoległych agentów tłumaczy jednolicie? Poprzez wspólny glosariusz terminologiczny, budowany przed przebiegiem z istniejących tłumaczeń. Każdy batch pracuje z tą samą listą słów; terminy fachowe i powracające sformułowania pozostają dzięki temu spójne we wszystkich batchach. Co się dzieje, gdy tłumaczenie nie przejdzie automatycznych kontroli? Wtedy nie dociera do importu. Kontrole przebiegają przed wgraniem: poprawność XML, kompletne tagi HTML, taka sama liczba punktów listy, nietknięte linki, brak niemieckich pozostałości słów. Dopiero czysty plik idzie przez /import z powrotem. Skąd wiecie, że po imporcie naprawdę wszystko dotarło? Poprzez kontrolny eksport: artykuł po imporcie jest ponownie wyprowadzany i porównywany z wgraną wersją. Samemu haczykowi statusu już nie ufamy – puste pola z „Translation is complete” były wszak punktem wyjścia całej tej historii. ### Właściwa dźwignia tempa: równolegle zamiast po kolei To, że z zadania na tydzień robi się kilka minut, nie wynika z szybszego pisania. Wynika z równoległości. Zamiast obrabiać pole po polu i język po języku, Claude rozkłada pracę na niezależne batche, tłumaczy je jednocześnie i na końcu wszystko scala – łącznie z kontrolami. ![Schemat równoległej orkiestracji: Claude dzieli pracę na batche, wykonuje je jednocześnie i scala; porównanie czasu tygodnie kontra minuty](https://4eck-media.de/wp-content/uploads/2026/07/bild-09-parallel-orchestrierung.avif) Przyjemne jest w tym to: Claude często robi to sam z siebie. Rozpoznaje, że poszczególne batche nie muszą nic o sobie wiedzieć, i uruchamia je równolegle, bez konieczności osobnego proszenia o to. Ale właśnie nie zawsze. Przy niejasno sformułowanym poleceniu model zdarza się, że grzecznie pracuje po kolei – wynik jest poprawny, tylko trwa dłużej. Dlatego tempo wpisujemy wprost do promptu. Wystarczy jedno zdanie, które po prostu dokleja się do instrukcji roboczej: ``` Obrabiaj batche równolegle, nie po kolei: uruchom kilka agentów tłumaczeniowych jednocześnie i scal wyniki na końcu. Process the batches in parallel, not one after another: run several translation agents at the same time and merge the results at the end. ``` Efekt jest dokładnie taki jak na grafice: tygodnie stają się minutami. A w biznesie, w którym czas jest jedynym surowcem, którego nie da się kupić, na końcu często decyduje nie lepszy produkt, lecz szybszy. Kto wdraża pomysł od razu, jest na miejscu, zanim konkurencja w ogóle zaczyna. ## Skąd wiemy, że naprawdę WSZYSTKO jest przetłumaczone Krótka odpowiedź: nie wierzymy ani jednemu haczykowi. Zamiast tego sprawdzamy każdy język trójstopniowo – najpierw status ogólny, potem każdy pojedynczy segment, potem samą treść. Dopiero gdy wszystkie trzy stopnie są czyste, język uchodzi u nas za gotowy. I właśnie ten sceptycyzm pozwolił nam znaleźć błędy, których w niemieckim oryginale od lat nikt nie zauważył. Jeśli dotarłeś do tego miejsca, znasz powód naszej nieufności: 1247 segmentów z zaznaczonym haczykiem „Translation is complete” – a za nim puste pola. Kto raz tego doświadczył, buduje sobie system kontroli. Nasz ma trzy stopnie. ### Stopień 1: Gdzie w ogóle jesteśmy? Macierz statusów. Na każdy język i typ treści – artykuły na blogu, realizacje, strony – widzimy na pierwszy rzut oka: complete, przestarzałe czy nieprzetłumaczone. To jednominutowy przegląd, który jako kierownik projektu chce się mieć każdego ranka. Żadnych dwudziestu kliknięć przez backend WPML, lecz tabela, która odpowiada na pytanie: gdzie jeszcze czegoś brakuje? Macierz mówi jednak tylko to, co WPML *sądzi*. Dlatego jest stopień 2. ![Macierz statusów przed/po: luki tłumaczeniowe na początku projektu i całkowicie zielone języki EN, FR, PL](https://4eck-media.de/wp-content/uploads/2026/07/bild-08-status-matrix.avif) ### Stopień 2: Czy haczyki się zgadzają? Skan segmentów. Eksportujemy każde pojedyncze zadanie tłumaczeniowe i szukamy maszynowo dwóch rzeczy: pustych pól docelowych i niemieckiego tekstu tam, gdzie żadnego być nie powinno. Haczykom statusu nie wolno bowiem wierzyć – właśnie tym skanem znaleźliśmy artykuły, przy których „complete” stało na pustych polach. Status był zadbany, strona na żywo w połowie niemiecka. Brzmi to jak dużo pracy, ale to skrypt: wyeksportować, porównać, lista wyników. Nazwy własne jak „Deutsche Gesellschaft für…” stoją na whiteliście, żeby nie prześlizgnęły się jako błąd. ### Stopień 3: Czy to także dobry polski? Puste pole znajdzie każdy skrypt. Ale germanizm? Nieodmieniony rzeczownik własny? Do tego każemy agentom AI czytać tłumaczenie jak rodzimi korektorzy w zestawieniu z niemieckim oryginałem – zdanie po zdaniu, sens naprzeciw sensu. Wynik przy polskim zaskoczył nas samych. Wszystkie 53 realizacje stały na „complete”. Korekta znalazła mimo to około 70 uwag: germanizmy, nieodmienione nazwy własne – a w jednym przypadku opis niewłaściwego klienta. Błąd typu kopiuj-wklej, który tkwił nawet w niemieckim oryginale. Latami online, przez żadnego człowieka niezauważony, przez AI znaleziony przy systematycznym porównaniu. Wszystkie 132 poprawki wgraliśmy w jeden wieczór. To jest dla nas właściwy sens tego rozdziału: AI nie tylko tłumaczy – jest audytorem, który przy 1500. segmencie się nie męczy. Ludzki korektor czyta 53 strony realizacji i w końcu się nuży; to nie krytyka, to biologia. Agent czyta segment 1500 z tą samą uwagą co segment 1. Trójstopniowa kontrola jakości - Stopień 1 – macierz statusów: język × typ treści, całościowy obraz w minutę - Stopień 2 – skan segmentów: wyeksportować każde zadanie, szukać pustych pól i niemieckich pozostałości słów; haczyki się nie liczą - Stopień 3 – rodzima korekta AI w zestawieniu z oryginałem: błędy sensu, kalki, odmiana - Dowód z praktyki: 53 polskie realizacje „complete” – a mimo to ~70 uwag, w tym niewłaściwy klient w jednym opisie - Wszystkie 132 poprawki wgrane w jeden wieczór ### Częste pytania o kontrolę jakości Czy wskazanie statusu w WPML nie wystarczy? Nie. Status mówi tylko, że zadanie tłumaczeniowe zostało zakończone – nie, że treść dotarła na stronę na żywo. Mieliśmy 1247 segmentów z haczykiem i pustymi polami. Dlatego zawsze sprawdzamy dodatkowo na poziomie segmentów. Kto kontroluje kontrolę – czy AI potrafi znaleźć własne błędy? Korekta sprawdza w zestawieniu z niemieckim oryginałem, nie z własnym tłumaczeniem, i przebiega jako osobny krok z osobną rolą. Do tego dochodzą automatyczne kontrole przed każdym importem: poprawny XML, kompletne tagi HTML, nietknięte linki. Na końcu i tak człowiek odbiera wyrywki u nas. Jak długo trwa taki przebieg kontrolny? Macierz statusów to minuta. Skan segmentów i korekta przebiegają automatycznie – przy polskim wszystkie 132 poprawki z korekty wgraliśmy w jeden jedyny wieczór. Czy korekta naprawdę znajduje rzeczy, które ludzie przeoczą? Tak, dowodnie: błąd kopiuj-wklej z niewłaściwym klientem tkwił nawet w niemieckim oryginale – i tam nigdy nikomu nie rzucił się w oczy. Systematyczne porównanie zdanie po zdaniu się nie męczy, i właśnie w tym leży jego przewaga. ## Kto tłumaczy, a kto kontroluje: podział pracy między modelami Tajna wskazówka z naszego workflow to nie oprogramowanie, lecz decyzja personalna: wykorzystujemy dwa różne modele AI – jeden tłumaczy, drugi kontroluje. Ten podział ról jest powodem, dla którego rachunek na końcu wychodzi. Podział wygląda tak: Claude Opus 4.8 jest modelem wykonawczym. Jest szybki i przy pracy masowej znacznie tańszy – idealny do właściwej pracy tłumaczeniowej, równoległych batchy po około 85 segmentów, obrabiania kolejki. Claude Fable 5 jest analitycznie mocniejszy, ale droższy – i dlatego jest potrzebny tylko punktowo: planuje przebieg, sprawdza wyrywki i odbiera wynik. Jeśli brzmi to znajomo, to dlatego, że tak zapewne organizujesz swój zespół: junior tłumaczy, senior recenzuje. Nikt nie każe najdroższej głowie w firmie przekładać 1700 segmentów tekstu ciągłego – ma ustalić strukturę i na końcu na to spojrzeć. Dokładnie to robimy z modelami. Tyle że oba pracują nocą i nie chorują. ### Szybko, tanio, dobrze – wybierz dwa? Stary trójkąt zarządzania projektami mówi: z szybko, tanio i dobrze dostajesz zawsze tylko dwa. Podział ról to nasza odpowiedź na to – dostarcza wszystkie trzy. Szybko, bo model wykonawczy pracuje równolegle w batchach. Tanio, bo za drogi model płaci się tylko za momenty, w których analiza jest naprawdę potrzebna: planowanie, wyrywek, odbiór. I dobrze, bo to właśnie nie ten sam model przepuszcza własną pracę, lecz kontroluje ją druga, mocniejsza instancja. Ważna jest kolejność: najpierw model senior planuje zlecenie – co jest tłumaczone, co pozostaje nietknięte (marki, URL-e, ustawienia ACF), jaki glosariusz terminologiczny obowiązuje. Glosariusz budujemy z istniejących tłumaczeń, żeby wszyscy równolegli agenci używali tych samych pojęć – inaczej ten sam termin fachowy w batchu 3 nazywa się inaczej niż w batchu 11. Potem model junior obrabia masę. Na końcu wraca senior i sprawdza wyrywkowo, czy wynik odpowiada wytycznej. Żaden segment nie idzie do importu, jeśli nie przeszedł przez ten łańcuch. Przy artykule liczącym 1725 segmentów wyglądało to konkretnie tak: 14 równoległych agentów, każdy z batchem około 85 segmentów i tym samym glosariuszem. Masa szła na tanim modelu – planowanie przed i odbiór po na mocnym. Wynik w 3 do 5 minut, bez tego, by droga instancja przetłumaczyła choćby jeden segment tekstu ciągłego samodzielnie. Dla Ciebie jako kierownika projektu oznacza to: przy projektach AI nie myśl w kategorii pytania „który model jest najlepszy?”, lecz „która rola potrzebuje którego modelu?”. Stosowanie najlepszego modelu wszędzie ma tyle sensu, co dawanie każdego zadania w zespole najdroższej osobie. Kto tłumaczy, kto kontroluje - Claude Opus 4.8 tłumaczy: szybko, taniej przy pracy masowej, równoległe batche po ~85 segmentów - Claude Fable 5 planuje, sprawdza wyrywki, odbiera: analitycznie mocniejszy, potrzebny tylko punktowo - Zasada: junior tłumaczy, senior recenzuje – oba pracują nocą i nie chorują - Wynik: szybko I tanio I dobrze – podział ról obchodzi stare „wybierz dwa” ## Co to oznacza w liczbach Najpierw bilans: 116 artykułów na blogu, 53 realizacje, 19 stron – angielski, francuski i polski stoją w 100 procentach na complete. Hiszpański właśnie działa, i to autonomicznie: według pisemnej instrukcji roboczej, bez tego, by ktoś siedział obok. Ramy czasowe dla tego: godziny zamiast tygodni. Dwa przykłady, które czynią różnicę uchwytną. Dla angielskiego przetłumaczyliśmy, sprawdziliśmy i zaimportowaliśmy 638 segmentów w jeden jedyny dzień – 50 realizacji, jeden artykuł na blogu, cztery strony. A największy kloc całej strony, artykuł o frameworku GEO z 1725 segmentami i ponad 10 000 słów, przeszedł w 3 do 5 minut: 462 segmenty dostarczyło gotowe Translation Memory, pozostałe 1215 przetłumaczyło, sprawdziło i zaimportowało 14 równoległych agentów AI. Ten sam artykuł, na którym edytor tłumaczeń wcześniej poległ z 1247 utkniętymi segmentami. Do tego francuski: 53 realizacje kompletnie, 401 segmentów przetłumaczonych lub poprawionych. A przy polskim wszystkie 132 poprawki z korekty poszły na żywo w jeden wieczór. Przy kosztach logika jest prosta: płacimy jeden abonament Claude – żadnego rozliczenia za słowo i za język. Automatyczne tłumaczenie WPML poprzez kredyty (DeepL, Google, Microsoft) istnieje, ale jest rozliczane dokładnie tak: za słowo, za język. Przy 116 artykułach razy kilka języków sumuje się to znacznie. Do tego dochodzi: abonament pokrywa nie tylko tłumaczenie, lecz także korektę, skrypty kontrolne i kontrolny eksport – kroki pracy, które w kalkulacji za słowo w ogóle się nie pojawiają. Do tego dochodzi efekt, którego nie planowaliśmy: zapytania płyną teraz ze Szwajcarii, Austrii, Japonii, Kanady i USA. Asystenci AI polecają nas na zapytania w rodzaju „najlepsza agencja WordPress” oraz w kwestiach SEO, marketingu i integracji AI. Rynek stał się globalny – a strona, która mówi tylko po niemiecku, jest na tym rynku niewidoczna. ### Czego AI tu nie potrafi Żeby nie powstało fałszywe wrażenie: nie twierdzimy, że AI potrafi wszystko. Teksty prawnicze i slogany marek potrzebują na końcu łańcucha człowieka – przy jednym wisi odpowiedzialność, przy drugim niuans, i jednego ani drugiego nie deleguje się modelowi językowemu. Także w naszym workflow finalny wyrywek odbiera człowiek. Ale to nie argument przeciwko podejściu, lecz jego ograniczenie. Tam, gdzie da się zautomatyzować tygodnie rutynowej pracy – 1725 segmentów wyeksportować, przetłumaczyć, sprawdzić, zaimportować -, jedyną racjonalną decyzją jest to zrobić. Odpowiedzialność niesie przy tym proces ze swoimi kontrolami: macierz statusów, skan segmentów, korekta, automatyczne kontrole przed każdym importem. Nie wiara w model. Projekt w liczbach - 116 artykułów na blogu, 53 realizacje, 19 stron – EN, FR i PL w 100% complete - Hiszpański działa autonomicznie według pisemnej instrukcji roboczej - 638 segmentów EN w jeden dzień; artykuł z 1725 segmentami w 3 do 5 minut - Koszty: jeden abonament Claude zamiast rozliczenia za słowo i język - Granica: teksty prawnicze i slogany marek potrzebują na końcu człowieka ## Co jest Ci potrzebne, żeby to odtworzyć Dobra wiadomość na wstępie: lista zakupów jest krótka. Nie potrzebujesz nowej platformy tłumaczeniowej, żadnej migracji ani specjalnego budżetu – lecz czterech rzeczy, z których trzy zapewne już masz. **Po pierwsze: WordPress z WPML.** Wystarczy każda wersja ze wsparciem XLIFF. Cały workflow wykorzystuje funkcje, które w WPML już tkwią – eksport i import XLIFF, Translation Memory, wewnętrzne API. Nic nie jest zastępowane, tylko udostępniane. **Po drugie: programista na pół dnia.** Mu-plugin – około 300 do 400 linii PHP, czyste wrappery wokół wewnętrznych funkcji WPML – generuje AI w jakieś dziesięć minut. Człowiek robi to, czego się nie deleguje: code review, wdrożenie, IP-allowlistę. U nas był to jeden wieczór. Dla bezpieczeństwa: tylko stałe wyjściowe IP środowiska AI przechodzą, żadnych tokenów w kodzie, a usuwać plugin nie może nic – eksportuje, importuje i melduje status, nic więcej. **Po trzecie: abonament Claude** z dostępem do Claude Code i Cowork. To motor całości – i powód, dla którego nie powstaje żaden rachunek za słowo. **Po czwarte: osoba do finalnego odbioru.** Rodzime wyrywki na końcu łańcucha. AI koryguje systematycznie, ale ostatnie dopuszczenie pozostaje przy człowieku. Nie musi to być tłumacz na pełny etat – chodzi o wyrywki, nie o kompletną lekturę; to kompletne wykonała już wcześniej maszyna. ### Kiedy nasza droga się nie opłaca? To też należy do uczciwej listy kontrolnej. Stronę o 5 podstronach przetłumaczysz szybciej ręcznie – budowa workflow opłaca się dopiero wtedy, gdy ilość bije pracę ręczną. A treści prawnicze idą u nas zasadniczo tylko z profesjonalną recenzją; tego świadomie nie automatyzujemy. Dla wszystkiego pomiędzy – blogów, realizacji, stron kompetencyjnych w kilku językach – obowiązuje: narzędzia leżą gotowe. Eksport XLIFF, Translation Memory, wewnętrzne API – to wszystko tkwi już w WPML; cztery trasy pluginu (/status, /requeue, /export, /import) czynią to tylko osiągalnym z zewnątrz. To, czego brakuje, to zwykle nie technika, lecz decyzja, żeby ją poskładać. Co jest Ci potrzebne do odtworzenia - WordPress + WPML, każda wersja ze wsparciem XLIFF - Programista na pół dnia: recenzja pluginu, wdrożenie, IP-allowlista - Abonament Claude z Code + Cowork - Osoba do rodzimego odbioru wyrywkowego - Nie ma sensu przy: stronach o 5 podstronach (praca ręczna jest szybsza) i treściach prawniczych bez profesjonalnej recenzji ## Na wynos: Prompt 1 – dozbrojenie (dla Claude Code lub Twojego programisty) Obietnicę ze wstępu teraz spełniamy. Poniższy prompt to skompresowana wersja specyfikacji, z której powstał nasz plugin pomocniczy. Skopiuj go do Claude Code – wynikiem jest szkic pluginu, który Twój programista zrecenzuje i wdroży. Dokładnie tak powstał nasz: dziesięć minut generowania, jeden wieczór recenzji i wdrożenia. Dwie rzeczy musisz dodatkowo załatwić ręcznie, bez których nic nie działa: Po pierwsze: udostępnij swoją domenę strony dla środowiska AI. Ważne – dzieje się to nie w aplikacji Claude, lecz w ustawieniach konta na stronie claude.ai, pod Capabilities → Allow network egress → Additional allowed domains. Tam wpisujesz swoją domenę (u nas 4eck-media.de). Powód: Claude pracuje w odizolowanym środowisku, które samo z siebie nie może wychodzić do otwartej sieci. Jeśli tego wpisu brakuje, środowisko blokuje każde żądanie do Twojego serwera – requeue, Export i Import zawodzą, zanim w ogóle wystartują. Jednorazowy ruch, bez którego cały workflow nie działa. ![Ustawienia na claude.ai: własna domena strony wpisana pod Capabilities, Allow network egress, Additional allowed domains](https://4eck-media.de/wp-content/uploads/2026/07/bild-11-claude-domain-allowlist.avif) Po drugie: jeśli używasz Claude także w przeglądarce (na przykład do kontroli w panelu administracyjnym WordPressa), dodaj swoją stronę w rozszerzeniu przeglądarkowym Claude do listy dozwolonych witryn. ``` Task: Build a WordPress mu-plugin ("translation-helper", single PHP file, ~300–400 lines) that exposes existing WPML translation operations over HTTP, so an external AI agent can run a full translation cycle without using the wp-admin browser forms. Routes (REST namespace translation-helper/v1): 1. GET /ping → { ok, wpml_version, plugin_version } - health check, no params. 2. GET /status → params: lang (required), type (post type, e.g. post/page/custom), per_page, page. Returns items with: post_id, title, target_lang, translation_status (not_translated | in_progress | needs_update | complete), job_id, needs_requeue. 3. POST /requeue → JSON body { post_id, target_lang }. Re-queues the post for translation using WPML's Translation Management API (equivalent to sending it to translation in the dashboard). WPML must prefill targets from Translation Memory. Returns new job_id. 4. GET /export → param job_id. Streams the job as XLIFF 1.2 (XML). 5. POST /import → multipart: job_id + file (the translated XLIFF). Applies the translation using WPML's own import routines. Returns { ok, segments_total, segments_applied, status }. Hard requirements: - Wrap EXISTING WPML functions only (Translation Management API, XLIFF export/import). Do not reimplement translation logic. Confirm exact function names against the installed WPML version before finalizing. - Auth: IP allowlist from a constant in the plugin file. Behind Cloudflare/proxies check CF-Connecting-IP (or X-Forwarded-For), not REMOTE_ADDR. Reject everything else with 403. - The plugin must not be able to delete content, create posts, or modify anything except applying translation jobs via /import. - Rate limiting: one concurrent write (requeue/import); return { code: "busy" } or { code: "rate_limit" } so the client can back off and retry. - Log every write operation (timestamp, IP, route, post_id/job_id) to a rotating file. Deliverables: the plugin file + a short README with the curl calls for all five routes. ``` Prompt 1: dozbrojenie w skrócie - Jeden mu-plugin, ~300–400 linii, pięć tras: ping, status, requeue, export, import - Tylko wrappery wokół istniejących funkcji WPML – sam nic nie tłumaczy, nic nie usuwa - Dostęp przez IP-allowlistę, każda operacja zapisu jest logowana - Generowanie: ~10 minut. Recenzja i wdrożenie przez człowieka: jeden wieczór - Potem cały cykl tłumaczeniowy działa bez formularza przeglądarki ## Na wynos: Prompt 2 – instrukcja robocza do tłumaczenia (Claude Cowork) Drugi prompt to instrukcja robocza do właściwego tłumaczenia. Zakłada on, że plugin z Promptu 1 działa. Używamy go w Claude Cowork; tam AI może przetwarzać pliki, uruchamiać skrypty i godzinami pracować autonomicznie. Dostosuj język, domenę i listę „nie tłumaczyć” do swojego projektu. ``` Task: Translate the website content of [YOUR-DOMAIN] from [SOURCE-LANG] to [TARGET-LANG] using the translation-helper plugin (REST namespace translation-helper/v1). Work autonomously, sequentially, and keep a verifiable journal. Cycle per post: 1. POST /requeue { post_id, target_lang } → new job_id. WPML prefills targets from Translation Memory - do not re-translate those segments. 2. GET /export?job_id=... → save the XLIFF (keep it as "before" artifact). 3. Classify every trans-unit: (a) TRANSLATE if target is empty or identical to a source that is real [SOURCE-LANG] text; (b) KEEP AS IS if it is a brand name, person, city, URL, or a short technical setting value; (c) TM-DONE if target differs from source - never overwrite these, but reuse them as your terminology reference. 4. Translate with strict rules: reproduce the HTML structure of the source byte-for-byte (same tags, attributes, entities, number of
  • ); translate only human text; SEO title ≤ 60 chars, meta description ≤ 160; [add your language conventions here]. Do not translate: [YOUR BRAND LIST], people, places, technical terms (SEO, PageSpeed…). 5. Validate before import: XML parses; tag list of every changed target equals its source; list item counts match; no leftover [SOURCE-LANG] function words (keep a whitelist for proper names). 6. POST /import (multipart) → expect segments_applied == segments_total, status complete. 7. GET /export again → verify your translations are actually in the re-export ("after" artifact). A status flag alone is NOT proof. 8. Journal line per post: post_id, job_id, segments total/prefilled/translated/kept, import result, verified yes/no. Constraints: all write requests strictly sequential; on "busy"/"rate_limit" back off 30→60→120s; batches of 5–10 posts; never touch posts outside the given list; never change source content; skip WordPress sample pages. Order of work: pilot on ONE small post first and show me the result. Then: references → pages → blog posts → [other post types]. Report after every batch. ``` I wskazówka, która u nas zrobiła największą różnicę w kosztach: rozdziel role. Tłumaczenie masowe jedzie u nas na Claude Opus 4.8 – szybko i tanio. Planowanie, wyrywki i odbiór robi Claude Fable 5 – analitycznie mocniejszy, ale potrzebny tylko punktowo. Junior tłumaczy, senior recenzuje. Tak dostajesz jakość, szybkość i rozsądną cenę jednocześnie. ### Częste pytania o tłumaczenie WordPressa z pomocą AI Czy to zastępuje profesjonalnego tłumacza? Nie – i mówimy to świadomie tak dobitnie. Dla tekstów prawniczych i sloganów marek człowiek należy na koniec łańcucha, tego nie zmieni nawet najlepsza AI. To, co AI zastępuje, to praca masowa: kazać ręcznie przetłumaczyć 116 artykułów na blogu, 53 realizacje i 199 stron kompetencyjnych nigdy nie było dla nas realistyczną opcją. Przy czystym procesie kontroli – automatyczne kontrole przed importem plus rodzima korekta w zestawieniu z oryginałem – AI jest dla tej masowej treści jedyną racjonalną decyzją. Ile kosztuje tłumaczenie strony WordPress z pomocą AI? Szczerze mówiąc: znacznie mniej niż alternatywy, ale dokładna liczba zależy od Twojej konfiguracji. Decydująca różnica leży w modelu rozliczania – automatyczne tłumaczenie przez kredyty WPML (DeepL, Google, Microsoft) jest rozliczane za słowo i za język, co przy 116 artykułach razy kilka języków robi się bardzo drogie. Nasz workflow działa natomiast przez abonament AI, który nie tyka za słowo. Do tego dochodzi jednorazowo konfiguracja: około 300–400 linii PHP, wdrożone przez programistę w jeden wieczór. Czy działa to także z Polylang lub TranslatePress? Co do zasady tak, bo główna idea jest niezależna od wtyczki: wyciągnąć treści z systemu przez eksport, przetłumaczyć i sprawdzić na zewnątrz, potem wgrać z powrotem przez import – obok formularza przeglądarki. Właśnie ten formularz był u nas wąskim gardłem (max_input_vars przy 1725 segmentach po cichu ucinał 1247). Konkretne trasy naszego pluginu geo-helper są jednak wrapperami wokół wewnętrznych funkcji WPML; dla Polylang lub TranslatePress programista musiałby zbudować podłączenie do ich interfejsów na nowo. Wzorzec pozostaje ten sam, implementacja nie. Co z SEO i hreflang? WPML sam ustawia oznaczenie hreflang, gdy tylko tłumaczenie uchodzi za kompletne – o to nie musisz się osobno troszczyć. Tytuły Yoast i metaopisy przechodzą jako całkiem normalne segmenty przez eksport XLIFF i są tłumaczone w tym samym cyklu. Ważne jest tylko, by agenci AI przestrzegali przy tym limitów długości dla tytułu i opisu, inaczej Google utnie. To da się zapisać jako reguła w instrukcji roboczej i automatycznie sprawdzać. Czy bezpieczne jest dawanie AI dostępu do strony? Tak, bo AI w ogóle nie dostaje ogólnego dostępu. Mu-plugin otwiera tylko cztery wąsko ograniczone trasy dla operacji tłumaczeniowych – status, requeue, eksport, import – i niczego nowego nie wymyśla, lecz wrappuje istniejące funkcje WPML. IP-allowlista przepuszcza tylko stałe wyjściowe IP środowiska AI, tokeny nie leżą w kodzie. A z założenia konstrukcyjnego plugin nie może usuwać treści ani tworzyć nowych: najgorszy możliwy przypadek to złe tłumaczenie, które utknie w recenzji. Co się dzieje przy aktualizacji WPML? Z reguły: nic, bo plugin wykorzystuje oficjalne wewnętrzne funkcje WPML zamiast własnych sztuczek na bazie danych. Właśnie te funkcje napędzają też zwykły eksport XLIFF i Translation Memory – są stabilnym fundamentem, zepsuta była u nas tylko warstwa formularza przeglądarki. Mimo to zalecamy po każdej dużej aktualizacji cykl pilotażowy: przepuścić jeden artykuł przez requeue, export, import i kontrolny eksport oraz porównać wynik. Kosztuje minuty i odbiera aktualizacji grozę. Ile języków jest realistycznych? Nasza uczciwa liczba: 10 języków jest założonych w WPML, 4 z nich są kompletne – EN, FR i PL w 100 procentach, hiszpański działa właśnie autonomicznie według pisemnej instrukcji roboczej. Wąskim gardłem nie jest przy tym już samo tłumaczenie; 638 angielskich segmentów w jeden dzień albo 1215 segmentów w 3 do 5 minut pokazuje, jak szybko to idzie. Wąskim gardłem jest recenzja: kto sprawdza wyniki, kto decyduje przy kwestiach terminologicznych? Planuj więc języki według swojej pojemności recenzenckiej, nie według technicznej wykonalności. Jak długo trwa konfiguracja? Krócej, niż większość oczekuje: u nas programista potrzebował pół dnia, a pierwszy artykuł przeszedł jeszcze tego samego dnia przez cały cykl. Specyfikacja mu-pluginu jest gotowa i możliwa do skopiowania – Claude Code wygenerował kod w jakieś 10 minut, recenzję, wdrożenie i IP-allowlistę załatwił nasz programista w jeden wieczór. Potem workflow jest od razu produkcyjny: requeue, export, tłumaczyć, sprawdzić, import, kontrolny eksport. ## Glosariusz: pojęcia z tego artykułu **ATE (Advanced Translation Editor)** – Przeglądarkowy edytor tłumaczeń WPML, w którym tłumaczenia są edytowane segment po segmencie i oznaczane jako „complete”. Przy bardzo dużych artykułach jego formularz natrafia na ograniczenia po stronie serwera – u nas w ten sposób po cichu przepadło 1247 z 1725 segmentów. **Egress-Allowlist** – Lista bezpieczeństwa stałych wyjściowych adresów IP, z których środowisko AI wychodzi do sieci. Tylko te IP mogą wywoływać trasy pluginu tłumaczeniowego; wszystkie inne żądania są odrzucane. **hreflang** – Atrybut HTML, który mówi wyszukiwarkom, w jakim języku i dla jakiego regionu przeznaczona jest wersja strony. WPML ustawia hreflang dla gotowych tłumaczeń automatycznie, dzięki czemu Google wyświetla właściwą wersję językową właściwym użytkownikom. **max_input_vars** – Ustawienie PHP, które ogranicza, ile pól formularza serwer przyjmuje na jedno żądanie (standardowo: 1000). Gdy formularz tłumaczeniowy przekroczy ten limit – nasz największy artykuł miał ponad 1700 pól – reszta jest ucinana bez komunikatu o błędzie. **mu-plugin** – „Must-Use-Plugin” w WordPressie: leży we własnym katalogu, jest zawsze aktywny i nie da się go dezaktywować przez backend administracyjny. Nasz geo-helper to taki mu-plugin liczący około 300–400 linii PHP. **Segment** – Najmniejsza jednostka tłumaczeniowa w WPML, typowo akapit, nagłówek albo pojedyncze pole. Nasz największy artykuł składa się z 1725 segmentów przy ponad 10 000 słów; nasi agenci AI obrabiają je w batchach po około 85 segmentów. **Translation Memory** – Pamięć tłumaczeniowa WPML: raz przetłumaczone segmenty są zapamiętywane i przy nowych zadaniach automatycznie wstępnie uzupełniane. Przy naszym największym artykule dostarczyła 462 z 1725 segmentów gotowych. **XLIFF** – Oparty na XML format wymiany dla tłumaczeń, który odkłada tekst źródłowy i docelowy parami na segment. Poprzez eksport i import XLIFF wędrują u nas całe artykuły jako jeden plik obok formularza – import to jedna jedyna operacja bez limitu max_input_vars. ## Słowo od nas Wszystko, co przedstawiono w tym artykule, opiera się na naszych własnych obserwacjach i wnioskach z praktyki. Nie jest to uniwersalny poradnik ani porada prawna czy techniczna. Wszystko, co wdrożysz samodzielnie, robisz na własne ryzyko. ## Podsumowanie: CMS numer jeden zasługuje na lepsze tłumaczenia Przez półtorej dekady przy tłumaczeniach WordPressa obowiązywała stara reguła projektowa: szybko, tanio, dobrze – wybierz dwa. Nasze podsumowanie po tym projekcie: reguła była cechą narzędzia, nie zadania. Odkąd cykl przebiega obok zepsutego formularza, a AI przejmuje rutynę, tłumaczymy w godzinach zamiast tygodni, płacimy abonament zamiast taryf za słowo – i dzięki trójstopniowej kontroli po raz pierwszy wiemy w sposób dowodliwy, że naprawdę wszystko jest przetłumaczone. Chcesz tego dla własnej strony? Skopiuj ten artykuł – cały tekst – i podaj go swojemu Claude Code. Jest w nim dość szczegółów, by mógł wyprowadzić z niego odtworzenie; oba prompty powyżej są punktem startowym. A jeśli wolisz zlecić: właśnie po to jesteśmy. Budujemy wielojęzyczne strony WordPress, które są znajdowane – przez ludzi i przez systemy AI. Więcej o tym na naszej stronie [Zlecenie stworzenia wielojęzycznej strony](https://4eck-media.de/pl/kompetencje/wielojezyczna-strona-internetowa-na-zamowienie-wiekszy-zasieg-wiecej-klientow/) – albo [skontaktuj się z nami](https://4eck-media.de/pl/kontakt/).