Language versions of beans

31 views
Skip to first unread message

Marko Tukiainen

unread,
May 4, 2015, 7:08:51 AM5/4/15
to redbe...@googlegroups.com
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

Marko Tukiainen

unread,
May 4, 2015, 9:10:33 AM5/4/15
to redbe...@googlegroups.com
Actually, after thinking about this a bit more, I'm starting to think that the ownLocalization method would be the best from a database design standpoint: it's infinitely expandable to cover all languages, there's no duplication of data or rows and queries should still be fairly efficient. That, or $product->fiproduct->name type of thing that just creates a separate table for each product.  

gabor

unread,
May 9, 2015, 7:13:35 AM5/9/15
to redbe...@googlegroups.com, m...@aptual.fi


Sorry for my rather late response.
It's extremely busy at work these days.

A localized description almost never belongs in the database.
At most you can store a language key in your database, like: $product->description = 'description.car.default';

Your localization strings should be in a localization file.
If your users need to edit them dynamically you can store them in the database but in a different table:

$descriptionBean->ownText = array( $english, $finnish );
$product->description = $descriptionBean;

Some companies like to use views for localization, combining a table with a language table.

I would never create duplicate entries per language, because all localized texts are associated with the same record.

cheers
Gabor

gabor

unread,
May 9, 2015, 7:16:01 AM5/9/15
to redbe...@googlegroups.com, gabord...@gmail.com, m...@aptual.fi


If you like we can help you to build an appropriate language system.
Since May I and the company I work for offer commercial support, we can even send someone over to assist you.
Or I can help you with these issues at working hours, using Skype etc.

http://www.redbeansupport.com/


cheers,
Gabor

Marko Tukiainen

unread,
May 13, 2015, 2:01:59 AM5/13/15
to redbe...@googlegroups.com, m...@aptual.fi
Thanks for the reply. 

The items that need to be localized are user inputs, so they most definitely belong in the database. The application itself is already localized and all its texts and messages are stored in a language files. But I agree, in this case just the texts should be stored in a separate table (or separate tables for each bean class) instead of duplicating all the data in the beans. 

Using (updateable) views to accomplish this is an interesting idea. How well would that work with RedBeanPHP? I guess reading and storing might work as is, but fluid mode might create some problems...

Marko
Reply all
Reply to author
Forward
0 new messages