Introducing Multi Language Support

Posted by Fizix Richard in Articles: Development on the 20th November, 2008

I was recently working with the vBulletin forum solution, integrating it with a clients website. While looking at the source and also the admin system a provision caught my eye; their phrase system which is used for both seperating text content from design elements within templates and also for supporting multiple language packs for a forum installation. So I started playing with a core language pack system based around a similar idea which works to make implementing multiple language versions of a website as painless as possible.


The Components


Ideally a language pack system would comprise several components.

  • A language pack database table; which contains entries for each language pack
  • A template parsing system which parses HTML layout elements with independant text elements; based on a selected language pack
  • An independant "phrase" database table; which contains the translations for each text component on the site
  • A template and phrase caching system for efficiency & performance
  • A language pack selector on the front site
  • A CMS Tool to create language packs and set the translated version of the default "phrase"



The Language Pack Database


A simple database table is needed to store the entries for each language pack; for example English, French and Spanish.


language(postid, title, status)




The table is called language and contains just 3 fields, a postid for the unique ID for each pack, a meaninful title for the language pack and a status field, which we use to identify the default language; in this case English.






The phrase database


We then require a second database table to store the phrases for the sites text content. To do this effectively you need to know what content the site provides; but thats all down to good planning and design, which we should be doing anyway.



We need a way to identify what to call each piece of text on the site; like vBulletin we will call them phrases. A phrase could be a menu link, a title, a heading, a paragraph of text and so on.



So we setup a database that looks something like this.




phrase(postid, languageid, title, string)




The postid is a unique ID for each phrase, the language id associated the phrase with a language pack, the title is simply a meaninful title, which we will also use to collect the phrase & the string is the translated text.



We could complicate the database further & ideally we would; by introducing a new linker table to list each phrase independantly of the language pack and then use the phrase table to store the actual translation. This would be used by the CMS tool when creating new language packs in order to setup the phrases ready for translation.






The Template Parser


We have already developed a powerful HTML template parsing engine, which includes basic logic parsing; so just had to create a few small changes to that system to support the language packs; namely to pass the current language ID to the parser and run a new phrase collection function.








The CMS Feature


The CMS feature has two parts to it; a language pack section and a phrase section.



The Language Pack Section

The Language Pack section will list all existing language packs, allow you to set the default pack and also allow you to create new packs. Upon creating a new pack the phrase table would be populated with default values which the translater can then edit using the Phrase section.



We could also add an edit pack and delete pack feature.





The Phrase Section

This section would list each language pack and in turn list each phrase when selected. Each phrase would show up its title and have a field for adding the string (the translated text). This allows content translators to easilly translate the sites content with no need for a technical programmer to assist; speeding up the process of translating content and in turn reducing the overheads involved.



From our experience with translation specialists; using such systems has a profound effect on the cost of translation when compared to more technical approaches such as editing raw XML data.






The Front Site


All that remains at this point is to add a language pack selector to the main site, which allows a user to select a language pack & maybe store a cookie containing their language preference for later use & then collect the ID of the language pack and pass it to the template parsing function. Provided you have setup your HTML elements to use phrase replacement variables (which I will mention in a moment) the system will work.



Phrase Replacement Variables

This is quite a simple process; in each template wherever an element of text appears (a phrase) you insert a varable; then in the programming code for each page have a set of declarations which tell the parsing engine which phrase to collect for each variable. 



That at least is the cheap and cheerful way; the more useful way & following in vbulletins footsteps; would be to use logic in the HTML templates which tells the engine which phrase to select; something like this:




<phrase=welcome_heading>




You then use a regular expression to prase these conditions and replace it with the text from the phrase database. The value in the phrase condition would be the title of the phrase.







I'm not saying this is a perfect method as it would need work; particularly with a large website; but fundamentally the method works well & can be built upon quite easilly.


			   


			   
			   
Tags


			   
web, development, databases, multi, language, language packs

		       



	           
   
	     


            
Post New Comment


	        
			

			   You must be a registered member of the labs to post comments or contribute. 

Registration is free so click here to sign up.
			


		 



	     
	     


            
Comments

	        
	  
There are currently no comments on this article.