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

But one thing:

Is there any portion of LDML that Locale does not need to model in order
to provide our lightweight implementation of "locale"?

To make this a little bit clearer:
Locale in the meaning of translation does not make use of LDML.
LDML is only needed for all additional locale aware classes like
"How to parse numbers, how to format calendars, get a list of all countries" and much more.

So Zend_Locale itself has until now no use of Zend_Locale_Data as Zend_Locale only has to
do translational issues.

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

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

All other questions will be answered later.

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

Here I must seperate two tasks which are known as "locale".

TRANSLATION:
Here we have to

• Know the translation-source
• detect locales automatically
• do the translation

LOCALE INFORMATION MANAGEMENT:
Here we have to do several things locale aware. This implements

• Formatting
• Parsing
• Describing

I've seperated these tasks.
Translation and all related issues are done by Zend_Locale.

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

Therefor when for example implementing Zend_Date object, this could be done independent from Zend_Locale,
and therefor it's faster.
Zend_Locale_Format is intendent to be used by other Classes which need to be locale aware.

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

Here we have to differ between

• a class which needs translation : Here the class has to implement Zend_Locale and make a connection to the source.
• a class which only needs the locale data : Here the class has only to implement Zend_Locale_Format.

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

All locale aware classes will first call this function when NO standard locale was found.
The standard locale will be stored by calling Zend_Cache for

The locale should be optional for constructors, not required.

Locale's are always OPTIONAL.
When no locale was given, all locale aware classes will use the default locale.

We need some sample use cases showing how Zend_Locale and related
classes will be used with Zend_Input_Filter.

I did'nt use Zend_Filter_Input until now.
I'm not sure what you want me here to show...

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

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

How Zend_Filter_Input can use Zend_Locale ???
There are 2 options:
1.) Zend_Filter_Input could use Zend_Locale_Format to know if a string is locale-aware and would get a
locale-unaware string.

So Zend_Filter_Input's function getInt would first have to call Zend_Locale_Format and could then do it's
job with the locale-unaware returned value.

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

2.) Zend_Filter_Input could be locale aware by knowing how to format.
There are 2 ways.
2.1) Zend_Locale_Format::getFormat(Zend_Locale::NUMBERFORMAT) would f.e. return '#,##0.0#'.
Zend_Locale_Filter then would have to parse as defined in the format.

No good way in my opinion, as Zend_Locale_Format::getInteger f.e. is already doing this job locale aware.

2.2) Zend_Locale_Data::getContent($locale,'numbersymbols') could return the
locale aware symbols for number formatting.
Then Zend_Filter_Input would have to parse the input checking the right symbols.

Also no good way in my opinion as Zend_Locale_Format::getInteger is doning this job already.

3.) Zend_Filter_Input could stay locale independent and the user would have to do the job.

This could be done, but why should the user be aware if his input string is locale aware or not.
Better to do this job automatically, so the user would not have to think of it.

For Dates it could look loke this

So my opinion is that Zend_Filter_Input should be locale aware, and it should have to use
Zend_Locale_Format.

So the user only has to do

all other things would be done internally.

This would be the best way in my opinion.

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

Zend_Date makes only use of Zend_Locale_Format and Zend_Locale_Data.
Both of these are static. Zend_Locale itself would not be used.
See above for LOCALE INFORMATION MANAGEMENT.

Instances should be serializable.

Added in the proposal

The private static "class" variables should become protected instead of
private.

In Zend_Locale_Data the internal variables were made private because
they store the information which is found in LDML and what locales have
been searched until now.

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

What is the intention for making them protected ??

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

Zend_Locale is this seperate class.
LDML is only accessable through Zend_Locale_Format/Data.

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

Caching has to be done in the source backends, as the base class does'nt know when a source is no longer avaiable.

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

Agreed.
Only problem for now...
How could a "compatible API" be done when we dont know how the I18N object will look like in PHP6

I've looked in several other languages and took out the most used things. This should de the job best

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

