RE: [PHP-DEV] intl naming

-----Original Message----- From: Derick Rethans [mailto:derick@php.net] 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