-
Notifications
You must be signed in to change notification settings - Fork 2
Working with the Translator
The translator is the endpoint of the Localisation API, defined at the Localisation package. But to ensure we're on the same page, we'll add it here as well.
In order to translate a collection or model, simply use the Translator facade:
use Translator;
$content = Content::find(1);
$translatedContent = Translator::translate($content);
In order to translate a model, the model must use the Translatable trait from the Localisation package. Ie.
class MyModel extends Eloquent {
use \Tectonic\Localisation\Translator\Translatable;
}
You must implement the required method: getTranslatableFields. This needs to return an array of the fields that are to be managed by the package.
You can return this directly in your controller actions (if you're running a set of API responses), and this will automatically create the JSON for you, necessary for your responses.
The default behaviour is to return all translations for a given content piece. This is handy for managing translations in a user interface. You can, however - simply restrict it to the current user's language.
$translatedContent = Translator::translate($content, 'en_GB');
This will return only the translations for English (Great Britain), if you have translations for that content stored in your database.
You can also define default languages, just in case the requested language translations are not available to a given user. To do this, you must tell the Translator what the default language is.
Translator::setDefaultLanguage('en_GB');
In this manner, the behaviour for returning translations changes slightly. If none can be found for the desired language, then it will return the default language translations.
The translation repository that is bundled with laravel-localisation, works with a translations table. That table has the following fields/columns:
- id
- language
- resource
- foreign_id
- field and
- value
The language is your language of choice, and this can be anything, but it's good to stick to locale codes, such as en_GB or en_US.
The resource represents the resource for the translation. Again, this could be anything but it's basically a grouping identifier. For example, a User model class name will be used as the translation resource for all fields and values for users that require translating.
The foreign_id is the id of the record that we may be working with. For example, a content record would have an id, and that would be stored as the foreign_id for a Content resource - along with the field and value, of course.
Field is as the name suggest - the name of the field. This is what will be used to decorate the entity object when the resource is translated. The value is simply the value for that translated field.
You can use the built-in TranslationRepository, or you can use your own, which can use any storage mechanism of implementation you like. Just make sure you implement the TranslationRepositoryInterface defined on the Localisation package, and then alias this to your repository, as you would normally in Laravel.
-
Home
- Objectives of this package
- [Who this package is for](Who this package is for)
- [Working with the Translator](Working with the Translator)
- [How it works](How it works)