Jump to:

3460 Posts in 1064 Topics by 739 members

Data Model Questions

SilverStripe Forums » Data Model Questions » alternative to translatable

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

Page: 1 2
Go to End
Author Topic: 1242 Views
  • lekoala
    Avatar
    Community Member
    30 Posts

    alternative to translatable Link to this post

    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?

  • martimiz
    Avatar
    Forum Moderator
    1086 Posts

    Re: alternative to translatable Link to this post

    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?

  • swaiba
    Avatar
    Forum Moderator
    1792 Posts

    Re: alternative to translatable Link to this post

    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!

  • lekoala
    Avatar
    Community Member
    30 Posts

    Re: alternative to translatable Link to this post

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

  • swaiba
    Avatar
    Forum Moderator
    1792 Posts

    Re: alternative to translatable Link to this post

    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!

  • martimiz
    Avatar
    Forum Moderator
    1086 Posts

    Re: alternative to translatable Link to this post

    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?

  • lekoala
    Avatar
    Community Member
    30 Posts

    Re: alternative to translatable Link to this post

    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.

  • martimiz
    Avatar
    Forum Moderator
    1086 Posts

    Re: alternative to translatable Link to this post

    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?

    1242 Views
Page: 1 2
Go to Top

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.