Wow.. Alrighty... I've read through all of this stuff -- everyone seems to have quite a strong opinion on this one :) Since I kinda brought it up with Maxim, let me provide a concept of implementation and defend it... I'd of course love to hear what you guys have to say...
I am completely +1 to the concept of taking error codes out of the PHP core and replacing them with an XML document, period. I say this regardless of language considerations -- I just think for everyone involved having a XML document which controls the errors that are generated is just a good idea. As I layed out before, I'd like to replace the current error system with a error-code based system (see my earlier thread for information on what I was thinking on this)... Now, on to the question of localization... The biggest complaint that people seem to have regarding localization is that the QA team and such would suddenly find themselves trying to dechipher french in order to track down a bug... It's funny, you guys don't want errors in a forigen language because they are too difficult to understand yet you don't mind forcing the developers who don't speak english to do the same? This is exactly my point. I feel that, with a proper implementation, PHP can be globalized WITHOUT making lives difficult for the development team. What I propose is based off of my first proposal of Error codes based on Maxim's suggestions. Basically, I'd like to see errors broken down into three separate code constants: TYPE, MODULE, AND ERROR... Where TYPE would be E_ERROR, etc, MODULE would be the extension causing the error (M_PHP_CORE, etc) and ERROR would be the actual error that occurred (i.e. E_PHP_CORE_PARSE). Notice that I am using "descriptive" names for the error constants. This is because I suggest that although each individual error message is localized to german, french, etc, every error message displays this "descriptive" errorcode... Ie.. Error (module: E_ERROR, M_PHP_CORE): A parse error occurred at line 34 of file foobar.php (E_PHP_CORE_PARSE) Störung (Modul: E_ERROR, M_PHP_CORE): Eine Satzgliederung Störung trat an Linie 34 der Akte foobar.php auf (E_PHP_CORE_PARSE) Erreur (modules: E_ERROR, M_PHP_CORE): A erreur parse occurred AT ligne 34 of fichier foobar.php (E_PHP_CORE_PARSE) This would be simple to implement, and no more of a hassle to maintain that what already exists however still provides enough information to the development/QA teams (we know the type, the module, and the actual error which occurred) yet still allows the developers who aren't english-speaking to still have some clue as to what the heck happened with their script. Finally, if I may make a suggestion... I really don't think there is a lot of weight in the argument that "I'd be fired if blah blah" in these discussions... I'm glad that you never have to work with forigeners who don't speak english (or really bad english), or that your code is always parse-error free... It doesn't mean that things like this have some sort of negative impact on the language and, although I get the feeling that many of my fellow developers on this list could really give to licks if PHP is a language that is enterprise-ready I wish they would acknlowedge that a lot of these things are exactly why PHP is still a hard sell to corporations. John >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]] On Behalf Of Maxim Maletsky >Sent: Monday, November 25, 2002 9:22 PM >To: [EMAIL PROTECTED] >Cc: 'PHP Developers Mailing List' >Subject: Re: [PHP-DEV] [PATCH] Redirect on Error > > > >On Mon, 25 Nov 2002 21:11:37 -0500 "Ilia A." <[EMAIL PROTECTED]> wrote: > >> 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? > >Of course it will. But, this is an option, so one can localize >them if wishes. Like in cases when you want English while your >co-workers use another language and you cannot change the main >php settings > >> > > > 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? > >XML is what I think would be the best for the whole thing of >managing errors. It could be integrated into the docs, >parallelly translated into multiple language, adding extra >flexibility and features growth. This can be also useful for >modifying errors for users themselves if they wish to. > >The rest I would not plan to change. > >-- >Maxim Maletsky >[EMAIL PROTECTED] > > > >-- >PHP Development Mailing List <http://www.php.net/> >To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
