PHP5

Localization means that an application (or homepage) can be used from different users which speak different languages. But as you already have expected Localization means more than only translating strings. It includes

Each computer user makes use of Locales, even when they don't know it. Applications lacking localization support, normally have implicit support for one particular locale (the locale of the author). When a class or function makes use of localization, we say it is locale-aware. How does the code know which localization the user is expecting?

A locale string or object identifying a supported locale gives Zend_Locale and it's subclasses access to information about the language and region expected by the user. Correct formatting, normalization, and conversions are made based on this information.

Locale identifiers consist of information about the user's language and preferred/primary geographic region (e.g. state or province of home or workplace). The locale identifier strings used in the Zend Framework are internationally defined standard abbreviations of language and region, written as language_REGION. Both the language and region parts are abbreviated to 2 alphabetic, ASCII characters.

A user from USA would expect the language English and the region USA, yielding the locale identifier "en_US". A user in Germany would expect the language German and the region Germany, yielding the locale identifier "de_DE". See the list of pre-defined locale and region combinations , if you need to select a specific locale within the Zend Framework.

<?php
require_once 'Zend_Locale';
$locale = new Zend_Locale('de_DE'); // German language _ Germany
            

A German user in America might expect the language German and the region USA, but these non-standard mixes are not supported directly as recognized "locales". Instead, if an invalid combination is used, then it will automatically be truncated by dropping the region code. For example, "de_IS" would be truncated to "de", and "xh_RU" would be truncated to "xh", because neither of these combinations are valid. Additionally, if the base language code is not supported (e.g. "zz_US") or does not exist, then a default "root" locale will be used. The "root" locale has default definitions for internationally recognized representations of dates, times, numbers, currencies, etc. The truncation process depends on the requested information, since some combinations of language and region might be valid for one type of data (e.g. dates), but not for another (e.g. currency format).

Beware of historical changes, as ZF components do not know about or attempt to track the numerous timezone changes made over many years by many regions. For example, we can see a historical list showing dozens of changes made by governments to when and if a particular region observes Daylight Savings Time, and even which timezone a particular geographic area belongs. Thus, when performing date math, the math performed by ZF components will not adjust for these changes, but instead will give the correct time for the timezone using current, modern rules for DST and timezone assignment for geographic regions.

For most situations, new Zend_Locale() will automatically select the correct locale, with preference given to information provided by the user's web browser. However, if new Zend_Locale(Zend_Locale::ENVIRONMENT) is used, then preference will be given to using the host server's environment configuration, as described below.

<?php
require_once 'Zend/Locale.php';
$locale  = new Zend_Locale();
$locale1 = new Zend_Locale(Zend_Locale::BROWSER);     // default behavior, same as above
$locale2 = new Zend_Locale(Zend_Locale::ENVIRONMENT); // prefer settings on host server
$locale3 = new Zend_Locale(Zend_Locale::FRAMEWORK);   // perfer framework app default settings
            

The seach algorithm used by Zend_Locale for automatic selection of a locale uses three sources of information:

Zend_Locale provides three additionally locales. These locales do not belong to any language or region. They are "automatic" locales which means that they have the same effect as the method getDefault() but without the negative effects like creating an instance. These "automatic" locales can be used anywhere, where also a standard locale and also the definition of a locale, it's string representation, can be used. This offers simplicity for situations like working with locales which are provided by a browser.

There are three locales which have a slightly different behaviour:

<?php
require_once 'Zend/Locale.php';
require_once 'Zend/Date.php';

// without automatic detection
//$locale = new Zend_Locale(Zend_Locale::BROWSER);
//$date = new Zend_Date($locale);

// with automatic detection
$date = new Zend_Date('auto');
            

In some environments it is not possible to detect a locale automatically. You can expect this behaviour when you get an request from commandline or the requesting browser has no language tag set and additionally your server has the default locale 'C' set or another properitary locale.

In such cases Zend_Locale will normally throw an exception with a message that the automatic detection of any locale was not successfull. You have two options to handle such a situation. Either through setting a new locale per hand, or defining a default locale.

<?php
// within the bootstrap file
require_once 'Zend/Locale.php';

