Development, Analysis And Research

Firstly, PHP has very little dependencies. It does not need any files copied to the system root as many installation instructions state (with the exception of certain PHP extensions).

Usage: PHP [options] [-f] <file>[--][args...]
PHP [options] -r <code> [--] [args...]
PHP [options[ [-B <begin_code>] -R <code>[-E <end_code>] [--] [args...]
PHP [options] -B <begin_code>] -F <file> [-E <end_code>] [--] [args...]
PHP [options] -- [args...]

As we can see a number of options can be passed to PHP that manipulates the way PHP acts. This will allow us to define the location of PHP.ini, if defined at all or other parameters that maybe injected. Apache is also configurable in a manner that will allow us to choose the PHP version to run upon apache‘s execution. For Example placing the following in httpd.conf will allow you to choose the version of PHP to be executed with apache.

<ifdefine PHP-5.0.0RC1>
  LoadModule PHP5_module C:\PHP\Distributions\PHP-5.0.0RC1-Win32\PHP5apache.dll
</ifdefine>

<ifdefine PHP-5.0.0RC2>
  LoadModule PHP5_module C:\PHP\Distributions\PHP-5.0.0RC2\PHP5apache.dll
</ifdefine>

<ifdefine PHP-5.0.0RC3>
  LoadModule PHP5_module C:\PHP\Distributions\PHP-5.0.0RC3-Win32\PHP5apache.dll
</ifdefine>

Using ‘ apache.exe -D PHP-5.0.0RC3-Win32‘.

Note: IfDefine is case sensative, also ensure Capital D is used in the command line as lower case has a different function (-d directory initial value for ServerRoot & -D parameter define parameter for <ifdefine>).

If any failures occur at this point, there are two common reasons, firstly in early versions of PHP, version 4 requires PHP.ini & PHP4ts.dll. As so many installation manuals like to tell you DO NOT PLACE ANY FILES IN THE SYSTEM ROOT, the best way to encapsulate installations is by placing any required file in the root path of the PHP.exe location, if using CLI copy the (PHP4ts.dll or PHP5ts.dll) & PHP.ini to that directory.

The order for PHP is to locate required files is %system%, %system32%, %systemroot%, %apacheroot%, %phproot%; in the general order of the system variable %path%. I recommend the follow directory structure when installing PHP…

cvs -d :pserver:cvsread@cvs.PHP.net:/repository checkout phpweb/distributions (extract all)

C:.
---PHP
    +---Distributions
        +---PHP-3.0.17-win32
        +---PHP-4.3.2-Win32
        +---PHP-4.3.3-Win32
        +---PHP-4.3.4-Win32
        +---PHP-4.3.5-Win32
        +---PHP-4.3.6-Win32
        +---PHP-4.3.7-Win32
        +---PHP-5.0.0RC1-Win32
        +---PHP-5.0.0RC2-Win32
        +---PHP-5.0.0RC3-Win32

For each, rename ‘PHP.ini-dist’ to ‘PHP.ini’ and if applicable copy ‘PHP.ini-dist’ & ‘PHP4ts.dll/PHP5ts.dll’ to the directory ‘cli’ as well as ammending ‘PHP.ini’ temp path to your systems temp. From each %rootphp% path you can configure that installation with its own customised ‘ini’. I recommend reading PHP directives at php.net. From this you can setup VirtualHosts, such as http://PHP4/, http://php5/ etc, which will make switching between PHP 3, 4 & 5 simple . Note: This is for development purposes and should not be used in a production enviroment.

Recently I have been researching into multi-lingual content, admittedly I have never properly looked into the concepts of Internationalization and Localization (i18n, l10n) before. Whilst reading the ICU documents. I have realised there is a significant lack of support for i18n & l10n in PHP applications. Despite the controversy with enterprise PHP, and the contenders commonly mentioned eZ Systems & Interakt, they still have limited support despite weak attempts at globalization (g11n).

The problem with i18n is the broad complexity of the field. Whilst PHP may well be able to handle i18n, it does not mean that the database or repertoire can? With regard to PHP in particular, I find that we make far too many assumptions; In general, this is a pitfall in many programming languages, so it is not justified pin pointing PHP developers. Whilst those particular details are applicable to i18n, we essentially need to look at a complete solution as a whole, which computer-based translation is just part of a recipe for an efficient globalized product.

I had a fundamental problem when I looked into Internationalizing data, this was simply to do with structuring globalized content. It is relatively simple handling string literals, which can be placed in a database and normalized. However, binary data and other forms of media are not ideally placed in a database. As, such structuring this data is challenging with regard to replication. Do you categorize content by country or language; as a result, I have concluded that replication is unavoidable in this instance. Although the approach that Internationalized Components for Unicode has taken with resource bundling is in hindsight the best approach. Some key points:-

• Keep Data Separate
• Keep Data Small
• Find the Best Available Data

Whilst, this would be ideal it is not a feasible to implement for a variety of reasons, so the only ideal is to mediate content and aid linguists with a form of mediation via computer-based translation. Lets try and open our eyes and develop higher level applications.