Download the PHP package mnapoli/doctrine-translated without Composer

Translated strings for Doctrine

This library is an alternative to the Translatable extension for Doctrine.

The basic idea is to shift from "something that magically manages several versions of the same entity" to "my entity's field is an object that contains several translations".

It aims to be extremely simple and explicit on its behavior, so that it can be reliable, maintainable, easily extended and understood. The goal is to do more with less.

Requirements

This library requires PHP 5.4 and Doctrine 2.5!

How it works

The library relies on a new major feature of Doctrine 2.5: embedded objects. An embedded object will see its properties inserted in the entity that uses it.

Example:

If you use YAML instead of annotations:

The TranslatedString is defined by you by extending Mnapoli\Translated\AbstractTranslatedString. That way, you can define the languages you want to support. This class is reusable everywhere in your application, so you only need to define it once.

As you can see, the properties must be public.

Here is the same mapping in YAML:

You can then start translating that field:

Usually in your application, you will not want to hardcode "en" or "fr" when reading or setting the value. This is because the current locale varies from request to request.

That is why this library provides helpers to make it much easier, along with the Translator object.

Example:

Current integrations:

• Twig

The configuration step is very straightforward:

• Symfony 2

The Mnapoli\Translated\Integration\Symfony2\TranslatedBundle is provided. You need to register the bundle in AppKernel.php:

Then in your app/config/config.yml:

The TranslatedBundle will automatically listen to the request's locale and configure the Translator accordingly.

That means you have nothing to do: just use the Translator, and it will use the request's locale to translate things.

If the current locale is not stored inside the request, you will need to set up an event listener manually. Here is an basic example using the session:

When the user logs in, his/her locale is stored inside the session. Here is the configuration:

• Zend Framework 1

You can then use the helper in views:

Watch out: the translate view helper already exists in ZF1. The example shown here will override it. You can use a name different than "translate" if you don't want to override it.

Pros and cons

With that method, you will end up with only one table in database:

This makes it very good for performances, and for other reasons:

• no round-trip to the database because you always get all the translations
• no joins, this is a perfectly simple query
• isolated translations (there isn't a single table for storing all the translations)
• no problems with indexes (you can add the indexes you want)
• very friendly with manually browsing/editing the database

However, be aware there are cons:

• if you support 100 languages, you will end up with huge tables and large objects in memory
• if you add a new language, you need to update your database (Doctrine can do it automatically though)

Translator

You saw above a basic example of using the translator.

Here is all you can do with it:

To create a new translation from scratch:

Operations

Sometimes you need to concatenate strings in a model, so you can't use the translator (and you maybe don't want to).

You can do some basic operations on the translated strings.

Concatenation

You can also create a string concatenation from scratch:

Implode

Just like the concatenation:

Untranslated strings

Sometimes you should give or return a TranslatedString but you have a non-translated string. For example:

Here there is a problem: '-' is a simple string, and if the calling code expects a TranslatedString then it won't work.

For this, you can simply create an "untranslated" string:

It will have the same value (or translation) for every language.

Fallbacks

You can define fallbacks on the Translator:

As you can see, fallbacks are optional, and can be multiple.

Now the translator will use those fallbacks:

You will note that you can also directly use fallbacks on the TranslatedString object:

Doctrine

Documentation currently being written

There are no changes regarding persisting or retrieving an entity. When you load an entity from database, all the translations will be loaded.

However, due to the fact that Product::name is not a string anymore, you cannot simply filter on the field. You need to write queries like this:

The same goes for ORDER BY:

The $lang (current locale) can be obtained from the Translator.

I am looking at ways to makes this more simple, for example with a DQL function (https://github.com/mnapoli/DoctrineTranslated/blob/master/src/Doctrine/TranslatedFunction.php). Feel free to help, currently this is stuck because Doctrine instantiate the "function" classes itself, which prevents using dependency injection to inject the current locale (or translator).

Current issue opened at Doctrine: #991.