try {
    $locale = new Zend_Locale('auto');
} catch (Zend_Locale_Exception $e) {
    $locale = new Zend_Locale('de');
}

// within your model/controller
$date = new Zend_Date($locale);
            

But this has one big negative effect. You will have to set your locale object within every class using Zend_Locale. This could become very unhandy if you are using multiple classes.

Since Zend Framework Release 1.5 there is a much better way to handle this. You can set a default locale which the static setDefault() method. Of course, every unknown or not full qualified locale will also throw an exception. setDefault() should be the first call before you initiate any class using Zend_Locale. See the following example for details:

<?php
// within the bootstrap file
require_once 'Zend/Locale.php';

Zend_Locale::setDefault('de');

// within your model/controller
$date = new Zend_Date();
            

In the case that no locale can be detected, automatically the locale de will be used. Otherwise, the detected locale will be used.

In the ZF, locale-aware classes rely on Zend_Locale to automatically select a locale, as explained above. For example, in a ZF web application, constructing a date using Zend_Date without specifying a locale results in an object with a locale based on information provided by the current user's web browser.

<?php
require_once 'Zend/Date.php';
$date = new Zend_Date('2006',Zend_Date::YEAR);
            

To override this default behavior, and force locale-aware ZF components to use specific locales, regardless of the origin of your website visitors, explicitly specify a locale as the third argument to the constructor.

<?php
require_once 'Zend/Date.php';
require_once 'Zend/Measure/Temperature.php';

$usLocale = new Zend_Locale('en_US');
$date = new Zend_Date('2006', Zend_Date::YEAR, $usLocale);
$temp = new Zend_Measure_Temperature('100,10', Zend_Measure::TEMPERATURE, $usLocale);
            

If you know many objects should all use the same default locale, explicitly specify the default locale to avoid the overhead of each object determining the default locale.

<?php
require_once 'Zend/Date.php';
require_once 'Zend/Measure/Temperature.php';

$locale = new Zend_Locale();
$date = new Zend_Date('2006', Zend_Date::YEAR, $locale);
$temp = new Zend_Measure_Temperature('100,10', Zend_Measure::TEMPERATURE, $locale);
            

The 'precision' option of a value is used to truncate or stretch extra digits. A value of '-1' disables modification of the number of digits in the fractional part of the value. The 'locale' option helps when parsing numbers and dates using separators and month names. The date format 'format_type' option selects between CLDR/ISO date format specifier tokens and PHP's date() tokens. The 'fix_date' option enables or disables heuristics that attempt to correct invalid dates. The 'number_format' option specifies a default number format for use with toNumber() (see Раздел 23.3.2, «Number localization» ).

The 'date_format' option can be used to specify a default date format string, but beware of using getDate(), checkdateFormat() and getTime() after using setOptions() with a 'date_format'. To use these four methods with the default date format for a locale, use array('date_format' => null, 'locale' => $locale) for their options.

<?php
require_once 'Zend/Locale.php';
Zend_Locale_Format::setOptions(array('locale' => 'en_US', 'fix_date' => true, 'format_type' => 'php'));
            

For working with the standard definitions of a locale the option Zend_Locale_Format::STANDARD can be used. Setting the option Zend_Locale_Format::STANDARD for date_format uses the standard definitions from the actual set locale. Setting it for number_format uses the standard number format for this locale. And setting it for locale uses the standard locale for this environment or browser.

<?php
require_once 'Zend/Locale.php';
Zend_Locale_Format::setOptions(array('locale' => 'en_US', 'date_format' => 'dd.MMMM.YYYY'));
// overriding the global set date format
$date = Zend_Locale_Format::getDate('2007-04-20, array('date_format' => Zend_Locale_Format::STANDARD);

// global setting of the standard locale
Zend_Locale_Format::setOptions(array('locale' => Zend_Locale_Format::STANDARD, 'date_format' => 'dd.MMMM.YYYY'));
            

Zend_Locale and it's subclasses can be speed up by the usage of Zend_Cache. Use the static method Zend_Locale::setCache($cache) if you are using Zend_Locale. Zend_Locale_Format can be speed up the using the option cache within Zend_Locale_Format::setOptions(array('cache' => $adapter));. If you are using both classes you should only set an cache for Zend_Locale, otherwise the data would be cached twice.