Laravel Translation Manager Laravel Package

Getting Started

Install it like any other Laravel package and confirm auto-discovery before touching config:

composer require highsolutions/laravel-translation-manager
php artisan vendor:publish   # inspect the list of tags, then re-run with --tag=...
php artisan route:list | grep -i translation

The package registers a service provider (auto-discovered) that wires up routes, views, and a config file. The publish step is the one place to slow down: run vendor:publish without a tag first so you can see what the package actually ships (config, views, assets, maybe migrations). Read the published config/translation-manager.php end to end — for a small package like this, that file is usually the entire API surface. Confirm the route prefix, middleware, and which locale directories it scans.

Where to look first, in order:

1. config/translation-manager.php — driver (file vs database), route prefix, middleware, locale list.
2. routes/ inside the package or the provider's boot() — to see the actual URI and guard.
3. The published views — this tells you exactly how keys are read and written back.

First use case: open the manager UI in local, pick your source locale (en), and scan an existing lang/en/*.php file for keys that are missing in a target locale. Add one translation, save, then git diff lang/ and confirm the file changed the way you expect. That single loop — view, edit, save, diff — is the whole product. Validate it before you build any workflow around it.

Before exposing it anywhere, wrap the routes in real auth. Most of these managers ship with web middleware and nothing else:

// config/translation-manager.php
'middleware' => ['web', 'auth', 'can:manage-translations'],

Implementation Patterns

Gate it to non-production or behind a permission. The most common deployment is: enabled in local/staging for developers, and in production only behind an admin gate. Do not let the default middleware be your only protection — these UIs write files to disk.

Treat the base locale as the source of truth. Establish lang/en as canonical, then use the manager's scan/compare view to find keys present in en but absent elsewhere. The daily loop is: developer adds keys in code, opens the manager, fills gaps per locale, commits. Keep the diff reviewable.

Separate the two file shapes. Laravel supports PHP array files (lang/en/messages.php, dot-notation keys) and JSON files (lang/en.json, flat keys). A translation manager usually handles both but writes them differently. Decide per project which you use and stay consistent — mixing them makes the "missing key" view noisy and hard to trust.

Split responsibilities by audience. Developers edit source keys in code and PRs. Translators work exclusively in the UI on a staging deployment, then someone commits the resulting lang/ changes. This keeps merge conflicts out of the translator's world and keeps the translator out of git.

Use it as a review surface, not just an editor. The comparison view is the highest-value feature day to day — it answers "what did we forget to translate?" far faster than grepping files. Wire that into your release checklist: before tagging, open the manager, confirm zero missing keys for shipping locales.

Automate the drift check in CI. If the package exposes an artisan command for scanning/exporting, run it in CI and fail on missing keys. If it doesn't, the same comparison is easy to reproduce with a short script that diffs array_keys across locale files — the manager is then a human-facing convenience layer, not a build dependency.

Customize through published views. If the default UI doesn't match your workflow (grouping, filtering, bulk actions), publish and override the Blade views rather than forking. Prefer view overrides and config over patching vendor code, since you'll want to update the package.

Pair with laravel-lang for baseline coverage. For the standard validation/auth strings, pull in community translations once; reserve the manager for your app-specific keys. Otherwise translators spend their time re-translating validation.required.

Gotchas and Tips

• File permissions are the #1 silent failure. The PHP process needs write access to lang/ (and possibly storage/ for the package's own state). Saves that "work" in the UI but don't persist are almost always www-data vs owner issues. Test a save and immediately cat the file.
• Generated files lose formatting. Most file-based managers rewrite arrays with a dumper, wiping comments, ordering, and alignment. Review git diff lang/ before every commit — otherwise translation PRs become unreviewable noise. If this matters, edit source keys by hand and use the manager only for target locales.
• Clear caches after edits. php artisan config:cache, route:cache, and any translation-cache package will mask changes. If edits don't appear, clear config/route/view caches first — don't debug the package.
• Route caching and package routes. Verify route:list after route:cache in production; a cached route table that predates the package install is a classic "404 on the UI" cause.
• Nested keys and dots. messages.welcome.title maps to ['messages' => ['welcome' => ['title' => ...]]] in PHP files but is a literal flat key in JSON files. A key with a dot in its name behaves differently across the two formats. Watch for this when migrating between them.
• Concurrent edits corrupt files. There is no locking. Two translators saving the same file simultaneously means one write wins silently. Either give each translator their own locale subset or serialize access.
• Keep the locale list in sync with reality. The config's locale array, the lang/ subdirectories, and config/app.php's locales must agree. A locale that exists in config but not on disk (or vice versa) produces confusing empty states.
• Small package — pin and read the source. At this size and star count, the entire codebase is a short read. Pin an exact version in composer.json, read the write path once so you know what it does to your files, and be prepared to fork. Check the composer.json Laravel version constraint against your app before upgrading either.
• Debugging order: service provider discovered (composer dump-autoload, check bootstrap/providers.php or config/app.php) → routes registered (route:list) → config published → write permissions → cache cleared. That sequence resolves nearly every issue.
• Extension points to know: the config's driver (switch file-based for DB-backed if supported), published views for UI changes, and any middleware/gate callback in config for access control. Reach for those before editing vendor files.