Translation Laravel Package

Product Decisions This Supports

• Localization roadmap scoping — code-owned vs. content-owned strings. The real decision this informs is whether multi-language is an engineering build (strings live in versioned lang/ files, every copy change is a ticket and a deploy) or an integration task (strings live in the database, ops/marketing edit them in an admin surface). Those are materially different in cost, velocity, and who owns the work. This package is only relevant to the second model, and it's the cheapest credible path to it — if the audit passes.
• Build vs. buy on the admin-facing half. Translation CRUD, a locale registry, fallback resolution, and a translator override is a small but non-trivial surface. Build cost is roughly 1–2 engineer-weeks plus tests; buy cost is a composer line plus audit time. The nuance a PM must carry into the room: this isn't a general-purpose Laravel library, it's a component of Orchestra Platform. The genuine decision is "do we adopt a slice of Orchestra Platform," and that belongs in a roadmap review, not a sprint ticket.
• Feature sequencing and fast-follow eligibility. If a timeboxed spike passes, translation management becomes a cheap fast-follow after an international launch rather than a blocking v1 requirement. If it fails, it collapses into a scoped work item with a known size — the ~1–2 week "port the loader pattern ourselves" estimate. Either outcome is a win: it converts an unknown into a budget line with a date on it.
• Framework upgrade planning. v6.0.0's entire changelog is "support for Laravel Framework v8." Package version is a function of the framework major, so adopting this pins the product to Laravel 8 and makes every future Laravel major a co-travelling dependency upgrade. That's a planning input for any roadmap that touches the framework, and it should be budgeted as recurring work rather than a one-off.
• Admin-managed content as a capability, not a feature. The product unlock is "no engineering ticket for a copy change." That's a durable operational velocity gain for multi-region SaaS, marketplace listings, per-tenant admin panels, and internal tools serving multilingual staff. Critically, the capability survives a failed audit — the loader pattern is portable at ~100 lines — so a negative verdict doesn't kill the roadmap item, it just changes who builds it.
• An explicit technical-debt posture. The decision isn't "is this good?" It's "do we accept a single-maintainer, zero-dependent, undocumented dependency versus owning a small, well-understood surface?" That's defensible for an internal tool or an MVP with a named owner. It is not defensible on a customer-critical path without one. Making that trade explicitly — in writing, with a name attached — is the PM decision here.

When to Consider This Package

Consider it when:

• You're already on Orchestra Platform at a version pairing with Laravel 8. In that case this is the native, idiomatic choice and integration is mostly config plus migrations.
• You're on (or about to be on) Laravel 8 and localization requires runtime-editable, database-backed translations surfaced in an admin UI — not just static language files shipped in a deploy.
• Localization needs are modest: CRUD over keys and values, locale enablement, and fallback resolution. Not translator workflows, review/approval cycles, or machine translation.
• You're accelerating an MVP or internal tool where time-to-demo beats long-term support provisioning, and you can absorb a fork later if the upstream stalls.
• You want a reference implementation. Reading its schema and translator-override design to inform an in-house build is a legitimate, low-cost use of this repo — arguably the highest-value use given the maintenance signals.
• You're an existing Orchestra consumer doing v5 → v6, where the practical task is a diff-and-verify rather than a fresh adoption.

Look elsewhere when:

• You are not on Orchestra Platform. The component assumes orchestra/foundation, orchestra/support, orchestra/memory, the extension model, migrations against Orchestra's schema conventions, and admin hooks that only resolve inside that runtime. Outside it, this is a liability rather than a library.
• You need sustained maintenance signals. Stars and dependents are effectively zero, the score is 0.3, and the v6.0.0 changelog is one line with no features, no deprecations, no migration guide, and no stated breaking surface. A compatibility bump is evidence of a pulse, not a track record. Confirm last-commit date, issue responsiveness, and CI matrix before betting a customer-facing path on it.
• You're pinned to Laravel 6 or 7. v6.0.0 is the Laravel 8 line and there's no indication of a backport. Adopting it moves your framework floor.
• You cannot absorb a major-version bump cycle. Every future Laravel major implies a corresponding package major, a lockfile resolution exercise, and re-validation of the translator override. Estimate it as recurring engineering budget, not a one-off.
• You need TMS-grade capability. Pluralization rules beyond whatever the loaded value contains, ICU message format, translator roles, review/approval, and translation memory are all out of scope. For Slavic or Arabic plural rules, that's symfony/translation's message formatter or a real TMS — don't bolt it on here.
• You can't name an internal owner. No owner, no adoption. Pin the exact version, vendor or fork it so a Packagist yank or an abandoned orchestra/* peer can't break the build, and own the upgrade path.

How to Pitch It (Stakeholders)

To executives — the one-liner: "Copy changes stop being engineering tickets. Marketing edits translations in an admin screen; the app picks them up. Cost is roughly two engineer-weeks to prove out, and the decision in front of us is whether to spend that now or queue it behind launch."

The value framing. Localization is usually scoped as a build. This reframes half of it as an integration: the product-facing work becomes a locale registry, fallback rules, and an edit surface, and the string-management half comes off the shelf. The operational payoff is velocity — a copy fix in a new market goes from "ticket, PR, deploy" to "someone types in a form." That's a real, recurring gain for any product with per-region or per-tenant content, and it's the kind of thing that looks small per-change and large across a quarter.

The cost framing. Two paths, both cheap enough to decide quickly. Buy: a composer dependency plus a timeboxed audit of a small, readable codebase (service provider, loader, migrations). Build: ~1–2 weeks to implement the same loader pattern against our own table. The audit is worth running first either way, because it either validates the buy or hands engineering a reference spec at near-zero cost.

The risk, stated plainly. This is a single-maintainer package with zero dependents, no documentation corpus, and a changelog one line long. Its version number tracks Laravel's, so it pins us to Laravel 8 and makes each future framework major a paired upgrade. It's a component of Orchestra Platform, not a general Laravel library — outside that runtime it's a liability. None of this is disqualifying for an internal tool or an MVP; all of it is disqualifying for a customer-critical path with no owner.

The ask. Fund a timeboxed spike (a day or two, not a sprint): seed a locale and a key, prove the translator override actually intercepts __() in a fresh process, and confirm the orchestra/* constraints resolve against our lockfile. Output is a go/no-go with a real estimate attached. In parallel, name the internal owner — if we can't, that's itself the answer, and we build the loader ourselves.

To engineering, in one paragraph. Treat __() as the contract; the loader override is the only integration point that matters, and registration order against Laravel's TranslationServiceProvider is where it silently fails (symptom: edits save, __() returns the old file value). Write a re-runnable importer from resources/lang/ via Arr::dot(), invalidate cache on model saved/deleted events rather than in controllers, make the fallback chain explicit and test the missing-in-locale-present-in-fallback case deliberately, lock keys as read-only after creation, and regress-test at the __() level — [locale, key, expected] triples against seeded SQLite. If the schema doesn't fit our tenancy model, skip the package's migrations entirely and implement LoaderInterface against our own table; same ergonomics, no Orchestra coupling on the data layer.