Jak przetłumaczyliśmy całą platformę za pomocą AI (i co miało z tym wspólnego podejście Agile)

Pod koniec 2025 roku platforma Agile Academy istniała w dwóch językach: niemieckim i angielskim. Cztery miesiące później była dostępna w ośmiu. Nie zatrudniliśmy agencji tłumaczeniowej. Użyliśmy AI. A zasady Agile odegrały kluczową rolę.

Punkt wyjścia

Jedna platforma, dwie bazy kodu, dwa języki i rosnąca międzynarodowa publiczność.

Agile Academy to nie jest pojedyncza aplikacja. To cały ekosystem:

• Baza wiedzy Kirby CMS: 440+ artykułów w 10 sekcjach, każdy ze złożonym Layout JSON, odnośnikami krzyżowymi i routingiem URL per język
• Platforma Ruby on Rails: Strony rezerwacji szkoleń, kursy e-learningowe, procesy zakupowe, strony produktowe z plikami lokalizacyjnymi i widokami
• Systemy backendowe: Szablony mailingowe, fakturowanie, e-maile transakcyjne
• Tłumaczenia UI: Menu, stopki, breadcrumby, przyciski i sam przełącznik języków — na obu platformach

Wszystko to istniało tylko w języku niemieckim i angielskim. Tymczasem nie mogliśmy dostarczać wyselekcjonowanych treści osobom, które nie mówią po angielsku ani po niemiecku, a stanowiły one rosnący udział naszej publiczności.

Tłumaczenie tego nie było po prostu zadaniem contentowym. Każdy język wymagał:

• Nowych tras w konfiguracji PHP Kirby (przeglądy artykułów, przepisywanie slugów sekcji, przekierowania)
• Plików na poziomie sekcji ze zlokalizowanymi slugami URL
• Stron przeglądowych, stron docelowych i stron strukturalnych (prawne, wydarzenia, strony autorów)
• Plików lokalizacyjnych ROR dla menu, stopki, stron szkoleń, e-maili
• Szablonów mailingowych w backendzie
• Spójności między systemami: to samo słowo „artykuły” w URL-ach, te same linki do stron prawnych, ta sama struktura menu

Tradycyjna agencja tłumaczeniowa mogłaby obsłużyć tekst artykułów. Ale nikt nie napisze za nas tras PHP, nie naprawi layoutów JSON ani nie zaktualizuje plików lokalizacyjnych Railsów. Potrzebowaliśmy innego podejścia.

Iteracja 1: Hiszpański

Kopiuj-wklej, ręczne zmiany w kodzie i miesiąc ciężkiej pracy. Podejście kaskadowe.

Hiszpański był naszym pierwszym językiem ekspansji. Proces wyglądał następująco:

1. Skopiuj tekst artykułu do ChatGPT lub Claude
2. Wklej tłumaczenie z powrotem do nowego pliku
3. Ręcznie napraw Layout JSON (mając nadzieję, że go nie zepsujesz)
4. Powtórz 440 razy tylko dla Kirby
5. Osobno przetłumacz pliki lokalizacyjne ROR, widoki, szablony mailingowe
6. Ręcznie dodaj trasy, pliki sekcji, strony przeglądowe w Kirby
7. Ręcznie zaktualizuj pliki lokalizacyjne i trasy w ROR
8. Ręcznie utwórz szablony mailingowe w backendzie

Zajęło to około miesiąca. Przetłumaczono tylko najważniejsze strony w obu systemach. Jakość była niespójna. Niektóre artykuły używały formy grzecznościowej, inne potocznej. Terminy Agile były czasem tłumaczone, czasem nie. Odnośniki krzyżowe między artykułami prowadziły do nieistniejących stron.

Prace infrastrukturalne były jeszcze bardziej bolesne. Każdą trasę trzeba było napisać ręcznie. Każdy plik sekcji trzeba było stworzyć od zera. Slugi URL były niespójne. Platformy ROR i Kirby musiały być zsynchronizowane (te same linki w menu, ta sama stopka, te same strony prawne), a śledzenie, co zostało zrobione gdzie, było koszmarem arkuszy kalkulacyjnych.

W terminach Agile był to klasyczny waterfall: jedna wielka paczka, ograniczone pętle zwrotne, brak automatyzacji, brak wspólnych standardów. Dostarczyliśmy to, ale wiedzieliśmy, że nie możemy skalować tego podejścia na sześć kolejnych języków.

Iteracja 2: Portugalski

Pierwsza automatyzacja, pierwsze skrypty, pierwsze użycie Claude Code. Tydzień zamiast miesiąca.

