Skip to end of metadata
Go to start of metadata

<h2>Removal of most i18n components</h2>

<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>

<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>

<p>In comparision, PHP 5.3 offers the following tools:</p>

<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>

<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>

<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>

<h3>Benefits</h3>

<p>Using PHPs i18n tools instead of framework internal ones:</p>

<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>Handling of application-wide locale</h3>

<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>

<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>

<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');
]]></ac:plain-text-body></ac:macro>

<p>To format a number (normal number or currency), you'd use the numberFormatter helper:</p>

<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>

<h4>Zend\Validator\Date and Zend\Validator\Number:</h4>

<p>These validators will, like the view helpers, wrap around the date and number formatter to supply validation.</p>

<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>

Labels:
i18n i18n Delete
l10n l10n Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Feb 16, 2012

    <p>What I missed is in the ZF1 Zend_Locale was a predefined set of supported locales. This might be the case: </p>

    <p>I support both en_GB and nl_NL in my translation files and en_GB is my default setting. A user performs a request with <code>Accept-Language: de, nl-nl;q=0.8, nl;q=0.7</code>. Now "de" is autodetected and I recognize it's not in my supported list. So, I switch to default en_GB and completely miss the second preference to have nl_NL as second-best <em>AND</em> supported language.</p>

    <ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
    $locale = new Zend\Locale\Locale;
    $locale->setSupported(array('en_GB', 'nl_NL'));
    $locale->setDefault('en_GB');
    $locale->autodetect($request);
    ]]></ac:plain-text-body></ac:macro>

    1. Feb 16, 2012

      <p>Indeed this sounds like a good idea for the auto detection. What would your expected result be, when not setting the supported locales? I'd assume in that case, "de" would be detected?</p>

      1. Feb 16, 2012

        <p>I'd argue the same indeed. </p>

  2. Feb 16, 2012

    <p>ad 1.<br />
    That is <strong>exactly</strong> why Zend\Date\Date should stay and wrap around \DateTime to add missing functionality (including locale-aware date parsing and outputting).</p>

    1. Feb 16, 2012

      <p>What do yu mean by "That"?</p>

      <p>I can't see any reason to extend \DateTime, as it has all the required functionallity. And binding the locale-aware formatting/parsing to an internal extended version of \DateTime doesn't give any benefit, but limits the usability.</p>

      1. Feb 16, 2012

        <p>What I miss in \DateTime is the api for resetting date by using a format (you can only use format when constructing the class). Zend_Date in ZF1 had a nice api for that, and to mimic it with \DateTime I have made this: <a class="external-link" href="https://github.com/kblomqvist/kblom-zf1/blob/master/library/Kblom/Date.php">https://github.com/kblomqvist/kblom-zf1/blob/master/library/Kblom/Date.php</a></p>

        <p>This is one of the missing functions in \DateTime that I would like to see in Zend\Date\Date.</p>

        1. Feb 22, 2012

          <p>As discussed on IRC, resetting a data instance is not really required, as you can, for instance, just create a new \DateTime object.</p>

    2. Feb 16, 2012

      <p>I can possibly see this stance. However, having looked at DateTime, I'm unclear what, if any, locales/formats DateTime does not support, both in terms of parsing and output. If you are aware of any, could you put together a list?</p>

      <p>Also, if parsing/formatting were in a separate class, how would this affect your workflows? What would having that functionality in an extension to DateTime enable/make easier? I think answering those questions will make more impact in terms of design decisions.</p>

  3. Feb 16, 2012

    <p>This RFC needs more detail: what specifically will you be refactoring, and why? what will the class structure look like? can you provide some sample interfaces/skeletons? etc. It's a bit vague to evaluate at this time. The goals seem solid enough – I'm simply lacking the details to adequately evaluate the scope.</p>

  4. Feb 16, 2012

    <p>If Zend\Date will be removed, the date validator goes as well I guess? Although, it did not serve well in ZF1, I would not like to abandon it. I suggest that we would have something similar I have already made here: <a class="external-link" href="https://github.com/kblomqvist/kblom-zf1/blob/master/library/Kblom/Validate/Datetime.php">https://github.com/kblomqvist/kblom-zf1/blob/master/library/Kblom/Validate/Datetime.php</a></p>

    1. Feb 17, 2012

      <p>I updated the RFC to reflect parsing/valiation of dates.</p>

  5. Feb 17, 2012

    <p>I guess Zend\Locale\DateTime\Formatter uses CLDR database. Then it should address the issue raised in ZF1 <a class="external-link" href="http://framework.zend.com/issues/browse/ZF-10850">http://framework.zend.com/issues/browse/ZF-10850</a>. In my opinion, the month names are wrongly interpreted from the CLDR.</p>

    <p>Ben, when you have the Formatter "ready for hacking" I would like to try to expand it to render a calendar around the given date. If I'm able to do it (by using the parts of the code I already have), I'm completely satisfied with the new structure and API you are suggesting here <ac:emoticon ac:name="smile" /></p>

    1. Feb 17, 2012

      <p>I'd like to discuss this topic with you. Are you in the #zftalk.2 channel on irc.freenode.org?</p>

  6. Feb 17, 2012

    <p>Will this include updates to Zend_Currency? or is that outside the scope of this RFC?</p>

    1. Feb 22, 2012

      <p>The features of Zend\Currency are covered by the \NumberFormatter in the Intl extension. </p>

      1. Feb 22, 2012

        <p>What about currency conversion? That appears to be left out (correctly, IMO) from the Intl extension.. Zend_Currency in ZF1 had a slightly flawed, but useful currency conversion feature.</p>

        1. Feb 25, 2012

          <p>I don't think that this is really suited as a stand-alone feature, as conversion rates very daily if not hourly. This should be implemented as a service using some external API, IMHO.</p>