Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

Data Model Questions /

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

alternative to translatable


Go to End


11 Posts   2836 Views

Avatar
lekoala

Community Member, 31 Posts

16 November 2011 at 1:39am

Edited: 16/11/2011 1:39am

Hi,

I wanted to share with everyone something I've created to be an alternative to the Translatable paradigm. It's one thing that bugs me with silverstripe, I don't like to have duplicated entries in my database or instead of translatable, using fields like myfield_en, myfield_fr is not very flexible. So, I got the idea to work on a dataobjectdecorator that is going to allow to make some fields localizable, while keeping only one "master" record. To achieve this, I simply create a table to store the localized fields called mytable_locale and use one row with the parentid and the locale + the localized fields.

The thing I like with this, is that I only make one query to get my translated dataobject every time (because i simply do a left join to get my localized fields), that I can rely on one single id as the reference, without having to go through a translationgroup table. As an extra bonus, it is super simple to edit in the admin because I don't need to have a special modeladmin or switch language or anything like that. I just create a tabset, with one tab for each locale, with the translated fields. Super easy.

It's still a bit rough right now and could surely be improved, but you can see a working example
http://www.sspaste.com/paste/show/4ec261c450c59

To use it, simply :
Object::add_extension('MyDataObject', 'Localizable');

Declare this property on the dataobject :
public static $localizableFields = array(
'name' => 'type'
);

And if you want to access transparently to your localized field, simply overload the __get method (haven't found a way to do this in the dataobject decorator)
function __get($fieldName) {
if($this->hasLocalization($fieldName) && Localizable::$automaticLocalization) {
return $this->localize($fieldName);
}
return parent::__get($fieldName);
}

What do you think of this approach ? any comments, suggestions?

Avatar
martimiz

Forum Moderator, 1391 Posts

16 November 2011 at 6:50am

Hi there

Interesting :-) Just to make sure I get this right from the start: do you intend this to be used instead of Translatable, or in combination with it?

Avatar
swaiba

Forum Moderator, 1899 Posts

16 November 2011 at 7:07am

What do you think of this approach ? any comments, suggestions?

I like it... it reminds me of what I did (here http://www.silverstripe.org/data-model-questions/show/8397?start=8) in order to over come adding full translation (adding translatable to teh full dataobject) because the price and setup of a product doesn't change - just the name and description.

So, again I like it alot and my use the approach int he near future!

Avatar
lekoala

Community Member, 31 Posts

16 November 2011 at 10:07pm

@martimiz : As swaiba mentionned, in some cases, I believe it makes more sense to be able to translate only a few fields. But for pages, the translatable approach might make more sense if you have some content that is not the same depending on the language. So I guess you could do both : only use my approach, or mix it. In the website I'm developing currently, I'm mixing both approaches : translatable for pages, localizable for dataobjects that need it.

@swaiba : yes I think it's a very similar approach, but instead of having two dataobjects, I made it work as a decorator.

Avatar
swaiba

Forum Moderator, 1899 Posts

16 November 2011 at 10:34pm

I think it's a very similar approach, but instead of having two dataobjects, I made it work as a decorator.

which is why I may be using it very soon ;-)
thank you for sharing!

Avatar
martimiz

Forum Moderator, 1391 Posts

16 November 2011 at 11:02pm

Edited: 16/11/2011 11:06pm

I get it - mixing the two would work for me, I suppose. I'm going to try out your solution as soon as I find a moment - I'm really curious... Thanks :-)

[EDIT] (Something popping up) When mixing Translatable and your decorator - you'd still need a way to synchronise relations for your translated page, wouldn't you?

Avatar
lekoala

Community Member, 31 Posts

16 November 2011 at 11:44pm

Indeed, if you use translatable, since you are going to have different pages, you will need to attach your dataobjects once for each language.

But maybe you could simply override the getter method for your relation to get directly the dataobjects from your main language or something like that.

Avatar
martimiz

Forum Moderator, 1391 Posts

17 November 2011 at 12:33am

Yes I suppose you could...

But that would mean if you wanted to make an existing site translatable, just decorating the DataObjects involved wouldn't be enough. You'd still have to add new getters to all classes that use them...

A bit of a challenge to think of a way in which the Decorator could play it's roll in this as well? :-)

Go to Top