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.

General Questions

General questions about getting started with SilverStripe that don't fit in any of the categories above.

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

Translatable Dataobjects on translated pages are not in correct locale


7 Posts   1448 Views


8 February 2011 at 12:54pm Community Member, 95 Posts

I added the Translatable extension to SiteTree and a DataObject, 'DOStaffMember'.
Using a default locale of en_US, i translated a page to another language, and when i open a DataObject from a ComplexTableField, the popup believes it is an en_US locale, not the current locale (it_IT or whatever). this is running silverstripe 2.4.5 release codebase.

Through debugging, i see that the class ComplexTableField_Popup doesnt know what locale it is, while ComplexTableField does.

anyone have any ideas where this is breaking? i can get the current locale through the controller in the ComplexTableField Class, but i'm not sure where the disconnect is.

thanks in advance,


11 February 2011 at 12:13am Community Member, 46 Posts

Could it be we're having the same problem?

If I select a different language from the Dropdown, I would expect that editing Dataobjects on the right side would give me the Sitetree for the selected language. But instead it always gives me the default language set.

I can force it by setting Translatable::set_current_language() to the desired language. But I don't know which language the editor has selected in the backend. There seems to be no language set..... I'll check the controller as you said it would know which language is selected...


11 February 2011 at 2:56am Community Member, 288 Posts

Yes this is a known bug and you have to make a change in one of the core files to fix this.
[url=]Here[/url] is the ticket report and there is a patch attached.

It stores the locale in the session which isn't something the core team wants to do. However right now there's no other easy way to fix this. With this fix the current locale will be correct but you might have to add it in yourself on the data object with onBeforeWrite().


11 February 2011 at 4:29am Community Member, 46 Posts

I'm not using the ComplexTableField but this smaller workaround helped me.

If someone is editing a page in a different language, that page has a different language, so I just get the page local for it

// get page relation in current editing language
$currPage = DataObject::get_by_id("SiteTree", $_SESSION['CMSMain']['currentPage']);

$fieldset->push(new SimpleTreeDropdownField('PageLinkID', 'Page Link', 'SiteTree'));


11 February 2011 at 12:22pm (Last edited: 11 February 2011 12:24pm), Community Member, 95 Posts

Hey All,
thanks for getting back to me. I'm upgrading a site from 2.3.3 to 2.4.5 and actually applied that patch in 2.3.3 a year or so ago. since i didnt see 'cant handle CMSMain action' error in the popup i assumed it was fixed. turned out that there was a further thread on that bug ticket which fixed half of my problem. I was able to set the locale of the record pulled up in the popup, but the CTF refreshed to default locale. the last patch in [url=]the bug ticket[/url] fixed the refresh issue.

i uploaded another patch to the ticket to fix the bug in 2.4.5.

hopefully this patch gets added soon so we dont have to apply it again in silverstripe 3. it is a more solid patch now because its not handling anything through sessions now.

thanks again for letting me know about the ticket.


11 February 2011 at 12:26pm Community Member, 288 Posts

Yeah we should really push for this stuff to get fixed so that Translatable actually works going forward.
I hate having to patch all my multilingual sites every time just to make them work.
Also one more thing that should be fixed is entity translations in the frontend of the site. Right now they're only affected by i18n so I end up setting the i18n locale to the same thing as the Translatable locale but I don't think that's the way it should work.


14 February 2011 at 7:11pm Community Member, 95 Posts

i thought i replied to this but just noticed that it didnt get posted. anyways, i raised this issue in the google core dev discussion group. [url=]Here's the thread[/url].

long story short, its possible that Translatable may become a module in the future.. could be good.. (and a lot of work). Has anyone put any thought around how to make the translation interface better? you can see my thoughts in the thread but i am very curious to get anyone else's thoughts.