I think that creating a own class for only one (1) function is a little bit excessive option.
There are only 2 ways for detecting locales.

• Http-Header - ACCEPTED_LANGUAGES content
• Environment Variables

What do you mean with "autocompleating" ?

When Requesting "de_TG", automatically de and root will be used.
Locale Information and also translation is ALWAYS recursive.
When you mean this with autocompletion we would break standard behaivor.
Keep in mind that there must always be an output, even when the requested string cannot be translated.

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

I think this was already be done when your comments were written.

I only found getLocale and setLocale...
Have you referred to an older proposal ??

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

Agreed.
But keep in mind that smaller project often use database for simpler access,
gettext is mostly used for middle sized projects, and TMX in realy big
project. Exceptions approve this rule

If Zend_Locale::setLocale() is actually a getter-type function that
"returns the actual set default Locale", then a name like
"getDefaultLocaleName" is more descriptive, but terribly long. Do you
have suggestions for a naming convention to clearly distinguish between:

getDefault() will return the default locale.
But you can also select to take the default locale only from
the browser or instead use the environment. getEnv()/getBrowser()

locale objects
locale names/strings in the form of <country_code>_<lang_code> (is
that sufficient to unambiguously specify a precise "locale"?)
locales, the array of supported/available locales
The comments and names for setLocale(), getLocale(), and getLocales()
are confusing (possibly accidentally swapped?). Let us use more
descriptive names, like getBrowserDefaultLocale(), getLocalString(),
getDefaultLocale(), and getAllLocales() .. or something similar. Please
clarify the names and purpose of these functions, and give example use
cases.

To clarify:

• Locale Names
  When no locale name is given the "standard locale" has to be used.
  This is normally the root. But it could also be an automatically found
  locale from browser or environment.

A locale is always represented by
LANGUAGE and REGION

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

So 'de' means all german speaking people or countries.
'de_AT' means only the austrian people which speak german.

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

This is the same for translation and also for reading the LDML.

'it' is also an precise definition of an locale. But this locale is region-unaware.

• Function names
  I think i've changed this even befor your comments.
  But I changed them a little bit more, so the purpose of a function should be clear now.

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

Take a look at Zend_Locale_Format.
All related function are avaiable in this class.

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

Parsing and Normalization has to be done in one step.
Formatting the output is another step.

Input Parsing and Normalization have t be done by construction time or
function call.

Output formatting is only done when output is needed (toString, convert,...)

Questions for Proposal Author/Team
Zend_Locale_Format needs clarification, including a list of possible
values for $input. For example, does Zend_Locale_Format::getFormat()
provide generic number formatting based on locale?

Yes it provides this rules based on locale.

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

Date(Calendar, Format) // Formating rules for a given date type

• Calendar could be default, gregorian, buddhist, chinese, hebrew, islamic, islamic-civil, japanese, persian
• Format could be default, full, long, medium, short

Time(Calendar, Format) // Formatting rules for a given time type

• Calendar could be default, gregorian, buddhist, chinese, hebrew, islamic, islamic-civil, japanese, persian
• Format could be default, full, long, medium, short

DateTime(Calendar, Format) // Formatting rules for a given calendar type

• Calendar could be default, gregorian, buddhist, chinese, hebrew, islamic, islamic-civil, japanese, persian
• Format could be default, full, long, medium, short

Timezone // Formatting rules for a timezone

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

Currency // Formatting rules for currency values

Is there any portion of LDML that Locale does not need to model in order
to provide our lightweight implementation of "locale"?

LDML is only avaiable through Zend_Locale_Format and Zend_Locale_Data.
Data is the ICU parser which gives us all wanted information.
Format is the parsing and normalization class which makes use of Zend_Locale_Data.

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

Things which will not be present for now are

• Collation
• Segment
• Transform (this means automatic transform with LDML and has nothing to do with translation of Zend_Locale)

They could be included in future.

----I hope all things are now clear.