- How do I install whitecube/lingua in a Laravel application?
- Install it with Composer using composer require whitecube/lingua, then publish and run the package migrations so the translations table exists. Publish the config file if you need to change the database connection, cache store, or admin UI settings. Finally, enable the database translation driver as described in the package docs and import your existing language files.
- Does Lingua replace Laravel's file-based translations?
- No. Lingua registers a database translation driver that works alongside Laravel's native file-based translations, and it falls back to your lang files when a key has not been stored in the database yet. That means you can migrate incrementally and still keep default strings versioned in Git. You can move keys into the database at your own pace without breaking anything.
- Will __() and @lang keep working after switching to the database driver?
- Yes. Because Lingua plugs in as a translation driver rather than a separate API, __(), @lang, trans_choice() and Lang::get() all resolve through the normal Laravel translator. Blade templates, validation messages and notifications need no changes. If a key is missing from the database, Laravel's usual file fallback returns the expected string.
- How do I import my existing lang files into the database?
- Lingua ships an Artisan command that reads your PHP and JSON language files per locale and writes them into the translations table. Run your migrations first, then run the import command, and re-run it whenever you pull updated language files from Git. Check how the command handles keys that already exist in the database before overwriting anything in production.
- Can Lingua find translation keys that are missing or unused?
- Yes, there is a scan command that searches your application code for translation keys and compares them against what is stored. It highlights keys used in code but missing from the database or files, per locale, which is handy before a release or when adding a new language. You can use this to keep every locale in sync instead of hand-checking files.
- Is Lingua fast enough for production translation lookups?
- Lingua includes a caching layer so that __() calls do not hit the database on every request. You should clear or rebuild that cache whenever translations are edited in the admin UI or imported via Artisan. Measure it against your own key count, cache driver and locale count, since very large translation sets behave differently from small ones.
- Can content editors change translations without a redeploy?
- Yes. The built-in admin UI lets you browse and edit translations per locale at runtime, and changes are persisted to the database, so no deploy is needed to fix a typo or reword copy. Treat those routes as sensitive: put them behind authentication and an authorization gate, and consider restricting them to non-production environments during initial rollout.
- Which Laravel and PHP versions does whitecube/lingua support?
- Check the composer.json constraints in the package before committing, since those declare the supported PHP and Laravel ranges. Install with a plain composer require rather than --ignore-platform-reqs so version conflicts surface immediately. Then smoke-test __() resolution, the admin UI and the import command on a staging branch of your app.
- What are the alternatives to Lingua for database-driven Laravel translations?
- spatie/laravel-translation-loader is the best-known option for storing translations in the database, but it gives you the loader and no editing UI. Other teams use a dedicated translation manager package or a hosted TMS such as Lokalise or Crowdin for the editor workflow. Choose Lingua if you specifically want the built-in admin UI and import/scan commands in a single Composer package.
- Is Lingua actively maintained and safe to depend on in production?
- Verify the upstream repository, release history and issue tracker before adopting it, because the package metadata does not clearly point to a maintained home. The code footprint is small and self-contained, so vendoring or forking it into your own VCS is a realistic mitigation. Pin the version in composer.json and add a test that covers your translation lookup paths so a future Laravel upgrade failure is caught early.