Virtual Happy Hour this month, Jun 28, we'll be getting a sneak preview at our soon to launch SaaS CMS!

Try our conversational search powered by Generative AI!

Stephan Lonntorp
Nov 22, 2018
  2659
(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:

[Display(Name="/path/to/lang/resource")]

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"?>
<languages>
  <language name="English" id="en">
    <contenttypes>
      <Contact>
        <properties>
          <Name>
            <caption>Contact name</caption>
            <help>The name of the contact.</help>
          </Name>
          <Country>
            <caption>Country of origin</caption>
            <help>The country of origin for the contact.</help>
          </Country>
        </properties>
      </Contact>
    </contenttypes>
  </language>
</languages>

Happy localizing!

Nov 22, 2018

Comments

valdis
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
valdis Nov 26, 2018 02:15 PM

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

Please login to comment.
Latest blogs
Remove a segment from the URL in CMS 12

Problem : I have created thousands of pages dynamically using schedule jobs with different templates (e.g. one column, two columns, etc..) and stor...

Sanjay Kumar | Jun 21, 2024

Copying property values part 2

After publishing my last article about copying property values to other language versions, I received constructive feedback on how could I change t...

Grzegorz Wiecheć | Jun 18, 2024 | Syndicated blog

Enhancing online shopping through Optimizely's personalized product recommendations

In this blog, I have summarized my experience of using and learning product recommendation feature of Optimizely Personalization Artificial...

Hetaxi | Jun 18, 2024

New Series: Building a .NET Core headless site on Optimizely Graph and SaaS CMS

Welcome to this new multi-post series where you can follow along as I indulge in yet another crazy experiment: Can we make our beloved Alloy site r...

Allan Thraen | Jun 14, 2024 | Syndicated blog