Automatyczne tłumaczenie treści stron i ofert z AI w n8n: jak budować pipeliney lokalizacji z kontekstem branżowym i glosariuszami

Problem z ręczną lokalizacją treści

Każda nowa strona, oferta czy opis usługi, które trzeba przetłumaczyć na dwa lub więcej języków, oznacza kolejne godziny pracy tłumacza, opóźnienia w publikacji i ryzyko niespójności terminologicznych. Automatyczne tłumaczenie z AI w n8n rozwiązuje ten problem, ale wymaga architektury, która zachowuje jakość — surowe wyjście z LLM nie nadaje się do publikacji bez glosariusza, kontekstu branżowego i walidacji.

Projektuję pipeliney tłumaczeń, które traktują AI jako silnik, ale kontrolują jego wyjście przez reguły biznesowe i glosariusze. Poniżej opisuję konkretną architekturę i decyzje, które podejmuję przy wdrażaniu takiego przepływu.

Architektura pipeline'u tłumaczeń w n8n

Pipeline tłumaczeń składa się z pięciu etapów, które muszę zaprojektować oddzielnie:

1. Pobranie źródła — webhook lub harmonogram pobiera treść z CMS, CRM lub pliku.
2. Przygotowanie kontekstu — dołączenie glosariusza, instrukcji stylu i informacji o branży.
3. Tłumaczenie przez LLM — zapytanie do modelu z pełnym kontekstem.
4. Walidacja i korekta — sprawdzanie spójności terminologicznej, długości i formatowania.
5. Eksport wyniku — zapis do CMS, pliku lub systemu zarządzania treścią.

Każdy etap implementuję jako osobny sub-workflow w n8n, co pozwala testować i modyfikować fragmenty bez przerywania całego przepływu.

Konfiguracja węzła tłumaczącego

W węźle AI Agent lub HTTP Request wysyłającym zapytanie do API modelu, konstruuję prompt z trzema sekcjami:

• Rola i instrukcja — określam, że model tłumaczy na konkretny język, zachowując ton i formatowanie źródła.
• Glosariusz — lista terminów z przypisanym tłumaczeniem, wstrzykiwana dynamicznie z bazy danych lub pliku JSON.
• Treść źródłowa — tekst do przetłumaczenia, oznaczony znacznikami, by model nie modyfikował struktury HTML ani shortcode'ów.

Przykład struktury zapytania:

Przetłumacz poniższy tekst na język angielski.

Glosariusz:
- usługa wdrożenia → implementation service
- opieka techniczna → technical maintenance
- audyt SEO → SEO audit

Zachowaj formatowanie HTML i nie tłumacz nazw własnych.

Tekst:
{{ $json.source_content }}

Budowanie glosariusza branżowego

Glosariusz to najważniejszy element pipeline'u tłumaczeń. Bez niego model będzie tłumaczył terminy techniczne i nazwy usług niespójnie — raz jako „implementation", innym razem jako „deployment".

Skąd pobrać terminy

• Istniejące tłumaczenia — eksportuję z CMS pary stron wielojęzycznych i wyciągam terminy, które pojawiają się konsekwentnie.
• Baza produktów i usług — nazwy usług z oferty firmy, które mają ustalone odpowiedniki w innych językach.
• Słowniki branżowe — standardy terminologiczne dla danej branży, jeśli są dostępne.

Jak przechowywać glosariusz w n8n

Używam węzła Redis lub bazy PostgreSQL jako trwałego magazynu glosariusza. Struktura rekordu:

{
  "term_pl": "opieka techniczna",
  "term_en": "technical maintenance",
  "term_de": "technische Betreuung",
  "context": "usługa utrzymania strony",
  "priority": 1
}

Pole priority pozwala mi sortować terminy — najważniejsze nazwy usług mają priorytet 1 i zawsze trafiają do promptu, nawet gdy okno kontekstu wymaga skrócenia glosariusza.

Dynamiczne wstrzykiwanie glosariusza

