Plan wdrożenia · dokument roboczy do dyskusji zespołowej

Angielska wersja interlab.pl

Analiza mechanizmu dwujęzyczności, uzasadnienie wyboru i etapowy plan wdrożenia — z priorytetem na lekkość i wydajność strony.

Data: 2026-07-05 Status: propozycja Zakres: PLEN Ingerencja w stronę: brak (na tym etapie)

Rekomendacja w jednym zdaniu

Polylang Business Pack + generowanie wersji EN przez nasz pipeline AI

Wtyczka daje wyłącznie szkielet dwujęzyczności (powiązanie PL↔EN, adresy /en/, hreflang, przełącznik języka). Treść tworzy pipeline, który i tak generuje 99% produktów. Dzięki temu nie płacimy — wydajnością ani pieniędzmi — za ciężkie funkcje automatycznego tłumaczenia, których nie potrzebujemy.

Koszt licencji: 139 €/rok (odnowienie ~70 €/rok) · staging w cenie · rollback bezpieczny

Kontekst

Po co nam wersja angielska

Interlab jest dystrybutorem aparatury pomiarowej współpracującym z markami zachodnimi (AFL, Yokogawa, FITEL, Silixa, NKT i in.). Angielska witryna to warunek wiarygodności przy rozmowach o dystrybucji na rynki EU oraz przy obsłudze klientów i producentów spoza Polski. To nie kosmetyka — to narzędzie sprzedażowe i wizerunkowe wobec partnerów, którzy dziś oceniają nas po polskojęzycznej stronie.

Cel dokumentu: wybrać mechanizm, który da poważną, indeksowalną wersję EN bez pogorszenia szybkości strony (świeżo optymalizowanej pod Core Web Vitals) i bez tworzenia trwałego obciążenia utrzymaniowego.

Analiza · sedno decyzji

Trzy mechanizmy — i dlaczego wybieramy właśnie ten

Rozważyliśmy trzy realne drogi. Kryteria oceny wynikają wprost z priorytetów: wydajność, zgodność z naszym pipeline AI, kontrola SEO, koszt i obciążenie utrzymaniowe.

Kryterium Automat / proxy
(Weglot, Linguise)
WPML Polylang Business
Wpływ na wydajność JS/latencja ciężki lekki
Zgodność z pipeline AI (REST) omija CMS oporny natywny REST
Kontrola SEO (URL, hreflang) ograniczona pełna pełna
Model kosztu abonament rosnący licencja+kredyty licencja stała
Utrzymanie nowych produktów w locie auto+akceptacja z pipeline
Koszt roczny ~zmienny €€ ~99 € + kredyty 139 €

Automat / proxy odrzucone

Tłumaczy stronę „w locie" nakładką JS lub proxy. Zaleta: zero pracy na starcie. Wady dyskwalifikujące: dokłada warstwę JavaScriptu i opóźnień (uderza w to, co właśnie poprawialiśmy w CWV), abonament rośnie z liczbą słów i odsłon, a kontrola nad SEO i terminologią techniczną jest ograniczona. Płacisz w nieskończoność za coś, co u nas jest jednorazowym wysiłkiem.

WPML odrzucone

Standard branżowy, najbogatszy — ale jego główny atut, automatyczne tłumaczenie, jest u nas zbędny, bo treść generuje pipeline. Zostaje wtedy sama waga: WPML dokłada tabele i zapytania, co na żywej, zoptymalizowanej produkcji jest realnym ryzykiem wydajnościowym. Do tego przez REST jest oporny — gorzej współpracuje z automatyzacją, na której opieramy dodawanie produktów. Bierzemy koszt (waga), rezygnując z jedynej korzyści, której nie wykorzystamy.

Polylang Business wybór

Zbudowany na natywnych mechanizmach WordPressa (język jako taksonomia) — najlżejszy z „prawdziwych" rozwiązań dwujęzycznych. Ma REST API, więc pipeline może tworzyć i od razu linkować kartę EN do PL. Daje pełną kontrolę SEO (osobne URL-e, hreflang). Koszt to stała licencja, bez kredytów za słowa. Trafia w każdy nasz priorytet naraz.

Kluczowa obserwacja, która przesądza sprawę

W cenniku Polylang jest ostrzeżenie, że jego wbudowane auto-tłumaczenie DeepL nie działa z Elementorem — a nasze karty produktów są w Elementorze. Dla większości to wada. Dla nas to potwierdzenie kierunku: funkcji auto-tłumaczenia wtyczki i tak byśmy nie użyli, bo tłumaczy pipeline. Odpada więc ostatni powód, dla którego ktoś sięga po cięższy WPML. Nie potrzebujemy kombajnu do tłumaczenia — potrzebujemy lekkiego szkieletu, a resztę robi automatyzacja, którą już mamy.

Architektura

Podział ról: wtyczka vs pipeline