Dla portugalskiego zmieniliśmy podejście. Zamiast kopiować i wklejać artykuł po artykule, napisaliśmy skrypty automatyzujące tłumaczenie przez wywołania API. Podaj angielskie źródło, otrzymaj przetłumaczony plik Kirby.

Co ważniejsze, zaczęliśmy używać Claude Code nie tylko do treści artykułów, ale także do prac infrastrukturalnych. Claude Code mógł przeczytać nasze istniejące trasy hiszpańskie i wygenerować odpowiedniki dla portugalskiego. Mógł tworzyć pliki sekcji, strony przeglądowe i aktualizować pliki konfiguracyjne.

Po stronie ROR Claude Code generował pliki lokalizacyjne na podstawie istniejących tłumaczeń hiszpańskich. Aktualizował szablony mailingowe, tworzył nowe widoki tam, gdzie było to potrzebne, i utrzymywał spójność odniesień między systemami.

Rezultat: około tygodnia zamiast miesiąca. Ale wskaźnik błędów wciąż był wysoki.

Skrypty nie rozumiały kontekstu. Tłumaczyły „Sprint” na portugalski. Psuły Layout JSON, dodając podziały wierszy wewnątrz ciągów znaków. Slugi URL czasem były błędne, ponieważ AI nie znał naszych konwencji routingu na obu platformach.

Spędziliśmy sporo czasu na przeglądzie i poprawkach. Ale co kluczowe, teraz dokonywaliśmy inspekcji i adaptacji. Każdy znaleziony błąd stawał się regułą dla następnej iteracji. Zaczęliśmy budować glosariusz. Udoskonaliliśmy prompt tłumaczeniowy. Udokumentowaliśmy konwencje URL, których obie platformy musiały przestrzegać.

Iteracje 3–6: Francuski, włoski, holenderski, polski

Wyspecjalizowane agenty, wiedza instytucjonalna i dwa dni na język.

Do czasu, gdy dotarliśmy do francuskiego, system dojrzał znacząco. Prawdziwą różnicę zrobiło podzielenie pracy.

Zamiast jednego dużego kontekstu AI próbującego obsłużyć wszystko, stworzyliśmy wyspecjalizowane agenty, każdy skupiony na jednej części systemu:

• Agenty tłumaczenia treści, które obsługiwały paczki artykułów Kirby, postępując zgodnie z promptem tłumaczeniowym i glosariuszem
• Agenty infrastrukturalne, które tworzyły trasy, pliki sekcji, strony przeglądowe w Kirby
• Agenty lokalizacyjne ROR, które tłumaczyły i tworzyły pliki lokalizacyjne dla platformy Rails
• Agenty weryfikacyjne, które uruchamiały skrypty wyłapujące uszkodzony JSON, błędne slugi URL, brakujące pola

Każdy agent miał zredukowane okno kontekstowe skupione na swoim konkretnym zadaniu. Dawało to znacznie lepsze wyniki niż jeden agent próbujący utrzymać całą platformę w pamięci.

Wiedza instytucjonalna była teraz skodyfikowana:

• Prompt tłumaczeniowy (TRANSLATION_PROMPT.md) definiował ton, format, reguły URL i wymóg dołączania informacji o AI
• Glosariusz (glossary.json) utrzymywał spójność terminów Agile we wszystkich językach
• Skrypty weryfikacyjne wyłapywały błędy zanim trafiły na produkcję: uszkodzony Layout JSON, błędne referencje hreflang, brakujące wymagane pola
• Lista kontrolna w CLAUDE.md dokumentowała każdy krok infrastrukturalny wymagany dla nowego języka (trasy, pliki sekcji, strony przeglądowe, strony strukturalne, synchronizacja menu/stopki)
• Kontrole spójności między systemami zapewniały synchronizację Kirby i ROR

Włoski zajął dwa dni. Holenderski zajął dwa dni. Polski zajął dwa dni. Każda iteracja była szybsza i bardziej niezawodna. Wskaźnik błędów spadał z każdym językiem, ponieważ system uczył się na każdym wcześniejszym błędzie.

Przed i po

To samo zadanie. Fundamentalnie inny system.

Zasady Agile w działaniu

To nie był tylko projekt tłumaczeniowy. To było sześć Sprintów uczenia się organizacyjnego.

Iteracyjne doskonalenie

Każdy język był Sprintem. Hiszpański był Sprintem 1: powolnym, ręcznym, pełnym nauki. Polski był Sprintem 6: szybkim, zautomatyzowanym, dopracowanym. Poprawa była wykładnicza. Każda iteracja nie tylko dodawała język. Ulepszała system na wszystkie przyszłe języki.

