For Mac, the most common browsers are Safari, Firefox, Opera and recently Chrome.  On my machine, I have setup the following browsers and versions:

• Safari: 2.04, 3.04, 3.12, 3.21, 4.04
• Firefox: 2.0.0.20, 3.0.17, 3.5.7
• Opera: 9.52, 9.64, 10.01, 10.10
• Chrome: 4.0.249.49 (Latest)

Well, let’s get to it!

First, I setup a folder in my Applications called Browsers (/Applications/Browsers).  I will explain later why we place all of our browsers in the Browsers folder.  Now, let’s install each browser individually.

Safari

Since I’m running OS X 10.6 with latest updates, Safari version 4.04 is installed.  So, in order to install previous versions, I use Multi Safari.  Multi Safari provides different versions of Safari with the specified WebKit bundled into the application.

To install, you simply download the files, and extract to our /Applications/Browsers directory.  All of the applications are named appropriately and ready to execute.  To my knowledge, there isn’t any profile management we need to perform unlike Firefox and Opera.

Firefox

To get started, we need to download the specific versions.  During the time of writing, 3.5.7 was the latest version.  I was able to download easily from mozilla.com.  Next we need to find archived versions.  These are located on Mozilla’s FTP server.  Once you’ve downloaded the versions you’re interested in, let’s start the installation process.

In order to run multiple instances of Firefox, I’ve found the best way is to create a different profile for each version use that profile when launching the browser.  Since I’m only interested in 2.x, 3.0.x and 3.5.x, I like to start with the oldest version first.  So, copy the Firefox application over to our /Applications/Browsers directory.  Once installed, we need to immediately rename it.  I renamed my to Firefox 2.

Next, let’s modify the script to launch Firefox and setup our profile.  Open up Terminal and perform the following commands:

cd /Applications/Browsers/Firefox\ 2.app/Contents/MacOS
mv firefox-bin firefox.bin
echo '!#/bin/bash' > firefox-bin
echo '/Applications/Browsers/Firefox\ 2.app/Contents/MacOS/firefox.bin -P firefox2 -no-remote' >> firefox-bin
chmod +x firefox-bin

The previous commands essentially rename firefox-bin to firefox.bin and create a new bash script to execute firefox.bin with a specified profile and to tell Firefox that it’s OK to run more than one instance.  You may be asking yourself, why is firefox-bin so important?  Well, firefox-bin is the bundle executable (CFBundleExecutable) according to the Info.plist in Firefox 2.app.  This means, when you load the application, it executes firefox-bin.  You can look at other command line arguments here.

Now, before you run the application, let’s setup our “firefox2″ profile. In the same directory, enter command: ./firefox.bin -ProfileManager.  This will prompt you with the Firefox profile manager where you will want to create a new profile labeled “firefox2″ (which is what we used as the -P argument in firefox-bin).  Once you’ve created the profile, exit from the profile manager and try loading the application by double clicking on it through Finder.

These steps can be repeated for each specific version you want to install.  Just keep in mind, the rule I follow is to create a new profile for each version being installed.  So, for example, Firefox 3.5, I would create a “firefox35″ profile and setup my firefox-bin to load it.

A few notes:

• If you installed OS X with the “Case-sensitive, Journaled” file system, multiple Firefox instances do not seem to work.  If you find a work-around, please let me know, I had to re-install after having an unsuccessful attempt.
• I like to tell my different versions of Firefox to not update automatically.  However, if you forget and it updates, you will simply need to follow the previous steps after the update has been applied.

Opera

I’ve provided a link to the Download for Mac OS X on Opera’s website.  This link also contains another link to more archived versions.

The steps taken after downloading your versions are somewhat similar to how we handled Firefox.  So, I will use the example of starting with the oldest version I’ve decided to install, 9.52.  So, copy the Opera application over to our /Applications/Browsers directory.  Once installed, we need to immediately rename it to Opera 9.52.

In order to keep individual profiles of Opera, you need to provide a PrefsSuffix file in the /Applications/Browsers/Opera 9.52.app/Content/Resources directory of the application.  This file will tell Opera what suffix needs to be added to the preferences folder created in ~/Library/Preferences.  Use the following command to set this up:

echo '9.52' > /Applications/Browsers/Opera\ 9.52.app/Contents/Resources/PrefsSuffix

