Hub bible college website – 2013

Whilst travelling around Europe, we stopped at Belgrade Bible college where we were asked to re-write their website. We’ tried to retain the general feel of the site, whilst making minor improvements where possible. We added a videos page, a calendar page (simple embed of a Google calendar), a blog, used consistent icons for the contact page and embedded a Google map on their contact page. We also created one stylesheet behind the whole site rather than having individual page stylesheets (as the old site did), which should help to improve consistency of pages across the site. Oh, and did we forget to mention that the site had to operate in both Serbian and English? Gotta love a bit of a challenge!

The main complexity with this site comes from the two languages. This was the first multi-lingual site that we’ve designed, so we learned a lot! Essentially, from our understanding, you have 4 options when it comes to multi-lingual sites:

1. A site per language – for example rs.hub.org.rs and en.hub.org.rs for the Serbian and English versions
2. Each page duplicated, one for each language – for example hub.org.rs/o-nama (Serbian) and hub.org.rs/about-us (English)
3. Two languages on each page – either Serbian and English text side by side, or only one language displayed at a time, with a switcher element
4. One master website, with on-the-fly translation – the whole website written in Serbian, with the option for English speakers to have an automatic machine translation when they visit it

We pretty much discounted number 4 straight away; the previous version of the website had human translation of all content into English, so to have machine translation would be a step backwards. Numbers 1 and 2 would potentially raise synchronisation issues across the site unless there was something to prompt content editors to update all pages. Number 3 would confuse search engines. All of them have their down-sides… so which should we choose? Our first call was to see what W3C say about best practice for multilingual sites. They’ve set up a site dedicated to the multi-lingual web, but it wasn’t particularly easy to find any guidance on which option to go with. The gut feeling was that options 1 and 2 felt best, so we started to hunt for WordPress plugins.

To add further complication to the multi-lingual conundrum, Serbian uses two alphabets; Latin and Cyrillic. There is a WordPress plugin (SrbTransLatin) which allows Cyrillic content to be displayed in either Latin or Cyrillic… this turned out to be very useful, as the content of the previous site is in Latin script and the Serbian WordPress localisation uses Cyrillic. Switch on plugin, turn to “always use Latin”. Bingo. So now we just needed something that could help to keep two Latin script versions of a page synchronised (as much as possible). To cut a long story, involving testing a couple of other plugins, we chose Xili Language to manage the synchronisation of pages in different languages.

This WordPress plugin adds a few little features here and there around the admin side of WordPress to tag pages and posts as written in a certain language. It’s not the most intuitive plugin to set up, but there’s extensive documentation and it’s quite good once you get your head around some of the quirks! In the case of creating pages, you specify the language of the page you’ve just created, then you’re prompted to add another page which is a translation of that page. The menus are then basically sorted out for you – if a visitor is viewing a Serbian page, the only other pages that will be shown in the menu will be Serbian pages. There’s then a PHP hook (a function named “the_curlang()”) which is then extremely useful to find out which language visitors are viewing the site in, so that you can add in extra content in headers and footers that are specific to that language.