Nova Translation Laravel Package

Getting Started

This is the first stable release (v1.0.0), so treat it as an initial evaluation rather than an upgrade. The two changes — an updated Laravel translation dependency and Laravel 6 support — tell you the package is built on top of Laravel’s native translator/loader contracts and is intended to be a drop-in extension of __() / @lang, not a replacement API.

Start here:

1. Install and inspect the manifest. composer require the package, then read its composer.json to confirm the Laravel 6 constraint (^6.0) and PHP requirement (Laravel 6 requires PHP >= 7.2). Because Laravel 6 uses package auto-discovery, check the extra.laravel.providers entry; if the package predates discovery you may need to register the service provider manually in config/app.php.
2. Publish and read the config. Run the package’s publish command (typically php artisan vendor:publish --provider="...ServiceProvider") and read the config file top to bottom before changing anything. The important keys are the translation driver/source, fallback locale, and any cache settings.
3. Verify the loader is actually wired in. The quickest smoke test is to put a known key in the package’s expected source (database table, JSON file, etc.) and call __('group.key') in php artisan tinker. If the string resolves, the custom loader is registered correctly and you can build on it.

The first real use case is usually one of two things: moving translations out of flat lang/ files into a database so non-developers can edit them, or adding a translation source that Laravel’s default file loader doesn’t cover. Confirm which one the package targets before designing around it.

Implementation Patterns

Use it behind the native translator. The main value of a package like this is that application code should not change. Keep calling __(), @lang, and trans_choice(); let the package’s loader resolve keys. This keeps you portable if you later swap the source.

Database-backed translations. A common pattern is a translations table keyed by locale, group, and key, with a model that the package’s loader queries. Seed it from existing lang/ files during migration, then treat the database as the source of truth. Keep a group column so __('auth.failed') maps cleanly to group = auth, key = failed.

Cache aggressively, invalidate on write. Translation lookups happen on nearly every request, so load all translations for a locale once and cache them (Laravel’s cache repository keyed by locale works well). Invalidate the locale’s cache in the model’s saved and deleted events rather than trying to expire by TTL. This is the single biggest performance lever.

Fallback and missing-key behaviour. Configure fallback_locale in config/app.php and let the package fall through to it. Decide up front whether missing keys should throw, log, or return the key itself; if the package exposes a “missing translations” hook, wire it to your logger so gaps are visible in staging.

Import/export workflow. If the package ships artisan commands for syncing files and the database, run export in CI to catch drift and import as part of deploy. If it doesn’t, write a small command that wraps the loader rather than duplicating key-parsing logic.

Locale-aware testing. In feature tests, use app()->setLocale() and assert against real keys. Add one test that asserts the database loader is used (e.g. change a row and see the resolved string change) so a config regression doesn’t silently fall back to flat files.

Gotchas and Tips

• Config cache is the usual culprit. After changing the translation source or locale settings, run php artisan config:clear. A stale cached config makes it look like the package is ignoring your changes.
• Key normalisation differs by source. File loaders treat group.key and nested arrays differently from a flat database table. Pick one convention (dot-notation, explicit group column) and enforce it in your import command, or you’ll get duplicate and orphaned rows.
• Laravel 6 specifics. This release targets Laravel 6 only in the sense of support; the updated translation dependency may pin a version of illuminate/translation that conflicts with older or newer framework versions. Check composer why-not if you’re on 5.x or 7+.
• Cache invalidation across deploys. If translations are cached per locale, a deploy that seeds new keys won’t be visible until the cache is cleared. Add cache clearing to your deploy script, or version the cache key.
• Fallback can mask gaps. A missing key in fr quietly returning the en string is convenient in production but hides incomplete translations. Log fallback hits in non-production environments.
• Extension points to inspect first. The service provider bindings and the loader/repository contracts are where customisation lives. If you need a different source (API, tenant-scoped table), implement the existing loader interface and rebind it rather than forking the package.
• Debugging resolution order. When a key resolves to the wrong string, check in this order: locale set on the request, fallback locale, cached translations for that locale, then the raw row in your source. That sequence isolates the problem quickly.