Laravel Translation Editor Laravel Package

Getting Started

• Requirements changed in v1.13.0: this release drops PHP 8.2 and Laravel 11 support. You now need PHP 8.3+ and Laravel 12+. Check composer.json constraints (php, illuminate/*) and your CI matrix before composer update.
• Install with composer require eXolnet/laravel-translation-editor, then publish the package's config/assets via php artisan vendor:publish (look for the TranslationEditorServiceProvider entry in the publish list rather than guessing the tag).
• Inspect the published config first — it's where the route prefix, middleware/guard, and the list of scanned translation paths live. That file, not the README, is the source of truth for your install.
• First use case: mount the editor on a local or staging environment and use it to bulk-fill the gaps in lang/{locale}/*.php files that your app already references. It's a development/authoring convenience, not a production CMS — treat it as a write-capable devtool and gate it accordingly.

Implementation Patterns

• Environment gating is the primary pattern. Register or enable the editor's routes only outside production. Typical shape: wrap the package's service provider / route registration in an if (app()->environment(['local', 'staging'])), or flip the package's enabled config key from an env var (TRANSLATION_EDITOR_ENABLED). Belt-and-braces: also add your auth middleware and an Gate check on top.
• Gate on authorization, not just obscurity. If staging is publicly reachable, put the editor behind auth + a policy/gate (Gate::define('edit-translations', ...)) restricted to developer or content-editor roles.
• Editing → commit workflow. Use the UI to author strings, then diff and commit the resulting lang/ files yourself. This keeps translations under code review and avoids a database-only translation store that drifts from git. Pair with a CI check that fails on missing keys across locales.
• Locale coverage loop. Iterate locales against your source locale, use the editor to fill untranslated keys, and re-run the coverage check. Good fit for teams where translators aren't comfortable editing PHP arrays.
• Keep it out of the request path for end users. No shared middleware group; register the editor's routes on a dedicated prefix with its own middleware stack so it never leaks into normal web traffic.

Gotchas and Tips

• Breaking change in v1.13.0 — PHP 8.2 / Laravel 11 removed. If you're pinned to Laravel 11, stay on the v1.12.x line (pin ^1.12 and note that no further fixes will land there). If you're upgrading, bump PHP first in CI, then Laravel, then this package — otherwise Composer will resolve to an older release without telling you why.
• Never enable in production. A web-writable translation editor behind a misconfigured middleware group is an arbitrary file-write vector over your lang/ directory. Verify with php artisan route:list | grep -i translation on a production-built container.
• Filesystem permissions. The editor writes into the lang path, so the PHP-FPM/web user needs write access to that directory (and to any custom path configured). Directory ownership issues on Docker/Forge are the most common "saves silently do nothing" cause.
• Caches mask changes. Config is cached (config:cache) and translations can be cached by the framework. After editing, php artisan config:clear and, depending on your setup, php artisan cache:clear before assuming the editor broke.
• Dot-notation collisions. Laravel flattens arrays with .; a literal key containing a dot, or a nested array whose sibling is a scalar, will round-trip incorrectly. Prefer flat, unambiguous keys for anything you edit through a UI.
• Vendor translations are not yours. Only point the editor at lang/ (and any JSON translation files you own) — editing vendor/ or package-published translations will be overwritten on the next vendor:publish --force.
• Git noise. Large reorderings of array keys in generated lang files produce unreviewable diffs. If you hit this, check the config for an output/format option or accept the churn knowingly rather than fighting it after every edit session.
• Extension points: published config (paths, middleware, route prefix), published views if you want to rebrand/localize the UI, and your own middleware/gate for auth. Reach for these before patching vendor code — the package is a thin UI over your lang files and rarely needs forking.