#native_company# #native_desc#

Native Language Support Page 2

By Didimo Emilio Grimaldo Tunon
on February 13, 2001

Explicit links

Many multi-lingual websites present the content in various languages, and do so by placing a
link on the document. There would be one link for each of the supported languages. This is a
very simplistic approach and should only be used if you need to have multi-lingual
content, but do not have the resources of a scripting language or dynamic content.
If a document is moved, or a new language is added or removed from the repertoire, then
the webmaster would have to edit, add or remove links in each of the affected documents.
This can be quite tedious.

Apache’s content negotiation

The Apache web server can manage language-sensitive content delivery by using the
information from the content negotiation headers. Then, the webmaster must provide the
static pages for each language and name them properly. For example if the welcome page is
available in Spanish and English, the webmaster would have these two files:
When the web server is well configured, it will deliver the appropriate web page based on
the language code according to the priority list.
This works perfectly for static pages. However, if you have a dynamic website where a great deal of the
pages is generated based on queries, then this approach will not work. Another
disadvantage is that you need to know how to do it and you may or may not have access to
the configuration files. My experience was that it was a bit tricky and it did not offer enough
flexibility for my purposes.
An advantage of this method is that the negotiation is between the browser and the Apache
server. You need only to provide the static content.

GNU Gettext with PHP

This internationalization tool has been around for some time for C programmers. There is
also a variant used on other Un*x, such as HP. Both are very good and are easy to use.
This extension has been available in PHP since version 3.0.6 and also in 4.0. The Gettext
extension is easy to use, and is good if you are generating your webpages dynamically. The
only thing left here would be the PHP code that generates the content and a set of message
catalogs. Supporting a new language is as easy as generating a new catalog with the
translations and dropping the file in the appropriate directory. Therefore, assuming you have a PHP
application named “myphp” and that the appropriate message catalogs exist and are installed,
then the application would have something like this:


/* Initialization of GetText in myphp */




/* Print some messages in the native language */

echo gettext("Hello new user");

_("You have no new messages");



My provider had recently upgraded from PHP 3.0RC5 to a PHP4.0 Beta 2 installation.
While PHP4 does have support for the Gettext extension, my provider did not compile the
PHP4 module with Gettext support. However, even if they
had, moving to another provider without Gettext would become a major headache.