- How do I install joedixon/laravel-translation?
- Install it with Composer using composer require joedixon/laravel-translation, then publish the package config and Blade views with the vendor:publish command. The service provider is auto-discovered, so no manual registration is needed in a standard Laravel app. After publishing, review the config file and decide which driver and locale setup you want before pointing anyone at the UI.
- Does joedixon/laravel-translation support Laravel 11 and Laravel 12?
- The last release was published in April 2023, which predates Laravel 11 and 12, so expect Composer constraint conflicts on current Laravel versions with no upstream fix. Run an install against your exact Laravel and PHP versions on a throwaway branch first and record which constraints fail, because that single test determines go or no-go. If the constraints are stale, your options are pinning to the last supported Laravel line, using a maintained community fork, or vendoring a patched copy with a replace entry.
- How do I secure the translation management routes?
- The package ships its own routes and cannot know your tenancy or role model, so authorization is entirely your responsibility. Wrap the routes in a named permission, a gate, or a local-only middleware before exposing them to anyone. An authenticated route that writes executable PHP into your codebase is a high-value target if the gate is misconfigured, so also confirm the routes are not inadvertently exposed through public route caching.
- Does it support JSON translation files like lang/en.json?
- The package reads the standard lang directory structure, so existing content needs no migration. However, JSON translation support has historically been the weaker path compared with PHP array files, so verify it separately with a real lang/en.json before committing to it. Inventory which locales and file formats are actually in scope, then test each one in staging.
- What is the difference between the file and database drivers?
- The package supports both file and database drivers for storing and organizing your strings. The file driver keeps translations in your lang directory so they stay versioned in git alongside the code, which is what most small teams want. The database driver moves strings out of the repo, which suits runtime editing but removes git history as your audit trail, so weigh that trade-off carefully.
- Does it work with namespaced or vendor translations from packages?
- Support for namespaced and vendor translations is not something you should assume, so verify it explicitly if your application ships or consumes packages with their own language files. Inventory the namespaces in scope and test browsing and saving against a namespaced file before rollout. If your translations are heavily namespaced, keep the package scoped to the app-level lang files it handles reliably.
- Can I use it on Laravel Vapor, Cloud Run, or read-only containers?
- It requires a writable lang directory, so it works fine on a VM but is problematic on read-only or ephemeral container filesystems. On immutable or hardened deployments, edits may fail outright or be lost when the container is replaced. Treat it as a local and staging authoring tool rather than something end users hit in production.
- How do translation edits actually get deployed?
- The UI writes to files in your codebase, so edits are not live in production automatically and anyone assuming otherwise is the main adoption failure mode. Establish the workflow before opening the UI: edit in staging, commit, run CI, then deploy. There is no locking or audit trail beyond git, and an interrupted save can leave a malformed PHP file, so keep changes small and review the diff before merging.
- Is joedixon/laravel-translation a replacement for Crowdin, Lokalise, or Phrase?
- No. It is the small-team, few-locales, strings-live-in-git tier of tooling, not a translation management system. It has no approval workflows, translator portals, or audit trail beyond your repository. If a TMS is already licensed or planned, treat this package as a stopgap convenience layer for developers and PMs, not as the destination.
- Is the package still maintained, and should I fork it?
- The last release was April 2023, so upstream appears dormant and there is no fix coming for compatibility issues on newer Laravel versions. The surface area is small, roughly a service provider, routes, controllers, and Blade views, which makes forking and patching feasible but a permanent if modest maintenance tax. Decide up front whether your team is willing to own that fork, or whether pinning to an older Laravel line is acceptable.