Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Locale Component Proposal

Proposed Component Name Zend_Locale
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Locale
Proposers
Revision 4.0 - 19 Sept 2006: Extracted translation classes to Zend_Translate
3.0 - 28 July 2006: Changed Class Skeleton and added new Use cases based on comments from Zend
2.1 - 11 July 2006: Changed Class Skeletons for matching actual work
2.0 - 20 Juni 2006: Reworked based on new Zend_Measure and Zend_Date Proposal. (wiki revision: 40)

Table of Contents

1. Overview

Zend_Locale is a basic wrapper for all I18N and L10N issues for the Zend Framework. It provides the framework with all locale related informations. All classes which should be locale-aware should implement Zend_Locale.

2. References

Locale Description Standard

Details to Locale Description Standard which has to be implemented

LDML - Locale Data Markup Language

LDML the Locale Data Markup Language is part of the CLDR Project and it describes the locales XLM based.

International Standards

The following international standards must be used

ISO 639

International Language Code Definition
ISO 639-1 for 2 letter, ISO 639-2 for 3 letter language codes

ISO 3166

International Country Code Definitions
ISO 3166-1 for 2 letter country codes

RFC 3066

Identification of languages

I18N General

Mailing Lists

Mailinglist discussions in past

Unicode Discussion for upcoming PHP6

Discussions for Zend Framework

3. Component Requirements, Constraints, and Acceptance Criteria

  • Wrapper functionality
  • Lightweight and fast implementation
  • Simple use
  • Automatic recognition of language the browser requests

4. Dependencies on Other Framework Components

5. Theory of Operation

Basics

Zend_Locale is a wrapper for all locale related informations, especially for the CLDR, in the Zend Framework. It has to be simple to use and as lightweight as possible.

Locale description format

Zend_Locale has to know all language codes (see ISO 639 and ISO 3166). Therefor a locale description format has to be implemented. As format the free avaiable LDML format will be used (part of CLDR), as it is already used by many Open Source Projects.

Automatic locale recognition

Zend_Locale has to recognize which language the browser is requesting (see ISO 639 and ISO 3166), and automatically find the best matching locale for the client. (Internal Fallback mechanism). Alternative it could check for the system locale (environment variables) when f.e. used at command line.

Formatting with locales

Zend_Locale_Format can tell other functions how to format datas in different locales. For this, the Module knows how different locales are formatting data. Data can be everything which is defined in LDML. This implements especially:

  • Date / Time
  • Currency
  • Measurement
  • Numbers
  • and all other descriptions which are handled through the LDML

Exception handling

Zend_Locale_Exception handles and throws all exceptions which our Zend_Locale Classes or their subclasses will throw

Basically we have to implement/know the following standards

ISO 639 - Language Codes
ISO 3166 - Region Codes
RFC 3066 - Country Codes

Outsourced or delayed functionality

Zend_Locale_Collate defines how alphabetic sorting has to be done in different locales, for example german, greek or russian where you have more than 26 letters or the pronouncing is different. This Class will be delayed for later implementation

Framework Components which use Zend_Locale

6. Milestones / Tasks

zone: Missing {zone-data:milestones}

7. Class Index

  • Zend_Locale - base class
  • Zend_Locale_Exception- exception handling
  • Zend_Locale_Format - A standard interface for locale formatting
  • Zend_Locale_Data - internal LDML handling class

8. Use Cases

Get default locale

Set other language

Get region and language

Get the accepted languages from a users browser

Formatting

Formatting numbers

Example useage of own date-format (Zend_Date will use Zend_Locale_Format internally)

Example useage of a own defined format

Checking if a locale string is a float value

Getting a locale translated list of all countries

