Workflow i18n w Vue 3 dla 500+ kluczy bez niespodzianek w produkcji

Co psuje się przy ponad 500 kluczach i18n

Gdy twoja aplikacja ma już kilkaset stringów, pierwszą rzeczą, która zwykle zaczyna szwankować, nie jest Vue I18n. To spójność. Ludzie dodają klucze w różnych stylach, duplikują ten sam pomysł pod różnymi nazwami i nikt nie jest pewien, które komunikaty można bezpiecznie usunąć.

Braki tłumaczeń przestają też być rzadkością. Pojawiają się na typowych ścieżkach użytkownika, zwłaszcza na rzadszych ekranach: ustawieniach, stanach błędu, pustych ekranach i powiadomieniach.

Gdy brakuje tłumaczenia, użytkownicy zwykle widzą jedną z trzech rzeczy: pusty interfejs (przycisk bez etykiety), surowe klucze (jak checkout.pay_now) albo dziwne zachowanie awaryjne, gdzie część strony przeskakuje na inny język. Żaden z tych przypadków nie wygląda jak drobny błąd — sprawia, że aplikacja wydaje się zepsuta.

Dlatego workflow i18n w Vue 3 ma większe znaczenie niż wybór konkretnej biblioteki. Biblioteka zrobi to, o co ją poprosisz. Przy skali zespoły często nie zgadzają się, co oznacza „zrobione”.

Typowy przykład: programista wypuszcza nowy przepływ „Invite teammate” z 40 nowymi stringami. Plik angielski jest zaktualizowany, ale francuski nie. Na stagingu wszystko wygląda dobrze, bo tester używa angielskiego. W produkcji użytkownicy francuscy widzą mieszankę przetłumaczonego i nieprzetłumaczonego UI, a support dostaje zrzuty ekranu surowych kluczy.

Naprawa to zdefiniowanie, co oznacza „zrobione” dla przetłumaczonego UI. Nie może to być tylko „dodane stringi”. Praktyczna definicja done zwykle obejmuje: klucze trzymają się reguł nazewnictwa, lokalizacje budują się bez ostrzeżeń o brakujących kluczach, liczby mnogie i zmienne renderują się poprawnie z prawdziwymi danymi, co najmniej jedna nie-domyślna lokalizacja została sprawdzona i zmiany copy są śledzone, żeby stare klucze nie zalegały.

Przy 500+ kluczach wygrywasz, traktując lokalizację jak proces wydania, a nie jak ostatnią zmianę w pliku.

Ustal kilka zasad zanim dodasz więcej stringów

Po kilku setkach stringów praca tłumaczeniowa przestaje być chaotyczna — to spójność staje się problemem. Mały zestaw zasad sprawia, że workflow i18n w Vue 3 jest przewidywalny, nawet gdy wiele osób co tydzień dotyka copy.

Zacznij od ustalenia, czym jest „pojęcie” (koncept) i trzymaj jedną źródłową definicję dla niego. Jeśli ten sam pomysł UI pojawia się w pięciu miejscach (np. „Save changes”), chcesz jednego klucza, a nie pięciu wariantów typu save, saveChanges, save_update czy saveBtn. Zduplikowane klucze z czasem dryfują w znaczeniu, co daje użytkownikowi odczucie niespójności.

Następnie zdecyduj, gdzie leży formatowanie. Zespoły często dzielą to przypadkowo: niektóre komunikaty zawierają interpunkcję i wielkie litery, inne polegają na tym, że kod je doda. Wybierz jedną strategię i się jej trzymaj.

Praktyczny domyślny podział:

• Umieszczaj gramatykę, interpunkcję i formatowanie widoczne dla użytkownika (np. „(opcjonalne)”) w wiadomości.
• Trzymaj czyste formatowanie danych w kodzie (daty, waluty, jednostki), a wynik przekazuj do i18n.
• Używaj placeholderów dla nazw i liczników, a nie konkatenacji stringów.
• Traktuj HTML w komunikatach jako przypadek specjalny z jasną regułą (dozwolone lub zabronione).

Potem zdefiniuj odpowiedzialności. Ustal, kto może dodawać nowe klucze, kto przegląda copy w języku bazowym i kto zatwierdza inne lokalizacje. Bez tego stringi są dodawane w pośpiechu i nigdy nie są przeglądane.

