Astrotomic/laravel-translatable for Database-Backed Eloquent Translations

Why laravel-translatable Targets Database-Backed Eloquent Models

Astrotomic/laravel-translatable removes repetitive application code for retrieving and storing translations that belong to Laravel model records. Its stated scope is narrow and practical: translations are fetched or saved when the model instance is fetched or saved. The package is therefore aimed at developers who keep content such as post titles in a relational database and need the same record to expose values for languages such as English, German, or French.

The distinction between translated data and locale-dependent application text matters. This package does not translate strings automatically. The README shows a German value, "Mein erster Post", as stored model data. It supplies access and persistence behavior for those values. Locale selection through Laravel's application facade determines which translation is returned when ordinary translated attributes are accessed.

It is a better fit for a content system than for static interface labels that already belong in Laravel language files. It is also a poor fit when translated records need an external translation API, a dedicated search index, or an editorial approval service. The repository does not document those integrations, so treating it as a complete localization platform would overstate what it provides.

Locale-Specific Model Access and Translation Persistence

The model API has two reading paths. Calling `translate('en')` selects a locale explicitly. Changing `App::setLocale()` changes the locale used by direct access to a translatable property. This lets application code keep a locale-independent model in memory while retrieving the appropriate translated attribute.

Writes use the same selected translation object. Assigning `$post->translate('en')->title` changes the English translation, and saving the parent model persists that change according to the package's documented behavior. Multiple locale arrays can also be supplied during model creation. The shape shown in the README places ordinary model fields beside locale keys, with each locale containing its translated attributes.

The optional `translations_wrapper` configuration changes how that input is grouped. With the wrapper configured, locale arrays sit beneath one named property rather than appearing as top-level keys. This is useful when a create or validation payload already has a clear translations container. It is a request-shape adaptation, not a change to the `translate('en')` reading API shown in the README.

Based on the repository layout, the implementation lives under `src/`, with package behavior covered through a PHP test suite. The public-facing documentation, however, is the more relevant source for integration decisions because the README does not provide the complete model trait, configuration file, migration, or database schema setup.

Composer Installation and the First English and French Post

The README gives Composer as the installation path. Run it in the Laravel application that should own the package. Composer then resolves the package and its declared dependencies for that project.

composer require astrotomic/laravel-translatable

After installation, the package still needs to be connected to the Eloquent model. The README does not include the required model declaration or translation-table configuration, so those exact files and keys should come from the linked full documentation rather than be guessed here.

The first documented creation call fills ordinary attributes and two locale arrays in one operation. This example expects `Post::create()` to accept the package's translation format after the model has been configured.

$data = [
  'author' => 'Gummibeer',
  'en' => ['title' => 'My first post'],
  'fr' => ['title' => 'Mon premier post'],
];
$post = Post::create($data);

The expected result is direct access to the French title through `translate('fr')`. The untranslated `author` value and the locale-specific `title` values coexist in the same model-creation payload.

Applications that prefer a nested request payload can configure the documented wrapper property:

'translations_wrapper' => 'translations',

With that setting, creation uses one `translations` key containing all locale arrays. This is documented as a configurable wrapper property; the README does not specify the complete configuration file path in the excerpt.

Reading and Updating a Post by Application Locale

For a simple read, fetch one model and explicitly select a locale. The README uses a `Post` model, although it does not show that model's complete definition.

$post = Post::first();
echo $post->translate('en')->title; // My first post

Direct property access follows the application locale instead. Setting English produces the English title, while setting German produces the translated German title shown by the package example.

App::setLocale('en');
echo $post->title; // My first post

App::setLocale('de');
echo $post->title; // Mein erster Post

Updating follows the same model-oriented path. The example selects English, changes `title`, and saves the parent `Post`. A later query is expected to return the new English value.

$post = Post::first();
$post->translate('en')->title = 'My cool post';
$post->save();

This design is convenient when several parts of an application need translated fields on an already loaded model. It also makes locale selection visible in code. Explicit calls such as `translate('en')` are easier to audit than implicit access when a request may change locale while processing several records.

The documentation does not cover transactions, mass-update behavior, translation deletion, fallback behavior, missing locales, validation rules, or rollback. Those cases must be verified against the full package documentation or tests before an application depends on package-specific behavior.

Compatibility, Releases, and the Cost of Staying Current

The repository is not archived. Its last push was on 2026-08-14, and the release list identifies that date as the release of v11.17.1. Earlier listed releases are v11.17.0 from 2026-03-27 and v11.16.1 from 2025-07-09. These facts indicate recent repository activity, but they do not answer application-specific questions such as upgrade compatibility or migration behavior.

The README's version table lists v11.17 as supporting Laravel 9, 10, 11, 12, and 13, with PHP `^8.0`. It also provides distinct compatibility ranges for older package versions. An adoption decision should use the exact installed package line rather than assume that every historical v11 release supports the newest Laravel version shown in the current row.

Upgrade cost is concentrated in framework compatibility, model configuration, and existing code that reads translated fields directly. The public API shown here is compact, so changing to another package may affect every locale-aware read and write rather than a single adapter. The repository includes `CHANGELOG` documentation at `docs/changelog.md`; that file is the first concrete place to inspect for changes between versions.

No migration or data transformation procedure is included in the README excerpt. Applications should therefore determine whether version changes alter the expected translation-table structure before upgrading production data.

MIT Licensing, Treeware Requests, and Alternative Storage Designs

The repository identifies the package as MIT licensed. The README separately asks production users to consider purchasing a tree through the Treeware project. These are distinct terms. The MIT designation states the repository's software license, while the Treeware message is an author request tied to the project's stated Treeware support. The repository does not make the tree purchase a condition in the installation command, and this review does not interpret the legal effect of either arrangement.

A real alternative is to store one set of language columns on the primary Eloquent table, for example separate `title_en` and `title_fr` fields, and expose locale selection through application code. That approach keeps every value in the main model table and avoids a package-managed translation API, but adding or removing a supported language can require schema changes. It also shifts locale handling into each model and consumer.

Astrotomic/laravel-translatable instead models values by locale and provides `translate()` plus create-time locale arrays. Based on the package's stated purpose, that is a better fit when the application wants multilingual attributes without writing the retrieval and persistence code itself. The README does not document a separate translation table schema, caching policy, external translation service, or fallback algorithm, so comparisons involving those behaviors cannot be resolved from the available repository information.

Editorial conclusion

Adopt Astrotomic/laravel-translatable when translated fields should live with Eloquent models and the application wants one package-managed API for several locales. Do not choose it if translations require a separate service, editorial workflow, or storage model that the package does not describe. Before adoption, verify compatibility with the intended Laravel and PHP versions, then define the model and locale configuration required by the package documentation. For v11.17, the repository states support for Laravel 9 through 13 and PHP ^8.0.

Frequently asked questions

Official sources

1. Astrotomic/laravel-translatable on GitHub
2. License: MIT
3. Project website
4. README
5. Releases