Download the PHP package hoai/laravel-translatable-main without Composer

Laravel-Translatable

If you want to store translations of your models into the database, this package is for you.

This is a Laravel package for translatable models. Its goal is to remove the complexity in retrieving and storing multilingual model instances. With this package you write less code, as the translations are being fetched/saved when you fetch/save your instance.

Docs

• Demo
• Laravel compatibility
• Tutorials
• Installation
• Configuration
• Features list
• FAQ / Support
• Donations

Demo

Getting translated attributes

Saving translated attributes

Filling multiple translations

Laravel compatibility

Tutorials

• Check the tutorial about laravel-translatable in laravel-news: How To Add Multilingual Support to Eloquent
• How To Build An Efficient and SEO Friendly Multilingual Architecture For Your Laravel Application

Installation in 4 steps

Step 1: Install package

Add the package in your composer.json by executing the command.

Next, add the service provider to app/config/app.php

Step 2: Migrations

In this example, we want to translate the model Country. We will need an extra table country_translations:

Step 3: Models

1. The translatable model Country should use the trait Dimsav\Translatable\Translatable.
2. The convention for the translation model is CountryTranslation.

The array $translatedAttributes contains the names of the fields being translated in the "Translation" model.

Step 4: Configuration

We copy the configuration file to our project.

Laravel 5.*

Laravel 4.*

Note: There isn't any restriction for the format of the locales. Feel free to use whatever suits you better, like "eng" instead of "en", or "el" instead of "gr". The important is to define your locales and stick to them.

Configuration

The config file

You can see the options for further customization in the config file.

The translation model

The convention used to define the class of the translation model is to append the keyword Translation.

So if your model is \MyApp\Models\Country, the default translation would be \MyApp\Models\CountryTranslation.

To use a custom class as translation model, define the translation class (including the namespace) as parameter. For example:

Features list

Please read the installation steps first, to understand what classes need to be created.

Available methods

Available scopes

Magic properties

To use the magic properties, you have to define the property $translatedAttributes in your main model:

Fallback locales

If you want to fallback to a default translation when a translation has not been found, enable this in the configuration using the use_fallback key. And to select the default locale, use the fallback_locale key.

Configuration example:

You can also define per-model the default for "if fallback should be used", by setting the $useTranslationFallback property:

Fallback per property

Even though we try having all models nicely translated, some fields might left empty. What's the result? You end up with missing translations for those fields!

The property fallback feature is here to help. When enabled, translatable will return the value of the fallback language for those empty properties.

The feature is enabled by default on new installations. If your config file was setup before v7.1, make sure to add the following line to enable the feature:

Of course the fallback locales must be enabled to use this feature.

If the property fallback is enabled in the configuration, then translatable will return the translation of the fallback locale for the fields where the translation is empty.

Country based fallback

Since version v5.3 it is possible to use country based locales. For example, you can have the following locales:

• English: en
• Spanish: es
• Mexican Spanish: es-MX
• Colombian Spanish: es-CO

To configuration for these locales looks like this:

We can also configure the "glue" between the language and country. If for instance we prefer the format es_MX instead of es-MX, the configuration should look like this:

What applies for the fallback of the locales using the en-MX format?

Let's say our fallback locale is en. Now, when we try to fetch from the database the translation for the locale es-MX but it doesn't exist, we won't get as fallback the translation for en. Translatable will use as a fallback es (the first part of es-MX) and only if nothing is found, the translation for en is returned.

Add ons

Thanks to the community a few packages have been written to make usage of Translatable easier when working with forms:

• Propaganistas/Laravel-Translatable-Bootforms
• TypiCMS/TranslatableBootForms

FAQ

I need some example code!

Examples for all the package features can be found in the code used for the tests.

I need help!

Got any question or suggestion? Feel free to open an Issue.

I want to help!

You are awesome! Watch the repo and reply to the issues. You will help offering a great experience to the users of the package. #communityWorks

Also buy me a beer by making a donation. ❤️

I am getting collisions with other trait methods!

Translatable is fully compatible with all kinds of Eloquent extensions, including Ardent. If you need help to implement Translatable with these extensions, see this example.

How do I migrate my existing table to use laravel-translatable?

Please see the installation steps to understand how your database should be structured.

If your properties are written in english, we recommend using these commands in your migrations:

How do I sort by translations?

A tip here is to make the MySQL query first and then do the Eloquent one.

To fetch a list of records ordered by a translated field, you can do this:

The corresponding eloquent query would be:

How can I select a country by a translated field?

For example, let's image we want to find the Country having a CountryTranslation name equal to 'Portugal'.

You can find more info at the Laravel Querying Relations docs.

Why do I get a mysql error while running the migrations?

If you see the following mysql error:

Then your tables have the MyISAM engine which doesn't allow foreign key constraints. MyISAM was the default engine for mysql versions older than 5.5. Since version 5.5, tables are created using the InnoDB storage engine by default.

How to fix

For tables already created in production, update your migrations to change the engine of the table before adding the foreign key constraint.

For new tables, a quick solution is to set the storage engine in the migration:

The best solution though would be to update your mysql version. And always make sure you have the same version both in development and production environment!

Donations

This software has been crafted with attention and love.

Show your love and support by sending bitcoin to this address: 167QC4XQ3acgbwVYWAdmS81jARCcVTWBXU

Or by sending to this PayPal address: [email protected]

❤️ Thank you!