Na koniec wybierz i udokumentuj strategię fallbacku. Jeśli klucz jest nieobecny, co powinien zobaczyć użytkownik: nazwę klucza, tekst z domyślnej lokalizacji, czy bezpieczny komunikat ogólny? W produkcji wiele zespołów woli fallback do domyślnej lokalizacji plus logowanie, żeby użytkownicy nie byli zablokowani, a zespół nadal dostawał sygnał, że coś jest nie tak.

Jeśli budujesz aplikacje Vue 3 z generatora takiego jak AppMaster (Vue3 web UI plus prawdziwy backend), te zasady nadal mają zastosowanie. Traktuj tłumaczenia jak treść produktową, a nie jak „tylko tekst deweloperski”, a unikniesz większości późnych niespodzianek.

Konwencje nazewnictwa kluczy, które pozostają czytelne

Po przekroczeniu kilkuset stringów spójność jest największym mnożnikiem. Wybierz jeden styl kluczy (większość zespołów używa ścieżek kropkowych, np. billing.invoice.title) i zrób z tego regułę. Mieszanie kropek, slashy, snake_case i przypadkowego kapitalizowania spowalnia wyszukiwanie i przeglądy.

Używaj stabilnych kluczy, które przetrwają zmiany copy. Klucz typu "Please enter your email" zepsuje się w momencie, gdy marketing zmieni zdanie. Preferuj nazwy oparte na intencji, jak auth.email.required czy auth.email.invalid.

Grupuj klucze najpierw według obszaru produktu lub powierzchni UI, a potem według przeznaczenia. Myśl w tych samych kubełkach, które już masz w aplikacji: auth, billing, settings, support, dashboard. To ułatwia skanowanie plików locale i zmniejsza duplikaty, gdy dwa ekrany potrzebują tej samej idei.

W obrębie każdego obszaru trzymaj mały zestaw wzorców dla typowych elementów UI:

• Przycisk: *.actions.save, *.actions.cancel
• Etykiety: *.fields.email.label, *.fields.password.label
• Podpowiedzi/pomoc: *.fields.email.hint
• Błędy/walidacja: *.errors.required, *.errors.invalidFormat
• Powiadomienia/toasty: *.notices.saved, *.notices.failed

Komunikaty dynamiczne powinny mówić, co się zmienia, a nie jak to jest składane. Nazwij komunikat według intencji i używaj parametrów dla zmiennych części. Na przykład billing.invoice.dueInDays z {days} jest czytelniejsze niż billing.invoice.dueIn3Days.

Przykład (dobrze działa w workflow i18n Vue 3): orders.summary.itemsCount z {count} dla liczby oraz orders.summary.total z {amount} dla kwoty. Gdy ktoś widzi klucz w kodzie, powinien wiedzieć, gdzie przynależy i po co, nawet jeśli ostateczne zdanie się zmieni.

Zasady liczby mnogiej i formatowania komunikatów bez niespodzianek

Teksty z liczbami mnogimi psują się cicho, jeśli traktujesz każdy język jak angielski. Zdecyduj wcześnie, kiedy użyjesz składni ICU, a kiedy wystarczy prosty placeholder.

Używaj prostych zamian dla etykiet i krótkich tekstów UI, które nie zmieniają się zależnie od liczby (np. "Welcome, {name}"). Przejdź do ICU dla wszystkiego, co zależy od liczby, bo trzyma wszystkie formy w jednym miejscu i robi reguły jawne.

{
  "notifications.count": "{count, plural, =0 {No notifications} one {# notification} other {# notifications}}"
}