Przed wysyłką do LLM wyciągam z bazy terminy pasujące do treści źródłowej. Używam prostego dopasowania substringów w węźle Code — jeśli termin z glosariusza występuje w tekście źródłowym, dołączam go do promptu. Dzięki temu nie zaśmiecam okna kontekstu terminami, które nie są potrzebne dla danego tłumaczenia.

Integracja z CMS i systemami zarządzania treścią

Pipeline tłumaczeń musi być połączony z miejscem, gdzie treść jest publikowana. Projektuję integracje z dwoma typami źródeł:

Webhook jako wyzwalacz

Gdy autor dodaje lub aktualizuje stronę w CMS, system wysyła webhook do n8n z treścią źródłową i metadanymi (język źródłowy, język docelowy, identyfikator strony). n8n uruchamia pipeline i po zakończeniu wysyła przetłumaczoną treść z powrotem do CMS przez API.

Harmonogram dla masowych aktualizacji

Dla istniejących katalogów treści używam węzła Cron, który cyklicznie sprawdza, które strony zostały zmodyfikowane od ostatniego tłumaczenia, i uruchamia pipeline tylko dla zmienionych rekordów. Węzeł Code porównuje daty modyfikacji z tabeli logów tłumaczeń z datami modyfikacji w CMS.

Mapowanie pól do tłumaczenia

Nie każde pole w CMS wymaga tłumaczenia. Definiuję listę pól, które przechodzą przez pipeline:

• Tytuły stron i ofert
• Treść główna (body)
• Metadane SEO (title, description)
• Etykiety formularzy i komunikaty

Pola techniczne — slugi, nazwy plików, klucze API — wykluczam z tłumaczenia jawnym filtrem w węźle Code.

Walidacja i kontrola jakości tłumaczeń

Surowe tłumaczenie z LLM zawiera błędy, które muszę wykryć przed publikacją. Implementuję trzy warstwy walidacji:

1. Walidacja terminologiczna

Po otrzymaniu tłumaczenia sprawdzam, czy terminy z glosariusza zostały użyte poprawnie. W węźle Code iteruję po glosariuszu i weryfikuję, czy przetłumaczony termin występuje w wyniku. Jeśli nie — flaguję rekord do ręcznej weryfikacji.

2. Walidacja strukturalna

Porównuję strukturę HTML źródła i tłumaczenia. Sprawdzam:

• Liczbę nagłówków H1, H2, H3 — musi się zgadzać.
• Obecność znaczników shortcode — nie mogą zostać usunięte ani zmodyfikowane.
• Długość akapitów — jeśli tłumaczenie jest ponad dwukrotnie dłuższe lub krótsze od źródła, flaguję do weryfikacji.

3. Walidacja metadanych SEO

Dla pól SEO sprawdzam, czy tłumaczenie mieści się w limitach:

• Title tag: maksymalnie 60 znaków.
• Meta description: maksymalnie 155 znaków.

Jeśli tłumaczenie przekracza limit, węzeł Code przycina tekst lub wysyła ponowne zapytanie do LLM z instrukcją skrócenia.

Routing wyników po walidacji

Po walidacji routinguję wyniki do trzech ścieżek:

• Auto-accept — tłumaczenie przeszło wszystkie testy, trafia do CMS.
• Auto-retry — tłumaczenie nie przeszło walidacji strukturalnej, ponawiam zapytanie z dodatkową instrukcją korekty.
• Human review — tłumaczenie nie przeszło walidacji terminologicznej, trafia do kolejki z powiadomieniem na Slack lub e-mail.

Optymalizacja kosztów API przy masowych tłumaczeniach

Tłumaczenie całego katalogu produktów lub kilkudziesięciu stron jednorazowo generuje znaczne koszty API. Stosuję trzy strategie ograniczania wydatków:

Buforowanie identycznych fragmentów

