Single Table Extended - nevadskiy/laravel-translatable GitHub Wiki

This strategy works in a similar way to Single Table, but with a slight difference. Translations to the fallback locale are stored in the original entity table, but translations to any other locale are stored separately in the single global translations table.

The following picture shows the database schema of this strategy. Columns that contain actual translations are highlighted in blue.

Set up

Let's make, for example, a translatable Book model that has 2 translatable attributes: title and description.

The model class may look like this:

<?php

namespace App;

use Illuminate\Database\Eloquent\Model;
use Nevadskiy\Translatable\Strategies\SingleTableExtended\HasTranslations;

class Book extends Model
{
    use HasTranslations; 

    protected $translatable = [
        'title', 
        'description',
    ];
}

The simplest books table migration might look like this:

Schema::create('books', function (Blueprint $table) {
    $table->id();
    $table->string('title'); // Used for translations to the fallback locale.
    $table->text('description'); // Used for translations to the fallback locale.
    $table->timestamps();
});

Publish the strategy migration using the command:

php artisan vendor:publish --tag=translations-migration

Execute the migrate command:

php artisan migrate

Configuration

All configuration options work similarly to the Single Table strategy.

Restrictions

Note that you cannot create a record for translatable model by setting translations only for custom locale (without translations in fallback locale) because the model requires the fallback translations to be stored in the original entity table.

$this->app->setLocale('uk'); // The fallback locale is considered to be `en`.

$book = Book::create($attributes); // This will fail.

To avoid that you can mark translatable fields as nullable in the database migration or force a model creation in fallback locale and add translations to other locales after that.