So when I say I work with Umbraco, people kind of always go, "ahh Umbongo Umbongo, they drink it in the Congo" referencing the TV advert jingle for sugar and fruit flavoured drink 'Umbongo' from the mid-nineteen eighties; which I can't deny is a particulary catchy jingle, but one I've always felt slightly self-concious singing along to. On the other hand, the Kia-Ora jingle of the same vintage and ouvre is as catchy as a rash, and I'm much more comfortable with it in the sing-a-long stakes. So when I had to name my blog which would largely concern Umbraco subject matter and I HAD to pick an eighties fruit based tv advert to reference, I chose the Kia-Ora one. Now I could have gone with the ad strapline 'We all adore a Umbraco' but somehow 'Umbraco, too orangey for crows' made more sense (nonsense). So sorry for wasting your time with this explaination, but I think it gives a fairly good indication about whether it's worth reading any of the blog posts...

In love with a dashboard...

Written by @marcemarc on Friday, 25 November 2016

So recently we helped upgrade one of our support client's Umbraco sites from v6 to v7, all went very smoothly, except suddenly...

...puncturing their haze of post upgrade bliss was the shocking realisation that they were entirely in love with the Cogworks CogPageReview dashboard and actually their entire world of workflow revolved around this simple content review date dashboard - and it wasn't in fact 'something they didn't really use and could live without' - but something they needed superfast, or otherwise, well... some content might get old and nobody would know....

I've come across this deceptively simple package a few times before, and people just tend to believe 'it's part of Umbraco', particularly for large sites containing public information that will only be valid for a certain period of time, you set the content review date, and don't have to remember to check next year, it's invaluable.


Anyway onsite I knocked together quickly a dashboard to do a similar job in Umbraco 7, and you can download it here for the time being, if it helps you out, and hopefully we can push this back into the original package, but what I have here is pretty hasty, it's working so far... fingers crossed.


... but hey that isn't what this blogpost is about...

I've blogged about creating dashboards and property editors before in the early days of V7 and fortunately now there is some pretty good information on this available in the Umbraco documentation, but but but: I can't recommend enough the Extending the Umbraco Backoffice training course for if you really want to get your teeth into how to build this kind of thing in V7...

So what I wanted to blog about was three small things I noticed putting this together that I sort of didn't really know about or had learnt recently from the above course and also had spotted in the refactoring of the 'proof of concept' (for proof of concept, read not very good) Redirect Dashboard that HQ ahem refactored for the 7.5 release - that seemed new to me and I thought were mildly worth talking out loud about, here they are:

1) Don't use $scope 'willy nilly'...

So I'd got into the habit of using $scope all over the place, and when we introduced property editors to the Umbraco Level 2 course we taught this approach - officially from the docs:

$scope as a Data-Model "Scope is the glue between application controller and the view."
and so enables your directives, controllers and views to share values and communicate in an agnostic manner.

Anyway cool kids don't seem to do it like that anymore - looking at the Redirects
dashboard the preferred pattern moving forward for Data Models is to declare a ViewModel
object or vm for short!

There is a good post about this here, by John Papa (not the Pizza guy):

You do this in your controller by declaring like so:

