Ok, so I am sitting in the lobby of the Palau de Congressos de Catalunya for Sitecore Symposium, I guess I should be writing about my experience, my views on the fantastic marketing features and technical innovations that have been presented to us during the event. However I find myself equally struck by the ease in which developers, marketers and other staff have communicated at a large European event with so many different cultures and how welcoming it has all been.
It got me thinking about something I have had on the back burner for a while and it’s time I sorted it out. I will start with this statement; ‘It is my belief that in the majority of respects, building a great Sitecore solution is almost completely the same regardless of whether you are building for single language, or building for multiple languages’. There are also of course a few important differences but that will be outside of the scope of this post, let’s focus on the basics.
For me, the main similarities are as follows:
- All text on the page should be editable.
- The site should be modular.
- Future multilingual capability becomes possible even if not a current requirement.
All text on the page should be editable – Page Labels & Dictionaries
I will come right out and say it, unless its improved somewhat, I am still not the biggest fan of the Sitecore’s default Dictionary implementation. I still to this day choose to utilise a simple dictionary that was developed by myself and Simon some 3 – 4 years ago on Sitecore 6.6, and to be honest, it still to this day works as well as it ever needed to. The default Sitecore Dictionary probably has improved in truth (I am happy to be proven wrong if someone cares to save me time and / or effort), but at it’s core the subtitle principle is true regardless of the implementation. ‘All text on the page should be editable’ – let’s take a second to think on this one, ’cause in truth – it’s obvious. This should include the form label text, the titles, the page title (element), the text that shows when you link to it etc etc. However, this should ALSO include things like:- placeholder text that disappears in search boxes, button text, image alt text and anything else you can think of. It’s actually not a trivial task when you think of it and I have seen a ton of implementations that miss this simple CMS principle.
Take this to it’s logical conclusion and you have already started on the road to making a decent (single tree structure) multi-lingual implementation.
The site should be modular
This is a bigger topic and at the same time smaller. The premise is that as far as you can, the site needs to be as isolated as it can be without making it too isolated. In so much as – you can reuse (for example) connectivity to third party systems such as sales force, google maps, google search appliance and even internally within Sitecore KEY elements such as your dictionary implementation and so one WITHOUT making them so tightly bound that they can only service one single implementation. The truth of the matter is that (as is so often the case in software development) 5 minutes thought upfront can often save you 10x that amount in future in unpicking and refactoring later on. In most cases the considerations that would be different mini sites / versions of a site will often be the same considerations of a multi-tree multi-lingual implementations. Things such as differing root paths, individual settings paths.
To clarify: The agile philosophy here still holds true in so much as we build following best practice to enable our *solution* to keep smells to a minimum. Things like the Open Closed Principle is (mostly) applicable to our Sitecore in this manner amongst many other design patterns & paradigms.
I think it is one of the most foolish ideals you can live with in Sitecore development to believe ‘It will never be multilingual’ or ‘We will never host another site on this installation’. We know to well in software development, clients do indeed change their mind regularly and the marketing managers decision to launch your UK site in Benelux / France or wherever should really be no shock to us. If we have followed the basics – getting the page editor experience right (everything content editable) etc, then you should be a long way on the way to getting the basis of a multilingual installation up and running.
Check for language versions
I know this is a small point, and probably shouldn’t live in this post, but it will probably save a world of hurt later and takes 10 seconds. The axes methods such as GetChildren() when used should also have a check on them to see the the Versions property has more than 0 (count or length – I can’t remember which). Sitecore will return child items of different languages by default but in most cases they will be empty or contain the default $name type standard values.
I guess as always we do our best to make the best solution possible for the client. I think if you follow the basics then you should land on your feet a little better when the call comes to launch your South African brand. Even if that call never comes, you still have a great page editor experience and ultimately give the users the most control of their site.