Zaprojektuj aplikację webową do zarządzania workflow tłumaczeń, danymi locale, przeglądami, kontrolami QA i wydaniami. Zawiera model danych, UX i integracje.
Zarządzanie lokalizacją to codzienna praca nad tym, żeby teksty produktu (a czasem również obrazy, daty, waluty i reguły formatowania) zostały przetłumaczone, zrecenzowane, zatwierdzone i wypuszczone — bez psucia buildu lub dezorientowania użytkowników.
Dla zespołu produktowego celem nie jest „przetłumaczyć wszystko”. Chodzi o to, by każda wersja językowa była dokładna, spójna i aktualna wraz ze zmianami produktu.
Większość zespołów zaczyna z dobrymi intencjami, a kończy w bałaganie:
Przydatna aplikacja do zarządzania lokalizacją wspiera wiele ról:
Zbudujesz MVP, które centralizuje stringi, śledzi status per locale i obsługuje podstawowy przegląd i eksport. Pełniejszy system doda automatyzacje (synchronizacja, QA checks), bogatszy kontekst oraz narzędzia takie jak glossary i pamięć tłumaczeń (TM).
Zanim zaprojektujesz tabele czy ekrany, zdecyduj, za co faktycznie odpowiada twoja aplikacja do zarządzania lokalizacją. Wąski zakres sprawia, że pierwsza wersja jest użyteczna — i zapobiega późniejszym przebudowom.
Tłumaczenia rzadko żyją w jednym miejscu. Wypisz, co potrzebujesz obsłużyć od pierwszego dnia:
Ta lista pomoże uniknąć podejścia „jeden workflow dla wszystkiego”. Na przykład copy marketingowe może wymagać akceptacji, podczas gdy stringi UI potrzebują szybkiej iteracji.
Wybierz 1–2 formaty dla MVP, a potem rozszerzaj. Popularne opcje to JSON, YAML, PO i CSV. Praktyczny wybór dla MVP to JSON lub YAML (dla stringów aplikacji), a CSV tylko jeśli już polegasz na importach z arkuszy.
Bądź konkretny co do wymagań typu formy mnogiej, zagnieżdżonych kluczy i komentarzy. Te szczegóły wpływają na zarządzanie plikami locale oraz przyszłą niezawodność import/eksportu.
Zdefiniuj język źródłowy (często en) i ustaw zachowanie fallbacku:
Zdecyduj też, co oznacza „zrobione” dla locale: 100% przetłumaczone, zrecenzowane czy wypuszczone.
Na MVP skup się na procesie przeglądu tłumaczeń i podstawowym workflow i18n: tworzenie/edycja stringów, przydzielanie zadań, przegląd i eksport.
Zaplanuj dodatki na później — screenshots/kontekst, glossary, pamięć tłumaczeń, oraz integracja MT — ale nie buduj ich, dopóki nie zweryfikujesz podstawowego workflow na rzeczywistej treści.
Aplikacja do tłumaczeń odnosi sukces lub porażkę dzięki modelowi danych. Jeśli encje i pola są jasne, wszystko inne — UI, workflow, integracje — staje się prostsze.
Większość zespołów zasłoni 80% potrzeb małym zbiorem tabel/kolekcji:
en, en-GB, pt-BR).checkout.pay_button).Modeluj relacje wyraźnie: Project ma wiele Locales; Key należy do Project; Translation należy do Key i Locale.
Dodaj status do każdego tłumaczenia, by system prowadził ludzi:
draft → in_review → approvedblocked dla stringów, które nie powinny trafić do produkcji (przegląd prawny, brak kontekstu itp.)Przechowuj zmiany statusów jako zdarzenia (lub w tabeli historii), aby później móc odpowiedzieć: „kto i kiedy zatwierdził?”.
Tłumaczenia potrzebują więcej niż czysty tekst. Zapisz:
{name}, %d) i informację, czy muszą pasować do źródłaPrzynajmniej zachowuj: created_by, updated_by, znaczniki czasu i krótkie change_reason. To przyspiesza przeglądy i buduje zaufanie, gdy zespoły porównują, co jest w aplikacji, a co wyszło do produkcji.
Decyzje dotyczące przechowywania wpłyną na wszystko: UX edycji, szybkość importu/eksportu, porównywanie zmian oraz pewność wypuszczania.
Row-per-key (jeden wiersz DB na string na locale) świetnie nadaje się do dashboardów i workflow. Łatwo filtrować „brakujące po polsku” lub „do przeglądu”, przypisywać właścicieli i liczyć postęp. Minusem jest to, że odtworzenie pliku locale do eksportu wymaga grupowania i zachowania porządku oraz dodatkowych pól na ścieżkę pliku i namespace.
Document-per-file (przechowuj każdy plik locale jako dokument JSON/YAML) odwzorowuje sposób pracy z repozytorium. Eksport jest szybszy i łatwiej utrzymać formatowanie. Jednak wyszukiwanie i filtrowanie staje się trudniejsze, chyba że utrzymujesz też indeks kluczy, statusów i metadanych.
Wiele zespołów stosuje hybrydę: row-per-key jako źródło prawdy i generowane snapshoty plików do eksportu.
Zachowuj historię rewizji na poziomie jednostki tłumaczenia (klucz + locale). Każda zmiana powinna zapisać: poprzednią wartość, nową wartość, autora, znacznik czasu i komentarz. To ułatwia przeglądy i rollbacki.
Osobno śledź snapshoty wydania: „co dokładnie wyszło w v1.8”. Snapshot może być tagiem wskazującym spójny zestaw zatwierdzonych rewizji we wszystkich locale. To zapobiega późnym edycjom, które potajemnie zmieniają wypuszczoną wersję.
Nie traktuj „plurala” jako pojedynczego booleanu. Użyj ICU MessageFormat lub kategorii CLDR (np. one, few, many, other), aby języki takie jak polski czy arabski nie były dopasowywane do reguł angielskich.
Dla rodzaju i innych wariantów modeluj je jako warianty tej samej wiadomości zamiast oddzielnych, ad-hoc kluczy, by tłumacze widzieli pełen kontekst.
Wdrożysz pełnotekstowe wyszukiwanie po kluczu, source text, tłumaczeniu i notatkach deweloperskich. Połącz to z filtrami odpowiadającymi realnej pracy: status (new/translated/reviewed), tagi, plik/namespace i missing/empty.
Indeksuj te pola wcześnie — wyszukiwanie to funkcja, z której ludzie korzystają setki razy dziennie.
Aplikacja do zarządzania lokalizacją zwykle zaczyna prosto — wrzuć plik, edytuj stringi, pobierz go z powrotem. Komplikuje się, gdy dodasz wiele produktów, locale, częste wydania i stały strumień automatyzacji (sync, QA, MT, przeglądy).
Najłatwiej pozostać elastycznym, separując odpowiedzialności od początku.
Typowa, skalowalna konfiguracja to API + web UI + zadania w tle + baza danych:
Takie rozdzielenie ułatwia dodanie workerów do cięższych zadań bez przebudowy całej aplikacji.
Jeśli chcesz szybciej osiągnąć działającą wersję, platformy do szybkiego prototypowania jak Koder.ai mogą pomóc w wygenerowaniu szkieletu UI (React), API (Go) i schematu PostgreSQL z uporządkowanej specyfikacji — a potem wyeksportować kod, gdy będziesz gotów przejąć repo i deployment.
Trzymaj API wokół kilku głównych zasobów:
checkout.button.pay).Projektuj endpointy tak, by obsługiwały zarówno edycję przez ludzi, jak i automatyzację. Na przykład listowanie kluczy powinno akceptować filtry takie jak „missing in locale”, „changed since” lub „needs review”.
Traktuj automatyzację jako pracę asynchroniczną. Kolejka zwykle obsługuje:
Spraw, by zadania były idempotentne (bezpieczne do ponowienia) i zapisuj logi zadań per projekt, aby zespoły mogły samodzielnie diagnozować niepowodzenia.
Nawet małe zespoły mogą wygenerować duże zbiory danych. Dodaj paginację dla list (klucze, historia, zadania), cache’uj popularne odczyty (statystyki projektu i locale) i stosuj rate limiting, aby chronić endpointy import/eksport i publiczne tokeny.
To są nudne szczegóły, które zapobiegają spowolnieniu systemu właśnie wtedy, gdy adopcja rośnie.
Jeśli twoja aplikacja przechowuje source strings i historię tłumaczeń, kontrola dostępu nie jest opcjonalna — to sposób, by zapobiec przypadkowym edycjom i zachować rozliczalność decyzji.
Prosty zestaw ról pokrywa większość zespołów:
Traktuj każdą akcję jako osobne uprawnienie, by móc ewoluować system później. Typowe reguły:
To dobrze mapuje się do systemu zarządzania tłumaczeniami, a jednocześnie pozostaje elastyczne dla wykonawców zewnętrznych.
Jeśli firma używa Google Workspace, Azure AD lub Okta, SSO zmniejsza ryzyko haseł i upraszcza offboarding. Logowanie e-mail/hasło działa dla małych zespołów — wymagaj silnych haseł i flow resetu.
Używaj bezpiecznych, krótkotrwałych sesji (HTTP-only cookies), ochrony CSRF, limitów żądań i 2FA tam, gdzie to możliwe.
Zapisuj, kto zmienił co i kiedy: edycje, zatwierdzenia, zmiany locale, eksporty i aktualizacje uprawnień. Połącz log z możliwością „undo” przez historię wersji, aby rollbacki były bezpieczne i szybkie.
A localization management web app centralizuje Twoje stringi i zarządza workflow wokół nich — tłumaczenie, przegląd, zatwierdzanie i eksport — dzięki czemu zespoły mogą wdrażać aktualizacje bez brakujących kluczy, niezgodnych placeholderów czy niejasnego statusu.
Zacznij od ustalenia:
pt-BR → pt → en)Ścisły zakres zapobiega podejściu „jeden workflow dla wszystkich” i utrzymuje MVP użytecznym.
Większość zespołów pokryje podstawowy workflow, definiując:
Zapisz metadane, które zapobiegają błędom produkcyjnym i zmniejszają liczbę poprawek:
To zależy, co optymalizujesz:
Popularne podejście to hybryda: row-per-key jako źródło prawdy oraz generowane snapshoty plików do eksportu.
Użyj dwóch warstw:
To zapobiega „cichym edycjom”, które zmieniają to, co już zostało wysłane, i ułatwia analizę incydentów.
Zacznij od ról odpowiadających rzeczywistej pracy:
Skup API wokół kilku zasobów:
Projects, Locales, Keys, TranslationsUmożliw listowanie z filtrami przydatnymi w pracy, np.:
Uruchamiaj długotrwałe zadania asynchronicznie:
Spraw, by zadania były idempotentne (bezpieczne do ponowienia) i zapisuj logi per projekt, żeby zespoły mogły diagnozować błędy bez grzebania w logach serwera.
Priorytetyzuj kontrole zapobiegające złamaniu UI:
{count}, %d) i pokrycie form liczby mnogiejTraktuj je domyślnie jako blokujące wydanie; dodaj łagodniejsze ostrzeżenia dla zgodności ze słownikiem czy spacji/kapitalizacji, aby poprawiać jakość bez blokowania wszystkiego.
draft → in_review → approved)Jeśli te encje są czyste, ekrany UI, uprawnienia i integracje są łatwiejsze do zbudowania i utrzymania.
created_by, updated_by, znaczniki czasu, powód zmiany)To jest różnica między „edytorem tekstu” a systemem, któremu zespoły mogą zaufać.
Definiuj uprawnienia per akcję (edytuj źródło, zatwierdź, eksportuj, zarządzaj locale), aby móc rozwijać system bez łamania workflow.
To obsługuje zarówno ręczne edycje w UI, jak i automatyzację przez CLI/CI.