Crowdin Api Laravel Package

Product Decisions This Supports

• Localization roadmap execution: If your product roadmap includes multi-market expansion (new locales for SaaS UI, marketing content, product catalogs, help center), Crowdin is a common TMS choice and this client is the PHP-side integration layer that unblocks automated string syncing between your app and translators. Note the 2.0.0 release narrows the compatible platform: it now targets PHP 8.1+ / Symfony 6 HTTP client, which effectively means Laravel 9+ (or Symfony 6) — relevant if any part of your estate is still on Laravel 8 / PHP 8.0.
• Build vs. buy for translation ops: You are buying the TMS (Crowdin) but building the connector. This package lets you evaluate "buy Crowdin + use this thin client" versus "buy Crowdin + build our own connector" versus "buy a heavier TMS with first-party PHP SDKs (Phrase, Lokalise, Transifex)." It lowers the switching cost of the Crowdin decision by ~1–2 engineer-weeks — if your stack is on the supported side of the 2.0.0 line.
• Feature: continuous localization: Enables a CI/CD-style pipeline where new UI strings, email templates, and content keys are pushed to Crowdin on merge, and translations are pulled back as PRs. That's a feature-shaped product decision (ship updates without a release train per language).
• Feature: in-context/bulk translation workflows: Supports admin-tool features — bulk export/import of project strings, tracking translation progress per locale, and gating market launches on 100% locale coverage pulled programmatically. The 2.0.0 move to Symfony HttpClient is a modest tailwind here: it supports concurrent/async requests natively, which matters if you fan out over many files or locales in a single bulk sync rather than looping Guzzle calls serially.
• Roadmap signal — CMS/PIM/e-commerce surfaces: The Akeneo provenance matters. If you're in the PIM/commerce/CMS space (Akeneo, Sylius, Oro, Magento-adjacent), this package's API coverage likely mirrors the workflows Akeneo themselves needed (product attributes, categories, asset metadata), which is a useful shortcut for scoping your own.
• Use case — agency/integration products: If your product is a Laravel-based delivery platform for clients (agencies, white-label SaaS), this is a per-tenant localization connector you can wrap once and reuse across tenants, rather than re-integrating per project. Standardize the wrapper on one pinned major version across tenants — mixing v1 (Guzzle) and v2 (Symfony) connectors in the same codebase doubles your test surface.

When to Consider This Package

Consider adopting when:

• Your stack is PHP 8.1+ on Laravel 9+/Symfony 6 and Crowdin is already (or is about to be) your TMS. On Laravel 8 / PHP 8.0, v2.0.0 is a non-starter — you'd be pinning the 1.x line (Guzzle-based), which is now effectively frozen.
• Your integration surface is thin: push/pull project files, list projects, manage directories, upload/download translations, handle branches — not advanced TMS orchestration (MT engines, QA workflows, string context, inline review).
• You want a permissive (MIT), forkable dependency rather than a vendor SDK with a support contract.
• You can tolerate a low-maintenance posture: one major release after a ~2-year gap, ~34 stars, 0 public dependents, and a one-line changelog ("Drop Guzzle in favor of Symfony 6 client") with no migration guide. The major version bump is the meaningful signal — this was a deliberate dependency modernization, not routine maintenance, and there's no evidence of a cadence behind it.
• You are prepared to wrap it behind your own interface (a TranslationClient port) so you can swap to a maintained fork or the official Crowdin SDK later without touching business code.
• You are not carrying custom Guzzle middleware you'd need to port. Anything built on HandlerStack — request logging, token refresh, retry/backoff, MockHandler tests — has no drop-in equivalent and must be re-expressed in Symfony's HttpClientInterface decorators, RetryableHttpClient, or MockHttpClient.

Look elsewhere when:

• You need a vendor-supported or SLA-backed client — Crowdin publishes official SDKs for other languages; PHP support may be better served by a maintained community package or a direct client you own.
• You need broad, current API coverage (Crowdin ships API changes frequently; this is still a 2023-era surface with a dependency swap on top — 2.0.0 changed the HTTP transport, not the endpoint coverage).
• Your team is TypeScript/Node or Python-first — don't adopt PHP just to use this.
• You need generated, typed models from Crowdin's OpenAPI spec for compile-time safety; this is a "simple" hand-written client, and "simple" is the design goal, not completeness. The 2.0.0 release does not change this.
• You need a single HTTP stack in your app. Laravel's Http facade is Guzzle-backed; adopting v2.0.0 means shipping symfony/http-client alongside Guzzle. That's fine architecturally but worth an explicit decision, especially for teams whose observability, mocking, and retry conventions are all Guzzle-shaped.
• You require active security response — a dependency bump every ~2 years is not a CVE triage cadence. Mitigate by pinning, vendoring/forking, and monitoring advisories against symfony/http-client directly.

If you already run v1.x: treat 2.0.0 as a planned migration, not a patch. Budget for (a) dependency and autoload changes, (b) re-implementing any Guzzle middleware as Symfony decorators, (c) rewriting HTTP-level test doubles from MockHandler to MockHttpClient, and (d) re-verifying error semantics — Symfony's client surfaces non-2xx responses without throwing unless you call throw(), which differs from code that assumed Guzzle exceptions. A contract test against a Crowdin sandbox is the cheapest way to prove parity before cutting over.

How to Pitch It (Stakeholders)

To executives (1 slide):

We can ship multi-language support ~2 engineer-weeks sooner by integrating Crowdin with a small open-source (MIT, zero-cost) PHP client maintained by Akeneo — a credible PIM vendor with the same localization problem we have. It's a thin connector, not a platform bet. The new 2.0.0 release modernizes its HTTP layer (Symfony 6 instead of Guzzle), which keeps it aligned with current Laravel/Symfony rather than decaying on an old stack — a good sign, though it is a breaking change and confirms this is a vendor side-project, not a supported product. Cost: no license, low lock-in (we can swap TMS or fork the client). Risk: low adoption, ~2-year gap between releases, one-line changelog; we contain that by wrapping it behind our own interface, pinning the version, and requiring PHP 8.1+/Laravel 9+. Decision needed: approve Crowdin as the TMS for the next two locales and confirm our platform baseline is 8.3; the client reduces engineering effort and keeps the exit door open.

To engineering:

It's a hand-written PHP client for the Crowdin REST API — covers projects, directories, files, translations, and branches with a service + client structure that composes fine in Laravel services. 2.0.0 is a breaking release: Guzzle is gone, replaced by symfony/http-client (PHP 8.1+, Symfony 6). Consequences for us: (1) we lose the Guzzle middleware ecosystem — logging, retry/backoff, and auth handlers need porting to HttpClientInterface decorators or RetryableHttpClient; (2) MockHandler test doubles become MockHttpClient; (3) error handling differs — non-2xx doesn't throw by default, so any code relying on Guzzle exceptions must be audited; (4) we now ship two HTTP stacks, since Laravel's Http facade is Guzzle-backed. Upside: native concurrency, which is genuinely useful if bulk sync fans out across files/locales. Plan: pin the major, wrap behind a TranslationGateway interface with our own DTOs, add contract tests against a Crowdin sandbox to catch drift, and budget a half-day to fork if a missing endpoint blocks us. If that overhead isn't worth it, the fallback is a 200-line client we own — same surface, one HTTP stack, no third party.

To product/design:

This unblocks "continuous localization": strings flow to translators on merge, translations flow back as PRs, and we can gate locale launches on coverage metrics pulled from Crowdin. It also gives us admin primitives (bulk export/import, per-locale progress) without building a translation console — and the new release makes bulk syncs cheaper to run concurrently. What it does not do: in-context preview, MT/QA orchestration, or design-time string management — those stay in Crowdin's UI or a later phase. Dependency note for planning: the integration now requires PHP 8.1+ / Laravel 9+, so if any tenant or client platform is older, that's a scoping item before we commit to a locale launch date.