Though i18n is not important for every script, there are several applications for which i18n is a necessity. For instance, customers to an online store are more likely to buy a product that is presented to them in their native language than if they are reading a language not familiar to them.
Likewise, if we're writing PHP scripts and programs that are free or available as open source programs, prospective users like to adapt them to their site and their culture. They want the look, feel, and language of the script to match their site; consequently, our script should be easy to customize, both in appearance and in language. PHP has the necessary infrastructure to support i18n – it supports conditional inclusion of files (each file could contain a different language, which we'll see later) and it supports the Gettext library.
So, why is it so hard to translate web site content into another language? Can't we just copy the script to another file and then translate the text? The answer is, because this is not a good solution. It is not easy to keep two or more versions synchronized. The process becomes harder as the translators forget to fix the problems that the original document writers have discovered. Communication costs increase rapidly as soon as more than three or four languages have to be supported. We would end up with several different versions of the same program that will not do things in exactly the same way.
It is necessary to have some system that helps manage the translations. It helps to view natural and programming languages as grammars producing text strings with slightly differing purposes. The system should place the natural language strings in a place that is distinct from location of the PHP script routines.
This makes bug fixing a lot easier, since translated texts will be easier to find. If we fix a bug in a natural language string, then it is easier to fix the bug for all natural languages used in the script, and not just for the version and the language we are supposed to maintain. Ease of text string access in all languages is essential for every translation system.
By moving the strings out of the heart of the script, programmers also gain some other advantages:
Translators don't have to decipher code. If the programmers want to have the GUI text or the web site documents translated into other languages, it's very important that translators have easy access to the natural language strings.
Making it less likely for translators to break the code is an important defensive programming skill. Even just adding an apostrophe or a quote can break the script.
A translator should be able to write translated text strings that are in tune with the target language. The text string could be written in any language, and could use any kind of punctuation without running into problems caused by misplaced quotes and strange characters. Again, text display has to be adapted to the target language without disturbing the rest of our program.
The diagram below should help PHP programmers and translators visualize the way in which PHP handles translated text:
