- How do I install and configure laravel-translatable in a Laravel app?
- Run composer require astrotomic/laravel-translatable, publish the translatable config, and define your locales. Then add the Translatable trait and a $translatedAttributes array to the model, along with a translation model and migration. A mid-level Laravel developer can realistically ship a first translated model in a day.
- Which Laravel and PHP versions does astrotomic/laravel-translatable support?
- The package versioning (v11.x) spans Laravel 5.6 through the claimed 13.x and is decoupled from Laravel's release cycle, so wide Composer constraints are convenient but not a compatibility guarantee. Your own CI matrix is the real gate. Laravel 9 through 13 on PHP 8.x is the idiomatic fit, but confirm exact versions before adopting.
- How does laravel-translatable store translations in the database?
- It uses the conventional side-table pattern: one row per entity and locale in a dedicated *_translations table, wired to the parent model through a Translatable trait and contract. The package deliberately does not take over routing, middleware, locale negotiation, caching, or admin UI. It is a primitive for storage and retrieval, not a localization platform.
- How do I read a translated attribute with a fallback locale?
- Use translate() for the current locale, translateOrDefault() to fall back to the default locale, and translateOrNew() when you need an instance to fill. hasTranslation() checks whether a translation exists. Fallback is resolved at runtime as object-level property resolution, not in SQL.
- Can I filter, sort, or search models by a translated column?
- Not automatically. Because fallback happens in PHP rather than SQL, any list view filtered or sorted by a translated column needs explicit joins, and fallback rows will not surface on their own. That is both a correctness risk and a performance risk for search, alphabetical indexes, and sitemaps.
- Is astrotomic/laravel-translatable still maintained and safe for production?
- It has a single active maintainer, issues-only support, and an optional non-mandatory Treeware funding model, so you should own an exit path. It is the maintained successor to dimsav/laravel-translatable, which is a reminder that succession happens. Verify adoption through Packagist stats and reverse-dependency searches rather than metadata such as dependent counts.
- How do I migrate from dimsav/laravel-translatable to this package?
- This is the maintained successor and the semantics are largely compatible, but diff the behavior before switching. For existing single-column data, use a two-phase cutover: add translation tables and backfill the default locale while dual-reading through the trait, then drop legacy columns a full release cycle later.
- How do I save or update translations for multiple locales at once?
- Use getTranslationsArray() for bulk reads, locale-keyed create and fill calls for writes, and the optional translations_wrapper for form payloads. Save through the parent model so the trait handles persistence. The package provides no per-locale publish state, authorship, or audit history.
- Does the package validate locale codes or support regional locales like es-MX?
- Locale configuration is free-form: the docs explicitly permit en, eng, el, or nested regional arrays such as es with MX and CO. Nothing validates incoming locale codes, which becomes silent data drift in a multi-team codebase. Decide whether you need regional locales or a flat list, and validate codes yourself.
- Will translated models cause N+1 queries or bloat my API responses?
- toArray() autoloads translations, which can inflate API payloads, and can invite N+1 queries if translations is not eager loaded. Eager load translations and shape output through API Resources. Also scope any read-cache keys by locale.