Download the PHP package igaster/laravel-translate-eloquent without Composer

Description

Translate any column in your Database in Laravel models. You need only one additional table to store translations for all your models.

Installation

Edit your project's composer.json file to require:

"require": {
    "igaster/laravel-translate-eloquent": "~1.0"
}

and install with composer update

Setup

Step 1: Create Translation Table:

Create a new migration with artisan make:migration translations and create the following table:

migrate the database: php artisan migrate

Step 2: Add translatable keys to you models

In your migrations define any number of integer keys that you want to hold translations. (Actually they are foreign key to the translatable.group_id). This is an example migration that will create a translatable key:

Step 3: Setup your model:

Apply the TranslationTrait trait to any model that you want to have translatable keys and add these keys into the $translatable array:

Now you are ready to use translated keys!

Usage

When you access a translatable key, then it's translation will be retrieved in the application's current locale. If no translation is defined then the Laravel's 'app.fallback_locale' will be used. If neither translation is found then an empty string will be returned. So simple!

Work with translations:

Important notes:

• When you create a new translation for the first time, you must save your model to persist the relationship: $model->save();. This is not necessary when updating a translation or adding a new locale.
• When you set a value for a translation then an entry in the translations table will be created / updated.

Create/Update translated models:

You can also use $model->update(); with the same way.

Laravel & Locales:

A short refreshment in Laravel locale functions (Locale is defined in app.php configuration file):

Working with the Translations object

You can achieve the same functionality with the igaster\TranslateEloquent\Translations object.

Want to dive deeper into the internals?

• Translations object holds all translations for a key. Multiple transltions are grouped under the same group_id value
• Translation object is an Eloquent model (maps to the translations table) that represents a single translation for one key in one locale

Eager Loading:

You can use these query scopes as if you want to retrieve a translation with the same query:

Notes:

• The above query scopes should be used as an endpoint of your queries as they will return either a Model or a Collection
• Eager loading is designed to reduce to a single query the read operations when you are retrieving a model from the Database. It uses a JOIN statement and not two subsequent queries as opposed to Eloquent eager loading. One limitation of this implementation is that you can only request the translation of a single field.
• If your models have multiple keys that should be translated then all the subsequent read operations will result in an extra query.

Performance considerations:

Please notice that using a single Table for all translations is not the optimal architecture when considering database performance. Each translation requires one seperate query to the database. If performance is an issue you can check alternative implementations like dimsav/laravel-translatable

Handle get() & set() Conflicts:

This Trait makes use of the __get() and __set() magic methods to perform its ... well... magic! However if you want to implement these functions in your model or another trait then php will complain about conflicts. To overcome this problem you have to hide the Traits methods when you import it:

and call them manually from your __get() / __set() methods:

Todo

• Cascade delete model + translations Fixed
• Eager Load multiple keys per request...
• any ideas? Send me a request...