- How do I install mortendhansen/laravel-database-translations in a Laravel app?
- Install it with Composer using composer require mortendhansen/laravel-database-translations, then run the package migrations so the translation tables exist. Laravel's package auto-discovery registers the service provider, and the package includes Artisan commands for importing your existing language files. Check the repository README for the exact publish and migrate commands for your version.
- Does it break my existing __() and @lang calls?
- No. The package provides a database-backed translation loader that plugs into Laravel's translator, so your existing __() and @lang calls keep working unchanged. You are swapping the storage layer behind the translator, not rewriting templates or application code.
- How do I move my existing PHP language files into the database?
- The package ships Artisan commands that import existing language files into the translation tables. Run the import once, review the imported entries, and the loader will serve strings from the database instead of the flat files. Keep your language files in version control until you have confirmed the import looks correct.
- Does it support multiple locales?
- Yes. Translations are stored as keys with per-locale values, so a single key can hold a different string for each locale your application supports. Locale switching works the same way it does in standard Laravel, and adding a language means adding values rather than creating new directories of files.
- Is a database translation loader fast enough for production?
- The package includes caching support to keep lookups fast, which matters because querying per string on every request would be costly. With caching enabled, repeated lookups avoid hitting the database on each call. Benchmark against your current file-based setup using a realistic number of keys before rolling it out.
- How do I edit translations at runtime without deploying?
- Because strings live in the database, you can update them while the app is running and changes take effect without a deployment. Most teams build a small admin screen or use the package's Artisan commands to manage entries. Clear or warm the translation cache after edits so the new values are actually served.
- Which Laravel versions does this package support?
- Check the composer.json constraints and the README on the GitHub repository for the supported Laravel and PHP versions. Because the package hooks into Laravel's translator through a service provider and a custom loader, it needs a Laravel release whose translation contracts it targets. Pin a version and run your test suite after any Laravel upgrade.
- How does database-backed translation affect my test suite?
- Tests that assert translated output will read from the database, so your test database needs the translation tables migrated and populated with the keys your assertions expect. Using RefreshDatabase plus an import or seeding step keeps results predictable. If that is more friction than you want, keep file-based translations in the testing environment.
- What are the alternatives to storing Laravel translations in the database?
- The default is Laravel's flat PHP language files, and there are also third-party translation management services and other database translation packages. This package's selling point is a drop-in loader that preserves standard __() and @lang syntax while making strings editable at runtime. Decide based on whether runtime editing is worth the extra storage, migration, and caching layer.
- Is the package actively maintained, and how do I handle upgrades?
- Check the GitHub repository for recent commits, tagged releases, and open issues before adopting it in a production app. Pin the version in composer.json and read the changelog when upgrading. Since your translations now live in the database, back up and export those tables regularly so you can migrate away or roll back if needed.