That’s it!  Now you can run the application and you will notice a folder is created in the ~/Library/Preferences/Opera Preferences 9.52. If you intend to install more versions, follow the same instructions that we just used.

Chrome

When writing this article, Google Chrome is in beta.  I was able to download the latest version here.  Since there’s only one version of Chrome for Mac OS X, I didn’t have to do any profile setup.  However, I’m sure when Chrome 5 arrives, I’ll have to figure this out so I can run different versions of Chrome simultaneously.

Browsers Folder + Dock

Ok, all of our browsers are setup and ready to roll. However, remember earlier I said I would explain why we created the /Applications/Browsers folder? Well, because it provides a nice way to be able to load any browser from your dock. The attached screenshot is the Browsers folder dragged to my dock.

I hope this helps my fellow web developers in setting up your environment.

Please note, this approach is targeted for MySQL 5.0+.

The approach I take here is a combination of using the TIMESTAMP field data type and a TRIGGER.

IMPORTANT: When using multiple TIMESTAMP fields in a table, there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause. This is why we need to use a TRIGGER to update one of the fields values.

In our case, we will set the date_modified field to contain the DEFAULT of CURRENT_TIMESTAMP and also set the ON UPDATE clause to CURRENT_TIMESTAMP.

CREATE TABLE `temp` (
  `field_value` VARCHAR(100) NOT NULL,
  `date_created` TIMESTAMP NULL DEFAULT NULL,
  `date_modified` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
)
ENGINE = InnoDB;

If you noticed in the CREATE TABLE snippet above we use the TIMESTAMP features on the date_modified field, but set our date_created field to NULL by default. We do this because our TRIGGER will populate the value before the insert.

DELIMITER //
 
CREATE TRIGGER temp_before_insert_created_date BEFORE INSERT ON `temp`
FOR EACH ROW
BEGIN
  SET NEW.date_created = CURRENT_TIMESTAMP;
END//
 
DELIMITER ;

In our trigger, we simply set the date_created value to the CURRENT_TIMESTAMP.

Now you will be able to insert and update rows in your table without having to specify the date_created or date_modified values.

INSERT INTO `temp` (field_value) VALUES ('testing');
UPDATE `temp` SET field_value = 'testing1';

Another approach that can be used is by setting the date_created value to NULL when inserting a row. This involves a different CREATE TABLE syntax.

CREATE TABLE `temp` (
  `field_value` VARCHAR(100) NOT NULL,
  `date_created` TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',
  `date_modified` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
)
ENGINE = InnoDB;

Notice our date_created field is now set to NOT NULL with a default value of 0000-00-00 00:00:00. Here’s an important note from the documentation:

TIMESTAMP columns are NOT NULL by default, cannot contain NULL values, and assigning NULL assigns the current timestamp.

In other words, when we insert and set the value to NULL on a TIMESTAMP field, it will insert the current timestamp.

An example insert/update statement would look like:

INSERT INTO `temp` (field_value, date_created) VALUES ('testing', NULL);
UPDATE `temp` SET field_value = 'testing1';

This approach allows us to avoid using triggers, however requires you to specify the NULL value when the query is executed.

So go ahead and check out Reserved Word Search @ www.reservedwordsearch.com.

For more information, please check out GistDoIt! @ www.gistdoit.com.

Zend Framework already contains components like Zend_Locale and Zend_Translate to assist in internationalizing your website.  You use the Zend_Locale instance in conjunction with the Zend_Translate to know what current locale is being used and how to translate the content.  I’m going to show you how to implement these into your website.

If you haven’t read the first part of this series, I would recommend it as all my examples here will be based on that structure.

To start off, let’s talk about how we are going to allow our website to know what locale to use.  What I’ve found to be a common practice to switch locales is based off of the URL.  For example, a sample format may look like mysite.com/:locale/controller/action.  Locales are usually represented with a language_REGION combination.  However, locales in our case are specified by only the language code.  You can find a list of language codes here.  If you wanted your site to be in Japanese, you would use the language code of ja.  An example of the URL might look something like mysite.com/ja/controller/action.  On top of specifying the locale in the path of the URL, I’ve also provided a way to determine the locale based off of the TLD in the URL.  For example, let’s say our mysite.com also has a Japanese TLD like mysite.jp.  When a request comes in and we find a supported TLD, we set the localed based on it.

Enough talk, let’s look at some code.