Inspekcja i adaptacja

Każdy błąd w jednym języku stawał się regułą zapobiegawczą dla następnego. Uszkodzony JSON? Dodaj walidator JSON do skryptu weryfikacyjnego. Przetłumaczono „Sprint” na portugalski? Dodaj go do glosariusza. Zła konwencja slugów URL? Udokumentuj ją na liście kontrolnej. System stawał się mądrzejszy, ponieważ wbudowaliśmy w niego pętle zwrotne.

Samoorganizujące się zespoły

Wyspecjalizowane agenty były w istocie samoorganizującymi się członkami zespołu. Każdy miał jasną odpowiedzialność, właściwy kontekst dla swojego zadania i zdefiniowane interfejsy z innymi. Agent treści nie musiał wiedzieć o trasach PHP. Agent infrastrukturalny nie musiał parsować Layout JSON. Separacja odpowiedzialności. Działa w oprogramowaniu i w zespołach.

Działające oprogramowanie ponad dokumentację

Prompt tłumaczeniowy, glosariusz, skrypty weryfikacyjne. Nic z tego nie zostało zaprojektowane z góry. Wszystko wynikało z realnych problemów napotykanych w realnej pracy. Prompt był przepisywany pięć razy. Glosariusz rósł z każdym językiem. Skrypty powstały z błędów, które przeszły przez ręczny przegląd. Żywa dokumentacja, ukształtowana przez faktyczne użycie, okazała się o wiele bardziej użyteczna niż jakakolwiek specyfikacja, którą moglibyśmy napisać z góry.

Reagowanie na zmiany

Nasze decyzje architektoniczne były napędzane przez błędy, nie przez planowanie z góry. Nie przewidzieliśmy, że Layout JSON będzie największym źródłem bugów. Odkryliśmy to podczas hiszpańskiego i zbudowaliśmy walidację przed portugalskim. Nie planowaliśmy specjalizacji agentów. Doszliśmy do niej po zobaczeniu, że jeden duży kontekst dawał gorsze wyniki niż kilka skoncentrowanych. Skończyliśmy z lepszym setupem niż cokolwiek, co moglibyśmy zaprojektować na tablicy.

Kluczowe wnioski

AI nie zastępuje myślenia Agile. Wzmacnia je.

1. AI wzmacnia twój proces — na dobre i na złe

Jeśli twój proces jest chaotyczny, AI wyprodukuje chaos szybciej. Jeśli twój proces jest zdyscyplinowany (jasne prompty, zdefiniowane standardy, pętle weryfikacyjne), AI wyprodukuje jakość na skalę. To samo narzędzie, które psuło nasz JSON w iteracji 1, produkowało bezbłędne wyniki w iteracji 6. AI się nie zmieniło. Nasz proces tak.

2. Kontekst jest wszystkim

Glosariusz, prompt tłumaczeniowy, lista kontrolna, reguły spójności między systemami. To wszystko są formy kontekstu. AI bez kontekstu to po prostu szybki tłumacz. AI z właściwym kontekstem to członek zespołu, który rozumie twoje konwencje, twoje przypadki brzegowe i twoje standardy jakości. Budowanie tego kontekstu to prawdziwa praca — i kumuluje się z każdym nowym językiem.

3. Rola człowieka przesuwa się z wykonawcy na architekta

W iteracji 1 ludzie tłumaczyli. W iteracji 6 ludzie projektowali system, definiowali standardy, przeglądali wyniki i doskonalili proces. Praca nie zniknęła. Przesunęła się na wyższy poziom myślenia. Mniej kopiowania i wklejania, więcej myślenia o tym, co składa się na dobre tłumaczenie, co tworzy spójne doświadczenie użytkownika i jak wyłapywać błędy zanim zrobią to użytkownicy.

4. Zacznij małymi krokami, dostarcz, ucz się, powtarzaj

Mogliśmy spędzić miesiące na projektowaniu „idealnego” pipeline'u tłumaczeniowego przed przetłumaczeniem choćby jednego artykułu. Zamiast tego zaczęliśmy od kopiowania i wklejania i iterowaliśmy. Każdy język czegoś nas nauczył. Każdy błąd ulepszył system. Zanim dotarliśmy do późniejszych języków, mieliśmy pipeline, którego żadne planowanie z góry nie mogłoby wyprodukować — ponieważ był ukształtowany przez realne problemy, nie hipotetyczne.