Api Platform Translation Bundle Laravel Package

Product Decisions This Supports

• i18n / market expansion sequencing. Whether "add locale" is a config change or an engineering epic. This bundle reduces it toward config + content, which changes how confidently you can commit to a market-by-market rollout in the roadmap.
• Build vs. buy (transport layer). The package replaces a class of bespoke work most Symfony teams write once and regret: Doctrine entity translation wiring, per-locale serialization groups, denormalization of nested translation objects, and Accept-Language / ?locale negotiation. The decision is roughly "one integration day vs. one to three sprint-weeks," not "framework vs. framework."
• API contract shape. It nudges you toward a locale-negotiated contract (one resource URI, locale in header/query) instead of locale-in-path (/en/products, /fr/products). That's a durable, hard-to-reverse public API decision — worth making deliberately, and this bundle is an implicit vote for the former.
• Data modeling for translations. Per-entity translation tables (the Sylius pattern) versus a single JSON/JSONB column. This choice drives editorial tooling, partial-translation fallback behavior, indexing/search quality, and reporting — the bundle only supports the former, so adopting it pre-commits you there.
• Write-path scope. Whether content authors can PATCH localized fields through the same API as reads, or whether writes stay in an admin app. Multi-locale concurrent editing and conflict semantics are a product decision, and this bundle makes the "writes through the public API" option cheap to offer.
• Fallback policy. Serving the base entity when a translation is missing is a content-ops decision (what does a partially localized market look like?), and adoption forces you to name that policy now rather than discover it in production.
• Editorial workflow buy-in. If the roadmap needs draft/review/publish, machine translation, or per-locale permissions, this package gets you the transport and nothing else — a signal to budget a separate CMS or workflow layer.

When to Consider This Package

Adopt when:

• The stack is Symfony + API Platform (not Laravel — despite the request framing, this is a Symfony bundle; PHP ecosystem yes, Laravel no). Confirm the API Platform major version it supports against yours before anything else.
• You already model, or are willing to model, translations as separate Doctrine entities per locale, Sylius-style.
• You need localized payloads on both read and write, which is the part most teams underestimate.
• The team is small and you'd rather not maintain a custom locale event subscriber and serializer context.
• You're adding locales incrementally, so centralizing locale config has real value.
• You're prepared to vendor or pin it. With 83 stars and 0 dependents you will, in practice, be the de facto maintainer.

Look elsewhere when:

• Laravel / Eloquent. Use spatie/laravel-translatable or equivalent; this is not the right ecosystem.
• You want single-row JSON/JSONB translations — the entity-per-locale assumption makes this a non-starter.
• You need translation workflow (draft → review → publish), MT integration, or per-locale permissions. This is plumbing, not a content platform.
• You need guaranteed forward compatibility with the newest API Platform majors. Small bundles with few dependents typically lag; a minor-version bump upstream can strand you.
• You require vendor SLA or commercial support. MIT, no commercial backing, no downstream consumers to share debugging burden with.
• Your locale count is 2–3 and read-only localization. A serializer group plus a request listener is genuinely less code than a dependency here.

How to Pitch It (Stakeholders)

For executives (one paragraph). Localization is on our roadmap, and the expensive part usually isn't translation — it's the API plumbing that makes every endpoint locale-aware. This package is that plumbing, pre-written: roughly a day of integration instead of a multi-week build, MIT-licensed, no vendor lock-in. The caveats are real but bounded: it's a small open-source project (83 stars, no known downstream users), recently released but effectively unmaintained by market standards, so we should vendor it into our repo and treat it as our code. That's a low-cost, reversible bet — not a platform commitment — and it should be framed to the business as "one less thing to build," not "we've solved localization."

For engineering (the substance). It gives you the Sylius translation pattern with the API Platform glue already written: translation entities stay conventional Doctrine, the bundle handles denormalizing nested translation payloads on write and resolving the right locale from Accept-Language or a query parameter on read. What you're buying is the boring, easy-to-get-subtly-wrong part. What you're not buying is a workflow, a fallback policy, or upgrade support — you own the fork, so pin the version, read the source (it's small), and test the API Platform upgrade path before you depend on it.

Honest positioning. Good bet if we're already Sylius-shaped on Symfony and want localized writes quickly. Wrong bet on Laravel, wrong bet if we'd rather store translations in a JSON column, and wrong bet if the roadmap actually needs a content workflow — in which case this saves us a week and distracts us from the real buy decision.