- How do I install and set up lexi-translate in a Laravel project?
- Install it with composer require omaralalwi/lexi-translate, then publish the package config and migrations and run php artisan migrate. Add the provided trait to each Eloquent model you want translatable, and set the active locale through the package facade or helper. Register any morph aliases you rely on before backfilling existing content. A basic spike in a standard Laravel app typically takes a few hours.
- How does lexi-translate store translations in the database?
- It uses the translation-table plus polymorphic-relation pattern: each translatable model gets a morphMany relationship to a shared translations table keyed by translatable_type, translatable_id, locale, and field. That design enables per-locale partial writes, clean indexing on locale, and cross-model queries such as loading every record that has a French translation. It differs from spatie/laravel-translatable, which packs all locales into a single JSON column, and is closer in shape to astrotomic/laravel-translatable.
- Should I use lexi-translate or spatie/laravel-translatable?
- Choose lexi-translate when you need uniform cross-model locale queries, per-locale partial updates, and indexed locale lookups across a stable, bounded set of translated fields. Choose a JSON-column approach when each model only has one or two short translated strings and you want to avoid the join overhead. Do not run both patterns in the same application, because you will end up with two sources of truth for locale content. Confirm which shape your data actually is before adopting.
- How do I switch locales at runtime with lexi-translate?
- The package exposes a facade and helper surface for setting the active locale at runtime, so you can switch languages per request without hand-editing lang files. In practice you set the locale early in the request lifecycle, usually from middleware or a route segment. When switching mid-request or inside a queue job, verify the fallback behavior and how the active locale scopes the cache keys.
- How does caching work in lexi-translate and how do I avoid stale translations?
- Reads are cached in front of the translations table, which makes repeated field access cheap but puts the burden on invalidation correctness. Check that the package hooks model saved and deleted events, and confirm whether bulk query()->update() writes, which bypass Eloquent events, leave stale cache entries behind. Use a shared cache store such as Redis or Memcached in production, since file and array drivers will silently break on multi-node deployments. Stale translations are a customer-visible defect, so add a test that writes, updates, and deletes a translation and asserts the read result each time.
- What happens when a translation is missing for the current locale?
- Fallback-locale semantics should be an explicit, documented contract: does an unresolved key return null, fall back to the app's default locale, or throw an exception? Test each locale path rather than assuming, especially for nullable fields and partially translated records. If the package does not offer the fallback behavior you need, wrap the accessor in your own domain method so the contract lives in your code instead of the vendor's.
- Which Laravel and PHP versions does lexi-translate support?
- Check the composer.json constraints and the README rather than inferring support from the release date, and confirm the package matches your PHP 8.x and Laravel versions. Look for a CI matrix covering the versions you actually run, because a low-adoption, single-maintainer package often tests only the latest release. If your application is on an older Laravel LTS, run your own test suite against it before committing.
- How do I avoid N+1 queries when translating Eloquent models?
- Eager load the translation relation with with('translations') so a collection resolves in one or two queries, then verify that repeated attribute access does not re-query for each field. Watch for accessors that lazy-load translations inside loops and for serializing large collections to JSON. Benchmark a realistic index page with the query log before and after adopting the package.
- Is lexi-translate production-ready and actively maintained?
- It is a low-adoption, single-maintainer package, and that maintenance risk matters more than the code itself. The architecture follows a well-established pattern and the dependency depth looks shallow, but you should pin the version, review the migration and cache logic yourself, and have a plan to fork if it goes unmaintained. For critical multilingual content, keep the translation read and write API behind your own interface so you can swap implementations later.
- Does lexi-translate work with a custom morph map?
- The translations table stores the morph type, so a custom morph map alias is written into translatable_type rather than the fully qualified class name. Register your aliases in AppServiceProvider before backfilling content, and be aware that renaming an alias later orphans existing rows unless you write a data migration. Also check column length and charset, because utf8mb4 index limits on the morph type column can bite on MySQL.