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.

General Questions /

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

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

Translatable Dataobjects on translated pages are not in correct locale


Go to End


7 Posts   3295 Views

Avatar
ChrisBryer

Community Member, 95 Posts

8 February 2011 at 12:54pm

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,
-Chris

Avatar
spankmaster79

Community Member, 46 Posts

11 February 2011 at 12:13am

Could it be we're having the same problem?

http://silverstripe.org/general-questions/show/15740

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

Avatar
MarcusDalgren

Community Member, 288 Posts

11 February 2011 at 2:56am

Yes this is a known bug and you have to make a change in one of the core files to fix this.
Here 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().

Avatar
spankmaster79

Community Member, 46 Posts

11 February 2011 at 4:29am

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']);

Translatable::set_current_locale($currPage->Locale);
$fieldset->push(new SimpleTreeDropdownField('PageLinkID', 'Page Link', 'SiteTree'));      
Translatable::set_current_locale(Translatable::get_default_lang());

Avatar
ChrisBryer

Community Member, 95 Posts

11 February 2011 at 12:22pm

Edited: 11/02/2011 12:24pm

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 the bug ticket 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.
-Chris

Avatar
MarcusDalgren

Community Member, 288 Posts

11 February 2011 at 12:26pm

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.

Avatar
ChrisBryer

Community Member, 95 Posts

14 February 2011 at 7:11pm

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. Here's the thread.

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.

thanks,
-Chris