Christian Assemblies International Showcases i18n on Drupal 6

Recently the Christian Assemblies International website was launched on Drupal 6. With much of the site’s content translated into 10 languages, it’s a perfect example of the excellent Drupal 6 i18n advances put to good use.

Build Story

The Need for Change

Christian Assemblies International is a largely volunteer-run Christian church, based in house groups throughout about 15 countries worldwide. The church’s original website was being manually maintained in 7 languages with Dreamweaver by a handful of very dedicated volunteers. Besides the obvious challenge of replicating changes 7 times throughout all pages, the workers had to struggle with making changes to languages that they couldn’t even half understand, like Russian and Polish. Many would have been keen to help in the work and share the load, but each new maintainer/helper required expensive software along with quite a bit of training, making the barriers to entry quite high. Adobe Contribute was used with some success to integrate non-technical users in a limited way, but slowly the site was becoming unmaintainable and a total rethink was needed.

The church needed a way to cheaply and easily spread the work amongst as many non-technical volunteers as wanted to help out – in short, to let each language group maintain their own site pages without the need for special web design skills.

Drupal the Right Platform

The front page of the former site.A small development team was assembled, and although none of them had more than fleeting experience with any CMS, a CMS was clearly seen as the way to go due to the fairly perfect fit of its aims with the requirements of the website. Open source was chosen because of price in combination with the knowledge that the free and commercial products are on similar par with each other. The general longevity, proliferation, customisability and flexibility (no vendor lock-in) of open source projects helped to push in this direction.

Much reading and research was done and the choices were whittled down to Drupal, Joomla and a couple of other outside contenders. In the end Drupal was chosen as Internet research suggested that the code is cleaner and better architected than Joomla, that it is ultimately more configurable and because of its seemingly better support for internationalisation. The information about i18n support from different CMS was not totally clear and easy to understand on the internet, but suffice to say that today the decision for Drupal could have been made from the point of i18n alone. From our current knowledge, Drupal is miles ahead of the competition. If you are building a CMS where i18n is a key requirement, you would need a special reason to choose software other than Drupal.

The Project

Being a non-profit organisation, the Christian Assemblies website build project had some similarities with the Drupal project itself. After the technical foundation had been laid, much of the “grunt” work was done by a team of about 100 volunteers. Thousands of pages of messy code previously created with WYSIWYG software were manually reformatted from scratch to XHTML strict standards using FCKEditor (with quite a few options tweaked). The result – about 1,000 English nodes, many translated into each of 8 other languages, making about 3,000 nodes in total.

Technical Aspects

A “Business Style” Site

The site was designed to be business-style in the sense of “non-community”. This meant a few special touches:

• Hiding the login block
• All teasers created manually with “Drupal break” function to ensure all articles have a genuine summarising or attention-grabbing overview.
• Comments are used internally on the site and are not viewable by the public. To keep the “non-community” look-and-feel, a bit of theming was required to remove the “log in to post a comment” links.

When you first pick up Drupal it’s not easy to see how to build a business-style site, although this is a very legitimate use for Drupal. We believe that the more sites and information that can promote this side of the software, the better for Drupal.

Front Page

The testimony and bible study articles on the front page are pulled from node queues.The featured testimony and featured bible study on the front page are node queues manually invoked via PHP code in the front page template.

Language Switcher

Here's the code used to create the JavaScript language switcher up the top right.

Content Types and i18n

Content types were heavily relied upon due to their ease of maintenance. Where in some projects a bit of PHP code can be inserted directly into node content, when you have 8 languages to service then it’s more sensible to create a new content type and put the PHP code into the template. Even if a certain content type is only used on one page, it’s actually used on 8 pages due to translation. An example of this is the full sheet list page, which is only used once per language.

Image Captions

One standard problem of static, strict HTML is creating image captions with the correct width to match the image. This is easily done with a Drupal input filter which we wrote up; inspired by the image caption module (our improvements have since been integrated into the project but still need a little refinement).

Lists of Christian Testimonies and Bible Study Articles

