compared with
Current by Ben Scholzen
on Feb 25, 2012 15:57.

Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (48)

View Page History
h2. Removal of most i18n components
<h2>Removal of most i18n components</h2>

h3. Introduction
<h3>Introduction</h3>

<p>As of PHP 5.3, almost all i18n features are now included in the PHP core. So far, the following features were covered by Zend Framework:</p>

* Zend\Locale\Locale:
** Representing a locale and its CLDR data
** Auto-Detection via HTTP request
* Zend\Locale\Format:
** Number formatting/parsing
** Date formatting/parsing
* Zend\Date\Date:
** Date manipulation
** Locale-aware formatting
** Locale-aware parsing
* Zend\Currency\Currency:
** Locale-aware formatting
** Locale-aware parsing
<ul>
<li>Zend\Locale\Locale:
<ul>
<li>Representing a locale and its CLDR data</li>
<li>Auto-Detection via HTTP request</li>
</ul>
</li>
<li>Zend\Locale\Format:
<ul>
<li>Number formatting/parsing</li>
<li>Date formatting/parsing</li>
</ul>
</li>
<li>Zend\Date\Date:
<ul>
<li>Date manipulation</li>
<li>Locale-aware formatting</li>
<li>Locale-aware parsing</li>
</ul>
</li>
<li>Zend\Currency\Currency:
<ul>
<li>Locale-aware formatting</li>
<li>Locale-aware parsing</li>
</ul>
</li>
</ul>

In comparision, PHP 5.3 offers the following tools:

* \Locale:
** Auto-Detection via HTTP header
** Locale validation
** Locale normalization
* \DateTime:
** Date manipulation
* \IntlDateFormatter:
** Locale-aware formatting
** Locale-aware parsing
** Timezone handling
* \NumberFormatter:
** Locale-aware formatting of numbers and currencies
** Locale-aware parsing of numbers and currencies
<p>In comparision, PHP 5.3 offers the following tools:</p>

The basic functionallity between both is the same, with the exception that the PHP 5.3 version offers more features. Further information about it can be found here:
<ul>
<li>\Locale:
<ul>
<li>Auto-Detection via HTTP header</li>
<li>Locale validation</li>
<li>Locale normalization</li>
</ul>
</li>
<li>\DateTime:
<ul>
<li>Date manipulation</li>
</ul>
</li>
<li>\IntlDateFormatter:
<ul>
<li>Locale-aware formatting</li>
<li>Locale-aware parsing</li>
<li>Timezone handling</li>
</ul>
</li>
<li>\NumberFormatter:
<ul>
<li>Locale-aware formatting of numbers and currencies</li>
<li>Locale-aware parsing of numbers and currencies</li>
</ul>
</li>
</ul>

- http://devzone.zend.com/1500/internationalization-in-php-53/
- http://php.net/intl

h3. Benefits
<p>The basic functionallity between both is the same, with the exception that the PHP 5.3 version offers more features. Further information about it can be found here:</p>

Using PHPs i18n tools instead of framework internal ones:
<ul class="alternate">
<li><a class="external-link" href="http://devzone.zend.com/1500/internationalization-in-php-53/">http://devzone.zend.com/1500/internationalization-in-php-53/</a></li>
<li><a class="external-link" href="http://php.net/intl">http://php.net/intl</a></li>
</ul>

- Better performance (some benchmarks show a difference of 5-10 times)
- Usage of third party code is easier, since date formatting is not a component-related feature anymore
- Proper timezone handling
- Less maintenace (we are less to blame)

h3. Handling of application-wide locale
<h3>Benefits</h3>

All helpers around the Intl extension will make use of \Locale::getDefault() if no explicit locale was passed to them. Thus, you'd set up your application in the following way:
<p>Using PHPs i18n tools instead of framework internal ones:</p>

- Determine locale, e.g. from URL or HTTP headers via \Locale::acceptFromHttp() (this could get another helper)
- Pass locale to \Locale::setDefault()
<ul class="alternate">
<li>Better performance (some benchmarks show a difference of 5-10 times)</li>
<li>Usage of third party code is easier, since date formatting is not a component-related feature anymore</li>
<li>Proper timezone handling</li>
<li>Less maintenace (we are less to blame)</li>
</ul>

h3. Refactoring and new components

In order to make working with PHP's i18n tools more comfortable, the following components will be introduced:
<h3>Handling of application-wide locale</h3>

h4. Zend\View\Helper\DateFormatter and Zend\View\Helper\NumberFormatter
<p>All helpers around the Intl extension will make use of \Locale::getDefault() if no explicit locale was passed to them. Thus, you'd set up your application in the following way:</p>

These view helpers supply wrappers around \IntlDateFormatter and \NumberFormatter, allowing to inject default locales and switching formatting options on-the-fly (each date format actually requires its own formatter instance). Formatting a date (either \DateTime or a unix timestamp) could look like this in a view:
<ul class="alternate">
<li>Determine locale, e.g. from URL or HTTP headers via \Locale::acceptFromHttp() (this could get another helper)</li>
<li>Pass locale to \Locale::setDefault()</li>
</ul>

{code:php}
<h3>Refactoring and new components</h3>

<p>In order to make working with PHP's i18n tools more comfortable, the following components will be introduced:</p>

<h4>Zend\View\Helper\DateFormatter and Zend\View\Helper\NumberFormatter</h4>

<p>These view helpers supply wrappers around \IntlDateFormatter and \NumberFormatter, allowing to inject default locales and switching formatting options on-the-fly (each date format actually requires its own formatter instance). Formatting a date (either \DateTime or a unix timestamp) could look like this in a view:</p>

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
// Formats a date with "medium" date format and
// "short" time format in the current locale.
$this->dateFormatter($date, 'medium', 'short');
{code}
]]></ac:plain-text-body></ac:macro>

h4. Zend\Validator\Date and Zend\Validator\Number:
<p>To format a number (normal number or currency), you'd use the numberFormatter helper:</p>

These validators will, like the view helpers, wrap around the date and number formatter to supply validation.
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
$this->numberFormatter($number);
$this->numberFormatter->formatCurrency($number, 'EUR');
]]></ac:plain-text-body></ac:macro>

The following components will have to be made compatible (no or almost no API change):
<h4>Zend\Validator\Date and Zend\Validator\Number:</h4>

- Zend\Filter\LocalizedToNormalized
- Zend\Filter\NormalizedToLocalized
- Zend\Measure
<p>These validators will, like the view helpers, wrap around the date and number formatter to supply validation.</p>

h2. Internal refactoring of Zend\Translator
<p>The following components will have to be made compatible (no or almost no API change):</p>

<ul class="alternate">
<li>Zend\Filter\LocalizedToNormalized</li>
<li>Zend\Filter\NormalizedToLocalized</li>
<li>Zend\Measure</li>
</ul>


<h2>Internal refactoring of Zend\Translator</h2>

<p>Zend\Translator will undergo minor internal refactoring in favor of better performance, mainly achieved through use of a better caching strategy. This is also required to make it compatible with PHP's internal locale handling. The API should stay the same and the translate-source adapters will be adopted as is, except where performance improvements or bug fixes are required. A few internal changes are also required to make translated segments in routing more performant.</p>

<h2>Location of all different i18n components</h2>

<p>To ease packaging of the i18n components, they should all be moved to a single namespace (for instance, Zend\I18n). </p>


<h2>Translatable routes</h2>

<p>To keep the standard router free of any i18n dependencies, translation features will be separated from them into separate routes, residing in the i18n namespace.</p>