On November 25, 2002 08:53 pm, Maxim Maletsky wrote: > Well, in this case you would just add locales like you do with dates, for > example. >
Meaning that you will be applying the locale logic in real time? Have you considered what kind of performance degradation this will entail? > > > And you, without speaking Italian, will be just as helpful to him. > > > > Wrong, I've read the first 5 words, the lexical parser in my head failed > > to interpret the message and accordingly I've moved on. Maybe someone > > will be more patient, but that is unlikely. Eventually someone may indeed > > look and address the report, but that may take weeks and possibly months > > for a problem I may or some other person could've addressed right away > > had it been in English. Bottom line is that people who are not getting > > payed to do support will apply minimum effort to understand the user, > > remember most open source developers are volunteers, making their life > > difficult certainly is not in the user's best interest. > > Again, having error codes gives and solves more than adds problems. [snip] > I don't agree with you, Ilia. Errors are string, even a part of the > documentation. They need to be also translated whether it does or does > not make a developer modifying an XML file. There can be several ways > accomplishing it. > > I am more that just +1 for globalization or run time reporting. I have nothing against error codes, that is a good idea. I just have a problem with XML errors and i18n in error messages generated by PHP. When do we draw the line, how about function prototypes inside the C source code? Should those be translated as well, it would make developing PHP by example easier, no? Ilia -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
