Hello,
It's been a while since I've posted about RedBeanPHP, even though I've been using it in several projects. With one application in particular, the time has come for me to start thinking about multiple language support.
Without RedBeanPHP I might add a second column to the primary key (for example: id, lang). RedBeanPHP obviously doesn't support having multiple items with the same id in the same table.
So I'm now considering my options on how to implement language versions into my beans. Let's say I have a bean $product that the user of my application has created:
$product->id = 1;
$product->name = "Car";
$product->description = "This is a nice car. Please buy it now.";
Now I would like to enable the user to translate the "name" and "description" fields to other languages. Ideally I would want this:
$product->id = 1;
$product->lang = "fi";
$product->name = "Auto";
$product->description = "Tämä on kiva auto. Osta se nyt.";
and then have another bean for each language with the same id but different values for lang, name and description. But I don't think it's possible.
The simplest solution would be to just store each localized string in the same bean in separate fields. This has quite a few drawbacks: the table gets bloated really quickly, especially if I support lots of languages. I also don't want to unnecessarily load extra data when accessing the beans.
Using something like $product->ownLocalization seems a bit excessive, but it might be the most RedBeanPHP compatible. There might be a bit of a performance hit (especially when working with multiple beans) and I imagine this would also require quite a bit of refactoring in my existing code.
I've thought about adding a separate identifier field to the table which would effectively group beans with different id under the same product umbrella, so I would have something like this:
$product->id = 1;
$product->identifier = 1;
$product->lang = "en";
$product->name = "Car";
and
$product->id = 2;
$product->identifier = 1;
$product->lang = "fi";
$product->name = "Auto";
This might work better, though it still might wreak havoc on reporting and other stuff that uses the id field to uniquely identify the product. So quite a lot of refactoring to do there as well.
So have any of you had to tackle this kind of a problem, and if so, what solutions have you come up with?
Thanks,
Marko