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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
