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.

Data Model Questions

alternative to translatable

Go to End

11 Posts   1271 Views


16 November 2011 at 1:39am (Last edited: 16 November 2011 1:39am), Community Member, 30 Posts


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

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?


16 November 2011 at 6:50am Forum Moderator, 1091 Posts

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?


16 November 2011 at 7:07am Forum Moderator, 1796 Posts

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

I like it... it reminds me of what I did (here 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!


16 November 2011 at 10:07pm Community Member, 30 Posts

@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.


16 November 2011 at 10:34pm Forum Moderator, 1796 Posts

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!


16 November 2011 at 11:02pm (Last edited: 16 November 2011 11:06pm), Forum Moderator, 1091 Posts

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?


16 November 2011 at 11:44pm Community Member, 30 Posts

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.


17 November 2011 at 12:33am Forum Moderator, 1091 Posts

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