Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36796
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain yahoo-inc.com from 216.145.54.172 cause and error)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns;
	h=received:x-mimeole:content-class:mime-version:
	content-type:content-transfer-encoding:subject:date:message-id:
	in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic:
	thread-index:references:from:to:return-path:x-originalarrivaltime;
	b=dh+NS4o41pDnxWnmlLw8S2Bnamzeruuddglo+QrhFhI+lGhuBjopedDzg3Y5lL1T
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 4 Apr 2008 01:50:00 -0700
Message-ID: <012AB2B223CB3F4BB846962876F472170121CC09@SNV-EXVS08.ds.corp.yahoo.com>
In-Reply-To: <47F5DC3D.6090302@lsces.co.uk>
Thread-Topic: [PHP-DEV] intl naming
Thread-Index: AciWJ+JjQ1MZMMp6S4C44BTDp1hZBgAAhCyQ
References: <47F463F0.4030407@zend.com> <47F47360.8040606@lsces.co.uk> <47F560E4.7060609@zend.com> <47F5DC3D.6090302@lsces.co.uk>
To: "Lester Caine" <lester@lsces.co.uk>,
        "PHP internals" <internals@lists.php.net>
Subject: RE: [PHP-DEV] intl naming
From: tex@yahoo-inc.com ("Tex Texin")

Lester asks:

THAT I agree with - BUT WHAT IS STOPPING PHP6 being the solution. I =
can't see any reason that time is being wasted on yet another PHP5.X =
when that same effort could be directed to getting at least a stable =
beta of PHP6 out the door?

Tex replies:

When we started this project nearly a year ago (earlier when I started =
lobbying Yahoo for resources for it) I naively imagined the project =
would be a few months. As PHP 6 was more than a year away and I =
suspected it would drift further into the future, it seemed like a good =
investment. We also considered that we wanted a solution that could be =
adopted immediately. PHP 6 being a major release would require more =
testing before deployment and likely also to have a few bugs. (No =
disrespect to the developers. It's a rule of thumb.)

The extension is near done, requires much less testing and as it is =
compatible with 5.2 is going to be very easy for people to test and =
deploy.
The tradeoff made sense.

When it comes down to it, we spent a few man-months and have a 5.2 =
solution and can deploy in 2008.=20
The same few manmonths on 6 would not give a deployed solution in 2008, =
if for no other reason then the effort it will take to test a major =
release, but also because (I expected) php 6 would not be ready in 2008.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Lester asks also:

MessageFormatter simply duplicates and complicates a simple display of a =
message with embedded variables. If I ask for to output a string with =
variables in using a different locale then the DATE variables should =
simple display the correct format for that locale. I should not have to =
go through all the code and re-write the variables in some complex =
format so another package can then do the same job that the core system =
IS ALREADY DOING?

Collator is already required to process strtoupper and strtolower, so =
why should we need to decide if we can use them or we need to create a =
new object and get that to do the job.

Tex replies:

I am not clear on what you are asking. It is expected that the string =
with embedded values is not substituted by a developer but by =
translators.
So for example, you could store the english string in a database table =
with a field for language and a field for the string and another field =
to identify the string.
A program could choose to retrieve a string by id and language and the =
string would be used with the formatter and program variables, to =
display the values correctly formatted for the locale in an =
appropriately translated string.

With respect to dates, there are simple and more complex forms. You can =
use the simple format. Also, note that even in one locale, you may want =
to influnce whether the date is a verbose long format or a shorter form. =
So the formatter offers options. The doc makes it seem very complex, but =
in practice it shouldn't be bad.