Let’s start by setting up our Zend_Locale.  In the application.ini, we use the Zend_Application_Resource_Locale to setup the locale component and set our default locale. In our case here, I’m setting the default locale to English.

application.ini:

...
# Locale
resources.locale.default = "en"
...

Next, we need to tell our application which locales are supported and also specify our TLD mappings. We do this by specifying front controller parameters in the application.ini.

application.ini:

...
# Front Controller Params
resources.frontController.params.locales[] = "en"
resources.frontController.params.locales[] = "ja"
resources.frontController.params.tldLocales.jp = "ja"
...

If you notice from the configuration above, I’ve added English and Japanese as my supported locales and I also mapped the jp TLD to use the ja language code. More on how we use those later.

Before I show the rest of the configuration needed, let me explain how the process works.

In order for your application to recognize when a locale is specified in the URL, you need to create special routes to parse out the locale. The approach I took was to override the existing Zend_Application_Resource_Router and implement the ability to automatically add locale routes to the application when enabled.

The process in which I added routes to my application was done previously in my Bootstrap.php with the _initRoutes() method. I’ve removed that code and moved the routes to be configured in the application.ini. Now that the routes are specified in the application.ini, it allows us to easily add/edit/remove routes from our application. There is also a benefit to doing this in regards to caching, which I will explain in a future article.

First, let’s take a look at how we will load the custom router application resource and override the existing application resource.

application.ini

...
# Custom Resource Plugins
pluginPaths.My_Application_Resource = APPLICATION_PATH "/../lib/My/Application/Resource/"
...

Now the application is setup to load custom application resources for the namespace specified. Since I am overriding the Zend_Application_Resource_Router, let’s look at My_Application_Resource_Router:

My/Application/Resource/Router.php:

<?php
class My_Application_Resource_Router extends Zend_Application_Resource_Router
{
    public $_explicitType = 'router';
 
    protected $_front;
    protected $_locale;
 
    /**
     * Retrieve router object
     *
     * @return Zend_Controller_Router_Rewrite
     */
    public function getRouter()
    {
        $options = $this->getOptions();
 
        if (!isset($options['locale']['enabled']) ||
            !$options['locale']['enabled']) {
            return parent::getRouter();
        }
 
        $bootstrap = $this->getBootstrap();
 
        if (!$this->_front) {
            $bootstrap->bootstrap('FrontController');
            $this->_front = $bootstrap->getContainer()->frontcontroller;
        }
 
        if (!$this->_locale) {
            $bootstrap->bootstrap('Locale');
            $this->_locale = $bootstrap->getContainer()->locale;
        }
 
        $defaultLocale = array_keys($this->_locale->getDefault());
        $defaultLocale = $defaultLocale[0];
 
        $locales = $this->_front->getParam('locales');
        $requiredLocalesRegex = '^(' . join('|', $locales) . ')$';
 
        $routes = $options['routes'];
        foreach ($routes as $key => $value) {
            // First let's add the default locale to this routes defaults.
            $defaults = isset($value['defaults'])
                ? $value['defaults']
                : array();
 
            // Always default all routes to the Zend_Locale default
            $value['defaults'] = array_merge(array( 'locale' => $defaultLocale ), $defaults);
 
            $routes[$key] = $value;
 
            // Get our route and make sure to remove the first forward slash
            // since it's not needed.
            $routeString = $value['route'];
            $routeString = ltrim($routeString, '/\\');
 
            // Modify our normal route to have the locale parameter.
            if (!isset($value['type']) ||
                $value['type'] === 'Zend_Controller_Router_Route') {
                $value['route'] = ':locale/' . $routeString;
 
                $value['reqs']['locale'] = $requiredLocalesRegex;
 
                $routes['locale_' . $key] = $value;
            } else if ($value['type'] === 'Zend_Controller_Router_Route_Regex') {
                $value['route'] = '(' . join('|', $locales) . ')\/' . $routeString;
 
                // Since we added the local regex match, we need to bump the existing
                // match numbers plus one.
                $map = isset($value['map']) ? $value['map'] : array();
                foreach ($map as $index => $word) {
                    unset($map[$index++]);
                    $map[$index] = $word;
                }
 
                // Add our locale map
                $map[1] = 'locale';
                ksort($map);
 
                $value['map'] = $map;
 
                $routes['locale_' . $key] = $value;
            } else if ($value['type'] === 'Zend_Controller_Router_Route_Static') {
                foreach ($locales as $locale) {
                    $value['route'] = $locale . '/' . $routeString;
                    $value['defaults']['locale'] = $locale;
                    $routes['locale_' . $locale . '_' . $key] = $value;
                }
            }
        }
 
        $options['routes'] = $routes;
        $this->setOptions($options);
 
        return parent::getRouter();
    }
}

