RE: [PHP-DEV] Error Codes, Langs, etc
At 02:27 27/11/2002, Stig S. Bakken wrote: Let's try being realistic, and focus on the quick wins first, such as good error codes. Go Stig. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
On Mon, 25 Nov 2002, 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. I'm a big -1 on introducing XML bloat for error codes/descriptions 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. But those _users_ expect us to support PHP for free. I think it's totally different. 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. But for all I know nobody on the QA team will do any effort to look at it, but just press the in-english quickfix; and I can assure you that that will be added right away IF this stupid localization idea is implemented. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Error Codes, Langs, etc
On Tue, 26 Nov 2002, John Coggeshall wrote: Maxim (and anyone else who is interested) Shall we try to get a patch for this working then? I'm thinking perhaps starting off with an XML file defining the error messages, which is converted to a cdb for actual use. Waste of time Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
I've seen a big poster in my local Fullbright foundation represantive. It says something like : One of every four people on the earth knows some English. Andrey -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Error Codes, Langs, etc
At 10:14 26.11.2002, Derick Rethans wrote: On Tue, 26 Nov 2002, John Coggeshall wrote: Maxim (and anyone else who is interested) Shall we try to get a patch for this working then? I'm thinking perhaps starting off with an XML file defining the error messages, which is converted to a cdb for actual use. Waste of time Derick Hi Jon, maybe Derick is right but here's for the error codes themselves: You could try to add only names or numbers as error codes. The first you must change is all php_error() calls to php_error_docref() calls. After that you will have to add those message codes and remeber no double entry. php_error_docref now uses internal php_error_cb(). Here you will have to find a solution for displaying your codes. Problems: Some php_error() calls are called from functions which do not have a TSRMLS_C(C) parameter. Here you must add TSRMLS_FETCH(). When all this is working you can try and work on i18n...but that'l be far away. Or someone else has a faster solution marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
John Coggeshall [EMAIL PROTECTED] wrote... : 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 code is a bit of an integer code, not constants. I wouldn't say its a bad idea, but might be difficult to start. +0.5 for constants. 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. I agree on it, especially, when you use DBs and other extension that have their own error reportings. At first, it would seem like how do you translate those? but in reality it would create a better understanding of the error. -- Maxim Maletsky [EMAIL PROTECTED] 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.
Re: [PHP-DEV] Error Codes, Langs, etc
Well, yes, if it is not XML it can still work. A thought here is - to connect built-in errors to the documentation, which is where XML would help. -- Maxim Maletsky [EMAIL PROTECTED] Shane Caraveo [EMAIL PROTECTED] 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 had wanted to avoid this whole thread, but decided to read this one message, and ouch. While I'm all for internationalization in general, I'm realy not all for using xml wherever possible just because it can be. There are existing techniques and libraries designed for this, find one and use it. Shane -- 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
Re: [PHP-DEV] Error Codes, Langs, etc
Again, XML was my throw to this thread. I intuitively thought of XML because it would help connecting the PHP error reporting to the official documentaion. Don't you think it would be helpful? Of course there are work-arounds for that too. -- Maxim Maletsky [EMAIL PROTECTED] John Coggeshall [EMAIL PROTECTED] wrote... : I had wanted to avoid this whole thread, but decided to read this one message, and ouch. While I'm all for internationalization in general, I'm realy not all for using xml wherever possible just because it can be. There are existing techniques and libraries designed for this, find one and use it. Well, I'm not really concerned with the method be it XML, whatever... It's the concept that holds the real value IMHO. John -- 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
Re: [PHP-DEV] Error Codes, Langs, etc
I am on. Here, without a patch sample, nothing will roll. Anyone joins? -- Maxim Maletsky [EMAIL PROTECTED] John Coggeshall [EMAIL PROTECTED] wrote... : Maxim (and anyone else who is interested) Shall we try to get a patch for this working then? I'm thinking perhaps starting off with an XML file defining the error messages, which is converted to a cdb for actual use. Anyone else game? John -Original Message- From: Sascha Schumann [mailto:[EMAIL PROTECTED]] Sent: Monday, November 25, 2002 11:29 PM To: Shane Caraveo Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Maxim Maletsky'; 'PHP Developers Mailing List' Subject: Re: [PHP-DEV] Error Codes, Langs, etc cats or gettext comes to mind. Neither are usable, though, because PHP would need to support multiple concurrent message catalogues on a per-thread base. gettext/catgets associate exactly one language with each process through the use of environment variables, so that they cannot be used in a multi-threaded server. A mechanism based on the bundled cdb, for example, would be superior in terms of speed, thread-safeness, and portability. - Sascha -- 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
Re: [PHP-DEV] Error Codes, Langs, etc
Andrey Hristov [EMAIL PROTECTED] wrote... : I've seen a big poster in my local Fullbright foundation represantive. It says something like : One of every four people on the earth knows some English. Why does Billy localize M$ windows then? And, most importantly, what would he sell without doing it? Remember, his users know basic IT english too. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
I've seen a big poster in my local Fullbright foundation represantive. It says something like : One of every four people on the earth knows some English. Why does Billy localize M$ windows then? And, most importantly, what would he sell without doing it? Remember, his users know basic IT english too. Billy tried localizing programming languages as well. Remember Excel 95? It ended up in complete disaster and was removed in the next office version. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
[EMAIL PROTECTED] (Marcus Börger) wrote... : At 10:14 26.11.2002, Derick Rethans wrote: On Tue, 26 Nov 2002, John Coggeshall wrote: Maxim (and anyone else who is interested) Shall we try to get a patch for this working then? I'm thinking perhaps starting off with an XML file defining the error messages, which is converted to a cdb for actual use. Waste of time Derick Hi Jon, maybe Derick is right but here's for the error codes themselves: You could try to add only names or numbers as error codes. The first you must change is all php_error() calls to php_error_docref() calls. After that you will have to add those message codes and remeber no double entry. php_error_docref now uses internal php_error_cb(). Here you will have to find a solution for displaying your codes. Problems: Some php_error() calls are called from functions which do not have a TSRMLS_C(C) parameter. Here you must add TSRMLS_FETCH(). When all this is working you can try and work on i18n...but that'l be far away. Or someone else has a faster solution Something like that. We can do lots of tests first for cb etc. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
I've seen a big poster in my local Fullbright foundation represantive. It says something like : One of every four people on the earth knows some English. Why does Billy localize M$ windows then? And, most importantly, what would he sell without doing it? Remember, his users know basic IT english too. MS made localization of WinXP and Office(wo documentation translated AFAIK). The .bg goverment spent $13mil for 30,000 licenses over 3 years. This is why MS they translated the GUI. They claimed that they spent several millions of US $ to do that. However a 16 year old boy here made a translation pack (translates about 80% of win98) without the need of several millions. The reason for buying these 30,000 licenses was that XP is on bulgarian and the workers in the goverment will work better. The question is how these workers worked before. Maybe they used abacuses. When there is a need people _learn_. The process is maybe slow but..that's the way. Anyway. Let's return on the localization of php. I am not on php-general ever more but when I was there were plenty of people that like to ask on the forum instead of reading the documentation which is quite clear. After that localization the same people will start to ask questions with errors in language other than english. When this time comes many people will stop to help because they don't know french,italian, spanish, chinese, etc. Andrey -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
Billy tried localizing programming languages as well. Remember Excel 95? It ended up in complete disaster and was removed in the next office version. The language won't chance. Stop the FUD. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
On Tue, 26 Nov 2002, Sascha Schumann wrote: Billy tried localizing programming languages as well. Remember Excel 95? It ended up in complete disaster and was removed in the next office version. The language won't chance. Stop the FUD. This is not FUD. He brought up the issue of M$ practises. And I didn't hear you answer the question about why is parse error more difficult to understand than register_shutdown_function? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
This is not FUD. He brought up the issue of M$ practises. And I didn't hear you answer the question about why is parse error more difficult to understand than register_shutdown_function? You need to learn a bit about writing good compilers. It is easy to write a compiler; it is hard to write a compiler with good diagnostic output. Yes, parse error is never a good error message, regardless of the language it is presented in. Fortunately, most error messages in PHP are easier to digest and actually provide some clue. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
On Tue, 26 Nov 2002, Sascha Schumann wrote: This is not FUD. He brought up the issue of M$ practises. And I didn't hear you answer the question about why is parse error more difficult to understand than register_shutdown_function? You need to learn a bit about writing good compilers. It is easy to write a compiler; it is hard to write a compiler with good diagnostic output. You missed my point: you cannot write PHP code without using English. Function names, reserved words, etc. are all in English. So does this mean that non-English speaking people are unable to write PHP code? Of course not. With a good manual this is perfectly possible. IMHO error messages are no different. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
On Tue, 2002-11-26 at 04:21, Shane Caraveo 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 had wanted to avoid this whole thread, but decided to read this one message, and ouch. While I'm all for internationalization in general, I'm realy not all for using xml wherever possible just because it can be. There are existing techniques and libraries designed for this, find one and use it. Amen to that. XML is not an altar where we go to sacrifice our CPU cycles every full moon. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Error Codes, Langs, etc
On Tue, 2002-11-26 at 05:04, John Coggeshall wrote: I had wanted to avoid this whole thread, but decided to read this one message, and ouch. While I'm all for internationalization in general, I'm realy not all for using xml wherever possible just because it can be. There are existing techniques and libraries designed for this, find one and use it. Well, I'm not really concerned with the method be it XML, whatever... It's the concept that holds the real value IMHO. IMO the concept has no real value for PHP. Today, PHP's error messages are totally useless for machine consumption (I don't consider using regexps to figure out whether fopen failed due to a read-only filesystem or full disk as well-suited for machine consumption). This is the first problem we should focus on, and even introducing simple error codes is going to increase the maintenance. Separating error messages into XML files or whatnot adds three times as much maintenance, for what benefit? When it comes to error message translations, we should either do it right and all the way, or not at all. I simply don't think we are up to doing it right. Documentation translations are constantly lagging behind, and I have no reason to believe that error message translations will lag behind any less. If someone wants help on php-general and their error message is in Urdu, then too bad. Companies like IBM and Oracle has solved this problem by introducing more complex error codes (such as 0123-456 File not found), which is an absolute must if one does go in this direction, or the poor Urdu-speaking guy won't be able to find people who can help him. But the task of maintaining such a registry, and avoiding that it degenerates into a chaotic mess, requires an amount of collective self-discipline that I simply don't think a big project like PHP can muster. Let's try being realistic, and focus on the quick wins first, such as good error codes. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
On 27 Nov 2002 01:27:18 +0100 Stig S. Bakken [EMAIL PROTECTED] wrote: If someone wants help on php-general and their error message is in Urdu, then too bad. Companies like IBM and Oracle has solved this problem by introducing more complex error codes (such as 0123-456 File not found), which is an absolute must if one does go in this direction, or the poor Urdu-speaking guy won't be able to find people who can help him. Right! I was mentioning that - no translation or any kind of other flexibility on errors is possible if there is no solid error code logic accomplished. These would help really a lot. Even if messges will never be localized, error codes will still be helpful a whole bunch. But the task of maintaining such a registry, and avoiding that it degenerates into a chaotic mess, requires an amount of collective self-discipline that I simply don't think a big project like PHP can muster. I doubt it adds all that much of complexity as many think. of course, it requires going through them all over and then, when coding, looking up for the code conventions. But, IMO, this all is not such a disaster to do. It can help more. Let's try being realistic, and focus on the quick wins first, such as good error codes. Amen! That is where i was leading and got misleading :) --- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
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 had wanted to avoid this whole thread, but decided to read this one message, and ouch. While I'm all for internationalization in general, I'm realy not all for using xml wherever possible just because it can be. There are existing techniques and libraries designed for this, find one and use it. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
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
Re: [PHP-DEV] Error Codes, Langs, etc
On Mon, 25 Nov 2002, Shane Caraveo 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 had wanted to avoid this whole thread, but decided to read this one message, and ouch. While I'm all for internationalization in general, I'm realy not all for using xml wherever possible just because it can be. There are existing techniques and libraries designed for this, find one and use it. I concur. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Error Codes, Langs, etc
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. As I mentioned via Shane's comments... XML isn't really the crux of the matter here, I'm more interested in the concept than implementation. I'm interested in hearing what libraries and techniques Shane has in mind. 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. I understand your issue, and If the system can't be implemented without a huge performance hit then we're in agreement. Perhaps the issue here is that I think the performance hit that could be taken can be limited almost completely to the occurance of an error, rather than during normal operations. 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. Well, obviously if you are writing a French web site it only makes sense that your error messages would be in French. Why the heck would you write a french site with German error messages? 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? Absolutely not. The error constant / values themselves could be #defined, requiring absoultely no CPU/memory cost to speak of. Regarding the back-reference, although it could be implemented in memory as a lookup table this could be stored in a file which is only referenced in the event of an error. 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. Well, it'd be easier to maintain because you wouldn't have to know a darn thing about C, or have to dig through thousands of lines of code in order to find this php_error() line that contains the error message. Placing the error information is a hair more difficult for the developer, who has to actually open up a separate file or two to add their constants But that's hardly a serious issue IMHO. John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Error Codes, Langs, etc
I had wanted to avoid this whole thread, but decided to read this one message, and ouch. While I'm all for internationalization in general, I'm realy not all for using xml wherever possible just because it can be. There are existing techniques and libraries designed for this, find one and use it. Well, I'm not really concerned with the method be it XML, whatever... It's the concept that holds the real value IMHO. John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
John Coggeshall wrote: 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. As I mentioned via Shane's comments... XML isn't really the crux of the matter here, I'm more interested in the concept than implementation. I'm interested in hearing what libraries and techniques Shane has in mind. cats or gettext comes to mind. man catgets google search: internationalization cats gettext seems to be ported more (it's on osx by default, cats isn't). Some defines can be created so that php does not have to be compiled with support for it: PHP_I18N(Some English Phrase Here) It can be configurable via (ugh) php.ini, or LANG from the environment. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
cats or gettext comes to mind. Neither are usable, though, because PHP would need to support multiple concurrent message catalogues on a per-thread base. gettext/catgets associate exactly one language with each process through the use of environment variables, so that they cannot be used in a multi-threaded server. A mechanism based on the bundled cdb, for example, would be superior in terms of speed, thread-safeness, and portability. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Error Codes, Langs, etc
Maxim (and anyone else who is interested) Shall we try to get a patch for this working then? I'm thinking perhaps starting off with an XML file defining the error messages, which is converted to a cdb for actual use. Anyone else game? John -Original Message- From: Sascha Schumann [mailto:[EMAIL PROTECTED]] Sent: Monday, November 25, 2002 11:29 PM To: Shane Caraveo Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Maxim Maletsky'; 'PHP Developers Mailing List' Subject: Re: [PHP-DEV] Error Codes, Langs, etc cats or gettext comes to mind. Neither are usable, though, because PHP would need to support multiple concurrent message catalogues on a per-thread base. gettext/catgets associate exactly one language with each process through the use of environment variables, so that they cannot be used in a multi-threaded server. A mechanism based on the bundled cdb, for example, would be superior in terms of speed, thread-safeness, and portability. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
Sascha Schumann wrote: cats or gettext comes to mind. Neither are usable, though, because PHP would need to support multiple concurrent message catalogues on a per-thread base. gettext/catgets associate exactly one language with each process through the use of environment variables, so that they cannot be used in a multi-threaded server. A mechanism based on the bundled cdb, for example, would be superior in terms of speed, thread-safeness, and portability. Why? The error messages are for the developer, not the masses. But generaly I agree with using something else. More the point is that stuff exists, techniques exist, no need to reinvent the wheel. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
Why? The error messages are for the developer, not the masses. But Imagine someone using his web-hoster's environment for debugging purposes. This affects the masses. generaly I agree with using something else. More the point is that stuff exists, techniques exist, no need to reinvent the wheel. Yes, gettext etc. are fine for stand-alone programs. PHP has different needs though. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
