Stephan Lonntorp
Nov 22, 2018
(2 votes)

Localizations in PropertyValueList

The PropertyValueList property type ca be really useful for things that don't have a need for reuse, or doesn't have a view. If you've used it you might have noticed that the editor experience, especially in regards to localizations, hasn't been optimal.

In Per's blog post from 2015, the question on how to localize arose, and Kai de Leuw answered with:


That worked really well, up until a few weeks ago.

In Episerver CMS UI 11.12, something was introduced, that broke this functionality. But have no fear, it can still be done, and it's even cleaner.

Now, your POCOs are localized in the same way that other content types are localized.

Provided you have a POCO like this:

public class Contact {
    public string Name { get; set; }
    public string Country { get; set; }

You can localize it with an XML like this:

<?xml version="1.0" encoding="utf-8"?>
  <language name="English" id="en">
            <caption>Contact name</caption>
            <help>The name of the contact.</help>
            <caption>Country of origin</caption>
            <help>The country of origin for the contact.</help>

Happy localizing!

Nov 22, 2018


valdis Nov 23, 2018 06:55 AM

hmm.. think I should really dig into this built-in localization thingy and try to remove xpath based things there as well ;)

Stephan Lonntorp
Stephan Lonntorp Nov 23, 2018 08:09 AM

@valdis Totally off-topic, but why? The XML based localization stuff (or your DbLocalizationProvider for that matter) should, in my opinion, only be used for translation of the Episerver UI. Everything else is content, and should be managed as such.

Treating UI texts as content enables editors to do A/B testing, scheduling and anything else that the CMS allows. While your DbLocalizationProvider certainly solves the editability challenge that the XML-based system has, and is a fine piece of engineering, in my opinion it solves a problem that shouldn't be a problem.

valdis Nov 26, 2018 02:15 PM

because you would not have these stringly-typed problems ;)

Please login to comment.
Latest blogs
Zombie Properties want to Eat Your Brains

It’s a story as old as time. You work hard to build a great site. You have all the right properties – with descriptive names – that the content...

Joe Mayberry | Mar 29, 2023 | Syndicated blog

Optimizely finally releases new and improved list properties!

For years, the Generic PropertyList has been widely used, despite it being unsupported. Today a better option is released!

Tomas Hensrud Gulla | Mar 28, 2023 | Syndicated blog

Official List property support

Introduction Until now users were able to store list properties in three ways: Store simple types (int, string, DateTime, double) as native...

Bartosz Sekula | Mar 28, 2023

New dashboard implemented in CMS UI 12.18.0

As part of the CMS UI 12.18.0 release , a new dashboard has been added as a ‘one stop shop’ to enable editors to access all of their content items,...

Matthew Slim | Mar 28, 2023

How to Merge Anonymous Carts When a Customer Logs In with Optimizely Commerce 14

In e-commerce, it is common for users to browse a site anonymously, adding items to their cart without creating an account. Later, when the user...

Francisco Quintanilla | Mar 27, 2023

How to Write an xUnit Test to Verify Unique Content Type Guids in Content Management

When developing an Optimizely CMS solution, it is important to ensure that each content type has a unique GUID. If two or more content types share...

Minesh Shah (Netcel) | Mar 27, 2023