To jest myśl przewodnia całego rozwiązania. Zwykły problem stron dwujęzycznych — „kto przetłumaczy i utrzyma drugą wersję" — u nas jest już rozwiązany, bo produkty i tak powstają maszynowo. Wtyczka odpowiada tylko za strukturę, nie za treść.

Pipeline AI

Treść: generuje kartę PL i jej odpowiednik EN (tłumaczenie wg słownika terminologii OTDR)

REST

Zapis: tworzy oba rekordy i ustawia powiązanie językowe PL↔EN

Polylang

Szkielet: URL /en/, hreflang, przełącznik, tłumaczenie menu

Efekt: „każdy produkt ma wersję EN" nie oznacza „ktoś ręcznie pisze 310 kart". Oznacza „pipeline generuje EN przy okazji tworzenia PL, a przy istniejącym katalogu robi to falami". Utrzymanie nowych produktów przestaje być osobną pracą — staje się częścią tego samego kroku.

Wydajność

Dlaczego to nie spowolni strony

To był Twój główny niepokój, więc wprost: narzut każdej wtyczki dwujęzycznej powstaje przy generowaniu strony — a interlab.pl serwuje strony z LiteSpeed Cache. Każdy język cache'uje się osobno, więc odwiedzający (i pomiar Core Web Vitals, który robi Google) dostaje gotowy HTML, a nie „wtyczkę mielącą zapytania na żywo". Cięższy jest panel admina, nie front.

  • Polylang jest najlżejszym z realnych wyborów — mniej zapytań i tabel niż WPML.
  • Język domyślny (PL) konfigurujemy bez prefiksu w URL — obecne adresy interlab.pl/... zostają bajt w bajt, zero ryzyka dla dzisiejszego SEO.
  • Weryfikacja nie z teorii, lecz z pomiaru: Lighthouse przed i po instalacji na stagingu (mamy narzędzia) — decyzja o produkcji dopiero po zobaczeniu liczb.

Realizacja

Plan wdrożenia — etapy