9. Class Skeletons

]]></ac:plain-text-body></ac:macro>

]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jul 17, 2006

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Feedback</ac:parameter><ac:rich-text-body>
    <p>Zend_Locale is conditionally accepted subject to the conventions,<br />
    stipulations, requirements, and changes listed below.</p>

    <p>Zend_Locale should focus on encapsulating the data specifying a<br />
    particular locale. It should contain information either fully or<br />
    partially describing a particular "locale", and includes functions to<br />
    access and modify this information.</p>

    <p>A ZF default locale object should be used in most places where a<br />
    component or function expects an optional locale object.<br />
    The default locale object should be constructed from an instance of<br />
    Zend_Config shared by all ZF components.</p>

    <p>The locale should be optional for constructors, not required.</p>

    <p>We need some sample use cases showing how Zend_Locale and related<br />
    classes will be used with Zend_Input_Filter.</p>

    <p>Where possible Zend_Date should be loosely coupled to Zend_Locale.<br />
    Ideally, many of the functions in Zend_Date would not even 'require()'<br />
    Zend_Locale.</p>

    <p>Instances should be serializable.</p>

    <p>The private static "class" variables should become protected instead of<br />
    private.</p>

    <p>Text string translation functionality should be split to a separate<br />
    class. Will the TXM and gettext backends need Zend_Cache or use purely<br />
    internal optimizations (e.g. specialized caching or "compiled" data<br />
    structures) to improve performance?</p>

    <p>Add to the requirements: "Functionality in Zend_Locale and<br />
    Zend_Locale_Translate that duplicates in PHP 6 and the new<br />
    object-oriented data extension will be replaced when available. Effort<br />
    should be made to provide wrapper functionality and a compatible API."</p>

    <p>Functionality to automatically create a locale object from information<br />
    sent in HTTP headers (i.e. sent by the browser) should be split to a<br />
    separate class. However, "auto-completing" a locale object given<br />
    partial data might still reside in Zend_Locale. Auto-completing may be<br />
    accomplished algorithmically, possibly using heuristics in some<br />
    circumstances. Auto-completion should not be automatic by default in<br />
    Zend_Locale.</p>

    <p>The word "locale" is overloaded too much. Function names need to be<br />
    more intuitive and descriptive. For example, these functions:<br />
    getLanguage() return a language code<br />
    getCountry() return a country code<br />
    getRegion() return a region code</p>

    <p>The SQL backend storage should remain in the incubator until performance<br />
    benchmarks demonstrate performance is comparable to the TMX and Gettext<br />
    storage backends to avoid potential complications with developers<br />
    encountering severe performance problems.</p>

    <p>If Zend_Locale::setLocale() is actually a getter-type function that<br />
    "returns the actual set default Locale", then a name like<br />
    "getDefaultLocaleName" is more descriptive, but terribly long. Do you<br />
    have suggestions for a naming convention to clearly distinguish between:</p>
    <ul class="alternate">
    <li>locale objects</li>
    <li>locale names/strings in the form of <country_code>_<lang_code> (is<br />
    that sufficient to unambiguously specify a precise "locale"?)</li>
    <li>locales, the array of supported/available locales</li>
    </ul>

    <p>The comments and names for setLocale(), getLocale(), and getLocales()<br />
    are confusing (possibly accidentally swapped?). Let us use more<br />
    descriptive names, like getBrowserDefaultLocale(), getLocalString(),<br />
    getDefaultLocale(), and getAllLocales() .. or something similar. Please<br />
    clarify the names and purpose of these functions, and give example use<br />
    cases.</p>

    <p>Parsing, normalization, conversion, and formatting function names<br />
    could benefit from sharing common looking names with other locale-related<br />
    classes.</p>

    <p>Methods should not combine input parsing, normalization, and output<br />
    formatting all in one step. Instead, parsing and normalization could be<br />
    encapsulated by a constructor. Then a "formatTo($someLocale)" can be<br />
    applied to the instance.</p>

    <h3>Questions for Proposal Author/Team</h3>

    <p>Zend_Locale_Format needs clarification, including a list of possible<br />
    values for $input. For example, does Zend_Locale_Format::getFormat()<br />
    provide generic number formatting based on locale?</p>

    <p>Is there any portion of LDML that Locale does not need to model in order<br />
    to provide our lightweight implementation of "locale"?</p></ac:rich-text-body></ac:macro>

    1. Jul 18, 2006

      <p>I will answer all related questions and make the changes a little bit later (much to redesign and think of, as I have to review 3 classes (one already made <ac:emoticon ac:name="laugh" /> ).</p>

      <p>But one thing:</p>
      <blockquote>
      <p>Is there any portion of LDML that Locale does not need to model in order<br />
      to provide our lightweight implementation of "locale"?</p></blockquote>
      <p>To make this a little bit clearer:<br />
      Locale in the meaning of translation does not make use of LDML.<br />
      LDML is only needed for all additional locale aware classes like<br />
      "How to parse numbers, how to format calendars, get a list of all countries" and much more.</p>

      <p>So Zend_Locale itself has until now no use of Zend_Locale_Data as Zend_Locale only has to<br />
      do translational issues.</p>

      <p>Zend_Locale_Data is a passive, standalone, static ICU/LDML Reader which returns only the<br />
      asked datas from LDML. It <strong><em>COULD</em></strong> be used totally independent.</p>

      <p>From LDML itself until now there will only be support of the main and the supplemental files.<br />
      There is no support for collation, segments or transforms planned until now.</p>

      <p>All other questions will be answered later.<ac:emoticon ac:name="cheeky" /></p>

      1. Jul 19, 2006

        <p>Thank you Thomas for your hard work on this important proposal. I completely understand the need for more time. Also, everyone is here to help, and answers can be worked out one part at a time, with comments back and forth between everyone interested in helping with this component.</p>

        <p>We repeated the lightweight design goal in the form of a question ("Is there any portion of LDML ..."), to make certain key design decisions are captured in these comment notes. These notes provide key reference material in the future, as components evolve. The question was added to this proposal, since Zend_Locale_Data/Format are implied by this proposal.</p>

    2. Jul 28, 2006

      <blockquote>
      <p>Zend_Locale should focus on encapsulating the data specifying a<br />
      particular locale. It should contain information either fully or<br />
      partially describing a particular "locale", and includes functions to<br />
      access and modify this information.</p></blockquote>
      <p>Here I must seperate two tasks which are known as "locale".</p>

      <p><strong>TRANSLATION:</strong><br />
      Here we have to</p>
      <ul>
      <li>Know the translation-source</li>
      <li>detect locales automatically</li>
      <li>do the translation</li>
      </ul>

      <p><strong>LOCALE INFORMATION MANAGEMENT:</strong><br />
      Here we have to do several things locale aware. This implements</p>
      <ul>
      <li>Formatting</li>
      <li>Parsing</li>
      <li>Describing</li>
      </ul>

      <p>I've seperated these tasks.<br />
      Translation and all related issues are done by Zend_Locale.</p>

      <p>Locale Information Management, which generally implements ICU/LDML usage, is done by Zend_Locale_Format.<br />
      This class is static as ICU could be used independent from Zend_Locale if this is needed.</p>

      <p>Therefor when for example implementing Zend_Date object, this could be done independent from Zend_Locale,<br />
      and therefor it's faster.<br />
      Zend_Locale_Format is intendent to be used by other Classes which need to be locale aware.</p>
      <blockquote>
      <p>A ZF default locale object should be used in most places where a<br />
      component or function expects an optional locale object.<br />
      The default locale object should be constructed from an instance of<br />
      Zend_Config shared by all ZF components.</p></blockquote>
      <p>Here we have to differ between</p>
      <ul>
      <li>a class which needs translation : Here the class has to implement Zend_Locale and make a connection to the source.</li>
      <li>a class which only needs the locale data : Here the class has only to implement Zend_Locale_Format.</li>
      </ul>

      <p>Indepentently the default locale could be found out by calling the static class Zend_Locale::getDefault.</p>

      <p>All locale aware classes will first call this function when NO standard locale was found.<br />
      The standard locale will be stored by calling Zend_Cache for</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      ['ZEND_DEFAULTLOCALE'];
      ]]></ac:plain-text-body></ac:macro>
      <blockquote>
      <p>The locale should be optional for constructors, not required.</p></blockquote>
      <p>Locale's are always OPTIONAL.<br />
      When no locale was given, all locale aware classes will use the default locale.</p>
      <blockquote>
      <p>We need some sample use cases showing how Zend_Locale and related<br />
      classes will be used with Zend_Input_Filter.</p></blockquote>
      <p>I did'nt use Zend_Filter_Input until now.<br />
      I'm not sure what you want me here to show...</p>

      <p>How Zend_Locale makes use of Zend_Filter_Input ???<br />
      Non... as Zend_Locale/_Format handles all locale things it-self.</p>

      <p>When it should use Zend_Filter_Input for example for parsing a locale aware float number:<br />
      Zend_Filter_Input::getFloat($locale); could be called.<br />
      But the problem here is that Zend_Locale_Format knows how to parse an input string properly,<br />
      and Zend_Filter_Input not.<br />
      When doing this, I would loose the property of parsing input locale aware.</p>

      <p>How Zend_Filter_Input can use Zend_Locale ???<br />
      There are 2 options:<br />
      1.) Zend_Filter_Input could use Zend_Locale_Format to know if a string is locale-aware and would get a<br />
      locale-unaware string.</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      // '1.500,400' could become 1500.4 or 1.5004 depending on the locale.
      Zend_Locale_Format::getInteger('1.500,400');
      ]]></ac:plain-text-body></ac:macro>
      <p>So Zend_Filter_Input's function getInt would first have to call Zend_Locale_Format and could then do it's<br />
      job with the locale-unaware returned value.</p>

      <p>This would be the best way in my opinion.<br />
      Zend_Filter_Input could use:<br />
      Zend_Locale_Format::getInteger<br />
      Zend_Locale_Format::getFloat<br />
      Zend_Locale_Format::getDate<br />
      and so on...</p>

      <p>2.) Zend_Filter_Input could be locale aware by knowing how to format.<br />
      There are 2 ways.<br />
      2.1) Zend_Locale_Format::getFormat(Zend_Locale::NUMBERFORMAT) would f.e. return '#,##0.0#'.<br />
      Zend_Locale_Filter then would have to parse as defined in the format.</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      $format = Zend_Locale_Format::getFormat(Zend_Locale::NUMBERFORMAT);
      parse($input, $format);
      ]]></ac:plain-text-body></ac:macro>
      <p>No good way in my opinion, as Zend_Locale_Format::getInteger f.e. is already doing this job locale aware.</p>

      <p>2.2) Zend_Locale_Data::getContent($locale,'numbersymbols') could return the<br />
      locale aware symbols for number formatting.<br />
      Then Zend_Filter_Input would have to parse the input checking the right symbols.</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      $symbols = Zend_Locale_Data::getContent($locale,'numbersymbols');
      $regex = '/('.$symbols['minus'].')

      Unknown macro: {0,1}

      (\d+(
      '.$symbols['group'].')

      )*(
      '.$symbols['decimal'].')

      Unknown macro: {0,1}

      \d+/';
      ]]></ac:plain-text-body></ac:macro>
      <p>Also no good way in my opinion as Zend_Locale_Format::getInteger is doning this job already.</p>

      <p>3.) Zend_Filter_Input could stay locale independent and the user would have to do the job.</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      $input = '-123.456,789';
      $parsed = Zend_Locale_Format::getInteger($input);
      $filter = Zend_Filter_Input->getInteger($parsed);
      ]]></ac:plain-text-body></ac:macro>
      <p>This could be done, but why should the user be aware if his input string is locale aware or not.<br />
      Better to do this job automatically, so the user would not have to think of it.</p>

      <p>For Dates it could look loke this</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      $input = '23.Mai 2006 12:00';
      $date = new Zend_Date($input);
      $parsed = $date->getIso();
      $filter = Zend_Filter_Input->getDate($parsed);
      ]]></ac:plain-text-body></ac:macro>
      <p>So my opinion is that Zend_Filter_Input should be locale aware, and it should have to use<br />
      Zend_Locale_Format.</p>

      <p>So the user only has to do</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      $input = '23.Mai 2006 12:00';
      $filter = Zend_Filter_Input->getDate($input);
      ]]></ac:plain-text-body></ac:macro>
      <p>all other things would be done internally.</p>

      <p>This would be the best way in my opinion.</p>
      <blockquote>
      <p>Where possible Zend_Date should be loosely coupled to Zend_Locale.<br />
      Ideally, many of the functions in Zend_Date would not even 'require()'<br />
      Zend_Locale.</p></blockquote>
      <p>Zend_Date makes only use of Zend_Locale_Format and Zend_Locale_Data.<br />
      Both of these are static. Zend_Locale itself would not be used.<br />
      See above for LOCALE INFORMATION MANAGEMENT.</p>
      <blockquote>
      <p>Instances should be serializable.</p></blockquote>
      <p>Added in the proposal</p>
      <blockquote>
      <p>The private static "class" variables should become protected instead of<br />
      private.</p></blockquote>
      <p>In Zend_Locale_Data the internal variables were made private because<br />
      they store the information which is found in LDML and what locales have<br />
      been searched until now.</p>

      <p>Making them protected will brake the class, as these variables are only<br />
      for internal use. When an other class could change what Zend_Locale_Data have<br />
      been found and searched for now it would be a big problem.</p>

      <p>What is the intention for making them protected ??</p>
      <blockquote>
      <p>Text string translation functionality should be split to a separate<br />
      class. Will the TXM and gettext backends need Zend_Cache or use purely<br />
      internal optimizations (e.g. specialized caching or "compiled" data<br />
      structures) to improve performance?</p></blockquote>
      <p>Zend_Locale is this seperate class.<br />
      LDML is only accessable through Zend_Locale_Format/Data.</p>

      <p>The backends are called upon to use Zend_Cache for internal caching.<br />
      Each backend has to use this by its own, because SQL-Caching is different than File-Caching,<br />
      and also each source has to be handled and therefor also cached different.</p>

      <p>Caching has to be done in the source backends, as the base class does'nt know when a source is no longer avaiable.</p>
      <blockquote>
      <p>Add to the requirements: "Functionality in Zend_Locale and<br />
      Zend_Locale_Translate that duplicates in PHP 6 and the new<br />
      object-oriented data extension will be replaced when available. Effort<br />
      should be made to provide wrapper functionality and a compatible API."</p></blockquote>
      <p>Agreed.<br />
      Only problem for now...<br />
      How could a "compatible API" be done when we dont know how the I18N object will look like in PHP6 <ac:emoticon ac:name="sad" /></p>

      <p>I've looked in several other languages and took out the most used things. This should de the job best</p>
      <blockquote>
      <p>Functionality to automatically create a locale object from information<br />
      sent in HTTP headers (i.e. sent by the browser) should be split to a<br />
      separate class. However, "auto-completing" a locale object given<br />
      partial data might still reside in Zend_Locale. Auto-completing may be<br />
      accomplished algorithmically, possibly using heuristics in some<br />
      circumstances. Auto-completion should not be automatic by default in<br />
      Zend_Locale.</p></blockquote>
      <p>I think that creating a own class for only one (1) function is a little bit excessive option.<br />
      There are only 2 ways for detecting locales.</p>
      <ul>
      <li>Http-Header - ACCEPTED_LANGUAGES content</li>
      <li>Environment Variables</li>
      </ul>

      <p>What do you mean with "autocompleating" ?</p>

      <p>When Requesting "de_TG", automatically de and root will be used.<br />
      Locale Information and also translation is ALWAYS recursive.<br />
      When you mean this with autocompletion we would break standard behaivor.<br />
      Keep in mind that there must always be an output, even when the requested string cannot be translated.</p>
      <blockquote>
      <p>The word "locale" is overloaded too much. Function names need to be<br />
      more intuitive and descriptive. For example, these functions:<br />
      getLanguage() return a language code<br />
      getCountry() return a country code<br />
      getRegion() return a region code</p></blockquote>
      <p>I think this was already be done when your comments were written.</p>

      <p>I only found getLocale and setLocale...<br />
      Have you referred to an older proposal ??</p>
      <blockquote>
      <p>The SQL backend storage should remain in the incubator until performance<br />
      benchmarks demonstrate performance is comparable to the TMX and Gettext<br />
      storage backends to avoid potential complications with developers<br />
      encountering severe performance problems.</p></blockquote>
      <p>Agreed.<br />
      But keep in mind that smaller project often use database for simpler access,<br />
      gettext is mostly used for middle sized projects, and TMX in realy big<br />
      project. Exceptions approve this rule <ac:emoticon ac:name="smile" /></p>
      <blockquote>
      <p>If Zend_Locale::setLocale() is actually a getter-type function that<br />
      "returns the actual set default Locale", then a name like<br />
      "getDefaultLocaleName" is more descriptive, but terribly long. Do you<br />
      have suggestions for a naming convention to clearly distinguish between:</p></blockquote>
      <p>getDefault() will return the default locale.<br />
      But you can also select to take the default locale only from<br />
      the browser or instead use the environment. getEnv()/getBrowser()</p>
      <blockquote>
      <p>locale objects<br />
      locale names/strings in the form of <country_code>_<lang_code> (is<br />
      that sufficient to unambiguously specify a precise "locale"?)<br />
      locales, the array of supported/available locales<br />
      The comments and names for setLocale(), getLocale(), and getLocales()<br />
      are confusing (possibly accidentally swapped?). Let us use more<br />
      descriptive names, like getBrowserDefaultLocale(), getLocalString(),<br />
      getDefaultLocale(), and getAllLocales() .. or something similar. Please<br />
      clarify the names and purpose of these functions, and give example use<br />
      cases.</p></blockquote>
      <p>To clarify:</p>
      <ul>
      <li>Locale Names<br />
      When no locale name is given the "standard locale" has to be used.<br />
      This is normally the root. But it could also be an automatically found<br />
      locale from browser or environment.</li>
      </ul>

      <p>A locale is always represented by<br />
      LANGUAGE and REGION</p>

      <p>Language en,de,fr means a standard which can be used in all en,de or fr spoken areas.<br />
      Region defined a specific information which is only related to this country</p>

      <p>So 'de' means all german speaking people or countries.<br />
      'de_AT' means only the austrian people which speak german.</p>

      <p>Also 'it_AT' could be possible when there are italic speaking ethnic groups in this region.<br />
      As 'it_AT' could not be found in LDML the next recursion is used.<br />
      'it_AT' degrades to 'it' only.</p>

      <p>This is the same for translation and also for reading the LDML.</p>

      <p>'it' is also an precise definition of an locale. But this locale is region-unaware.</p>
      <ul>
      <li>Function names<br />
      I think i've changed this even befor your comments.<br />
      But I changed them a little bit more, so the purpose of a function should be clear now.</li>
      </ul>

      <blockquote>
      <p>Parsing, normalization, conversion, and formatting function names<br />
      could benefit from sharing common looking names with other locale-related<br />
      classes.</p></blockquote>
      <p>Take a look at Zend_Locale_Format.<br />
      All related function are avaiable in this class.</p>
      <blockquote>
      <p>Methods should not combine input parsing, normalization, and output<br />
      formatting all in one step. Instead, parsing and normalization could be<br />
      encapsulated by a constructor. Then a "formatTo($someLocale)" can be<br />
      applied to the instance.</p></blockquote>
      <p>Parsing and Normalization has to be done in one step.<br />
      Formatting the output is another step.</p>

      <p>Input Parsing and Normalization have t be done by construction time or<br />
      function call.</p>

      <p>Output formatting is only done when output is needed (toString, convert,...)</p>
      <blockquote>
      <p>Questions for Proposal Author/Team<br />
      Zend_Locale_Format needs clarification, including a list of possible<br />
      values for $input. For example, does Zend_Locale_Format::getFormat()<br />
      provide generic number formatting based on locale?</p></blockquote>
      <p>Yes it provides this rules based on locale.</p>

      <p>The following standard formats could be returned locale based from the function getFormat($type):</p>

      <p>Date(Calendar, Format) // Formating rules for a given date type</p>
      <ul class="alternate">
      <li>Calendar could be default, gregorian, buddhist, chinese, hebrew, islamic, islamic-civil, japanese, persian</li>
      <li>Format could be default, full, long, medium, short</li>
      </ul>

      <p>Time(Calendar, Format) // Formatting rules for a given time type</p>
      <ul class="alternate">
      <li>Calendar could be default, gregorian, buddhist, chinese, hebrew, islamic, islamic-civil, japanese, persian</li>
      <li>Format could be default, full, long, medium, short</li>
      </ul>

      <p>DateTime(Calendar, Format) // Formatting rules for a given calendar type</p>
      <ul class="alternate">
      <li>Calendar could be default, gregorian, buddhist, chinese, hebrew, islamic, islamic-civil, japanese, persian</li>
      <li>Format could be default, full, long, medium, short</li>
      </ul>

      <p>Timezone // Formatting rules for a timezone</p>

      <p>Decimal // Formatting rules for decimal values (-123,456.789)<br />
      Scientific // Formatting rules for scientific values (-12.345e-67)<br />
      Percentage // Formatting rules for percentage values (1432%)</p>

      <p>Currency // Formatting rules for currency values</p>
      <blockquote>
      <p>Is there any portion of LDML that Locale does not need to model in order<br />
      to provide our lightweight implementation of "locale"?</p></blockquote>
      <p>LDML is only avaiable through Zend_Locale_Format and Zend_Locale_Data.<br />
      Data is the ICU parser which gives us all wanted information.<br />
      Format is the parsing and normalization class which makes use of Zend_Locale_Data.</p>

      <p>In LDML there are several informations which are very usefull.<br />
      f.e. a localized list of all languages, regions, monthnames and much more.</p>

      <p>Things which will not be present for now are</p>
      <ul class="alternate">
      <li>Collation</li>
      <li>Segment</li>
      <li>Transform (this means automatic transform with LDML and has nothing to do with translation of Zend_Locale)</li>
      </ul>

      <p>They could be included in future.</p>

      <p>----I hope all things are now clear. <ac:emoticon ac:name="wink" /></p>

      1. Aug 01, 2006

        <h3>Filtering</h3>
        <p>I like your approach to integrating Zend_Locale into Zend_Filter_Input, partly because it reduces the total amount of code a developer must write to use these classes compared to alternatives.</p>

        <h3>private static</h3>

        <p>If static class variables are private, then how can anyone extend or modify the class? If everyone is absolutely certain the class will never be extended by a developer in a meaningful way, then private static might be ok. If a developer can add a method that "breaks" the parent class by manipulating a protected static variable, that is not sufficient reason to prevent all developers from subclassing the parent class.</p>

        <h3>Compatibility with I18N PHP</h3>

        <blockquote><p>"How could a 'compatible API' be done when we dont know how the I18N object will look like in PHP6"</p></blockquote>

        <p>lol .. so true! We do the best we can in the time we have, don't worry about it too much, as this is not really a strict requirement, but more of a guideline (compatibility with PHP, as it evolves).</p>

        <h3>Automatic Locale Recognition</h3>

        <p>Automatic locale recognition can take more forms than just using information from HTTP headers. HTTP_ACCEPT_LANGUAGE sometimes contains partial informations, like only "en". Similarly, we might only know the region or country. Thus, in some circumstances a complete, full specification of a locale is not known. I use the term "auto-completing" for the process of algorithmically using known facts to determine the real locale. If you believe the total amount of code for detecting locales from environment variables, HTTP_ACCEPT_LANGUAGE, etc. would be small, then I don't think anyone will object to including it in the Zend_Locale class. We want to be careful that a simple "hello world" program doesn't start using classes with lots of unnecessary locale code. However, if we ever begin implementing other forms of auto-completion (e.g. deriving a locale from a postal address, phone number, etc.), I would be concerned about possible code bloat in Zend_Locale.</p>

        <h3>$locale means .. ?</h3>

        <blockquote><p>"The word 'locale' is overloaded too much. Function names need to be ..."</p></blockquote>

        <p>Yes, while our comments were assembled and reviewed the proposal was updated and function names improved, so our comments about function names were addressed before the comments were posted. I searched through the current usage of the word 'locale' in the Zend_Locale proposal, and only one key ambiguity concerns me. In the code and examples, $locale sometimes refers to an instance of Zend_Locale, and other times it refers to a string. Is there something we could do to reduce possible confusion between locale objects and locale strings?</p>

        <h3>LDML Bloat</h3>

        <p>In examining the XML files, I see numerous files containing mostly XML tag names, and very little data (e.g. en_US.xml - even has bloat in the form of comments). I also see other files containing lots of data that very few will ever need (e.g. en.xml, ja.xml). I see that Locale/Data/ requires 8.6 MB of disk space in Cygwin / NTFS. However, there are only 3,615,863 bytes used for all of these files, with the majority comprising XML "overhead".</p>

        <p>Is it possible or reasonable to consider alternative ways of storing and accessing this information, in order to avoid performance issues for those using only subsets of this data?<br />
        Hint: This might be a version 2 objective.</p>

        <h3>Text Translation</h3>

        <p>Zend_Locale still includes translation functionality. There have been concerns that this would result in unnecessary overhead for applications not using any translation features, but needing other functions of the locale classes, such as date-related functions. Given the separation of the other classes listed in the Zend_Locale proposal, perhaps these concerns are unfounded. However, without more information, it is difficult to determine the impact of supporting translation directly in the Zend_Locale API.</p>

        <h3>Help</h3>

        <p>I also highly recommend recruiting help from amongst the ZF community of CLA signees. There is much to do here. The early alpha and beta testers of these incubator components could be a great resource not only for helping with testing and coding, but also in figuring out good unit tests (at least 80% coverage prior to review for inclusion to core), helping with the documentation, and practical use case examples.</p>

        <h3>P.S.</h3>

        <p>Some of our previous comments apply to previous versions of the proposal. Nevertheless, I believe the comments are still relevant, as they establish and clarify requirements.</p>

  2. Aug 02, 2006

    <p>Text Translation<br />
    ---------------------<br />
    Thomas, things starts to looks really great, thanks !!!</p>

    <p>Just one more think <ac:emoticon ac:name="smile" /> ... I agree with Gavin you should move out the Translation part from the Zend_Locale class. I think Zend_Locale, as his name is suggesting it, should only managing locales and support other local sensitive component to make localization possible. Then Zend_Translation will deal with translation string. Each one is doing what's they are suppose to do and naming thing this way help to understand what the code is doing. <br />
    My $0.02</p>