function($scope,$http) {
var vm = this;  

and then in your view:

<div class="redirecturlsearch" ng-controller="tooorangey.ContentReviewController as vm">

now you can set properties on the view model in the controller in a similar way to as
you would have used $scope:

vm.dashboard = {
  loading: false,
  nofDaysAhead: 30,
  documentTypeWhiteList: '', // comma delimited string of doc types to include if blank includes all...
  indexSetSearcher: "InternalSearcher",
  reviewDateFieldAlias: "reviewDate"

and refer to properties in your view like so:

ng-if="vm.results.HasResults && vm.dashboard.loading === false">

so here I'm grouping the dashboard status and settings on an object and for some reason
to me it seems to make the controller much much easier to read...

... and you don't need to inject $scope into your controller unless you are using it for
non data model purposes, eg setting watches and the like.

2) Backoffice styling - flexgrid and pagination, particularly pagination.

Making things look good in the backoffice has always been a bit of guesswork over what is there, and providing your own styles, which then as Umbraco changes start to look a bit weird... what package creators need is a style guide for property editors and dashboards that they can use to keep the look and feel of their creations consistent with the vanilla backoffice... the good news is I'm told the style guide is very much a planned thing that will happen soon.In the meantime if you are presenting tabular data, the redirects dashboard has the most recent HQ approach to this kind of thing and the first thing you notice is Flexbox for table layout is in the core, was that always there? I don't know, but it's certainly worth being aware of and utilising!

The most exciting thing though for me, because I hate implementing paging... is there is a new directive called 'umb-pagination' <umb-pagination - to consistently handle paging ui in the backoffice, and it's really easy to repurpose: so all I needed to do here was
to create a pagination object on my viewmodel with totalPages, pageNumber, etc, populated
from my search results

vm.pagination = {
   pageIndex: 0,
   pageNumber: 1,
   totalPages: 1,
   pageSize: 20

and implement a 'goToPage(pageNumber)' method in my controller to be responsible
for returning the correct page of results.... result!

function goToPage(pageNumber) { 
   vm.pagination.pageIndex = pageNumber - 1;
   vm.pagination.pageNumber = pageNumber;;

also we have an <umb-loading-indicator directive to handle the interaction when it takes a while to build the report

and an <umb-empty-state to show a message when there is no content review...

3) Finally language translations of text within the dashboard

I've always kind of wanted to provide the opportunity for people to translate the text used within a property editor or dashboard I'd created, but never really understood how. It's not just cos I'm English and think people from other countries will undertand if I just talk louder... anyway this isn't new, but is all setup by convention and so it might not be apparent what to do.

In your angularJS dashboard view or property editor you can use the <localize tag with a key and a default value (there is also a localize service if you need to work with the translated text in your controller)

<localize key="contentReviewDashboard_reviewDate">Review Date</localize>

in this example the localized text would be drawn from an item key called 'reviewDate' in an area called 'contentReviewDashboard'

now here's the convention bit: create a /lang folder within your package/property editor folder

now create an xml file matching the language and culture or your site eg en-us.xml

then within that file specify a <language tag and create your area and your specific key items:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<language alias="en" intName="English (US)" localName="English (US)" lcid="" 
<area alias="contentReviewDashboard"> <key alias="pageName">Page Name</key> <key alias="reviewDate">Review Date</key>

you create a different file for each language you wish to support.

It's then easy for someone to copy your lang file, and create their own if they decide to use your dashboard or property editor with Spanish editors etc

In conclusion

It's well worth attending that 'Extending the Umbraco backoffice' course

and it's worth 50 certification points on your path to be an Umbraco Master.

Umbraco code IS poetry - National Poetry Day 6th October.

Written by @marcemarc on Thursday, 06 October 2016

Today, the 6th of October is National Poetry Day - when I was younger, so much younger than today I used to write awful urban romantic poetry, (marcemarc completists can find out more here: Anyway I've often thought there is a similarity between beautiful code and poetry, the metre, readability, code blocks are like verses and of course whilst your code needs to compile - it does not have to rhyme...

oh and Poets and Coders seem equally obsessed with late nights and drinking coffee.

...with Umbraco and it's interfaces beginning with I, and all those package names beginning with u - my mind has often thought it should be possible to construct an Urban Romantic poem containing entirely references to classes and interfaces in the codebase and umbraco package names...

but of course that is ridiculous and here's the proof:

Our... Dialogue...

I Pub
lished ...

uComment "uTwit"
 "Sassy MobEye Widget!!"
"articulate ShowOff", uCounters

Delete All Children

INotificationModel Slimsy

X SL Touch ?
X ML Dump

Solis Search
301 Moved Permanently
I Content Finder

uShare Similarity
nuPickers ?

U, I, Oh Matic
Think of the children!


... Content.

really sorry!, I'm sure it could be bettered, also interested if anyone has any code that rhymes...

In terms of proper poetry I can recommend The Number Poems by Matthew Welton.

Umbraco Anti-Patterns

Written by @marcemarc on Thursday, 16 June 2016

Following up on my talk at Codegarden 2016, a few people have asked me about getting a copy of the slides...

Also read this, it says it better:

Developers Learn to say No


We have become exhausted slaves in a culture of positivity


Code Reviews: Just do it!

It would be a good openspace session to discuss creating a library of common Umbraco coding patterns, showing off variations of how to implement common functionality, or even a library of common Compositions, that you could select, and download into your Umbraco site...or something.


Umbraco Street Bingo


I see Umbraco Logos...

thanks to everyone who came to the talk and said nice things about it.

It's available to stream here.

ps. "Ladies and Gentlemen it's nice to be back... " was a joke by English Comedian Malcolm Hardee RIP - who was a genius clown of alternative comedy in the 1990's 

pps. T-shirt is Jeffrey Lewis and the Jrams:

This Note's for you... Editor Notes Updated

Written by @marcemarc on Monday, 21 March 2016

Editor notes has been Steinmeiered... Greystated; well Umbraco legend Chriztian has been using it and having ideas.

Principally it's all very well having this huge colourful Editor note reminding, sometimes nagging editors to do a thing in a certain way, (and the idea is to use this on areas not used that often), but there becomes a point, if you are an editor, and you use the site everyday, that a well meaning note, well it becomes irritating and patronising and takes up screen space and therefore infringes on an editors sense of wellbeing, particularly if you done a good grammatical error in the text of the note, or made a sentence too long, with too many commas and ands.

So now there is an option to configure the note to be 'collapsible' - the editor can read the note, and then decide 'they got it' and hide it, expanding it later lest they forget. (The state of collapsibility should be remembered using browser local storage for each note.)






So setting the Node Render Mode to 'Html' means everything is as before, 'Collapsible' gives you the new functionality and 'SlidingPane' is another alternative that will slide out a panel containing the note.


The latest version is .3 and is available and updated on Our Umbraco and Nuget too (Install-Package tooorangey.uEditorNotes).

Previously on uEditorNotes

Bad Spaces

Written by @marcemarc on Monday, 29 February 2016

So the Tiny MCE Rich Text Editor has been adding a lot of extra <p></p> tags and <p>&nbsp;</p> in Umbraco recently; Bad spaces - particularly when inserting Macros it seems.

In the past I've played with the Tiny MCE config, and used the 'forced_root_block' setting and that has prevented them from being added: see an article here on how to do that:

but somehow, on this last project I was working on - I couldn't get it to work like it used to :-( let me know if it still works right ? (probably just caching or something)

Anyway I didn't have time to mess around, tweaking and hoping and F5ving; and so instead, I hooked into the ContentService's saving event, checked for my rich text editor property (with alias 'content'), and used a Regex to strip out any empty paragraphs:

void ContentService_Saving(IContentService sender, Umbraco.Core.Events.SaveEventArgs e)
   foreach (var content in e.SavedEntities)
      if (content.HasProperty("content"))
         var contentHtml = content.GetValue("content");
         if (contentHtml != null)
 { // remove empty paragraphs var removeBlankParasRegex = @"<p[^>]*>(\s| |)*"; var strippedHtml = Regex.Replace(contentHtml.ToString(), removeBlankParasRegex, ""); // remove empty paragraphs with a non breaking space content.SetValue("content",strippedHtml);

} } } }

