Admin Translations Laravel Package

Technical Evaluation

Overall read: This is a 2020-era companion package to another niche package, with zero adoption signals and no release since 2020-05-15. The supplied assessment-pm.md describes a "maintained upstream" and frames the last release as a routine "alignment bump." The release history does not support that framing — five years of silence after a dependency-only patch is the signature of an abandoned package, not a maintained one. That discrepancy is the most important finding here and should be corrected before this document reaches a decision forum.

Architecture fit

• Not standalone. The description scopes it as a "Translation manager for savannabits/admin-ui." Adopting it means adopting (or at minimum validating against) a second, equally stale admin UI framework. That is an architectural commitment disguised as a feature add.
• Two drivers (file + database) is the right shape for a translation manager, but only the DB driver is viable for containerized or multi-instance deployments. The file driver writes into the application's lang/ tree at runtime, which collides directly with version control, build artifacts, and immutable filesystems.
• Publishable config and migrations mean we take ownership of schema and its lifecycle — this is a "buy" that behaves like a "build" after week one.

Integration feasibility

• composer require is trivial in isolation. The real test is whether a 2020 constraint set resolves against a current Laravel/PHP runtime. Expect conflicts on illuminate/*, Livewire, and whatever the admin-ui dependency chain pins.
• No evidence of a test suite, CI matrix, or supported-version declaration in the supplied materials. Absence of CI means the only credible compatibility evidence is a resolution run we perform ourselves.
• Migration reversibility is undocumented; assume published migrations are one-way until proven otherwise.

Technical risk

• Highest risk: unmaintained code with filesystem write capability behind an authenticated admin surface. Group and key names are user-supplied and flow into file paths. That is the textbook path-traversal / arbitrary-write vector. Any non-local deployment requires a security read of that write path first — and we have no CVE history to lean on as a proxy for prior scrutiny.
• Framework EOL. "v7" here aligns with a Laravel line that has been out of security support for years. Our runtime is the binding constraint, not the package's.
• Bus factor ~1, zero dependents. No downstream community exists to notice breakage or publish a patch. Every future Laravel major becomes our problem.
• Silent data loss. If we deploy from a built image, file-driver edits vanish on the next rollout. This fails quietly, which is worse than failing loudly.

Key questions

1. Which Laravel/PHP versions are we actually targeting, and does composer update resolve without --ignore-platform-reqs?
2. Do we already run savannabits/admin-ui, or would this pull in a second unmaintained dependency plus its transitive tree?
3. Is the underlying requirement "let non-engineers edit copy" or specifically "let people edit Laravel lang files"? The first is a CMS/TMS problem; only the second justifies this package.
4. Who reviews translation writes, and is there an audit-trail obligation from legal or the localization owner?
5. Can we accept fork-and-own, and who is the named maintainer?
6. Is there already an approved TMS (Crowdin, Lokalise, Phrase) or a maintained OSS alternative in the stack that we'd be duplicating?

Integration Approach

Stack fit

• Good fit: Laravel monolith, server-rendered admin, 2–5 locales, single region, writable filesystem, small content team.
• Poor fit: Kubernetes or immutable images without the DB driver; headless/API-only services; multi-tenant products where translation sets are per-tenant; any team with a formal review-and-approve localization workflow (none is documented here).

Migration path

• Greenfield: safe to spike, not safe to depend on.
• Existing app with hand-maintained lang/ files: migrate into the DB driver — one-way, codebase stays read-only. This is the only low-risk direction.
• Do not automate DB → files. That reintroduces the write-to-repo problem we just removed.

Compatibility

• Assume incompatibility until CI proves otherwise. Timebox a spike (2–3 days) that produces two artifacts: a composer resolution report against our pinned framework constraint, and a written security review of the file-write path.
• If the spike fails, stop. Do not build a compatibility shim for an unmaintained package; a shim is a permanent tax on a dependency nobody else uses.
• If it passes, pin an exact version plus commit hash, and commit the lockfile.

Sequencing

1. Decision gate: timeboxed spike on a throwaway branch. Output = go/no-go with evidence.
2. If green: fork into our namespace, add CI (resolution + a smoke test exercising the write path), and name an owner.
3. Harden before production: admin-only middleware, audit logging on every write, and the DB driver as the default with the file driver disabled by config.
4. Roadmap: do not schedule as a standalone initiative. Bundle with other dependency work in a maintenance window — the source assessment is right on this point, even if its premise about upstream health is wrong.

Operational Impact

Maintenance

• Effectively ours from day one. Zero releases since 2020 means zero upstream fixes; every Laravel upgrade we perform becomes a fork-maintenance task. Cost this as internal ownership, not vendor consumption.
• The fork needs a named owner and a pinned upgrade cadence, or it rots faster than an in-house tool would have — because we inherit unfamiliar code and the maintenance burden.

Support

• None. No vendor, no SLA, no community (0 dependents), documentation at README depth. Support load lands entirely on the adopting team, including for questions that would be answered by a single upstream issue in a healthy project.

Scaling

• File driver: breaks under horizontal scale — N pods produce N divergent filesystems — and under immutable deploys.
• DB driver: reads scale fine, but if translations are resolved through the table on every render it lands on the critical path. Cache aggressively, invalidate on write.
• Admin UI search/filter over 10k+ keys will degrade without indexes; expect slow list views at scale, and budget for that or accept the limit.

Failure modes

• Silent revert: file-driver edits lost on deploy — the highest-probability, lowest-visibility failure.
• Write failure: read-only FS or permissions produce 500s on save, possibly after partial writes.
• Privilege escalation: admin UI functioning as arbitrary file write if key/group inputs aren't sanitized.
• Dependency dead-end: a future Laravel major makes the package unresolvable, forcing an unplanned mid-quarter migration or an emergency fork.
• Split source of truth: some strings in DB, some in files, producing locale-specific bugs that only reproduce in one language.
• Migration drift: published migrations subsequently edited in place, so environments diverge.

Ramp-up

• Engineers: low (hours to a day) if they know Laravel admin packages.
• Content editors: medium — there is no documented review, preview, or approval workflow, so process has to be invented around it.
• On-call: high for the non-obvious case. Whoever is paged when "the translation reverted after deploy" needs the file-vs-DB driver distinction and the deploy interaction written down before first production use.

Recommendation: the 0-start / 0-dependent / no-release-since-2020 profile is a disqualifier for direct dependency, independent of code quality. Ordered options: (1) a narrow in-house admin screen over our own translations table, or an approved TMS if review workflow matters; (2) fork-and-own only if the spike is green and the need is genuinely small and bounded; (3) consuming as-is is not recommended. Flag the "maintained upstream" claim in the source assessment as unverified.