Symfony2+Doctrine2: How to properly localize records?

Question

I'm looking to manage record localization with Doctrine on the Symfony2 framework.

Requirements are

• ability to translate records
• ability to add a record in one locale only
• a developer-friendly reusable pattern of any kind to accomplish this

So far I have implemented the DoctrineExtensions library to make use of the Translatable extension. Everywhere I read it is regarded as the preferred way of handling translations. I realize this is not the same as localization but it seems this is the closest I was going to get.

Let's say I have a product table with translatable products. My default language is english. After I insert a product in the default english locale I can later add a translation to let's say italian. What I haven't been able to do with the Translatable extension is to only add a product in the Italian locale. If I do that, the Translatable extension also adds the product in the default language (english) but with italian content. And then it proceeds to also add an italian translation.

My product entity looks like this; (simplified)

<?php
namespace Acme\DemoBundle\Entity;

use Gedmo\Mapping\Annotation as Gedmo;
use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 * @ORM\Table(name="acmedemobundle_product")
 */
class Product
{
    /**
     * @ORM\Column(type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    private $id;

    /**
     * @ORM\Column()
     * @Gedmo\Translatable
     */
    protected $name;
    ...
}

Is there a way to add a record in a non-default language only? Or am I looking in the wrong place?

-

Before using Symfony&Doctrine, I was used to managing localized data in two tables which were then joined together using the requested locale.

For example, the products table contained all locale-indepent data like

• id
• category_id

and the products_i18n table contained all localized data like

• product_id
• locale
• name
• description
• slug

This way, there is only one main record which can be used for relations, and one or more localized extensions. A record without a localized extension would be seen as nonexisting.

Perhaps there is a way to accomplish that instead?

-

To be honest, so far I haven't found much useful information at all on this specific subject. I can't imagine I'm the first to come across this issue.

Any help on this matter is greatly appreciated!

============== UPDATE

I decided to go with a custom solution that ties two tables together like I illustrated in my example above. Main reason for this (besides I needed the functionality) is that Translatable saves ALL translated data in a single table. This doesn't feel right from both a performance and crisis-scenario point of view. Much more organized to have each table's localized data in it's own table rather than aggregated.

For now, I accepted Peter's answer since it was the most helpful. If a better answer comes along, I will consider switching. Cheers!

Answer 1

Look at the Translatable behavior extension for Doctrine 2

Answer 2

This question seems to be a bit of a source of misunderstanding. When you want to make products only available in certain regions (based on the locales ), you are not asking about the translation being only available based on a locale.
It is pretty perfect that the doctrine extension insists on providing a default translation for your product, otherwise your application won't be able to handle request properly.
After all, the product is available in all regions or locale zones, so how to provide the information for the translated content, say, name?
If there is no default settings for the translated name, this means the product displayed within the default zone can't resolve its name. The entity is incomplete as the name would be null.
To add the product to a certain locale zone only, you would have to add a property to your product, as

/**
 * @ORM\Column(type="string")
 */
private $localeZone;

which then gives you a posssibilty of filtering entities. You also could setup your Entity Product as a MappedEntity and use several Subs for Local entities, this would give you a change of storing products for italy in ItalianProducts , e.g. though I would not personally like this thought, as it is a distinguishing of objects based on the value of an property therein it, rather then a difference in behavior or data structure.