The nice thing about this approach is the editors get immediate feedback when they save, that the rogue spacing has been removed before they publish.

Whereas if you are relying on:

@Umbraco.Field("propertyAlias", removeParagraphTags:true)

then it will still look a bit messy in the back office.

To register the saving event, create a class that inherits ApplicationEventHandler, and override ApplicationStarting to hook up to the saving event:

public class ApplicationStartUp : ApplicationEventHandler
   protected override void ApplicationStarting(UmbracoApplicationBase umbracoApplication, ApplicationContext applicationContext)
      ContentService.Saving += ContentService_Saving;

Custom Macro Parameter Types Editor Odyssey

Written by @marcemarc on Tuesday, 16 February 2016

Hey this may not be obvious but creating Custom Macro Parameter Type's in Umbraco 7 has gotten insanely easy, without anyone really shouting about it. (or if they did I wasn't listening properly, I do apologise - I bet there's something on Tim Geyssens' excellent blog about it - but in fact if you wondered about this and looked in the official docs:

it says:

"If you want to create a new macro parameter editor you will need some c# programming and database knowledge:

First create a class deriving from a webcontrol and implement the IMacroGuiRendering interface. Afterwards, open your database editor. Find the cmsMacroPropertyType table and add the a new property editor."

Boo, that sucks! and it's also not true anymore!

