Translation and localization: the agent answers

I’d use **Phrase Strings with `react-i18next` and Phrase’s i18next OTA delivery**—assuming the budget supports it.

It fits your requirements particularly well:

- Translators get a browser editor, comments, screenshots, QA checks, review states, and an in-context React workflow. [Phrase editor](https://support.phrase.com/hc/en-us/articles/5822638157340-Strings-Editor-Overview)
- Approved translations can be published as an OTA release and loaded by the app without rebuilding it.
- Releases can be scoped by locale, app version, branch, or tag.
- If Phrase or the network is unavailable, its OTA mechanism supports falling back to the last successful download or bundled translations. [Phrase OTA documentation](https://support.phrase.com/hc/en-us/articles/5804059067804-Over-the-Air-Strings)
- An EU data center is available in Ireland, relevant to German/EU procurement and privacy review. [Phrase data centers](https://support.phrase.com/hc/en-us/articles/5748008399388-Data-Centers)

The architecture I’d implement is:

1. Replace hard-coded text with stable keys such as `checkout.payment_failed`.
2. Use `react-i18next` and ICU-style messages for interpolation and plurals.
3. Commit an English baseline—and preferably last-known German and Japanese bundles—with the app.
4. Fetch a versioned, reviewed Phrase release at startup, cache it, and fall back to the bundled files.
5. Let translators edit freely, but only serve translations after review and an explicit production release.
6. Export translation files regularly so Phrase is not your only copy.

One important distinction: changing an existing German or Japanese translation would not require a redeploy. Adding a completely new UI message still normally requires a code deployment because the component must reference its new key.

### What else I weighed

| Platform | Why I considered it | Why it wasn’t my first choice |
|---|---|---|
| **Crowdin** | Strong translation workflow, integrations, and CDN-based content delivery. Probably my value-oriented runner-up. | I prefer Phrase’s documented i18next OTA release/fallback model for this specific React setup. |
| **Lokalise** | Excellent translator experience, screenshots, workflows, branching, and broad developer mindshare. | Its official OTA SDK documentation currently emphasizes iOS, Android, and Flutter; web React would involve more custom OTA API/CDN plumbing. [Lokalise OTA](https://developers.lokalise.com/docs/ota-sdk) |
| **Transifex Native** | The cleanest direct React runtime model: its React SDK fetches newly published translations from its content delivery service. [Transifex React SDK](https://developers.transifex.com/docs/react-sdk) | More coupling to Transifex’s runtime/source-string model; I’d rather retain ordinary i18next JSON files and easier portability. |
| **Self-hosted JSON on S3/CloudFront** | Cheap, fast, fully controlled, and easy for the app to fetch at runtime. | You would still need to build translator UI, permissions, review, screenshots, translation memory, audit history, and publishing controls—or connect another TMS anyway. |

The main argument against Phrase is cost: its current Team plan is listed at **$1,245/month billed annually**, with OTA request limits, so it may be disproportionate for a small product. [Phrase pricing](https://phrase.com/pricing/) If that quote is uncomfortable, I’d pilot **Crowdin** next rather than weakening the architecture.

For Germany and Japan specifically, I would also require:

- `de-DE` and `ja-JP`, not generic language assumptions.
- `Intl.NumberFormat` and `Intl.DateTimeFormat` for currency, dates, numbers, and time zones.
- No sentence construction by concatenating fragments.
- Translator screenshots and character/context notes.
- Native linguistic review—especially for Japanese formality, terminology, spacing, and line wrapping.
- Pseudolocalization and visual regression checks before launch.

I’d use **Phrase Strings**, integrated with `i18next`/`react-i18next` and Phrase’s over-the-air distribution.

It fits the important distinction here:

- Developers deploy new UI and new translation keys.
- Translators can update German and Japanese values afterward.
- Approved translations are released through Phrase and fetched at runtime, without rebuilding the React app.

Phrase explicitly supports OTA delivery for web apps using i18next, including release controls, locale fallbacks, cached translations, and bundled-file fallback if its service is unavailable. It also offers EU-hosted OTA endpoints, which is useful for a German launch. [Phrase OTA documentation](https://support.phrase.com/hc/en-us/articles/5804059067804-Over-the-Air-Strings)

### Recommended shape

Refactor hard-coded text into stable keys:

```tsx
const { t } = useTranslation();

return <button>{t('checkout.place_order')}</button>;
```

Then:

1. Keep English source strings and keys in the repository.
2. Push or synchronize those keys to Phrase in CI.
3. Let translators work in Phrase with screenshots, descriptions, glossary terms, and review status.
4. Publish only reviewed translations to an OTA production distribution.
5. Load translations at startup, cache the last successful version, and fall back to bundled English if loading fails.
6. Periodically pull translations back into the repository so the app never depends exclusively on the network.

Phrase’s editor provides review workflows, comments, screenshots, metadata, and QA checks. [Phrase Strings editor](https://support.phrase.com/hc/en-us/articles/5822638157340-Strings-Editor-Overview)

One caveat: OTA usage is plan-limited. Current documented web request allowances range from 500,000 on Starter to 25 million on Business, so expected traffic and caching strategy need to be part of the quote. [Phrase limits](https://support.phrase.com/hc/en-us/articles/8548271212188-Phrase-Strings-Limits)

### What else I weighed

| Platform | Why it was considered | Why I wouldn’t lead with it |
|---|---|---|
| **Transifex Native** | Probably the cleanest direct React/JavaScript OTA model. New translations become available without restarting or deploying. [JavaScript SDK](https://developers.transifex.com/docs/javascript-sdk) | Its source-phrase/native SDK approach creates more platform coupling than conventional i18next resource files. I’d choose it if minimizing localization plumbing outweighed portability. |
| **Crowdin** | Good translator collaboration, automation, and CDN/OTA delivery; often attractive on price and for teams already using Crowdin. | Its documented OTA path is less directly aligned with a conventional React-web/i18next stack, so I’d expect a little more integration work. |
| **Lokalise** | Strong translator experience, screenshots, workflows, integrations, and a credible enterprise shortlist candidate. | I would validate its exact React-web runtime-delivery behavior and pricing in a proof of concept before choosing it over Phrase’s explicit i18next OTA support. |
| **Build-time JSON in Git** | Simple, portable, inexpensive, and resilient. | Every translation correction requires a build/redeploy, so it fails your core requirement unless paired with your own translation CDN. |
| **Home-grown translation API/CDN** | Maximum control and potentially lower marginal cost. | You would still need to build translator UI, permissions, review, audit history, screenshots, QA, glossary support, caching, and rollback. Rarely worthwhile at this stage. |

Before signing, I’d run a short proof of concept with Phrase and Transifex using roughly 50 real strings. Test preview context, reviewer approval, rollback, missing-key behavior, cache expiry, service outage behavior, and Japanese typography.

Also, “no redeploy” can safely cover **changes to translations for existing keys**. Adding a new button, interpolation variable, or plural structure remains a code change and should still go through deployment. Keep OTA publishing gated—an instant translator-save-to-production pipeline makes accidental copy changes far too easy.

I’d use **Phrase Strings with `react-i18next` and Phrase’s over-the-air distribution**.

It fits both sides of the problem:

- Translators get a proper editor, context, comments, glossary/translation memory, review states, and assignments.
- The React app downloads approved translation bundles at runtime, so German and Japanese copy can be published without rebuilding the application.
- Phrase officially supports OTA delivery for `i18next`, including scheduled or manually promoted releases, locale fallbacks, and cached/bundled translations when its service is unavailable. [Phrase OTA documentation](https://support.phrase.com/hc/en-us/articles/5804059067804-Over-the-Air-Strings)

I’d implement it this way:

1. Replace hard-coded strings with stable semantic keys such as `checkout.payment_failed`, using ICU-compatible interpolation and plurals.
2. Keep English, German, and Japanese fallback files in the repository.
3. Extract and push new English keys to Phrase in CI.
4. Let translators work in Phrase, with screenshots or developer notes for ambiguous strings.
5. Serve only reviewed translations through separate staging and production OTA distributions.
6. Cache the downloaded bundle and fall back to the bundled English or last-known-good version if delivery fails.

Keeping `react-i18next` as the application-facing API is important: Phrase remains the translation backend rather than becoming deeply embedded throughout your components.

What else I weighed:

| Option | Assessment |
|---|---|
| **Transifex Native** | My runner-up. Its React SDK is particularly clean for runtime delivery and can discover strings from code. I’d choose it if minimal file handling and the fastest initial migration mattered more than platform portability. [Transifex React](https://www.transifex.com/react-i18n/) |
| **Lokalise** | Excellent translator experience and automation, but its official OTA SDKs currently focus on iOS, Android, and Flutter. A React web app would require more custom OTA/API plumbing. [Lokalise OTA](https://developers.lokalise.com/docs/ota-sdk) |
| **Crowdin** | Strong collaboration, integrations, and vendor marketplace. Worth including in a commercial trial, especially if price or community translation matters, but Phrase’s documented `i18next` OTA path is a more direct fit here. |
| **Self-hosted JSON on S3/CDN** | Cheap and operationally simple, but you would need to build review workflows, permissions, glossary/translation memory, version promotion, audit history, and translator UI yourself. |
| **Build-time localization only** | Reliable and easy to cache, but fails the explicit no-redeploy requirement. |

Before committing, I would run the same 30–50 representative strings through Phrase and Transifex with the actual German and Japanese translators. Score editor usability, screenshots/context, review and rollback, branching, API latency, support, and total cost. Phrase’s OTA usage is plan-limited, and its current business pricing is sales-led, so traffic volume and translator-seat requirements need to be priced explicitly. [Phrase pricing](https://phrase.com/pricing/)

One boundary I’d preserve: OTA should update copy, not application behavior. New keys and UI structure still ship through normal deployments; translators can safely revise already-defined text between releases.

I’d use **Locize with `react-i18next`/i18next**.

It fits this case unusually well: React-native integration, a translator-facing editor, review workflows, and CDN delivery of approved translations. Translators can correct German or Japanese copy and publish it without rebuilding the React app. Locize is maintained by the i18next team, which keeps the integration fairly direct. [Locize’s i18next integration](https://www.locize.com/i18next) and [react-i18next’s setup guide](https://react.i18next.com/latest) document the pairing.

### Recommended design

- Replace hard-coded text with stable keys such as `checkout.payment_failed`.
- Use English as the source/fallback locale, with `de` and `ja` as targets.
- Organize keys into namespaces such as `common`, `checkout`, and `account`.
- Send new keys to Locize from development or CI.
- Require translator/reviewer approval before publishing production translations.
- Have production clients read approved resources from Locize’s CDN.
- Bundle or cache a known-good English translation set so an outage never produces blank UI.
- Never ship a Locize write credential or enable `saveMissing` in production. Public CDN reads do not require an API key. [Locize production guidance](https://www.locize.com/docs/guides/going-to-production)

One important boundary: translators can update the translation of an **existing key** without a deployment. Introducing a new screen, key, interpolation variable, or layout still requires a code release.

### What I weighed

| Option | Assessment |
|---|---|
| **Locize** | Best fit for a React-only product wanting simple runtime delivery. Tight i18next integration, versioning, review, glossary, in-context editing, and CDN publishing. Current plans are transparent and start much lower than enterprise suites; review workflows begin on the Growth tier. [Pricing](https://www.locize.com/pricing) |
| **Phrase Strings** | My choice if you expect a larger localization organization, multiple product platforms, vendor management, sophisticated TMS workflows, or stricter enterprise procurement. It supports i18next OTA delivery and fallback behavior, but adds more platform and cost than this React use case appears to need. Its current Team plan is listed at €/$1,245 per month annually. [OTA documentation](https://support.phrase.com/hc/en-us/articles/5804059067804-Over-the-Air-Strings), [pricing](https://phrase.com/pricing/) |
| **Lokalise** | Excellent translator experience and broad integrations. However, its first-party OTA SDKs currently focus on iOS, Android, and Flutter; a web React implementation would lean on its API or a custom delivery layer. That makes it less direct here. [OTA SDK documentation](https://developers.lokalise.com/docs/ota-sdk) |
| **Crowdin** | Strong choice for community/open-source localization and supports CDN/OTA patterns. Its most prominent first-party OTA workflow is mobile-oriented, so I would prefer Locize’s maintained i18next backend for this specific SPA. [Crowdin OTA](https://crowdin.com/features/ota-content-delivery) |
| **Git-hosted JSON + CI** | Cheapest and gives engineering full control, but translators must work through Git or another editor, and publishing usually means a build/deploy unless you construct and operate your own CDN pipeline. |
| **Home-grown translation API** | Maximum control and possible self-hosting, but you would be rebuilding translation memory, glossary, permissions, review state, placeholder validation, audit history, and translator UX. Not worthwhile at this stage. |

### Guardrails I’d insist on

Use a staging and production translation version, publish only reviewed strings, validate placeholders and plural forms, and retain rollback history. Cache resources rather than fetching on every render.

For Germany and Japan, also test text expansion, compound German labels, Japanese line breaking, formal tone, addresses, names, dates, numbers, and currencies using `Intl` rather than translated formatting strings. Give translators screenshots or descriptions—short strings such as “Save,” “Order,” and “Back” are otherwise easy to mistranslate.

I’d run a short pilot with one complete flow, around 100–200 keys, and have the actual German and Japanese translators evaluate the editor before committing. The likely final choice remains Locize unless enterprise workflow or procurement requirements push the decision toward Phrase.

I’d use **Phrase Strings with `i18next`/`react-i18next` and Phrase OTA**.

It fits your requirements unusually directly: translators get a proper browser-based translation and review workflow, while Phrase’s official OTA integration supports i18next and serves approved translations to the React app at runtime. It also caches the last successful download and falls back to translations bundled with the application if Phrase is unavailable. [Phrase OTA documentation](https://support.phrase.com/hc/en-us/articles/5804059067804-Over-the-Air-Strings)

A sensible architecture is:

1. Replace hard-coded text with stable keys such as `checkout.payment_failed`.
2. Keep English, German, and Japanese resources in i18next format.
3. Push source strings to Phrase through its CLI or CI integration.
4. Give translators screenshots, descriptions, character limits, glossary terms, and interpolation variables in Phrase.
5. Publish only reviewed translations to a production OTA distribution.
6. Have the app load that distribution at startup, with cached and bundled English resources as fallbacks.

I would still commit a translation snapshot during normal releases. OTA should update existing copy and translations, but the app must remain usable during an outage, first load, or bad localization release. It also should not become a way to introduce new UI behavior remotely.

What I weighed:

| Platform | Assessment |
|---|---|
| **Phrase Strings** | Best fit because it has an explicit i18next OTA integration, review gates, release distributions, locale fallbacks, and resilient caching. The tradeoff is cost: OTA requests are plan-limited, and current team pricing is aimed more at established companies than tiny teams. [Pricing and limits](https://phrase.com/pricing/) |
| **Crowdin** | Strong runner-up, and potentially preferable for a cost-sensitive or community-driven project. It has good translator UX, screenshots, Git/CLI automation, and a JavaScript OTA client backed by its CDN. Its most polished first-party OTA story is still presented around native mobile, so I consider the React-web path slightly less turnkey. [Crowdin JS client](https://crowdin.github.io/crowdin-api-client-js/index.html) |
| **Lokalise** | Excellent editor, automation, branching, and developer workflow. I would choose it readily if translations were delivered at build time. Its official OTA SDKs are primarily iOS, Android, and Flutter; React web requires using its OTA API or building a custom integration, which is unnecessary engineering here. [Lokalise OTA documentation](https://developers.lokalise.com/docs/ota-sdk) |
| **Self-hosted files on S3/CloudFront** | Cheapest runtime delivery and maximum control, but you would still need to build or buy translator editing, review, screenshots, audit history, permissions, publishing, and rollback. Usually false economy unless you already operate those pieces. |

Two details matter for Germany and Japan:

- Use `de-DE` and `ja-JP` deliberately, with English fallback behavior defined rather than relying only on browser-language guessing.
- Treat formatting as localization, not translation: use `Intl` for dates, numbers, currencies, time zones, and pluralization. Never ask translators to construct sentences by concatenating fragments.

Before signing, I’d run the same representative 50–100 strings through Phrase and Crowdin with the actual German and Japanese translators. The deciding test is whether they can understand context, flag ambiguity, review changes, and safely publish without engineering help—not merely whether both vendors can store JSON.

I’d use **Locize with `react-i18next`**.

It is the most direct fit for your requirements: translators get a translation-management UI, while the React app loads approved translations from a CDN at runtime. Publishing a German or Japanese correction therefore doesn’t require rebuilding the application. Locize is built by the i18next team and supports automatic string capture, translation memory, terminology, review workflows, versioned environments, and in-context editing. [Locize overview](https://www.locize.com/) · [production guidance](https://www.locize.com/docs/guides/going-to-production)

A sensible architecture would be:

- Replace hard-coded copy with stable semantic keys such as `checkout.payment_failed`.
- Use `react-i18next` for lookup, interpolation, pluralization, and locale selection.
- Keep development, staging, and production translation versions separate.
- Let translators edit freely, but only serve reviewed and explicitly published production translations.
- Load published resources from Locize’s CDN with browser caching.
- Ship at least the source language—and preferably the last approved German and Japanese resources—as a local fallback. The app must remain usable if the CDN is unavailable.
- Never put a Locize write API key in the browser. Production should have read-only access to published resources. These are also Locize’s documented production recommendations. [CDN fallback](https://www.locize.com/docs/general-questions/i-want-to-use-the-locize-cdn-but-would-like-to-have-a-fallback-that-uses-local-bundled-translations)

What I weighed:

| Platform | Strength | Why I would or wouldn’t choose it |
|---|---|---|
| **Locize** | Tightest React/i18next integration and runtime CDN delivery | Best match for a React-first team wanting low integration overhead. Public pricing starts inexpensively, though CDN requests and advanced workflow requirements need sizing. [Pricing](https://www.locize.com/pricing) |
| **Phrase Strings** | More comprehensive enterprise localization suite; web/i18next OTA support | My alternative if you need sophisticated governance, vendor management, or a broader localization organization. Likely more platform and cost than this initial two-market launch needs. [Phrase OTA](https://support.phrase.com/hc/en-us/articles/5804059067804-Over-the-Air-Strings) · [pricing](https://phrase.com/pricing/) |
| **Lokalise** | Excellent translator experience, integrations, and automation | Strong TMS, but its official OTA SDK documentation currently emphasizes Android, iOS, and Flutter rather than React web. For this exact delivery model I’d want a proof of concept or use a separate export/CDN pipeline. [OTA SDK](https://developers.lokalise.com/docs/ota-sdk) |
| **Crowdin** | Good collaboration, screenshots, community translation, and OTA | Attractive when crowdsourcing or a large contributor community matters. Its clearest first-party OTA story is mobile; less natural than Locize for an ordinary React web app. [Crowdin OTA](https://crowdin.com/features/ota-content-delivery) |
| **Self-hosted JSON + object storage/CDN** | Maximum control and low vendor dependency | Technically straightforward, but you would have to build translator access, approvals, history, glossary, notifications, and publishing safety. Usually false economy unless compliance or scale justifies it. |

Two important boundaries:

1. OTA should update **copy**, not application behavior. A translation cannot safely introduce a new UI state or replace a missing source key.
2. “Instant” production editing is risky. Use an approval and publish step, retain previous versions for rollback, and choose a cache interval that balances freshness against CDN traffic. Locize’s standard CDN currently has a fixed one-hour TTL; its Pro CDN provides more control. [CDN comparison](https://www.locize.com/docs/integration/cdn-types-standard-vs-pro)

For Germany and Japan, I’d also require translator notes/screenshots, a product glossary, and native review. Use `Intl` for dates, numbers, currencies, and time zones; don’t treat those as translated strings. Test German expansion and compound words, Japanese line breaking and formality, interpolation, plurals, and layouts with no spaces.

The deciding factor is straightforward: **choose Locize if this is primarily a React product localization problem; choose Phrase if this is the beginning of a larger enterprise localization operation.**

I’d use **Transifex Native** for this case.

Its React SDK is designed around exactly your requirement: developers mark or extract source strings, translators work in Transifex, and the production app fetches approved translations over the air from its Content Delivery Service. Translation changes therefore don’t require rebuilding the React bundle. It supports React 16–19, ICU message syntax, contextual metadata, and content splitting for loading translations by area of the app. [React SDK](https://developers.transifex.com/docs/react-sdk) · [Native overview](https://developers.transifex.com/docs/native)

The shape I’d implement is:

- Replace hard-coded UI text with `<T>` or `useT()`.
- Push newly introduced English strings from CI, keeping the write credential out of the browser.
- Give German and Japanese translators context, screenshots, terminology, and character limits.
- Serve only `reviewed` or `finalized` translations to production; Transifex supports status-based delivery filters. [Release management](https://developers.transifex.com/docs/release-management)
- Fetch locale bundles at startup or language change, cache them, and fall back to bundled English if delivery fails.
- Trigger cache invalidation after approval if you need immediate publication; otherwise the hosted CDS refresh cycle may introduce a delay. The CDS can also be self-hosted on S3/CloudFront, Azure, Google Cloud, or Redis. [CDS documentation](https://developers.transifex.com/docs/content-delivery-service)

What I weighed:

| Option | Assessment |
|---|---|
| **Transifex Native** | Best fit: first-class React SDK and runtime delivery with reviewed-only filtering. Lowest custom integration burden. |
| **Phrase Strings** | Strong enterprise TMS and worth choosing if your organization already uses Phrase. Its OTA offering explicitly supports i18next, but I’d validate the precise React-web workflow and plan entitlements in a proof of concept. [Phrase OTA](https://support.phrase.com/hc/en-us/articles/5804059067804-Over-the-Air-Strings) |
| **Lokalise** | Excellent translator experience and integrations, but its documented prebuilt OTA SDKs focus on iOS, Android, and Flutter; a React web implementation may require its OTA API or your own CDN pipeline. [Lokalise OTA API](https://developers.lokalise.com/reference/working-with-the-ota-api) |
| **Crowdin** | Strong collaboration, Git integration, and community localization. I’d favor it when repository-based translation files are the primary workflow, rather than making browser-runtime delivery the deciding factor. |
| **Localize** | Very fast script-tag/DOM translation, but less attractive for a React product because it obscures explicit message keys, typing, component context, and predictable rendering. |
| **i18next + S3/CDN** | Maximum portability and control, but you must build publishing, approvals, cache invalidation, rollback, translator tooling, and observability yourself. |

Two cautions matter regardless of vendor:

1. “No redeploy” should apply to changes to existing translations. Adding a brand-new UI message still normally accompanies a code release.
2. Do not let every translator edit go directly live. Publish only reviewed strings, retain the last-known-good bundle, and support rollback. Otherwise OTA turns a typo—or a compromised translator account—into an immediate production incident.

Before signing, I’d run a short proof of concept and commercial/security review covering German/EU data-processing requirements, SSO and audit logs, translator seats, OTA/CDN limits, exportability, and Japanese linguistic QA. For Japan, also test line wrapping, full-width punctuation, dates, names, and layouts without assuming German-style word boundaries.

I’d use **Phrase Strings with `react-i18next` and Phrase’s i18next over-the-air distribution**.

It fits the operating model you want:

- Developers replace hard-coded copy with stable keys and ICU-compatible messages.
- Translators work in a browser with context, screenshots, glossary, translation memory, comments, and review states.
- Approved translations are published as a controlled release and fetched by the React app from Phrase’s CDN—no application redeploy.
- Phrase supports i18next OTA explicitly, offers EU delivery endpoints, and falls back to cached or bundled translations if OTA is unavailable. [Phrase OTA documentation](https://support.phrase.com/hc/en-us/articles/5804059067804-Over-the-Air-Strings)

A sensible architecture would be:

```text
React → react-i18next → bundled English fallback
                     ↘ Phrase CDN: de-DE, ja-JP
```

Keep English in the repository as the source of truth and emergency fallback. Cache downloaded catalogs locally, refresh them on startup or a reasonable TTL, and publish only reviewed translations—not every translator keystroke. The initial conversion from hard-coded strings requires a normal deployment; subsequent translation-only changes do not.

What I weighed:

| Option | Strength | Why I wouldn’t lead with it |
|---|---|---|
| **Phrase Strings** | Strong translator workflow, i18next OTA, release controls, EU endpoints, mature enterprise governance | Expensive and increasingly sales-led; current plans meter managed words, seats, and OTA requests. [Pricing and limits](https://phrase.com/pricing/) |
| **Crowdin** | Best value for many smaller teams; good translator UI, screenshots, Git integration, and a JS OTA client supporting React | More assembly is required around your existing i18next setup and release governance. [Crowdin OTA JS client](https://crowdin.github.io/ota-client-js/) |
| **Transifex Native** | Probably the quickest code-to-runtime path; React SDK discovers content and serves translations OTA | Greater SDK/vendor coupling, and its JavaScript feature matrix does not list offline support—so I’d want to engineer and test fallback behavior carefully. [React integration](https://www.transifex.com/react-i18n/), [feature matrix](https://developers.transifex.com/docs/transifex-native-feature-matrix) |
| **Lokalise** | Excellent product-oriented UI and automation; often pleasant for translators and PMs | I wouldn’t select it without a commercial comparison against Phrase; runtime delivery, request limits, data residency, and required plan need careful validation |
| **Home-grown JSON on S3/CDN** | Cheapest infrastructure and no TMS lock-in | You would still need to build assignments, review, glossary, screenshots, audit history, permissions, and publishing controls—the expensive parts |

For Germany and Japan, I’d also require:

- `de-DE` and `ja-JP` locale-specific formatting through `Intl`, not translated formatting strings.
- A German terminology glossary and formal/informal voice decision (`Sie` versus `du`).
- Japanese native review, rules for product-name transliteration, punctuation, spacing, and line wrapping.
- Screenshot/context attachment for ambiguous short strings.
- Pseudolocalization and layout testing before launch.
- A GDPR/DPA and data-residency review; Phrase documents separate EU OTA/CDN domains.
- Versioned translation releases with rollback, monitoring, and bundled fallbacks.

If the localization budget is modest, I’d choose **Crowdin instead**. If reliability, review governance, and European procurement matter more than cost, **Phrase is my recommendation**.

I’d use **Phrase Strings with `i18next`/`react-i18next` and Phrase OTA delivery**.

It fits the two distinct needs well:

- Translators get a proper workspace with context, comments, translation memory, terminology, review states, and permissions.
- The React app retrieves approved German and Japanese catalogs at runtime, so copy corrections do not require a new application deployment.
- Phrase’s OTA integration explicitly supports i18next, locale fallbacks, scheduled or manual releases, app-version targeting, and cached/bundled fallback when the service is unavailable. An EU data center is available. [Phrase OTA documentation](https://support.phrase.com/hc/en-us/articles/5804059067804-Over-the-Air-Strings)

### Architecture I’d implement

1. Replace hard-coded text with stable message IDs using `react-i18next`.
2. Keep the English source catalog and a baseline copy of each shipped locale in Git.
3. Push new or changed source messages to Phrase from CI.
4. Have translators work in `de-DE` and `ja-JP`, followed by native-speaker review.
5. Publish only reviewed translations to separate staging and production OTA distributions.
6. Load catalogs at startup and cache the last successful version; fall back to bundled English if the network or Phrase is unavailable.
7. Refresh on application startup or at a controlled interval—not on every render.

This removes redeploys for **translation changes**, but adding a brand-new UI message still normally accompanies a code release because the React code must reference its new message ID.

### What I weighed

| Option | Assessment |
|---|---|
| **Phrase Strings** | Best overall balance here: mature translator workflow, direct i18next OTA support, controlled releases, fallbacks, version targeting, and EU hosting. Branching and Git/CI tooling are strong, although some capabilities depend on higher plans. [Branching](https://support.phrase.com/hc/en-us/articles/5856411356316-Branching-Strings), [GitHub Action](https://developers.phrase.com/en/developer-tools/strings-github-action) |
| **Crowdin** | Very close second and potentially the better value after pricing. It has a JavaScript OTA client for React, CDN delivery, repository integrations, and particularly good in-context translation. I would run it in the proof of concept alongside Phrase. [JavaScript OTA client](https://store.crowdin.com/ota-client-js), [in-context localization](https://crowdin.com/features/in-context-translations) |
| **Lokalise** | Excellent translator experience, screenshots, glossary, and workflow automation. Its official OTA SDKs currently focus on iOS, Android, and Flutter; web React delivery would require a more custom API/CDN integration, so it is less direct for this requirement. [Lokalise OTA documentation](https://developers.lokalise.com/docs/ota-sdk) |
| **Locize** | Attractive if the team wants the most i18next-native, lightweight solution. I would favor it for a smaller engineering-led operation, but Phrase offers a broader localization-management workflow as the company adds markets and vendors. |
| **Translation files committed through PRs** | Simple, auditable, and vendor-independent, but every translation correction follows the deployment cycle, contradicting the main requirement. |
| **Home-grown database/CMS endpoint** | Delivers runtime updates, but you would be rebuilding review workflow, terminology, translation memory, permissions, QA, versioning, rollback, and translator UX. |

Before signing, I would run a two-week Phrase-versus-Crowdin pilot using real strings and obtain quotes based on translator seats, processed words, OTA requests/MAU, environments, and branching. Those commercial limits can outweigh small feature differences.

Two guardrails matter: remote translations must contain presentation content only—never executable configuration—and rich HTML should be avoided or strictly sanitized. German needs expansion testing and compound-word handling; Japanese needs explicit formality/style guidance and testing around line breaks, dates, names, and full-width punctuation.

I’d use **Phrase Strings with `react-i18next` and Phrase OTA**.

That combination separates three concerns cleanly:

- React uses stable keys and handles interpolation, plurals, dates, and fallback behavior through i18next.
- Translators work in Phrase’s browser editor with context, screenshots, terminology, translation memory, assignments, and review states.
- Approved translation releases are delivered to the app at runtime through Phrase’s CDN, so correcting German or Japanese copy does not require rebuilding the React application. Phrase officially supports OTA delivery for i18next and web applications. [Phrase OTA documentation](https://support.phrase.com/hc/en-us/articles/5804059067804-Over-the-Air-Strings)

A sensible flow would be:

```text
React source → key extraction/CLI → Phrase
                                  ↓
                        translate → review → publish
                                  ↓
                        OTA/CDN translation bundle
                                  ↓
                              React app
```

I would still ship a bundled copy of each locale with normal releases, then treat OTA as an update layer. Cache the last successful bundle, retain English as the final fallback, and never let an unavailable localization service produce blank UI.

What I weighed:

- **Transifex Native:** The strongest alternative if minimizing integration work is the priority. It has a purpose-built React SDK, runtime content delivery, lazy loading, ICU syntax, context metadata, and customizable missing-string behavior. It can be more convenient than maintaining locale files, but it couples application rendering more directly to Transifex’s SDK and content model. [React SDK](https://developers.transifex.com/docs/react-sdk), [runtime delivery](https://developers.transifex.com/docs/javascript-sdk)
- **Crowdin:** Attractive for price-sensitive or developer-led teams. Its JavaScript OTA client explicitly supports React and can deliver generated resource bundles through a CDN. I would shortlist it alongside Phrase, especially if community translation or Crowdin’s ecosystem matters. [Crowdin OTA JS client](https://crowdin.github.io/ota-client-js/)
- **Lokalise:** Excellent translator experience and automation, but its documented first-party OTA SDKs currently focus on Android, iOS, and Flutter—not React web—so runtime web delivery would require a more custom API/CDN path. [Lokalise OTA SDK](https://developers.lokalise.com/docs/ota-sdk)
- **Build-time Git synchronization:** Simple and auditable, but it fails your core requirement because every translation correction needs another deployment.
- **A home-grown database or S3/CloudFront setup:** Technically straightforward, but you would end up rebuilding review workflows, permissions, history, glossary management, screenshots, and translator tooling.

Before committing, I’d run a short Phrase-versus-Transifex trial using real strings and obtain quotes. Pricing can change the decision substantially once translator seats, source-word limits, environments, SSO, branching, and OTA traffic are included.

Two implementation cautions matter more than the vendor:

1. Only reviewed translations should reach the production OTA channel. Runtime publishing is effectively a production content change, so give it approvals, audit history, rollback, and staging.
2. Localization is more than string substitution. Use ICU-aware messages, `Intl` for dates/numbers/currency, and test German expansion, Japanese line breaking and fonts, formality, address/name ordering, accessibility labels, and SEO metadata.

So my default choice is **Phrase + i18next + controlled OTA releases**; I’d switch to **Transifex Native** if the team values the most direct React/runtime model over portability.

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.

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.

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).

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.

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?