Translation Manager Laravel Package

Getting Started

This is a Backpack-for-Laravel add-on that puts a CRUD screen in front of your on-disk lang/ files, so non-developers can fix copy without a deploy. It is a UI, not a translation platform — no database, no TM, no vendor sync.

Minimal setup:

composer require backpack/translation-manager
php artisan vendor:publish --provider="Backpack\TranslationManager\TranslationManagerServiceProvider"

Then confirm three things before touching the UI:

1. Backpack is installed and the admin panel boots. The package registers routes under your Backpack prefix; if config/backpack/base.php route prefix is non-default, note it.
2. The lang path is correct. Laravel 9+ uses lang/, older apps use resources/lang/. Check the published config for the path/group settings and that it resolves against app()->langPath(), not a hardcoded string.
3. The process user can write those files. php-fpm/www-data needs write access to the lang directory, or every save silently no-ops.

Where to look first: the package's src/ is small — read the controller and the routes file to see exactly which routes and middleware got registered, then the config to see which locales and groups it will enumerate. The views directory tells you what's overridable.

First use case: open the manager, pick en / messages, and change one string. Then git diff lang/ — that diff is the whole contract of this package, and it tells you immediately how much file reformatting you'll be living with.

Implementation Patterns

Copy-editing handoff. The highest-value pattern: source locale en is developer-owned, target locales are editor-owned. Give editors a Backpack role that can reach the translation screen only, and keep en behind a permission so keys don't get invented in the UI. Key renames stay a code task; string edits become a content task.

Sidebar/menu integration. Add the entry to config/backpack/sidebar.php (or the menu file) with a can: gate matching whatever permission you created. Do not rely on the package's default registration being hidden — verify by logging in as a limited role.

File-write → commit workflow. Treat saves as source changes: a post-save git commit or a nightly job that commits lang/ gives you history, review, and rollback the package doesn't provide. In practice this means: staging environment allows edits, production points at the same repo path, and deploys never overwrite uncommitted editor changes.

Missing-key auditing. The manager is a decent viewer of what exists per group/locale even if you don't let anyone edit. Pair it with a CI check that diffs the key set of en against every other locale and fails the build on missing keys — that keeps the UI honest, since saving through it won't add keys to sibling locales for you.

Stopgap posture for prod-editable strings. If the business genuinely needs runtime-editable copy (marketing banners, emails), don't stretch this into that role. Use a DB-backed translation loader and treat the file manager as a dev/staging tool. Mixing the two gives you "I edited it in the admin but the file wins" bugs that are miserable to trace.

Gotchas and Tips

• Read-only filesystems. Laravel Vapor, read-only container images, and most serverless setups will break saves — the write fails or is lost on the next deploy. Either mount the lang dir as a volume, or skip this package there entirely.
• Noisy git diffs. The package rewrites PHP array files, which typically means lost comments, reordered/alphabetized keys, and changed quoting/indentation. Expect a one-time "reformat" commit per file, then accept it. Don't fight it with a linter that re-reformats on pre-commit.
• Dotted keys and nesting. Flattening nested arrays means a literal dot inside a key is ambiguous. If you have keys like validation.email.required stored flat, confirm the manager round-trips them before letting an editor loose.
• Raw string editing breaks placeholders. :name, :count, and plural foo|foos forms are edited as plain text with no validation. Add a post-save hook or a CI grep that asserts the set of :placeholders in each translation matches the source locale. This is the single most common way this package causes a production bug.
• JSON translations. lang/en.json support is typically partial relative to PHP group files. If your app uses JSON keys for JS strings, verify behavior rather than assuming.
• Caches beat you to it. After a save, a DB-backed loader, config:cache, or OPcache can make the change look ignored. When "it didn't save," check the file on disk first, then the loading layer.
• Access control is on you. The routes are admin routes, but confirm the Backpack auth middleware is actually applied in your install and that the screen isn't reachable by a logged-in non-admin. Also consider whether an editor should be able to create new groups — usually no.
• Version pinning. With ~53 stars and no dependents, this addon trails Backpack majors. Check its composer.json constraints against your Backpack version before upgrade season, and expect to pin or patch. The upside of the low surface area is that reading and forking the whole thing is an afternoon.
• Extension points worth knowing: published views (override via the package's view namespace), the published config (locales/groups/paths), and the route registration (replace with your own controller if you need an audit log or draft/approve flow). There is no built-in revision history — that's the first thing to build on top.