Because now in the wonderful world of Umbraco 7 and angularJS - if you can create an Umbraco Property Editor, you can create a custom Macro Parameter Type Editor too!

The secret (shsssshhh) is to create an angularJS property editor, as you normally would, then in the package.manifest file; add the property:

isParameterEditor and set it to true.

that's it.

Not only will your editor appear in the list of property editors, it will now be available as a Macro Parameter Type too !!


Example, (always you want an example).

Well in the real world, I often have to build Umbraco sites where editors insert images into a Rich Text Area. (as not everyone is weaned onto using the grid yet). Now you might want that inserted image to have very specific markup ie class="responsive-image", and have a caption underneath, or use the new html5 picture element that all the cool kids are talking about instead of the img tag.

So this could lead you to abandoning the Insert Media button and creating a macro instead to insert the image into the rich text editor, you can specify a parameter of media picker type; and then be very specific about the markup that gets written out for the picked image.

undefinedWhich is all great and that but,... then the editor wants to align the image right or left amongst their text. Well you can create another parameter which is a textbox and have them type L or R into it or maybe create another Macro called 'Insert Image Right' to add the floating markup but it doesn't feel awesome. What you really want to provide is a nice radio button list to infer the options for positioning the image.

The default Macro Parameter Types are a bit lacking when it comes to this kind of thing.

So let's create a custom 'ImagePosition' Macro Parameter Type editor, to provide radio button options of how to position the inserted image, that we can then read in our macro implementation to apply relevent markup / css classes etc.

