Heal Your Church WebSite


Teaching, rebuking, correcting & training in righteous web design.

Creating multilingual websites

One of the more interesting aspects of having lived in NYC and Washington D.C. is that I’m used to hearing many accents from new Americans from all over the World; including many who attend my church.

With the recent surge in the Hispanic population in our area, and with a Korean Church that leases space from my church, I’ve often thought it might be useful to offer the Redland Baptist website in many colors and flavors that bless our geographic region. In other words, or actually in terms of the Internet, we’re talking Localization and Internationalization – something I suppose I ought to explore when I upgrade the Redland site to MovableType 3.1.

But what about those of you who don’t use MovableType, especially those of you rolling your own content ‘manglement’ solutions for church or charity website?

How it works

Whether you use someone else’s system or your own to publish your church’s website, it doesn’t hurt to know how it works. Which is why I’d like to direct your attention to a set of articles by Karl Seguin entitled:

  1. Creating multilingual websites – Part 1
  2. Creating multilingual websites – Part 2

While Mr. Seguin discusses Internationalization from a .NET perspective, how he goes about using this programming tool can and should be applied to any just about any architecture I can think of. Here are just a few quick reasons why:

  • He inherits and overrides the ‘Resource Manager’ to dynamically feed upon XML files so you don’t have to compile the site every time you add or change a language.
  • Content is further separated from formatting and processing.
  • He eliminates the need for multiple pages using an Apache/Mod_Rewrite like technique.
  • The door is thrown wide-open to offer localization functionality into a web service.
  • He drives the site using meta-data that is data that describes the data; only he goes the extra step to make sure it is well normalized.
  • Placeholders, or what we in blogging refer to as templates, allow for programmatic changes to what is (dynamically) display.

If nothing else, how to set up the database and the how to run a re-direct on an IIS server is worth the bandwidth.

Question D’Jour

So is your site bi-lingual? If so, how do you go about getting it done? Have you ever developed a multilingual solution? If so, how did your approach differ from that of Mr. Seguin? Inquiring minds want to know – so leave a comment.

8 Comments

  1. With Paristemi, we have a file with all of the string variables that are displayed on the site and called strings_en.inc (it’s a PHP site). If we want to allow for another language, we just have to have another file like strings_sp.inc (for spanish, which we may be adding in as soon as a month). Then it’s just setting the language to Spanish instead of English, and keeping that information in either a session variable or a cookie (right now the switching functionality isn’t implemented, but you can set what the default language is).

    All of the text on the site except for the database is now in whatever language the user chooses. I guess not having a different db could be a drawback, but I’m not sure that churches have the resources to translate all of the calendar events, messages, etc. But what do you think?

  2. Dean:

    Programmer that I am, I was still having trouble following this. But, I manage a website that is available in Spanish, English, French and Italian (at one time we had Portugese as well). FAMVIN (http://famvin.org) is a PHPNuke site, so Nuke handles some of the multilingual issues.

    But there is a larger issue involved that goes beyond translating from ENESFR – these are cultural issues. In the beginning, we tried to have the same formats and content on all sites. And finally came to the realization that what works for the English, may have not appeal for the spanish, italian or french audiences. So, not we have a content person for each version. The sources are often the same, but the presentation and focus are at times different.

    It’s something to consider in designing a church website for a multi-lingual, multi-cultural audience. The Word is the same, the Vision is the same, but the presentation can vary greatly. I’ve had to come to understand that even certain colors have drastically different connotations in different cultures!

    I dare say also that at the local level (FAMVIN is international) that some of these considerations would apply. The protestant churches have caught on to this. We find Our Lady of Guadalupe on signs in front of Baptist and evangelical churches. That wouldn’t mean much to the standard white, whitebread southerner, but it speaks “church” to the hispanic population. Locally our hispanic population is predominantly working class, with little education. This is interspersed with university faculty and students – what a mix. On our local parish website, when we finally get it going, I think that we will have to consider what to put in each language.

    The challenge goes well beyond just translating the words and phrases. To be successful at bi-lingual sites we must not only “translate” but embrace the diversity of our experience of God. No one way serves every culture or every person in a culture. The God we serve and celebrate is far to grand to be restricted to a single image.

    Sorry to go on like this – the technical difficulties are hard enough, and then you get to the message!

  3. Although we use a simple property file for some of the main headings and images, our 3 languages (english, simplified chinese and traditional) are stored in our database and are entered through our custom content management on a charset UTF-8 type page. Babelfish does a fairly good job on our site, but unfortunately our three congregations have different information to manage, which is why everything is not simply just translated through language resource files.

    Having our own content management allows separation of duties to different users so the left hand doesn’t necessarily need to know what the right hand is doing.

    On presentation, I pass around a ‘lang’ variable which basically dictates what content is retrievable from the database.

  4. Our church site is English-only at the moment (and probably will be for a while – not much ‘zhwoom’ in the web department at the moment), but in tri-linugal Belgium multi-lingual sites are very common. One huge hassle I have as a native English speaker is which language to choose. Yes, I can choose English, but it’s usually very hackneyed, and often doesn’t contain a lot of the information that is in the mother language of the site owner. So I usually pick Dutch or French. Anyways, what just about all these sites ignore is this language switch problem – quite common that you see a page that tries its best in translation, but you really want to see if there’s a version in another language that’s a bit better. But clicking the ‘other language’ option brings you back to the root of the site, instead of the corresponding page. If the page is available in another language, ideally, the link should bring you directly to that other language. Otherwise you have to try to find your way to that page according to that other language’s nav structure — bah!! This is especially necessary in the site I’m developing, since it sort of bablefishes short phrases from Dutch into French and English, and behold, these translations are far from perfect!

    This approach requires a different db structure – there needs to be an identifier across languages so the script can tell if there is a translation available, and what it’s url is. And it’s a pain. Too much work probably for a single site, but for cms builders serious about the mulit-lingual issue, a must.

  5. Just wanted to say that the other posters really opened my eyes when it comes to creating multi-lingual sites. I especially didn’t think about the layout being a big issue. I’m going to put into the roadmap the ability to choose a strings file, templates, and database per language. The admin can then choose if they want/have the time to use each of the individual options.

  6. (Karl’s fine, btw)…

    I haven’t posted this follow up anywhere else, but I learnt some things after writing those articles from the people who wrote to me. Mainly, my experience comes in developing trilingual sites with three fairly similar languages (english, french and spanish). A lot of people though emailed asking for help on creating sites in a non-latin language and in english. With non-latin languages a number of issues that I would never have considered came up, such as special characters and encoding, right to left reading and tool support (Visual Studio.Net had some issues).

    Also, something I find particularly neat, most people who emailed me probably didn’t know english as their first language. It stands to reason that most people who are concerned about multilingualism probably have a site developed in their countries primary language and are also interested in developing in english to reach a broader audience. I just hadn’t considered that before and found it quite, as I said before, neat :)

    Karl

  7. My experiences with multilingual websites has been poor. Webmasters don’t seem to be willing to put the resources into creating proper sites. Translation isn’t cheap folks. For those needing only machine translation try altavista or translationbooth.

    The website translation box that translationbooth.com offers (called tsunami) has over 800 language combinations and is free. Altavista offers about 16 language combinations and is also free.

  8. Hi Kylie,

    Thanks for the advice. Just had a look at http://www.translationbooth.com and it seems that they now offer cheap and quick human translation and not just machine translation.

    Eddie