-----Original Message----- From: Derick Rethans [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2008 4:37 AM To: Tex Texin Cc: Lester Caine; PHP internals Subject: RE: [PHP-DEV] intl naming
Tex, please please quote properly, it is really hard to follow the conversion down below here. http://www.netmeister.org/news/learn2quote.html has some good information on this topic. regards, Derick Derick, Please state what you object to. I looked at the article. I attributed the text, I responded inline, I clipped the text to the piece I was responding to, blank line in between. I could have used a > instead of a colon in the attribution... And perhaps a signal that I clipped. Is that what bothers you? The questions and answers look straightforward to me. On Fri, 4 Apr 2008, Tex Texin wrote: > 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. > 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. > > ============== > 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. > > -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
