Admin Translations Laravel Package

Product Decisions This Supports

• Who owns copy: engineering or the business. Today, changing a user-facing string means a ticket, a code change, a PR review, and a deploy. This package moves that to a web editor in the admin panel, where an ops or marketing owner can edit file-based or database-backed strings directly. That is the real decision it supports: whether translation changes stay on the release train or come off it. The answer determines headcount mix, deploy cadence, and how fast we can respond to a copy bug in production.
• File-based vs. database-backed translations. The package supports both drivers, which forces an explicit architectural choice we would otherwise defer: file-based means content is versioned, reviewed, and deployed with code (good for compliance, auditability, rollback); database-backed means content is runtime-editable and cache-invalidated (good for velocity, bad for review discipline). This is a one-way-ish door — migrating from DB strings back to files later is painful — so it deserves a deliberate call, not a default.
• Build vs. buy for internal tooling. Translation management is a commodity admin CRUD surface. The alternative is ~a few hundred lines of our own Filament/Nova resource over Laravel's Lang facade and a translations table. Consuming a package is cheaper if it is maintained; building is cheaper if it is not. Given zero stars, zero dependents, and no release since May 2020, the honest framing is "adopt as a reference implementation or a fork candidate," not "adopt as a dependency."
• Locale expansion on the roadmap. Shipping locale N+1 is currently an engineering project. If this package works, it becomes a content project. That changes the cost curve for internationalisation and makes "add Spanish/Portuguese" a business decision rather than an engineering capacity decision — which is exactly the kind of lever worth putting in front of a roadmap review.
• Ecosystem commitment. The description says it is a translation manager for savannabits/admin-ui. Adopting it is a commitment to that admin stack, not just to this package. If we are not already on admin-ui, the real decision on the table is the admin framework, and this package is a trailing consequence of it.
• Vendor spend avoidance. A self-hosted editor is a substitute for Lokalise/Phrase/Crowdin seats. For a small team with a handful of locales, the SaaS line item may be hard to justify; this package is the zero-marginal-cost option, with the trade-off that we own the maintenance and get none of the collaboration, QA, or MT features.

When to Consider This Package

Consider it when:

• We are already running savannabits/admin-ui. This is a companion package; outside that stack it is a partial solution with integration work attached.
• We have a small number of locales and a small string corpus, and the pain is "changing copy takes a week," not "we need translator workflows, review states, and pluralisation QA."
• Non-engineers need edit access and we want that without standing up a SaaS TMS or building an admin surface from scratch.
• We are comfortable pinning or vendoring the source. With no releases since 2020, we should assume we may need to patch it ourselves and budget accordingly.
• We have validated it against our current Laravel/PHP version. A 2020 package targeting the Laravel 6/7 era is likely to need work for Laravel 9/10+; do not assume compatibility from the description alone.

Look elsewhere or defer when:

• It does not run on our framework version and the fix is more than trivial. This is the most likely outcome and should be checked in a spike before it appears in any plan.
• We need translator collaboration features — review workflows, comments, screenshots-in-context, TM/MT, pluralisation linting. That is a genuine TMS category and no amount of admin CRUD substitutes for it.
• We need audit trails, approval gates, or segregation of duties on user-facing copy (regulated products, financial or medical content). DB-backed string editing without an audit log is a compliance finding waiting to happen.
• Security review matters. Zero stars and zero dependents means no community scrutiny of the code. Anything that writes to translation files or accepts arbitrary keys from a web form needs a read of the source before it goes near production, particularly around path handling and key sanitisation.
• The package would sit on a critical path with no internal owner. Unmaintained dependency plus no maintainer capacity is the worst combination; that is a build-or-fork decision, not an adopt decision.

Recommended next action: timebox a one-day spike — install against our Laravel version, publish config and migrations, confirm the admin UI integration, and read the file-write path for path-traversal and key-injection issues. Decide on that evidence. If the spike fails on framework compatibility, treat the repo as a design reference and build the thin admin resource ourselves; the surface area is small enough that this is a realistic fallback rather than a fallback in name only.

How to Pitch It (Stakeholders)

For executives: Every user-facing string change currently costs us an engineering cycle — a ticket, a review, a deploy. This package moves that work into the admin panel, so the business can fix copy and add locales without waiting on a release. It is self-hosted, so it also removes a potential per-seat SaaS line item for translation tooling. The caveat is maintenance: the package has had no release since 2020 and no visible community adoption, so the realistic proposal is not "add a dependency" but "adopt it as a starting point and own a small fork." That is still cheaper than a TMS subscription at our scale, and it converts locale expansion from an engineering project into a content project — which is the outcome worth funding. I am asking for a one-day evaluation, not a commitment.

For engineering: It is a thin admin CRUD over Laravel's Lang facade and a translations table, with file and database drivers, search/filter by group and locale, and publishable config and migrations. It is built for savannabits/admin-ui, so it is only attractive if we are on that stack. Two things to verify before we plan around it: whether it runs on our Laravel/PHP version (last release was May 2020, pre-dating Laravel 9), and whether the file-write path sanitises keys and paths properly — it accepts input from a web form and touches the filesystem, and there is no community review to lean on with zero stars and zero dependents. If it installs cleanly and the write path holds up, take it and pin it. If not, the honest comparison is our own Filament resource over the Lang facade, which is a small, well-understood piece of work and removes the unmaintained-dependency risk entirely. Either way, decide the file-vs-database driver question explicitly up front — that one is expensive to reverse.