Dziesięć języków do aplikacji, która ma teksty wpisane na sztywno
Panel B2B ma 400 ekranów i wszystkie teksty po polsku wpisane bezpośrednio w JSX. Firma wchodzi na 10 rynków w ciągu pół roku. Zespół tłumaczy jest zewnętrzny, a developerzy nie mogą zatrzymać pracy nad funkcjami.
Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.
Moje rozwiązanie
Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.
Pokaż, czego szuka rekruter, i modelową odpowiedź
Co sprawdza rekruter
- Czy planujesz migrację stopniowo i z automatyzacją
- Czy znasz format ICU i bibliotekę, która go obsługuje
- Czy projektujesz proces z tłumaczami, a nie tylko kod
Odpowiedź seniora
Biblioteka z obsługą ICU MessageFormat (react-intl / FormatJS, i18next z ICU, next-intl lub Lingui), bo polskie odmiany, płeć i liczby wymagają czegoś więcej niż podmiany stringów. Klucze nazywam po znaczeniu i miejscu (checkout.summary.total), nie po treści.
Migracja: codemod lub narzędzie ekstrakcji (np. formatjs extract, Lingui extract) wyciąga teksty z JSX do katalogu wiadomości, reszta ręcznie moduł po module. Reguła ESLint zabrania nowych tekstów wpisanych na sztywno, więc problem nie rośnie. Tłumaczenia ładowane leniwie per język i per obszar aplikacji, nie jeden plik na 2 MB.
Proces: plik źródłowy synchronizowany z platformą tłumaczeń (Crowdin, Lokalise, Phrase) w CI, kontekst i zrzuty ekranu dla tłumaczy, brakujące tłumaczenia z fallbackiem i raportem, pseudo-lokalizacja w testach do wykrycia nieprzetłumaczonych i ucinanych tekstów. Wdrażam rynek po rynku za flagą.
Typowe wpadki
- Sklejanie zdań z kawałków: t('masz') + liczba + t('wiadomosci')
- Klucze będące polskim tekstem
- Ręczne wysyłanie plików JSON do tłumaczy mailem
Dopytają o
- Jak obsłużysz teksty pochodzące z backendu i CMS-a?
- Jak przetestujesz, że nowy ekran nie ma brakujących tłumaczeń?
- Kto zatwierdza tłumaczenia i jak wycofasz błędne?