- How do I install mgcodeur/laravel-translation-loader?
- Install it with Composer using composer require mgcodeur/laravel-translation-loader, then publish the package config and migration files with Laravel's standard vendor:publish command. Run your migrations to create the translations table, populate it with your strings, and confirm the package service provider is registered. Once that is done, Laravel's translator resolves strings from the database instead of the lang directory.
- Which Laravel and PHP versions does this package support?
- Release 1.2.0 supports Laravel 10, 11, 12 and 13, with PHP ^8.1 widened at the same time. Support is expressed as a tested matrix rather than one broad range, and the CI configuration carries explicit exclusions for unsupported framework and PHP pairings. Check that matrix for the exact validated combinations before you document a support claim for your own project.
- Does it work with the trans() and __() helpers and the @lang directive?
- Yes. The package swaps Laravel's default file-based translation loader for a database-driven one, so trans(), __() and the @lang Blade directive continue to work unchanged. Application code does not need to be rewritten, because only the source the loader reads from changes, not the resolution API.
- How do I migrate my existing lang files into the database?
- The package ships migration and model support, but it does not automatically import your existing lang/ directory, so you need a one-off import script that reads the PHP arrays and writes rows into the translations table. This data migration is usually the largest piece of adoption work, so confirm the actual table schema against the package docs first. Run the import in staging and diff the resolved output before switching production traffic over.
- How does caching work and how do I clear stale translations?
- The package includes a caching layer so repeated key lookups do not hit the database on every request. Because cached strings can go stale after an edit, you need an explicit invalidation step on write, clearing the affected entry or the whole translation cache when a record is saved. Confirm the invalidation contract in the docs, since stale entries surface as user-visible UI defects rather than build-time warnings.
- What happens if a translation key is missing from the database?
- Fallback behaviour is the first thing to verify, because with a database loader a missing key can render as a raw key string in your UI instead of failing loudly at build time. Laravel's usual fallback locale and key-as-fallback conventions still apply, but whether this package falls back to files, to the fallback locale, or to the key itself should be confirmed in the docs. Cover the case with a test before you commit to an estimate.
- Can non-developers edit translations at runtime with this package?
- Yes, and that is the primary use case: strings live in a database table, so an admin panel, CMS or per-tenant override screen can edit them without a deploy. It suits admin-editable copy, customer-specific overrides and A/B-testable strings. If your translations are developer-owned and ship atomically with releases, the package adds a stateful dependency with no payoff.
- Is it safe in production and what is the performance overhead?
- It is production-usable, but it moves a core framework service into a stateful dependency, so every database blip or stale cache entry becomes a visible UI defect. Unbounded per-request key lookups can add query overhead, so lean on the built-in caching, watch for repeated lookups in loops and load test before scaling. The package is also maintained by a single author, so be ready to pin a known-good version or fork it.
- Will it conflict with other packages that wrap Laravel's translator?
- It can. Localisation suites, admin panels and cached-translation layers that also decorate the Translator may conflict or resolve in an unexpected order. Test the package inside your real dependency graph rather than in isolation, and check which service provider registers last so the intended loader wins.
- When should I avoid using a database translation loader?
- Skip it when translations are developer-owned code that should be versioned, code-reviewed, diffable and deployed atomically with the release. The package fits products where non-developers need to edit copy at runtime, such as CMS-driven content, multi-tenant overrides or admin-editable strings. This is a scope decision about where i18n lives, not a version decision.