Fragmenty, które powtarzają się na wielu stronach (np. bloki CTA, stopki, komunikaty formularzy), tłumaczę raz i buforuję w Redisie z kluczem opartym na hashu treści źródłowej i języku docelowym. Przed wysyłką do LLM sprawdzam, czy tłumaczenie fragmentu już istnieje w buforze.

Routing modeli według złożoności

Krótkie teksty metadanych SEO tłumaczę tańszym modelem (np. GPT-4o-mini), a długie treści stron — modelem wyższej jakości. Decyzję podejmuję w węźle Switch na podstawie długości tekstu źródłowego w tokenach.

Przetwarzanie wsadowe

Zamiast wysyłać każde tłumaczenie jako osobne zapytanie, grupuję krótkie fragmenty (metadane, etykiety) w jedno zapytanie batchowe z jawnymi separatorami między fragmentami. Ogranicza to liczbę wywołań API i redukuje koszty tokenów systemowych.

Checklist wdrożenia pipeline'u tłumaczeń

Przed uruchomieniem pipeline'u na produkcji weryfikuję każdy punkt:

• Glosariusz zawiera wszystkie kluczowe terminy z oferty firmy.
• Glosariusz jest podłączony do pipeline'u jako dynamiczne źródło danych.
• Prompt tłumaczący zawiera instrukcję zachowania formatowania HTML.
• Lista pól wykluczonych z tłumaczenia jest zdefiniowana i przetestowana.
• Walidacja terminologiczna flaguje brakujące terminy z glosariusza.
• Walidacja strukturalna porównuje liczbę nagłówków i obecność shortcode'ów.
• Walidacja SEO sprawdza długość title i meta description.
• Routing wyników rozdziela auto-accept, auto-retry i human review.
• Buforowanie powtarzalnych fragmentów jest włączone i testowane.
• Routing modeli według długości tekstu jest skonfigurowany w węźle Switch.
• Sub-workflowy są wersjonowane i przetestowane oddzielnie.
• Poświadczenia API są przechowywane w credential store n8n, nie w kodzie workflowu.
• Logi tłumaczeń zapisują datę, źródło, język docelowy i wynik walidacji.

Obsługa języka polskiego jako źródła

Polska morfologia i składnia tworzą specyficzne wyzwania dla LLM. Przy projektowaniu pipeline'u tłumaczeń z polskiego na inne języki uwzględniam:

• Zaimki i odmianę — polskie formy osobowe i rodzajowe często gubią się w tłumaczeniu na języki bez rodzajów (np. angielski). Dodaję do promptu instrukcję zachowania liczby i formy oryginału.
• Kolejność wyrazów — polski szyk swobodny może prowadzić do nienaturalnych konstrukcji w języku docelowym. W instrukcji określam, że tłumaczenie ma być idiomatyczne, nie dosłowne.
• Terminy branżowe — polskie terminy z branży IT i marketingu często mają ustalone odpowiedniki angielskie, które różnią się od dosłownego tłumaczenia. Glosariusz jest tu kluczowy.

Sub-workflowy jako moduły pipeline'u

Dzielenie pipeline'u na sub-workflowy pozwala mi utrzymać porządek i testowalność:

• translate-content — przyjmuje tekst, język docelowy i glosariusz, zwraca tłumaczenie.
• validate-translation — przyjmuje źródło i tłumaczenie, zwraca wynik walidacji i status.
• sync-to-cms — przyjmuje przetłumaczoną treść i metadane, wysyła do CMS przez API.

Każdy sub-workflow wywołuję przez węzeł Execute Workflow, co pozwala mi aktualizować logikę walidacji bez modyfikowania głównego przepływu.

---

Automatyzacja tłumaczeń to jeden z elementów szerszych wdrożeń AI, które projektuję dla firm — od pipelineów treści po integracje z CRM i systemami operacyjnymi. Jeśli planujesz skalować lokalizację treści lub potrzebujesz przepływu, który łączy tłumaczenie z publikacją i walidacją, mogę zaprojektować rozwiązanie dopasowane do Twojego stosu technologicznego.