In order for this custom application resource to override the existing one, the key is public $_explicitType = 'router';. Now when routes are setup in the application.ini for the router resource it won’t use the Zend_Application_Resource_Router, but rather My_Application_Resource_Router.

This application resource sets up the Zend_Controller_Router_Rewrite by parsing the specified options parsed from the application.ini. Notice this custom application resource extends from the original Zend_Application_Resource_Router which allows us to have the application resource perform the default actions if the locale option is not enabled in the configuration. By default, the custom router application resource will perform the default actions to the routes. You need to explicitly specify in the application.ini that the router is locale aware.

My_Application_Resource_Router simply takes in the specified routes from the application.ini and adds locale routes automatically so you don’t have to chain/duplicate routes in the configuration.

Let’s look at our application.ini to see how we are setting up the router to be locale aware and adding a route.

application.ini:

...
# Router/Routes
resources.router.locale.enabled = true
resources.router.routes.action_index.route = ":action/*"
resources.router.routes.action_index.defaults.controller = "index"
resources.router.routes.action_index.defaults.action = "index"
...

In the previous configuration snippet, we enable our router application resource to be locale aware and add a basic Zend_Controller_Router_Route which is the same as specified previously in our Bootstrap.php. When the router application resource is finished adding the routes to the router, there will be two:

1. :action/*
2. :locale/:action/*

Currently the My_Application_Resource_Router supports Zend_Controller_Router_Route, Zend_Controller_Router_Route_Regex and Zend_Controller_Router_Static routes. When these routes are specified and the router application resource is locale aware, it will automatically create routes for the supported locales.

We’ve covered a lot already, but there are still a few more steps involved. We are almost finished, I promise!

At this point, we have specified our default and supported locales and setup our routes using our custom router application resource. Now we need to do one more thing and that is to determine which locale to load and create our Zend_Translate instance.

In order for us to determine which locale, if any, has been specified in the request, we use a controller plugin to parse the request and set the correct locale and setup our translation component.

First, we need to enable the controller plugin in our application.ini.

application.ini:

...
# Front Controller Plugins
resources.frontController.plugins.I18n = "My_Controller_Plugin_I18n"
...

Next, let’s look at the controller plugin source:

My/Controller/Plugin/I18n.php:

<?php
class My_Controller_Plugin_I18n extends Zend_Controller_Plugin_Abstract
{
    /**
    * Sets the application locale and translation based on the locale param, if
    * one is not provided it defaults to english
    *
    * @param Zend_Controller_Request_Abstract $request
    */
    public function routeShutdown(Zend_Controller_Request_Abstract $request)
    {
        $frontController = Zend_Controller_Front::getInstance();
        $params = $request->getParams();
        $registry = Zend_Registry::getInstance();
 
        // Steps setting the locale.
        // 1. Defaults to English (Done in config)
        // 2. TLD in host header
        // 3. Locale params specified in request
        $locale = $registry->get('Zend_Locale');
 
        // Check host header TLD.
        $tld = preg_replace('/^.*\./', '', $request->getHeader('Host'));
 
        // Provide a list of tld's and their corresponding default languages
        $tldLocales = $frontController->getParam('tldLocales');
 
        if (array_key_exists($tld, $tldLocales)) {
            // The TLD in the request matches one of our specified TLD -> Locales
            $locale->setLocale($tldLocales[$tld]);
        } else if (isset($params['locale'])) {
            // There is a locale specified in the request params.
            $locale->setLocale($params['locale']);
        }
 
        // Now that our locale is set, let's check which language has been selected
        // and try to load a translation file for it. If the language is the default,
        // then we do not need to load a translation.
        $language = $locale->getLanguage();
        if ($language !== $locale->getDefault()) {
            $i18nFile = APPLICATION_PATH . '/data/i18n/source-' . $language . '.mo';
            try {
                $translate =
                    new Zend_Translate('gettext', $i18nFile, $locale, array('disableNotices' => true));
 
                Zend_Registry::set('Zend_Translate', $translate);
                Zend_Form::setDefaultTranslator($translate);
            } catch (Zend_Translate_Exception $e) {
                // Since there was an error when trying to load the translation catalog,
                // let's not load a translation object which essentially defaults to
                // locale default.
            }
        }
 
        // Now that we have our locale setup, let's check to see if we are loading
        // a language that is not the default, and update our base URL on the front
        // controller to the specified language.
        $defaultLanguage = array_keys($locale->getDefault());
        $defaultLanguage = $defaultLanguage[0];
 
        $path = '/' . ltrim($request->getPathInfo(), '/\\');
 
        // If the language is in the path, then we will want to set the baseUrl
        // to the specified language.
        if (preg_match('/^\/' . $language . '\/?/', $path)) {
            $frontController->setBaseUrl($frontController->getBaseUrl() . '/' . $language);
        }
 
        setcookie('Zend_Locale', $language, null, '/', $request->getHttpHost());
    }
}

