There are a number of approaches to making your website multilingual and as in all design decisions your site’s requirements should dictate which way you go in the end analysis. In this article I am not going to survey the pros and cons of each approach, rather we will take a look at a custom built multilingual framework that makes things easy for translators.
All web site text be it a word, sentence, paragraph, link or whatever is stored in a backend database and accessed by a key ie. an integer, and a language identifier, EN for example. So you might have a couple of records like: 1, EN, “Hello” and 1, TU, “Salam” You might also have fields that indicate on what page the text can be found which is useful later in the translation application.
Each web site content page exists one time for multiple languages. There is no need to replicate the source code for each page. Using this approach I built a php based application and everywhere text appeared in the HTML it was replaced with a php function that looked something like this: p(“Hello”,1) The function ‘p’ prints the word “Hello” in whatever language is active at the time. If English is active the function simply returns the English text that was sent to it. If another language is in use the function looks up that text entry in the required language and returns it. The active language can be stored in a GET or Session variable. An obvious benefit of this approach is that the text “Hello” remains in its rightful place in the page source and is easily readable and maintainable. Other approaches sometimes leave you with nothing but a cryptic text key and you have to look up the text manually to be able to read the HTML.
As you probably aren’t interested in keeping track of a large database of text id’s by hand e.g. Hello=1, Good bye=2, there are simple approaches to automation. For example when programmers write “Hello” they simply code p(“Hello”). Later on a utility runs, finds the virgin “Hello”, assigns it an id and updates the code to look like p(“Hello”,1). The same utility can check existing text entries to see if the English text (or whatever your base language is) has been updated and then make a note in the database that will alert translators that the translation must also be updated. In our database we keep track of the current English text and the previous English text so that translators can see history of the text change.
What about efficiency you ask? To avoid database lookups for every text display, we load the entire text database for a particular language into a Session array variable whenever a user changes languages. This is quite fast and not noticeable to the user. If you have a large web site you might chose to load only selected portions of the site into the array at any one time. The ‘p’ function then does a very fast array lookup to return the appropriate text. Of course the base language requires no lookup at all since it is already passed to the function.
With all of the text in a database it is easy to build applications for translators to add a brand new language or update text that has been modified in the source pages. Translators don’t need to know html to do their work. One nice feature is to be able to copy a translation for a particular text that is the same on multiple pages. Be careful about reusing translations as the translation may need to vary based on the page context.
This is by no means an exhaustive description of what has to be done to make your site completely multilingual. There are many issues that range from simple things like date and currency display to more subtle issues driven by culture like what pictures or colors do you use? So now you can visualize at least one design framework option for your multilingual site. Here is a site where this method has been used: www.goodneighboraz.com Good luck going global!