Kolejność jest celowa: najpierw dowód na stagingu i pomiar wydajności, dopiero potem produkcja. Ze stagingu na produkcję przenosimy wiedzę i konfigurację, nie bazę danych (staging nie jest klonem produkcji — ID się różnią, więc treść EN budujemy na prodzie tym samym pipeline'em, sterowanym po slug).

Faza 0

Decyzje i przygotowanie

Zatwierdzenie zakresu startowego i budżetu przez zespół. Zakup licencji Business Pack (whitelistowanie adresu stagingu u supportu Polylang). Ustalenie, kto odpowiada za korektę terminologii EN.

Wynik: zgoda zespołu + licencja
Faza 1

Staging — instalacja i pomiar

Instalacja Polylang na stagingu. Pomiar Lighthouse przed. Konfiguracja: PL jako język domyślny bez prefiksu, EN pod /en/, hreflang, przełącznik. Pomiar Lighthouse po.

Wynik: liczby wydajności przed/po
Faza 2

Staging — jedna kategoria end-to-end

Przeprowadzenie jednej pełnej kategorii przez pipeline: karty produktów EN, kategoria EN, menu EN, hreflang, przełącznik. Wizualny i funkcjonalny dowód, że przepis działa na Elementorze.

Wynik: działający wzorzec do powielenia
Bramka

Decyzja GO / NO-GO

Zespół ocenia: wydajność (spadek ratingu?), jakość tłumaczeń, wygląd, pracochłonność. Dopiero pozytywna decyzja otwiera drogę na produkcję. Do tego momentu produkcja jest nietknięta.

Wynik: świadoma zgoda na produkcję
Faza 3

Produkcja — snapshot i instalacja

Pełny backup produkcji (baza + pliki) — to jest przycisk „cofnij". Instalacja i konfiguracja Polylang identycznie jak na stagingu: PL bez prefiksu, EN pod /en/.

Wynik: szkielet EN na prodzie + snapshot rollbacku
Faza 4

Produkcja — build EN falami

Generowanie wersji EN przez pipeline w kolejności priorytetu: strona główna i strony statyczne → kluczowe kategorie → topowe produkty → reszta katalogu → FAQ → blog. Katalog nie jest „zepsuty" w międzyczasie — brakujące EN mają fallback.

Wynik: rosnąca, indeksowalna wersja EN
Faza 5

SEO i indeksacja

Hreflang PL↔EN, osobna mapa strony dla EN, zgłoszenie w Google Search Console, kontrola indeksacji i braku duplikatów. Powiązanie z Yoast.

Wynik: EN widoczny i poprawny w Google
Faza 6

Utrzymanie — na stałe w procedurze

Aktualizacja procedury dodawania produktów: od teraz każdy nowy produkt to jeden krok tworzący PL + EN naraz. To eliminuje ryzyko rozjechania się katalogów w czasie.

Wynik: dwujęzyczność samopodtrzymująca się

Zakres

Co trzeba przetłumaczyć

Skala robocza dla pipeline'u (liczby orientacyjne wg obecnego stanu katalogu). Priorytet: najpierw to, co widzi zagraniczny klient przy pierwszym kontakcie.

~91
kategorie
~310
produkty
~300
Q&A (FAQ)
~40+
wpisy blog
strony statyczne, menu, stringi

Priorytet 1 (start): strona główna, O firmie, Kontakt, top kategorie, ~30 flagowych produktów. Daje wiarygodną wersję EN w krótkim czasie. Priorytet 2–3: reszta katalogu, FAQ, blog — falami.

Ryzyka

Ryzyka i sposób ich ograniczenia

RyzykoOgraniczenie
Spadek wydajności / ratinguPolylang lekki + LiteSpeed cache; pomiar Lighthouse przed/po na stagingu; bramka GO/NO-GO przed produkcją
Uszkodzenie obecnego SEOPL jako język domyślny bez prefiksu — dzisiejsze URL-e nie zmieniają się wcale
Jakość tłumaczeń technicznychTłumaczenie wg słownika terminologii OTDR EN↔PL + korekta domenowa na priorytetach
Konflikt z Elementorem / wtyczkamiCały test na stagingu; jedna kategoria end-to-end przed skalowaniem
Rozjechanie katalogów w czasieWpisanie kroku EN na stałe w procedurę dodawania produktów (Faza 6)
Duplicate content w GooglePoprawny hreflang + osobne mapy strony + kontrola w GSC

Bezpieczeństwo

Rollback — jak się wycofać

Polylang nie przepisuje treści PL w żaden własny format — trzyma język jako zwykłą taksonomię, a powiązania w kilku tabelach. Twoje produkty PL pozostają normalnymi produktami WooCommerce niezależnie od wtyczki.

  • Na stagingu: rollback = deaktywacja wtyczki. Zero konsekwencji dla produkcji, bo jej nie dotykaliśmy.
  • Na produkcji: prawdziwy przycisk „cofnij" to snapshot z Fazy 3 — przywracamy bazę i pliki, jest jak nie było.
  • Treści EN to osobne wpisy — po rollbacku „wiszą" bez powiązania, można je hurtowo usunąć lub zostawić jako szkice. Nic się nie psuje.
  • Dzięki PL bez prefiksu język domyślny nigdy się nie przesuwa — brak przekierowań do naprawy po wycofaniu.

Budżet

Koszty

PozycjaKosztCharakter
Polylang Business Pack (Pro + WooCommerce)139 €/roklicencja, staging w cenie
Odnowienie po roku~70 €/rok−50% rabatu
Tłumaczenie treści0 € narzędzirobi pipeline AI
Korekta terminologii ENczas zespołutylko priorytety
Praca wdrożeniowaczas / AIjednorazowa + falami

Uwaga: Business Pack (139 €), a nie zwykłe Pro (99 €), bo nasze produkty to produkty WooCommerce, których tłumaczenie jest tylko w dodatku Woo / Business Packu.

Do decyzji zespołu

Pytania otwarte na spotkanie

1. Zakres startowy

Pełny katalog EN od razu, czy „priorytet first" — landing + top kategorie/produkty na start, reszta falami?

2. Korekta techniczna EN

Kto z zespołu zaklepuje terminologię aparatury po tłumaczeniu maszynowym? To jedyny element wymagający człowieka.

3. Języki w przyszłości

Tylko EN, czy przewidujemy kolejne (DE, FR)? Polylang obsługuje wiele — warto wiedzieć, czy projektować pod skalę.

4. Harmonogram

Kiedy Faza 1 (staging + pomiar)? To niski-ryzykowny krok, który da twarde liczby przed jakąkolwiek decyzją o produkcji.

Konkluzja

Rekomendacja

Polylang Business Pack + generowanie EN przez pipeline AI to dla naszego przypadku wybór bijący alternatywy na całej linii: najlżejszy dla wydajności, najlepiej zgrany z automatyzacją, którą już mamy, z pełną kontrolą SEO, stałym kosztem i bezpiecznym rollbackiem. WPML i automaty odpadają, bo ich główne atuty (auto-tłumaczenie, „zero pracy") są u nas zbędne — treść dostarcza pipeline — a ich wady (waga, koszt bieżący, słabsze SEO) trafiają wprost w nasze priorytety.

Proponowany pierwszy krok: Faza 1 na stagingu — instalacja i pomiar wydajności przed/po. Niski koszt, zero ryzyka dla produkcji, a daje twarde liczby do decyzji.

Dokument roboczy · interlab.pl · przygotowany do dyskusji zespołowej · na tym etapie brak jakiejkolwiek ingerencji w stronę produkcyjną. Liczby katalogu orientacyjne wg stanu na 2026-07-05; ceny Polylang wg cennika producenta (bez VAT).