- What does fsi/translatable do for Laravel Eloquent models?
- fsi/translatable adds locale-aware attributes to Eloquent models so you can define translatable fields once and read or write them for the active locale. It provides automatic fallback when a translation is missing, configurable locales, and transparent reads and writes without repetitive accessor boilerplate. It is a model-layer content translation tool, not a full internationalization stack for routes, UI strings, or translation workflows.
- How do I install fsi/translatable in a Laravel application?
- The expected flow is to require the package with Composer, publish its configuration and migrations, and add the provided trait to the Eloquent models that need translated attributes. You then adjust any code that reads or writes those translated fields. Before committing, confirm the published migration and configuration match your intended storage strategy and database engine.
- How do I configure supported locales and fallback behavior in fsi/translatable?
- The package exposes configurable locales and fallback behavior, typically through its published configuration file. You define the locales your application supports and how missing translations should resolve when the active locale has no value. Check the published config after installation and verify fallback behavior in model tests before relying on it in production.
- Which Laravel and PHP versions does fsi/translatable support?
- The exact Laravel and PHP constraints are not stated in the provided material, so verify them in the package composer.json before adoption. The technical evaluation specifically recommends checking Laravel and PHP version constraints as part of feasibility. Do not assume compatibility with your application version without confirming the Composer resolver output.
- Does fsi/translatable require Doctrine, and is that a problem for Laravel?
- Version 1.2.2 widened doctrine/doctrine-bundle to ^3.0, and the key question is whether that package is a hard runtime requirement, a require-dev dependency, or only suggested. If it is a hard runtime requirement, it can pull an unused ORM bundle into a Laravel application and is a legitimate reason to stop. Read composer.json and the lockfile resolver output rather than assuming the Doctrine dependency is harmless for Laravel.
- How are translated values stored by fsi/translatable: JSON column or translations table?
- The storage strategy depends on the schema and is one of the first things to verify after publishing migrations and configuration. The evaluation describes per-locale values as using either a sibling translations table or a JSON column depending on schema. Review the write amplification, indexing story, and query behavior for each locale before choosing it for high-traffic content.
- Can I filter, sort, or eager-load translated attributes in the database with fsi/translatable?
- The critical feasibility question is whether translated values can be used in WHERE and ORDER BY clauses at the database level or only after hydration in PHP. You should verify support for your database engine, including JSON path behavior on MySQL, Postgres, and SQLite, plus generated columns or functional indexes. If filtering and sorting must happen in PHP, that may be unacceptable for large datasets.
- Does fsi/translatable work with API resources, Filament or Nova, Scout, and caching?
- The package is a model-layer extension, so integration with API resources, admin panels such as Filament or Nova, Laravel Scout, and caching layers must be validated in your application. The evaluation lists these interactions as secondary feasibility checks rather than guaranteed compatibility. Test localized reads, writes, eager loading, and cache invalidation with the exact tools your project uses.
- Is fsi/translatable production-ready and actively maintained?
- The main risk is provenance: the evaluation notes zero stars, zero dependents, and a single-vendor maintainer, meaning little production evidence outside the author's own estate. A contributor outside the fsi-open organization authored PR #43, which is a positive signal but not a support commitment. Treat the package as code you are adopting, price the cost of a fork into the decision, and re-check maintenance health periodically.
- When should I avoid fsi/translatable or choose an alternative?
- Avoid it if you need route localization, UI string catalogs, or a translation-management workflow, because it is scoped as a content-model concern only. For content-field translation, compare it with other Eloquent translation packages and a custom JSON-column approach, especially if database-level filtering and sorting are required. If the Doctrine dependency is a hard runtime requirement or maintenance signals remain weak, a fork or a different package may be safer.