Database Localization Laravel Package

Getting Started

0.3.0 is a maintenance-focused release for the package’s database-backed translation loader. It reverts earlier database and loader implementation changes and includes fixes for translation existence checks and updating translation values inside database transactions. Treat the loader/database internals as still in motion: pin 0.3.0 and validate against your app’s translation schema before upgrading.

Minimal steps:

1. Require/pin the package at 0.3.0 in composer.json and install dependencies.
2. Publish the package config and migrations using the provider/tag documented by the package, then run php artisan migrate.
3. Confirm the service provider is registered and the translation loader/driver is configured to use the database-backed loader.
4. Start with one small use case: move a handful of app-specific translation keys into the database, then verify __('key'), Lang::get('key'), and Lang::has('key') across your default and fallback locales.

Where to look first:

• The package README’s install/config sections.
• The package service provider and translation loader binding.
• The published config file and migration/schema.
• The 0.3.0 diff around loader/database changes and the two revert commits.
• Existing translation import/seed commands or documented workflows.

Implementation Patterns

• Use the database loader for application translations that editors need to change at runtime; keep framework/vendor translations in files unless the package explicitly supports merging both cleanly.
• Seed or import translations idempotently. Prefer an updateOrCreate-style import keyed by locale, group, and key rather than blind inserts.
• Wrap multi-key or multi-locale updates in DB::transaction. 0.3.0 fixes an issue with updating translation values inside database transactions, but still test both commit and rollback paths in your app.
• Exercise existence checks explicitly: Lang::has(), Lang::hasForLocale(), fallback-locale behavior, missing groups, and empty translation values. The 0.3.0 existence-check fix is worth covering with a regression test.
• If you cache translations or the package provides a cache layer, update the database and clear/invalidate the relevant translation cache in the same workflow.
• For admin-editing workflows, update through the package’s public model/repository/command APIs where available, then clear caches and verify the next request resolves the new value.
• If you previously adapted code to unreleased database or loader changes, revert those adaptations. Do not build against internal loader classes unless the package documents them as stable extension points.
• In tests, use RefreshDatabase and include cases for transaction rollback, fallback locale resolution, and cached-vs-uncached reads.

Gotchas and Tips

• 0.3.0 reverts both “Change database” and “Change loader implementation”. If you compared against a dev branch or pre-release docs, the final schema/loader behavior may not match. Run migrations against both a fresh and existing database.
• Pin the exact version and review the release diff before upgrading. The loader/database churn suggests internal APIs may change again.
• The existence-check fix may alter behavior for missing keys, empty strings, or fallback locales. Add tests around Lang::has() before relying on it for UI conditionals.
• The transaction fix does not remove the need for cache discipline. If translations are cached, an update committed inside a transaction can still leave stale cached values unless you invalidate after commit.
• Config caching can hide loader configuration changes. After changing the translation driver/loader config, run php artisan config:clear locally and rebuild production caches intentionally.
• After schema or loader changes, clear relevant caches (config:clear, cache:clear, and any package-specific translation cache).
• Debug loader resolution through the container and verify the expected loader is actually active; a misconfigured driver can silently fall back to file translations.
• Add indexes for common lookup columns such as locale, group, and key. A database loader can add query overhead on every translation lookup if uncached.
• Prefer public extension points: published config, documented loader binding, cache store, import commands/jobs, and model/repository APIs. If you subclass the loader, add integration tests for get, has, and group loading.