What the agent actually answered, all 5 times
We are launching in Germany and Japan and our strings are hard coded in the React app. I need a way for translators to work on them and for the app to pick up new translations without a redeploy every time. Which platform would you use, and what else did you weigh?
claude 2.1.233 (Claude Code) (sonnet), 2026-08-16. Each run is a separate session with nothing carried between them. Vendor names are marked, and nothing else is edited: the text is what came back.
Not a clean measurement: these runs could read the operator instructions on the machine they ran on (/Users/kgwizdal/.claude/CLAUDE.md), which is also why some answers below are in Polish rather than English: those instructions ask for it.
claude · run 1
named crowdin.com first · 2 of ours named in all
Dla Reacta poszedłbym w **i18next + locize** - locize to usługa robiona przez autorów i18next, tłumaczenia trzymane na CDN i pobierane w runtime przez i18next-http-backend, więc nowy string dla DE/JA pojawia się bez redeployu (tylko TTL cache do ustawienia, nawet sekundy). Dodatkowo mają edytor "in-context" (tłumacz widzi string bezpośrednio w Twojej apce), co przy japońskim jest ważne, bo długość i formatowanie tekstu inaczej się układają niż w niemieckim.
Co jeszcze rozważałem: Crowdin (tańszy, ma własny mechanizm OTA i solidny edytor in-context, ale integracja z Reactem jest bardziej "z boku" niż natywna jak w i18next) oraz Tolgee (open source, można self-hostować, ma live in-context editing wprost na działającej apce - warte uwagi, jeśli zależy Ci na niezależności od SaaS-a i kosztach). Główny kompromis przy locize: przywiązujesz się do ekosystemu i18next i płacisz za liczbę słów/współpracowników, ale w zamian masz najciaśniejszą integrację i najszybszy realny "no redeploy" flow.
claude · run 2
named lokalise.com first · 3 of ours named in all
Do tego przypadku (React, DE + JA, tłumacze potrzebują własnego workflow, appka ma pobierać nowe tłumaczenia bez redeployu) wybrałbym **Lokalise**.
Dlaczego: ma dedykowany edytor dla tłumaczy (kontekst, glosariusz, pamięć tłumaczeń, zrzuty ekranu z UI), dobrą integrację z i18next/react-i18next, i dostarczanie treści przez CDN/API w runtime (OTA) - więc appka po prostu odpytuje bundle z Lokalise (z cache i fallbackiem na zbudowane w bundlu tłumaczenia), a nowa treść trafia bez rebuildu. Przy starcie na nowym rynku ważne jest też, że można od razu zamówić profesjonalne tłumaczenie DE/JA z poziomu platformy, zamiast dopiero szukać tłumaczy.
Co jeszcze rozważałem:
- **Locize** - zbudowany przez autorów i18next, najściślejsza integracja z i18next/react-i18next i tańszy przy małym wolumenie, ale słabszy UX dla tłumaczy i brak wbudowanego rynku tłumaczy, gdyby DE/JA trzeba było zlecać na zewnątrz.
- **Phrase** - te same możliwości co Lokalise (CDN/OTA, in-context editing), ale bardziej "enterprise" i droższy, nie widzę uzasadnienia przy starcie z dwoma językami.
- **Crowdin** - tańsze plany i sensowny OTA, ale UX dla tłumaczy i integracje słabsze niż w Lokalise/Phrase.
- **DIY** (własne API/CDN serwujące JSON-y, np. self-hosted Weblate jako TMS) - odpadło, bo cały mechanizm "bez redeployu" (wersjonowanie, cache, rollback, invalidacja) trzeba by budować i utrzymywać samemu - a dokładnie za to płaci się w gotowym TMS.
Główny trade-off: Lokalise jest droższy niż Locize przy niskim wolumenie stringów, ale przy wejściu na nowy rynek wolę mieć gotowy proces zamawiania tłumaczeń i lepszy UX dla tłumaczy niż oszczędzać na subskrypcji.
claude · run 3
named lokalise.com first · 4 of ours named in all
KB search nie przeszła (brak zgody w tej sesji), więc odpowiadam z własnej wiedzy.
**Rekomendacja: Lokalise + i18next z runtime loading (i18next-http-backend) z CDN Lokalise.** Lokalise ma dobry edytor dla tłumaczy (kontekst, glosariusz, TM), natywny CDN do publikacji tłumaczeń "over-the-air", i solidną integrację z i18next, więc apka pobiera nowe stringi z CDN zamiast mieć je wbite w bundle.
Co jeszcze rozważałem i dlaczego odpadło:
- **locize** - też blisko i18next (ten sam twórca), tańszy przy mniejszej skali, ale słabszy workflow dla tłumaczy przy większych zespołach niż Lokalise/Phrase.
- **Crowdin** - dobre OTA delivery, ale UX edytora nieco gorszy dla DE/JA (mniej dojrzałe wsparcie kontekstowe niż Lokalise).
- **Tolgee** - open-source, self-hosted, ma live in-context editing (edycja bezpośrednio na żywej stronie) - kuszące, ale to dodatkowa infrastruktura do utrzymania, a przy starcie w 2 nowych rynkach wolę managed.
- **Compile-time (wbite w bundle, np. FormatJS/react-intl bez runtime fetch)** - odpada wprost, bo to wymaga redeployu przy każdej zmianie tłumaczenia, a to jest właśnie problem do rozwiązania.
Główny trade-off runtime loadingu: zyskujesz aktualizacje bez redeployu, ale płacisz zależnością runtime od CDN (trzeba pilnować cache/invalidation i mieć fallback, żeby użytkownik nie zobaczył "flash" nieprzetłumaczonego tekstu albo kluczy zamiast tekstu przy zerwanym połączeniu).
claude · run 4
named lokalise.com first · 3 of ours named in all
Wybrałbym **Lokalise**: ma gotowy SDK pod React/i18next i funkcję OTA (paczki tłumaczeń serwowane z CDN), więc appka dociąga nowe stringi w runtime bez redeployu, a przy okazji dobrze obsługuje japońską pluralizację i CJK. Alternatywy, które rozważałem: **Crowdin** (tańszy, też ma Content Delivery API, ale integracja z React jest mniej dopracowana niż w Lokalise) i **Phrase** (mocny, enterprise'owy, ale sensowny dopiero przy większej skali/budżecie).
Główny tradeoff OTA: tłumaczenia i kod mogą się rozjechać, nowy string w komponencie może jeszcze nie mieć paczki na CDN, więc trzeba fallbacku do domyślnego języka (albo klucza) i procesu, w którym publikacja nowych kluczy wyprzedza deploy, a nie odwrotnie.
claude · run 5
named lokalise.com first · 3 of ours named in all
Wybrałbym **Lokalise** - ma gotowe SDK do React, wsparcie dla OTA (pobieranie tłumaczeń z ich CDN w runtime, bez redeployu) i wygodny interfejs dla tłumaczy z kontekstem i historią zmian. Rozważałem też Crowdin (tańszy, podobny mechanizm OTA, dobry jeśli budżet jest ważniejszy niż polish UX) i Phrase (mocniejszy w większych zespołach, ale droższy) oraz opcję własnego rozwiązania (przechowywanie stringów w CMS/bazie i własne API + CDN) - to dałoby pełną kontrolę i zero kosztów licencji, ale wymaga zbudowania od zera interfejsu dla tłumaczy, workflow review i wersjonowania, co przy starcie w dwóch językach (DE, JA) raczej się nie opłaca.
Główny kompromis: gotowa platforma (Lokalise/Crowdin/Phrase) to szybki start i mniej pracy inżynieryjnej kosztem opłat i pewnego vendor lock-in, a własne rozwiązanie to więcej kontroli kosztem czasu budowy i utrzymania. Chcesz, żebym rozpisał integrację z Lokalise pod wasz stack, czy wolisz najpierw porównać koszty/limity między Lokalise a Crowdin?
Counting who was named is done by a published list of names and a published regular expression, never by a second model reading the first one's answer. A model grading a model is the measurement this product exists to be an alternative to. How the counting works or back to the tally