This is what our package.manifest file looks like:

 "$schema": "/App_Plugins/manifestSchema.json",
 "propertyEditors": [ 
 "alias": "tooorangey.ImagePosition",
"name": "Image Position",
 "isParameterEditor": true,
 "editor": {
 "view": "~/App_Plugins/tooorangey.ImagePosition/ImagePosition.html",
 "valueType": "STRING"
 "javascript": [

Our View:

<div ng-controller="tooorangey.ImagePositionController">

<div class="radio" ng-repeat="position in positions" id="selectstatus-{{position.Name}}">
 <input type="radio" name="position" ng-change="handleRadioClick()"
 ng-model="model.value" value="{{position.Name}}">{{position.Name}}

Our Controller:

(I'm hardcoding the options here, there isn't the concept of prevalues for Macro Type Parameter Property Editors, but you could read the values in from an API endpoint etc

angular.module("umbraco").controller("tooorangey.ImagePositionController", function ($scope) {

 if ($scope.model.value == null) {
    $scope.model.value = 'FullWidth';

$scope.positions = [
    Name: 'FullWidth'
    Name: 'Left'
  Name: 'Right'
   Name: 'Center'

 $scope.handleRadioClick = function (status) {
 // alert($scope.model.value); 

we can then read the parameter in our macro using:

var imagePosition = Model.GetParameterValue<string>("parameterAlias");

and depending on this value align our images appropriately.

In conclusion it does kind of mean you can kind of go to town on creating custom Macro Parameter Types to make the editing experience more delightful or at least be aware it's easy to re-use existing property editors on macros parameter types.

Moving, Just keep moving... or how to move your properties when you've mucked up your compositions and doc types

Written by @marcemarc on Wednesday, 10 February 2016

Ok so the scenario here is you've created a Document Type, let's say for a News Article, and you've used Compositions to compose your Document Types,
because you have lots different types of pages with lots of common properties between them.

However your News Articles need to be tagged and you have two different 'tagging' properties that are only used on News Articles, and because they are only used on a News Article, you've created them as properties on the News Article document type itself, rather than an actual 'Tagging Composition'.

All's well, the tagging isn't used anywhere else.

But then suddenly in your agile iterations it becomes clear that there needs to be a 'Video News Article' Document Type for a different kind of
Article, with all the same properties as a News Article but with some extra ones for videos and that.

The Video News Article needs the same tagging properties as the News Article - Nested Document Type Veterans know that you can surely just create your new
Video News Aricle, underneath your News Article, it will inherit all the properties of the News Article, and enable to add your additional Video
properties, along with a suitable video icon - job done.

However in the brave new world of Compositions, this will lock the structure of the News Article document type, and you'll get the message, this content
type is used as a parent and/or in a composition and therefore cannot be composed itself...


or for those of you following along in the lovely new 7.4 UI:


What does that actually mean ? well it means you can't add or remove any compositions in the future from the News Article document type - but it's not unreasonable in this scenario to think you might want to update the News Article again, I mean the client has just invented the need for a Video News Article what else will change ?

So what are the options...

Well you might also think you could just create a new composition, create the tagging properties on that, and add that composition to your two article document types; however these will be new 'different' properties with different ids, and you will lose any data on the existing news article tagging properties that have already been entered.

I think maybe what the message is trying to suggest is that you should now treat the News Article document type as a composition, and create a further new News Article doc type underneath, and migrate all of your existing content from the old News Article to the new one; but it's not a quick fix.

Finally your other more obvious solution is to duplicate the properties on both the News Article and the Video News Article, and it will be fine, but as a developer it
will nag away at you for the rest of your caffeine fueled development days, and when people say the project went well, and the client says they are really
happy with what you've done, you will not be able to enjoy this feedback, because in your heart you know the solution is fundamentally flawed, broken and makes you sad to think of it.

If only there was a way to move the properties from the Document Type to a Composition, without losing the data...

... ok not saying try this at home or anything but.

In the Umbraco database (stop reading now, he's talking about hacking the Umbraco database directly, he's gone mad) the data is stored against the Property
Id, and that Property appears on a particular document type because it is mapped to a ContentTypeId (the doctype) and to a PropertyTypeGroupId (the tab on
the doctype) sooooooooooooo

In the Umbraco Back Office create a new Composition, say _taggingcomposition. Add a tab called 'Tagging' - and update your News Article and Video News
Article to use that composition.

Now connect to your Umbraco Sql Server Db and run the following:

SELECT TOP 1000 [id]
FROM [atgmedia].[dbo].[cmsPropertyTypeGroup]

find your new composition and tab, (it will be the last one), and make a note of the Id and the ContentTypeNodeId for your new composition / tab

let's say ContentTypeNodeId is 1234
and Id = 66

Find the Id of the property you want to move, using it's alias:

SELECT TOP 1000 [id]
FROM [atgmedia].[dbo].[cmsPropertyType]
where alias = 'aliasOfYourProperty'

Let's say the Id is 111

Now Update the properties entry in the cmsPropertyType table to use the new ContentTypeId and PropeTypeGroupId for your new composition:

Update cmsPropertyType
SET contentTypeId = 1234, propertyTypeGroupId = 66
Where id =111

(substituting your values of course)

But nothings happened!

So properties and where they appear are all cached, so we need to trigger the application to restart for Umbraco to become aware that the properties have

So break the web.config or recycle the app pool etc

And now the tagging properties should appear on the Composition, and in turn appear on both the News Article and the News Video Article; and because the ids
of the underlying properties 'haven't changed' they've never really left the News Article document type, all the tagging data values entered so far
on News Articles remain intact.

So you're all ready for next week's 'Sound Clip Article' right?

... and I'm not saying you're healed and free to bask in the feedback on the project from the client, because even though the situation is resolved,
let's face it, you're still really annoyed and jaded with yourself for not foreseeing this requirement in the first place!

Update August 2018

Dave Woestenborghs (@dawoe21) says: 

just don't try that on cloud..because it will break your deployments. Main reason why this PR is not merged yet :

Evolution of the grid

Written by @marcemarc on Monday, 20 April 2015

I've been looking at the new Grid Layout approach in Umbraco 7, and have been trying to get my head around how the grid editor you configure in the backoffice => maps => to the kind of responsive grid html you might put together for a these days website.

The mapping mismatch is that out-of-the-box you have a 'responsive' framework 'bootstrap3.cshtml' or 'bootstrap2.cshtml' - partial razor file to get you started, that is wired to work with the GetGridHtml umbraco helper method, that magically writes out the content the editor has entered into the grid (and you can overload it with the 'framework' partial view of your choice - I have created one for foundation5 for use with this blog - [Insert responsive framework debate here]),

I digress,

so 'out-of-the-box' the starter 'framework' razor examples will just write out col-md-4, for your chosen cell of '4' column width; but in reality you are probably also going to want to write out further classes to control how the cell responds to being laid out on different screen sizes, ie you may want your col-md-4 to be col-xs-6 on a smaller display screen, or col-lg-8 on a larger display, or push or pull or offset or whatever.

It would be easy to dismiss or misunderstand the grid's viability, based on this mismatch - but there are workarounds, and it's early days for the grid, and it's a bit like shooting the first evolved land mammal in the foot on the grounds that it could not type.

So anyways workarounds -

you can customize your responsive framework razor file to handle your crazy overriding of the responsive grid layout, how you do this depends a little on who is going to be editing the site, and what their level of understanding of responsive grids. Traditionally it's designers who would perhaps understand and control where the site design decides to respond in a grid, but the lines blur when it comes to content delivery...

1) Non Grid Aware Editors - you will probably want to create custom grid row's with meaningful names eg. 'Product Row' or 'Featured Articles' and then in your framework partial view, check for the name of the row and write your own custom implementation of the grid

@foreach (var row in s.rows) {
if (row.Name == "Product Row"){
else {
//default row render
@renderRow(row, false);

The editor need not know where and how the content breaks, but broadly get the notion of the grid organising the content. There is no row 'alias' so you need to target the row 'name' used on the particular project.

2) Grid Aware-ish Editors - crying out for an alternative to the rich text editor, you can perhaps call your columns more griddy names '4 col row' etc although that soon becomes '4 col 3 on ipad portrait row'...

... You can create 'custom config settings' for editors to apply to 'cells' or to 'rows', just by adding a bit of json config to your grid data type, you could add a 'row type' radiobutton list, and use these values in the framework razor partial to customize the row rendering.




You get a blob of json representing the grid content, and you can see here the 'config' settings that you have configured, to be added, and the value chosen by the editor.


3) Super Grid Aware Editors - They can just apply the relevant grid css class names to the grid cell or row via the settings button, but every time they add content they'd need to remember to apply them, imagine the flexibility...


So why does all this feel a bit fiddly at the moment? - Umbraco isn't trying to tie you to using bootstrap, and there isn't a common vocabulary to say things like '4 column layout that collapses to 2 on an iPad Portrait view, but 1 column on smaller devices' - the grid class names are the language, and each responsive grid has different class names and techniques, and so presenting these in the back office coherently would be a bit difficult.

With the 'Custom Config Settings' they have added a degree of flexibility to allow you to extend the interface to give editors additional input to each row and cell which could be used to determine how they are rendered, but I think it would be nice to have the option to do this at the data type configuration stage -  'out of plain site' of the editors, ie when you configure the columns for a row, it would be good to be able to set some default css classes here or other maybe other settings.


So if you created a "Product Row" of 4 - 4 - 4 when you set the value 4, in the grid data type editor, you could also add 'col-xs-6' then whenever this row is rendered in the framework file it's custom css class could be written out, along with additional editor added classes.

In the scenario that the designer still decides the points at which the design should respond, the site implementers could add the relevant classes here, and not have to customize the framework razor file, and editors wouldn't need to know the grid classes, or wouldn't need to remember to apply them on every row, on every page.

UPDATE: I created an accompanying Issue / feature request - and tentative fix:



It's not that simple, this dictionary, never has a word for the way I'm feeling

Written by @marcemarc on Monday, 13 April 2015

Ok so you upgrade your client's website to Umbraco 7 - their multilingual editors in Umbraco 6 didn't have access to 'settings' and the 'dictionary' - even if you relocated it to the translation section (where is should be by default) - but you worked around this by installing Dictionary Dashboard package coupled with 'my Dictionary Search thing' (see:

- but now with the upgraded site, you announced to the client, that one of the upgrade benefits is the dictionary section of Umbraco can now be moved into the 'translation section' (, which you do for them, but they've kind of forgotten what the dictionary section looks like, as they have been accustomed to the workaround, and they 'don't like' the new way of changing dictionary items in Umbraco 7, the editors want to be able to search for the translated text rather than know the dictionary key, and since there is no Dictionary Dashboard package for Umbraco 7 and my search thing was a User Control, you hastily cobble together this:





Which should allow editors to search by dictionary key or by the translated text, and then link to the settings section, or edit the text, there and then.

It's on github here:

Our Umbraco:

Nuget: Install-Package tooorangey.uDictionaryItemSearch

Yes, I see how it works, but what is the Dictionary Item called that I need to edit ?

Written by @marcemarc on Wednesday, 29 October 2014

The Dictionary section of Umbraco is a place to create, well, dictionary items, you create this 'Dictionary item' with a key name: perhaps 'Read More' and then for each language setup for your Multi-Lingual Umbraco site you get at textbox to provide the alternative translated text version for 'Read More' in the various languages.

Some description

Some description

The idea being that inside your Umbraco Templates, Contour Forms, DocType labels etc, you can write out the dictionary item, and depending on the culture setting of the part of the Umbraco tree the page is displayed, the appropriate translation is used from the dictionary.

Something like: @Umbraco.GetDictionaryValue("Read More") will do the trick.

So this is great, one place for repeated phrases or small bits of text, saving editors from repetitive typing of the same thing and ensuring consistency, and ignoring for a moment that language translation is not necessarily that simple all the time, with the nuances of context and inflexion, the facility is there to provide language alternatives.

So you create a few Dictionary items for your site, they get translated all well and good. They rarely change. You probably followed some kind of naming convention, maybe you nested items in groups under other items, it made sense to you at the time, and possible to the editors.

However the problem kicks in when you inherit an Umbraco site, created by someone else, a long time ago, it's happening a lot - now at some point when creating a multi-lingual website in Umbraco it must have been fashionable to try and see just how many dictionary items could be created, and nested, a competition perhaps ? CG09??, with extra points for different naming conventions and case ? Was it possible to get Karma for creating dictionary items ??

Anyway even the most well thought out structure of dictionary items is difficult to follow on a large multi-lingual site, and we have been through a pattern of redesigns recently where phrases in the dictionary items needed to change; and nobody could remember what the relevant dictionary key's in the back office were called anymore...

And on some of these sites the editors did not have access to the Settings tab where the Dictionary sits (and it isn't straightforward to move this to a different section the way the permissions are checked - it should be in Translation, shouldn't it ?). On these sites we generally have the excellent DictionaryDashboard package installed, allowing editors to select the dictionary key from a dropdown, and edit accordingly.

Brilliant, but imagine for a moment I am French, (Oui, mon ami C'est vrai): I see on my site the phrase:

Il n'existe pas de résultat pour le critère sélectionné

I need to edit this phrase, but which Dictionary Key ?

DictionaryDashboard has a dropdown of all keys, but not in alphabetical order, and the key names are all English ?? it's not always obvious, Keep pressing and guessing ?

So I was getting fed up being asked which key, and guessing or having to look it up in the template; for 65 keys, for 25 translations, I exported a 'look up' spreadsheet...
 but it was still easier for them to ask, and even if they had the key they had to find it in the dropdown...

So maybe be good if you could just type the value in somewhere, for a particular language, and it tell you what the dictionary key was, and maybe find it in Dictionary Dashboard ?

So... Set the language and enter the translation you are looking for

Some description


It goes off look through all the dictionary items for the selected language to see if there is a matching value to the search text:

Some description

Voila! (as us French say): search results - you see the keyname, and the value (just to be sure) and if there are no exact matches it will do a 'contains' search.

Now instead of having to find the key in DictionaryDashboard's Dictionary Editor, click edit:

Some description


It finds it for you!

Anyway it's just another Umbraco 6 usercontrol, and you add to the same Tab you have the Dictionary Editor of the Dictionary Dashboard installed.

And the code is on GitHub here:

If you are in a similar position of inheriting and supporting multi-lingual Umbraco sites with award winning complicated Dictionary Key structures, then I hope this might help someone else out... or if one already exists, why didn't you tell me about it ?