Pisz komunikaty z liczbami w sposób łatwy do przetłumaczenia. Preferuj pełne zdanie i trzymaj placeholder liczby (#) blisko rzeczownika. Unikaj sprytnych obejść, jak ponowne używanie tego samego klucza dla „1 item” i „2 items” w kodzie. Tłumacze muszą widzieć cały komunikat, a nie zgadywać, jak zostanie złożony.

Planuj co najmniej =0, one i other, i udokumentuj, czego oczekujesz dla 0. Niektóre produkty chcą „0 items”, inne wolą „No items”. Wybierz jeden styl i się go trzymaj, żeby UI było spójne.

Zwróć też uwagę na języki z większą liczbą kategorii mnogich niż się spodziewasz. Wiele języków nie przestrzega prostej pary „one vs many”. Jeśli później dodasz nową lokalizację, komunikat mający tylko one i other może być gramatycznie niepoprawny, nawet jeśli wyświetla się.

Przed wysyłką przetestuj liczby mnogie z prawdziwymi wartościami w UI, a nie tylko patrząc na JSON. Szybki test, który łapie większość problemów, to: 0, 1, 2, 5 i 21.

Jeśli budujesz aplikację Vue3 (np. w AppMaster), przetestuj to na ekranie, na którym tekst się pojawia. Problemy z layoutem, obcinaniem tekstu i niezręcznymi łamaniami linii pojawiają się tam najpierw.

Organizacja plików lokalizacji w miarę wzrostu

Po kilku setkach stringów jeden wielki en.json staje się wąskim gardłem. Ludzie edytują ten sam plik, konflikty merge rosną, i tracisz orientację, gdzie leży copy. Dobra struktura utrzymuje workflow i18n w Vue 3 stabilnym, nawet gdy produkt się zmienia.

Sugerowane struktury

Dla 2–5 lokalizacji dzielenie po funkcjach zwykle wystarcza. Trzymaj taką samą strukturę plików w każdej lokalizacji, żeby dodanie klucza było przewidywalną zmianą.

• locales/en/common.json, locales/en/auth.json, locales/en/billing.json
• locales/es/common.json, locales/es/auth.json, locales/es/billing.json
• locales/index.ts (ładuje i scala komunikaty)

Dla 20+ lokalizacji zastosuj tę samą ideę, ale utrudnij dryf. Traktuj angielski jako źródło prawdy i wymuszaj, by każda lokalizacja odzwierciedlała te same foldery i nazwy plików. Jeśli pojawi się nowa domena (np. notifications), powinna istnieć we wszystkich lokalizacjach, nawet jeśli tekst jest tymczasowy.

Dzielenie po domenach redukuje konflikty merge, bo dwie osoby mogą dodawać stringi do różnych plików, nie wchodząc sobie w drogę. Domeny powinny odpowiadać strukturze twojej aplikacji: common, navigation, errors, settings, reports, plus foldery funkcyjne dla większych obszarów.

Utrzymanie spójności kluczy

W obrębie każdego pliku trzymaj ten sam kształt kluczy we wszystkich lokalizacjach: to samo zagnieżdżenie, te same nazwy kluczy, inne teksty. Unikaj „kreatywnych” kluczy w każdym języku, nawet jeśli fraza ciężko się tłumaczy. Jeśli angielski ma billing.invoice.status.paid, każda lokalizacja musi mieć dokładnie ten klucz.

Centralizuj tylko to, co naprawdę powtarza się wszędzie: etykiety przycisków, ogólne błędy walidacji i globalna nawigacja. Kopia specyficzna dla funkcji trzymaj blisko domeny funkcji, nawet jeśli wydaje się wielokrotnego użytku. „Save” należy do common. „Save payment method” należy do billing.

Treści dłuższe

Długie teksty pomocy, kroki onboardingowe i szablony e-maili szybko robią się nieporęczne. Kilka zasad pomaga:

• Umieszczaj treści długie w osobnej domenie (np. help lub onboarding) i unikaj głębokiego zagnieżdżenia.
• Preferuj krótkie akapity zamiast jednego ogromnego stringa, żeby tłumacze mogli pracować bezpiecznie.
• Jeśli marketing lub support często edytuje tekst, trzymaj te komunikaty w dedykowanym pliku, by zmniejszyć churn gdzie indziej.
• Dla e-maili przechowuj temat i treść oddzielnie i trzymaj placeholdery spójne (imiona, daty, kwoty).

Taka organizacja ułatwia przegląd zmian, tłumaczenie stopniowe i unikanie niespodzianek tuż przed wydaniem.

Krok po kroku: workflow dodawania i wypuszczania stringów

Stabilny workflow i18n w Vue 3 to mniej narzędzi, a więcej powtarzalnych, małych kroków. Nowy tekst UI nie powinien trafić do produkcji bez klucza, domyślnego komunikatu i jasnego statusu tłumaczenia.

Zacznij od dodania klucza do twojej bazy lokalnej (często en). Napisz domyślny tekst jak prawdziwe copy, nie placeholder. To daje produktowi i QA coś czytelnego do przeglądu i zapobiega „tajemniczym stringom” później.

Gdy używasz klucza w komponencie, uwzględnij parametry i logikę pluralną od pierwszego dnia, żeby tłumacze widzieli pełny kształt wiadomości.

// simple param
$t('billing.invoiceDue', { date: formattedDate })

// plural
$t('files.selected', count, { count })

Jeśli tłumaczenia nie są gotowe, nie zostawiaj brakujących kluczy. Dodaj tłumaczenia-wypełniacze w innych lokalizacjach albo oznacz je jako pending w spójny sposób (np. prefiks TODO:). Ważne, by aplikacja renderowała przewidywalnie, a przeglądający mogli szybko znaleźć nieukończone copy.

Przed mergem uruchom szybkie automatyczne kontrole. Niech będą nudne i surowe: brakujące klucze między lokalizacjami, nieużywane klucze, niedopasowanie placeholderów (brak {count}, {date} lub złe nawiasy), niepoprawne formy pluralne dla wspieranych języków i przypadkowe nadpisania.

Na koniec zrób krótkie przejrzenie UI w co najmniej jednej niebazowej lokalizacji. Wybierz język z dłuższymi tekstami (często niemiecki lub francuski), aby złapać overflow, obcięte przyciski i niezręczne łamania linii. Jeśli twoje UI Vue3 jest generowane lub utrzymywane wraz z innymi częściami produktu (np. aplikacją Vue3 produkowaną przez AppMaster), ten krok nadal ma znaczenie, bo layouty zmieniają się wraz z rozwojem funkcji.

Traktuj te kroki jako definicję done dla każdej funkcji, która dodaje tekst.

Typowe błędy, które zespoły powtarzają

Najszybszy sposób, by uczynić lokalizację uciążliwą, to traktować klucze i18n jak „zwykłe stringi”. Po kilku setkach kluczy małe nawyki zamieniają się w błędy produkcyjne.

Klucze, które dryfują, kolidują albo kłamią

Literówki i różnice w kapitalizacji to klasyczne przyczyny brakującego tekstu: checkout.title w jednym miejscu, Checkout.title w drugim. Na przeglądzie kodu wygląda to dobrze, a potem fallback języka cicho trafia do produkcji.

Inny częsty problem to ponowne używanie jednego klucza dla różnych znaczeń. „Open” może oznaczać „Otwórz zgłoszenie” na ekranie supportu i „Otwórz teraz” na stronie sklepu. Jeśli użyjesz jednego klucza, jedno z tych miejsc będzie niepoprawne w innych językach, a tłumacze będą zgadywać.

Prosta reguła pomaga: jeden klucz = jedno znaczenie. Jeśli znaczenie się zmienia, stwórz nowy klucz, nawet jeśli angielski tekst jest taki sam.

Błędy layoutu spowodowane założeniami „tekstowymi”

Zespoły często hardkodują interpunkcję, odstępy lub fragmenty HTML w tłumaczeniach. To działa, dopóki język nie wymaga innej interpunkcji albo UI nie renderuje markupu inaczej. Trzymaj decyzje o znacznikach w template'ach, a komunikaty skupione na tekście.

Na urządzeniach mobilnych problemy się ukrywają. Etykieta, która mieści się w angielskim, może zawijać się na trzy wiersze po niemiecku albo wykroczyć poza ramkę po tajsku. Jeśli testujesz tylko jeden rozmiar ekranu, nie zauważysz tego.

Obserwuj typowe przewinienia: zakładanie kolejności słów z angielskiego przy wstawianiu zmiennych (imiona, liczniki, daty), składanie komunikatów przez konkatenację zamiast używania pojedynczego komunikatu, brak testów dla długich wartości (nazwy produktów, adresy, szczegóły błędu), wysyłka z włączonym cichym fallbackiem, więc brakujące klucze wyglądają "ok" po angielsku, i kopiuj-wklej kluczy edytując tylko angielski.

Jeśli chcesz workflow i18n w Vue 3, który pozostaje spokojny przy 500+ kluczach, traktuj klucze jako część API: stabilne, konkretne i testowane jak wszystko inne.

Kroki QA, które wcześnie wychwytują brakujące tłumaczenia

Brakujące tłumaczenia łatwo przeoczyć, bo aplikacja wciąż „działa”. Po prostu cofa się do klucza, złego locale albo pustego stringa. Traktuj pokrycie tłumaczeń jak testy: chcesz szybki feedback zanim cokolwiek trafi do produkcji.

Automatyczne kontrole (uruchamiane na każdym PR)

Zacznij od kontroli, które przerywają build, nie tylko drukują ostrzeżenia, których nikt nie czyta.

• Skanuj codebase pod $t('...') i t('...'), następnie weryfikuj, że każdy użyty klucz istnieje w bazowej lokalizacji.
• Porównaj zestawy kluczy między lokalizacjami i przerwij build, jeśli którejś lokalizacji brakuje kluczy (chyba że klucz jest na krótkiej, przeglądanej liście wyjątków, jak „en-only legal notes”).
• Oznacz klucze osierocone, które są w plikach locale, ale nigdzie nie są używane.
• Waliduj składnię wiadomości (placeholdery, bloki ICU/plural). Pojedynczy uszkodzony komunikat może zrzucić stronę w runtime.
• Traktuj zdublowane klucze albo niezgodności kapitalizacji jako błędy.

Trzymaj listę wyjątków krótko i pod opieką zespołu, nie jako „cokolwiek przejdzie CI”.

Kontrole runtime i wizualne (staging)

Nawet przy CI chcesz mieć siatkę bezpieczeństwa na stagingu, bo prawdziwe ścieżki użytkownika wywołują teksty, które zapomniałeś, że są dynamiczne.

Włącz logowanie brakujących tłumaczeń na stagingu i dołącz kontekst potrzebny do szybkiej naprawy: locale, route, nazwa komponentu (jeśli dostępna) i brakujący klucz. Niech będzie głośne. Jeśli łatwo to zignorować, to zostanie zignorowane.

Dodaj pseudolokalizację i użyj jej do szybkiego przeglądu UI. Proste podejście to przetransformowanie każdego stringu (wydłużenie i dodanie markerów), żeby problemy z layoutem rzucały się w oczy, np.: [!!! 𝗧𝗲𝘅𝘁 𝗲𝘅𝗽𝗮𝗻𝗱𝗲𝗱 !!!]. To łapie obcięte przyciski, złamane nagłówki tabel i brakujące odstępy przed wysyłką.

Na końcu wykonaj krótkie przed-wydaniem sprawdzenie najważniejszych ścieżek w 2–3 lokalizacjach: logowanie, checkout/płatność, kluczowe ustawienia i nowa funkcja, którą wypuszczasz. Tam łapiesz „przetłumaczono, ale placeholder jest zły”.

Dodawanie nowych języków i bieżące zmiany copy

Dodanie nowego języka robi się chaotyczne, gdy traktujesz to jako „pracę copy” zamiast małe wydanie produktowe. Najłatwiejszy sposób, by workflow i18n w Vue 3 pozostał stabilny, to sprawić, by aplikacja budowała się nawet gdy locale jest niekompletne, a jednocześnie by luki były widoczne zanim użytkownicy je zobaczą.

Gdy dodajesz nową lokalizację, zacznij od wygenerowania tej samej struktury plików co lokalizacja źródłowa (często en). Nie tłumacz najpierw, zrób strukturę najpierw.

• Stwórz nowy folder/pliki lokalizacji z pełnym zestawem kluczy skopiowanym z źródła.
• Oznacz wartości jako placeholdery TODO, żeby brakujące stringi były widoczne w QA.
• Dodaj język do przełącznika dopiero po pokryciu podstaw.
• Przeprowadź jedno ekranowe przejście, by złapać problemy z layoutem (dłuższe słowa, zawijanie).

Tłumaczenia często przychodzą późno, więc ustal wcześniej, co oznacza „częściowe” dla twojego produktu. Jeśli funkcja jest skierowana do klienta, rozważ flagę funkcji, żeby funkcja i jej stringi wypłynęły razem. Jeśli musisz wypuścić bez pełnych tłumaczeń, preferuj jasny fallback (np. angielski) zamiast pustych etykiet, ale niech będzie to głośne na stagingu.

Aktualizacje copy to miejsce, gdzie zespoły psują klucze. Jeśli zmieniasz sformułowanie, zostaw klucz stabilny. Klucze powinny opisywać intencję, nie dokładne zdanie. Zmianę nazwy klucza rób tylko, gdy zmienia się znaczenie, i wtedy przeprowadź kontrolowaną migrację.

Aby uniknąć „zombie strings”, deprecjonuj klucze celowo: oznacz je jako przestarzałe z datą i zamiennikiem, trzymaj przez jeden cykl wydania, a potem usuń po potwierdzeniu, że nie ma żadnych referencji.

Trzymaj notatki tłumaczeniowe blisko klucza. Jeśli twój format JSON nie pozwala na komentarze, przechowuj notatki w małym dokumencie towarzyszącym lub w pliku metadanych (np. "używane na ekranie sukcesu checkout"). To jest szczególnie pomocne, gdy twoja aplikacja Vue 3 jest generowana z narzędzia takiego jak AppMaster i wiele osób dotyka copy i UI.

Przykład: wypuszczenie funkcji z 60 nowymi stringami

W jednym sprincie zespół wypuszcza trzy rzeczy naraz: nową stronę Ustawień, ekran Billing i trzy szablony e-maili (paragon, płatność nieudana, kończący się trial). To około 60 nowych stringów i tu zaczyna się zwykle bałagan i18n.

Zespół zgadza się grupować klucze według funkcji, potem według powierzchni. Tworzy się nowy plik dla każdej funkcji, a klucze trzymają ten sam wzór wszędzie: feature.area.element.

// settings
"settings.profile.title": "Profile",
"settings.security.mfa.enable": "Enable two-factor authentication",

// billing
"billing.plan.current": "Current plan",
"billing.invoice.count": "{count} invoice | {count} invoices",

// email
"email.receipt.subject": "Your receipt",
"email.payment_failed.cta": "Update payment method"

Zanim zacznie się praca tłumaczeniowa, stringi z pluralami są testowane z realistycznymi wartościami, a nie domysłami. Dla billing.invoice.count QA sprawdza 0, 1, 2 i 5 używając seeded danych (albo prostego przełącznika deweloperskiego). To wcześnie łapie niezręczne przypadki, jak "0 invoice".

QA wykonuje wtedy skoncentrowany przepływ ujawniający brakujące klucze: otwiera Settings i Billing i klika każdą kartę raz, wywołuje każdy szablon e-maila na stagingu kontami testowymi, uruchamia aplikację z aktywną nie-domyślną lokalizacją i zleca przerwanie builda, jeśli w logach pojawią się ostrzeżenia o brakujących tłumaczeniach.

W tym sprincie QA znajduje dwa brakujące klucze: jedną etykietę na ekranie Billing i jeden temat e-maila. Zespół naprawia je przed wydaniem.

Przy decyzji, czy zablokować wydanie czy pozwolić na fallback, stosują prostą zasadę: ekrany skierowane do użytkownika i e-maile transakcyjne blokują wydanie; teksty niskiego ryzyka, tylko dla adminów, mogą tymczasowo wracać do języka domyślnego, ale tylko z ticketem i jasnym deadline'em.

Następne kroki i prosta lista kontrolna wydania

Workflow i18n w Vue 3 pozostaje stabilny, gdy traktujesz tłumaczenia jak kod: dodawaj je w ten sam sposób za każdym razem, testuj i mierz rezultaty.

Lista kontrolna wydania (5 minut przed mergem)

• Klucze: trzymaj się wzorca nazewnictwa i zachowaj zakres jasny (strona, funkcja, komponent).
• Plurale: potwierdź, że formy mnogie renderują poprawnie przynajmniej w jednym języku z wieloma regułami pluralnymi.
• Placeholdery: zweryfikuj, że zmienne istnieją, mają takie same nazwy wszędzie i wyglądają poprawnie z prawdziwymi danymi.
• Fallbacki: potwierdź, że zachowanie przy brakującym kluczu odpowiada twojej polityce.
• Ekrany: przejrzyj na gorąco kilka ekranów najbardziej narażonych na błędy (tabele, toasty, modalne okna, puste stany).

Co mierzyć (żeby problemy pojawiały się wcześnie)

Wybierz kilka prostych liczb i przeglądaj je regularnie: wskaźnik brakujących kluczy w twoim teście, liczba nieprzetłumaczonych stringów w nie-domyślnych lokalizacjach oraz liczba nieużywanych kluczy (stringi, które już nigdzie się nie pojawiają). Śledź je per wydanie, jeśli to możliwe, żeby widzieć trendy zamiast jednorazowych incydentów.

Zapisz dokładne kroki dodawania stringa, aktualizacji tłumaczeń i weryfikacji rezultatu. Trzymaj to krótkie i dołącz przykłady nazw kluczy i użycia pluralów. Nowi współtwórcy powinni potrafić to zrobić bez pytań.

Jeśli budujesz narzędzia wewnętrzne, AppMaster (appmaster.io) może być praktycznym sposobem na utrzymanie spójności copy UI i kluczy tłumaczeń między aplikacją Vue3 web a aplikacjami mobilnymi, bo wszystko jest zarządzane w jednym miejscu.

Zaplanuj jedno małe zadanie zdrowotne i18n w każdym sprincie: usuń martwe klucze, popraw niespójne placeholdery i przejrzyj ostatnie braki. Małe porządki biją panikę o tłumaczenia na produkcji.