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 /

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

Translate / Translatable and Dataobjects

Go to End

13 Posts   7725 Views


Community Member, 28 Posts

14 August 2009 at 4:03am

Hi Community

can anyone help me with Translatable and Dataobjects?

I'm currently testing a multilanguage setup. Translatable works fine for my first test pages.
I additionally have dataobjects (called GalleryImage) with has_one relations (image) and text fields (Title, description, and so on).
i put "Object::add_extension('GalleryImage', 'Translatable');" in my config and the GalleryImage_translationgroups table was built.
Now, how can i translate my data objects? where do i find or how can i add the nice "create new language" dropdown or something similar?

Please Help....

Thanks, Ralf


Community Member, 28 Posts

17 August 2009 at 4:27am

Edited: 17/08/2009 4:44am

ok, no answer
and neither DOM nor CTF seem to like my translatable DataObjects very much...

so i ended up doing following:
- truned OFF Translatable for my DataObject
- added following fields: 'Title_en_US' and 'Description_en_US' (my default locale is de_DE)
- so i won't have to duplicate my gallery images for translation (like Translatable does in SiteTree) and have information for all languages in one Dataobject.

in my GalleryImage.php i added a function like this:

public function localeTitle() {
	if (Director::currentPage()->Locale != Translatable::default_locale()) {
		$functionName = 'Title_'.Director::currentPage()->Locale;
		$this->Title = $this->$functionName;
	return $this->Title;

and similar for description so i can access the right (translated) title and description from my templates.

in my GalleryPage.php i did something this:

function translatedGalleryImages() {
	$Data = $this -> GalleryImages();
	// Get Dataobjects from Original-Languague-Page
	if ($this->Locale != Translatable::default_locale()) {
		$Data = $this->getTranslation(Translatable::default_locale()) -> GalleryImages();
	return $Data;

so i can control the translated Dataobjects in the Template with <% translatedGalleryImages %>

and in in function getCMSFields():

$galeriemanager = new HasManyComplexTableField(... ctf config ....);
if (Director::currentPage()->Locale == Translatable::default_locale()) {
	$fields->addFieldToTab('Root.Content.Galerie', $galeriemanager);
} else {
	$fields->addFieldToTab('Root.Content.Galerie', new LiteralField('Gallery Message','<p>Galerie bitte in Standardsprache ('.Translatable::default_locale().') bearbeiten</p><p>Please edit your gallery in default language ('.Translatable::default_locale().')</p>'));
return $fields;

maybe one can define the original language as fallback (Title/Description) or filter objects which have/haven't filled out fields for current displayed language...


Community Member, 88 Posts

2 September 2010 at 6:28pm

I'm having the same problem on my current project. How can I add a nice 'create new language' Button on my Customized DataObject in the ModelAdmin?

derralfs solution is not practicable for my DataObject, as it would require do duplicate about 35 fields. Moreover it's not the way Translatable and DataObject was build for, is it?


Forum Moderator, 1899 Posts

1 October 2010 at 5:02am

Edited: 02/10/2010 3:43am

I'm going to hit this wall soon... it is the one reason to keep all of your data in the sitetree and have it managed in the 'Create Translation' stuff. The most key items that are mostly content are going to return into the site tree for this reason.

But there are still many items that cannot go there and I use ModelAdmin to manage their data.

My plan is to take the items that need to be translated and move them into 'WebsiteDisplayData' (with a has_one locale) type object and then link them to the original dataobject with a has_many.... so....


*needs to be translated


-has_many NewDataObjectWebsiteDisplayData

-has_one Locale

What do you think? Is there a better way?

Another possibility (that might become a module as it is a more generic way of doing it..) could be to create something that you can select a dataobject and then create a translation of it's data where you can then select each field and enter your translation. This would store something like...

class TranslatableDataObject
	static $db = array(

Then a function could be created like...

function TranslateDataObject($doMyObject)

...that could look up the object id in the translation and then overwrite the fields that have a translation as specified above.

Maybe this is a topic for the core dev list?



Forum Moderator, 1899 Posts

8 October 2010 at 11:03pm

After reading this....

It is clear that the option of has_many translations for my fields is not going to work because the popup HTMLField is not working with tinymce... anyone got this functionality working?


Forum Moderator, 801 Posts

12 October 2010 at 9:38pm

We've created a proof of concept ModelAdmin with Translatable a while ago:

It basically adds a language switcher to the ModelAdmin UI, and then hooks the language filtering into search results and adds it to new records. It doesn't take care of making a ComplexTableFIeld (or any relations edited through ModelAdmin) translatable, but should illustrate whats generally required to do this.

Anybody keen to pick up this module and extend it? We could use:
- List of existing translations (linked to translated edit form) on each record edit form
- "Create translation" dropdown/button
- Readonly fields of original language (that might already be in place through Translatable->updateCMSFIelds())

In terms of getting CTF to support Translatable:
- Add a language dropdown on the "add" popup
- Limit listing based on $_GET['Locale'] (or TranslatableCTF->$locale really).
- Links to existing translations in "edit" popup

Any takers?


Forum Moderator, 1899 Posts

13 October 2010 at 4:56am

Edited: 13/10/2010 5:08am

Well here is a patch for 2.4.2 to enable some of the javascript.


$('#myid').livequery('click', function()  ...

is now...

jQuery('#myid').change(function() ...

And yes that is very nice and can help very much - but there are quite a few things that will be need to make it "user" proof! It won't be for a couple of weeks because I have some other development from our software which I have promised to make open. But definitaly as I move forward this is a great start.



Forum Moderator, 801 Posts

15 October 2010 at 9:17am

I've committed your patch in

Looking forward to your contributions on this module - yeah, I think there's still a lot to do in terms of UI ;)

Go to Top