These are my notes from Chris Owen's presentation, 'Building a bilingual CMS' (for the National Museum of Wales) at the MCG Spring meeting. Chris' slides for 'Building a bilingual CMS' are online. There's some background to my notes about the conference in a previous post. Any of my comments are in [square brackets] below.
Why did they build (not buy) a CMS?
Immediate need for content updating, integration of existing databases.
Their initial needs were simple – small group of content authors, workflow and security weren't so important.
Aims: simplicity, easy platform for development, extensible, ease of use for content authors, workflow tailored to a bilingual site, English and Welsh kept together so easier to maintain.
It's used on main website, intranet, SCAN (an educational website), Oriel I (more on that later in a later talk), gallery touch-screens and CMS admin.
The website includes usual museum-y stuff like visitor pages, events and exhibitions, corporate and education information, Rhagor (their collections area – more on that later too) and blogs.
How did they build it?
[In rough order] They built the admin web application; created CMS with simple data structures, added security and workflow to admin, added login features to CMS, integrated admin site and CMS, migrated more complex data structures, added lots of new features.
They developed with future uses in mind but also just got on with it.
Issues around bilingual design:
Do you treat languages equally? Do you use language-selection splash screens or different domain names?
Try to localise URLs (e.g. use aliases for directories and pages so /events/ and /[the Welsh word for events]/ do the same [appropriate] thing and Welsh doesn't seem like an afterthought). Place the language switch in a consistent location; consider workflow for translation, entering content, etc.
Use two-character language codes (en/cy), organise your naming conventions for files and for database fields so Welsh isn't extra (e.g. collections.en.html and the equivalent .cy.html); don't embed localised strings in code. [It's all really nicely done in XML, as they demonstrated later.]
Coding tip: pull out the right lang at the start in SQL query; this minimises bugs and the need to refer to language later.
It's built on XML, as they have lots of databases and didn't want to centralise/merge them together; this means they can just add news ones as needed.
Slide 16 shows the features; it compares pretty well to bigger open-source projects out there. It has friendly URLs, less chance of broken links, built in AJAX features and they've integrated user authentication, groups so there's one login for whole website for users. The site has user comments (with approval) and uses reCaptcha. There's also a slide on the admin features later – all very impressive.
They've used OO design. Slide 18 shows the architecture.
Content blocks are PHP objects – the bits that go together that make the page. Localised. Because links are by ID they don't break when pages are moved. They're also using mootools.
The future: they want to have more user-centric features; work with the [Welsh project] People's Collection and other collaborations; APIs with other sites for web 2.ish things; more use of metadata features; they will make it open source if people think it's useful.
They would really open it up, via something like sourceforge, but would take lead.
[Overall it's a really impressive bit of work, sensibly designed and well implemented. Between that and the Indianapolis Museum of Art I've seen some really nice IT web tools in museums lately. Well done them!]