Would you like to provide multi-language support on your site?
In this article we discuss three different ways in which you could
organize your site to support multiple languages. We do not say
that the three ways discussed in this article are the only ways
of achieving the goal but this could be a good starting point.
The three methods discussed in this article
are:
Dynamic Content Generation
Site Replication, and
Selective Replication
Let us now discuss these three methods, and also discuss the advantages
and disadvantages of each.
METHOD 1
Dynamic Content Generation
Although this method is a very complicated way of organizing your
site to support different languages, it could be an option if you
have only two languages, or even three to support on a fast server.
It is also a good idea to use this option only if your site is not
huge.
In this method all the text of the site is stored in a database.
Every page carries a variable (a session variable or a query string)
to identify which language the site is to be displayed in. Based
on that, the content is pulled out from the respective tables for
the language chosen, and displayed.
You might now be wondering, what about Graphics? You have two choices.
If the amount of graphics that your site uses is very minimal, you
could consider storing them in the database itself as blob fields.
Another way is to simply open up a new
table
with the following
structure:
Name
English
German
French
Stored in this manner, you could give each image a name, and store
only the relative paths to the different images in the database.
When pulling it onto the client page, get the path and pull it out
from the file system.
The messages can be stored in the database in a similar format,
except instead of "Name" use a unique ID for each message.
This message can then be called in the necessary pages of the site.
You could also declare an array which you include in all pages,
that contains all the messages. Please take care to keep the message
number's constant once assigned because if the messages re-shuffle
it could be a tedious task to re-do all the messages on the site.
This method has many disadvantages. A few significant
ones are:
There could be a performance degradation of the site if the
amount of content of the site is huge.
Editing the site would require you to either directly edit the
content in the tables, or alternatively provide an admin panel
to edit the content of each page on the site!
The load on the database is too high which could lead to lower
performance
As you can see, this method is good for small websites that have
less content and graphics. Providing for a complete administration
panel for the content is a big thing in itself, and the reliability
can never be guaranteed.
METHOD 2 Site
Replication
This is one of the most commonly used methods on the web.
In this approach the main site, which is in the default language
of the website, resides in the root folder of the site. This basically
is how a website is when it's a single-language site. When you want
a site in German you would replicate the entire site into a directory,
say German. The links in the German site should refer to the corresponding
pages on the German site only. Now typing www.mysite.com would give
the site in the default language, but www.mysite.com/german would
give the German version of the site. On every page of the site you
would have a select box with language choices. All this box does
is to re-direct the user to the same page that sits on the chosen
language site.
Do use proper tools when replicating the site. If you were to do
it manually you will have to edit each other files on the site and
correct the links on them to point to the pages on the language
site. If you use a tool like Dreamweaver, for example, this task
will be done automatically.
Now there are a few pages where the select box cannot be placed.
These are pages that utilize what are called hidden form fields,
which carry form information from page to page. Passing these over
to another page would be a problem unless you have a mechanism to
detect all the form variables and redirect to the same page on the
other language site with the variables passed in the query string.
This method has a disadvantage too:
Any bug that is cleared on the main site needs to be cleared in
all the other language sites. If you have 3 languages that you support,
apart from the default language then this would increase work involved
in any maintenance/bug-fixing/content-changing task 3-fold. You
would have to make the change in the main language site, and then
the change in each of the 3 other sites.
This does have a work-around. In your initial design of the site
if you take care of code/content to be re-usable, this would not
be an issue. All the language sites use the same includes so if
there is any change in functionality all you would have to do is
change the include file.
METHOD 3
Selective
Replication
Of the three methods we discuss in this article, this is the most
efficient one. Although difficult to set up the first time, the
maintenance effort is lower than the other two methods discussed.
This method is used by many major websites, including Microsoft,
for multi-language support.
In Selective Replication we have the main site, which has no content
or images whatsoever. The various images sit in various folders
marked EN, GR, ES, etc depending on the languages. All the files
that go into each of these directories have the same names. So,
the English logo file name will be logo.gif, and so will the logo
file for the other languages too.
The content (messages, javascript alerts, etc) have two places
in which they can be stored. One way is to store each individual
message as separate text files, or an alternative way is to make
them sit in an array which is included in every ASP file and the
message that needs to appear is called from the array. Each language
has a separate array which resides in its directory. So the array
include depends on the language that is chosen by the user. For
information on how to create/use an array for this purpose, please
see my article on "efficient use of arrays".
This method has no stress on the database. The database is designed
to hold generic information applicable for all the languages.
The problem in this approach arrives only when the site is re-designed,
the template changed and the content reworked. You will then have
to re-create all the files in the language directories and change
all the calls in the site files to include the newly created template
files. Using text files for storing major content and storing all
one/two line messages in an array or database tables could significantly
drop time in maintenance of simple content changes.
CONCLUSION
In
all the three steps discussed, bear in mind that the database needs
to be able to handle Unicode characters. German characters like
the §, etc need Unicode support to show up. By default, Windows
installs with the Western European (ISO) encoding standard which
supports all Unicode characters.
It would be a good idea to keep re-usability as priority one when
designing the site. The more code/graphics/content you can make
reusable for all the sites, the lesser the headache for maintenance
and bug-fixing. Click here
if you would like to see my article on Reusability.
You might also want to mix features of these three methods and
derive a method suitable to your site. For example, you could use
Selective Replication for the graphics and files and store all the
content in the database using the Dynamic Content Generation method.
If you are interested in outsourcing the web development of your multi language project to us please contact us.
Site
Replication
Selective
Replication
In
all the three steps discussed, bear in mind that the database needs
to be able to handle Unicode characters. German characters like
the §, etc need Unicode support to show up. By default, Windows
installs with the Western European (ISO) encoding standard which
supports all Unicode characters.