To start, notice this plugin listens on the routeShutdown() method. We use this because our request has gone through our router and the request is now setup and ready to be processed. In the routeShutdown() method, we first load our Zend_Locale instance from the registry where it was set up in our application.ini. Next, we need to determine which locale, if any, needs to be set. By default, we’ve set our locale to use English (en) in our application.ini. We will parse out the TLD from the host and see if it maps to one of our specified TLD locales. If that doesn’t exist, then we will look in the request to see if the locale param was set. If both of the checks can’t find a specified locale, we then simply use the default.

Since our locale is now setup, we need to load a translation file. In my example provided, I use gettext translation files. I place these files in the app/data/i18n folder. The file naming scheme looks like source-{locale}.mo. Another example would be if we had a Japanese translation file, it would look something like source-ja.mo. The plugin will try to load the translation file based on the locale language specified and add it to our Zend_Registry and tell our Zend_Form it’s default translator.

Finally, our plugin uses the specified locale language to determine if we need to update our base URL in the front controller. We want to set the base URL to the specified locale which allows other components like Zend_Navigation to persist the locale in the links produced.

There you have it! You’re site is now internationalized and ready for it’s content to be translated.

But wait, that’s not all! I’ve also provided a view helper which produces a locale switcher. This view helper simply creates elements that contain images of the specified locale and shows the enabled/disabled locale while allowing you to click on the image and switch the current locale.

app/views/helpers/LocaleSwitcher.php:

<?php
class Default_View_Helper_LocaleSwitcher extends Zend_View_Helper_Abstract
{
    public function localeSwitcher()
    {
        $output = array();
        $frontController = Zend_Controller_Front::getInstance();
 
        $locales = $frontController->getParam('locales');
        $request = $frontController->getRequest();
        $baseUrl = $request->getBaseUrl();
        $path = '/' . trim($request->getPathInfo(), '/\\');
 
        if (count($locales) > 0) {
            $locale = Zend_Registry::get('Zend_Locale');
            $localeLanguage = $locale->getLanguage();
            $defaultLocaleLanguage = array_keys($locale->getDefault());
            $defaultLocaleLanguage = $defaultLocaleLanguage[0];
 
            array_push($output, '<ul id="locale_switcher">');
 
            foreach ($locales as $language) {
                $imageSrc  = 'img/i18n_';
                $imageSrc .= $language . '_' . ($localeLanguage == $language ? 'on' : 'off');
                $imageSrc .= '.gif';
 
                $urlLanguage = $defaultLocaleLanguage == $language
                    ? ''
                    : '/' . $language;
 
                if (strlen($baseUrl) === 0) {
                    $localeUrl = $urlLanguage . $path;
                } else {
                    $localeUrl = preg_replace('/^' . preg_quote($baseUrl, '/') . '\/?/',
                        $urlLanguage . '/', $path);
                }
 
                array_push($output, '<li>');
                array_push($output, '<a href="' . $localeUrl . '">');
                array_push($output, '<img src="' . $this->view->assetUrl($imageSrc) . '" alt="' . $language . '" />');
                array_push($output, '</a>');
                array_push($output, '</li>');
            }
 
            array_push($output, '</ul>');
        }
 
        return join('', $output);
    }
}

I’ve included an updated Zend Framework Best Practices zip file which contains all of the files/directory structure we’ve discussed so far in the series.

The original gist of this process can be found here: http://gist.github.com/189194.

That’s it for now. Until next time!