On November 25, 2002 09:52 pm, John Coggeshall wrote: > 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...
I am definitely -1 for this idea. XML is a buzzword, it is good in some cases not so good in others, definitely not a one size fits all solution. In PHP's case it would add decency on an XML parser, make life of developers adding, modifying, removing error messages difficult and just like the documentation will seriously lag behind the primary (English) 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. That is just one complaint. I personally have a BIG issue with this due to performance considerations. IMO PHP already has more then enough overhead just adding more to the pile will drive some users away. RAD (Rapid Application Development) gets you only so far eventually for large scale applications speed becomes essential and if Perl, Python, C can offer it then those languages will be picked over PHP. > 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.. What will happen to localized error message when the charset of the page they are displayed on does not support the charset required for proper rendering of the text? Most likely gibberish. > 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) > If you have a constant for every error would that not mean you will need to register hundreds if not thousands of constants at run time at an enormous CPU & memory cost? > 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. > How do you figure that it would be just as easy to maintain? Right now adding an error is just a matter of writing the English text inside the C file I am working on. By having messages localized they'll need to be stored else where XML, gettext database and so on... meaning that there is already more for the developer to do. Ilia -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
