Allow translatable strings with media types (ImageData etc.)


Since ImageData ( is not translatable we need to translate same descriptions and alternative texts over and over again in multiple locations, blocks, pages etc. where ever the image is used.

Issue is even more relevant now, that most governments require sites to be accessible. 

There has been conversation about this missing feature over the years on Episerver World:

Would it be possible to re-design media types, so that those will also implement ILocalizable? Based on the response from support issue is following:

You can check the class structure of ImageData and there's a Blob properties. This means the object can perform streaming and file read/write and this obviously cannot implements ILocalizable.

Which means that probably media types should be wrapped to something to allow ILocalizable?

Oct 09, 2020 9:18

Good suggestion!

I have solved it like this:

Oct 11, 2020 8:19

Interesting approach. Does this method allow use of only one culture specific property? I think I have to test it out. 

Oct 12, 2020 8:21
Tomas Hensrud Gulla - Oct 12, 2020 8:31
Add as many as you need.

If it's more than 1-3, I create a tab for earch languge.
Keijo Mukku - Oct 12, 2020 9:24
Ok. I did test this out and it did not work out the way I hoped it would. Thanks for the suggestion anyways. Let's hope that this will be fixed in future.
Tomas Hensrud Gulla - Oct 12, 2020 9:28
What did not work according to your expectations?
Keijo Mukku - Oct 12, 2020 9:48
I was hoping it would somehow magically bring translatable property to image via DescriptionBlock. That's why I did asked about one culture specific property. As ImageData is not translatable, local block in it isn't translatable either. It works but requires multiple fields for different languages. Not good for translation tools and user experience differs from Episervers native way of translating content.
Tomas Hensrud Gulla - Oct 12, 2020 9:50
Thanks, I understand, and agree.

It is possible, and I did it on one of the solutions I worked on a couple years back.

Grzegorz Wiecheć wrote how to do it 5 years ago

If it is a plain new solution then it should be simple to add, but if the solution is allready up and running, you will get issues as the images that is allready uploaded doesn't have culture set in the DB, so that you need to set manual to your masterlanguage if I remember correctly. Unfortanly I don't think I kept the SQL script I wrote to fix it :/ 

But the old images should still be displayed, just will have issues editing/translating them

Oct 13, 2020 7:40
Keijo Mukku - Oct 13, 2020 8:16
This seems promising and straightforward. Thanks! Unfortunately our solution is already up and running, and I don't feel comfortable running SQL scripts against DB at this point. I need to test this when I have more time.

I noticed Grzegorz also points to this blog posting from Patrick van Kleef ( , which quotes Linus Ekström: ‘The answer is no, currently all media data are non-localizable. There was several reasons for this but the main one was that we did not have time to manage all bugs/quirks that appear when you need to deal with localizable media. Therefore, the decition was to handle media as non-localizable content (just as the old VPP based file system), as least for the EPiServer 7.5 release.’

I also wonder what bugs/quirks he is referring to. I hope that some one from Episerver reads this and finally, after half decade, decides to take this forward.
Sebbe - Oct 28, 2020 15:19
Looks like Jake Jones have made a script here for migration

Note that you may need to edit the script a little to suite you
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.