These lists were created with views, but due to difficulties in taking full control over page views on an internationalised site, no views were used directly. Instead all the views you see in the Christian Testimonies and Bible Studies sections are embedded into templates of various content types. This gave us precise control over URL path, page title, and node title in relation to the argument given to the view. An “ordered taxonomy term” view was created which is basically a standard list of all content tagged with a taxonomy term, but ordered by a custom field called “importance”. This allowed us to put the most interesting testimonies and Bible articles at the top, not just the most recent!

Page Context

Probably the most serious problem with Drupal at the moment is the problem of context: defining areas of the site and making the user feel that they know which part of the site they are in. The drupal.org site is a perfect example of this – it’s hard to figure out which section you are in, where the main navigation is, where to go next, etc. There is actually a module by the name of context which seeks to solve the problem – it looks promising but it wasn’t ready for us.

The problem we faced was that we used primary links as the source of secondary links, and when a reader views a testimony we wanted the relevant secondary links of that section to be shown. The simple way to do this is put that particular testimony as a third level under a secondary link menu item, but after you do that with about 500 nodes, your site starts to freeze up and run out of memory when you edit things. So some fancy code was written in our template.php with the help of the support@drupal.org mailing list (thanks guys!) to get the correct secondary links items to appear at any time. Actually just the other day I discovered the menu trails module which looks like a simpler solution.

Photo Albums

Believe it or not, amongst the dozens of slideshow modules out there we couldn’t find one that would allow thumbnail view/selection, captions, and auto-change (play slideshow) for our photo albums – except for Gallery2 but the advertising in that otherwise excellent module was unacceptable. So we grabbed a non-Drupal JavaScript slideshow module, recoded bits and pieces and made a content type based on this JavaScript code.

Videos

The testimonies are quite interesting – when a testimony page loads it checks a certain directory for a .flv file named after the node number and language, e.g. 18193-en.flv. If it finds one then it loads and plays it, such as on Aruna’s testimony. The jw flash player is used to play the videos and it also supports subtitles and an initial picture which are auto-discovered in a similar way to the video itself – see Jessica’s testimony for an example of subtitles.

Checking the file system on each testimony page load is probably not the most resource-efficient manoeuvre, but was chosen for reduced maintenance – it means that what’s on the file system is always in sync with what is showing on the page, it doesn’t require clicking a CCK field which might drift out of sync with what is actually on the file system.

Scripture pop-ups

Mousing over any scripture reference allows the user to read that passage.The old website had a fancy JavaScript feature whereby hovering your mouse over any scripture (Bible) reference caused the entire text of the scripture to pop up in a little window. This was coded manually and as a result only functioned on certain pages and in certain languages due to the massive effort involved. This feature was important to replicate due to the Biblical focus of the website, but there was a strong desire to create this functionality automatically. Initially the Glossary module was used, allowing pop-ups to be sourced from the taxonomy, but this still required manual entry of each scripture text into the taxonomy – a lot of effort and possibilities for error. Inspired by the glossary module, we found a text version of the bible in each language and put it into the database, and created an input filter which would detect the Bible references and in each case grab the relevant text from the DB for the pop-up. Lastly we used the jtooltips module to create the nice style effects. The pop-ups are visible on basically every page of the website, but if you want to see a page with heaps of them check out the 1050 New Testament Commands page. As of this writing, this feature is in English only but we are working to support all other languages.

Alpha software

The site was actually launched with CCK still in alpha and views2 in beta. Not the most advisable approach but we desperately wanted D6 due to the i18n features and unsurity of a simple upgrade path from D5, so the decision was made early on to just go for it. The main drawback of this was actually being a test pilot and having to figure out how to do many things ourselves, which does result in slower development... as others had simply not done/asked/written about them yet! But in the end it was worth it.

Credits

• Technical Lead, Chief Architect – John Fletcher (fletchgqc)
• Project Management – John Whyte (acts238) and Fraser Chudziak
• Web Developers – Mike Foerg (michael.foerg@googlemail.com), Toby Tscherry (tobemann).

... Greatly helped by about 100 other volunteers who worked their guts out!

An Ongoing Success Story

Subsequent to the success of the project and the skills learned, John Fletcher went on to start his own company: Salt Websites Web Development. Please see his website if you’re interested in his services – Mike is also available for freelance work and can be contacted via his drupal.org contact forms.