Re: [PHP-DEV] [PATCH] Redirect on Error
On Thu, 2002-11-28 at 19:08, Marcus Börger wrote: At 18:59 28.11.2002, Ilia A. wrote: On November 28, 2002 12:56 pm, Maxim Maletsky wrote: Shall we still consider introducing error codes to PHP? IMO, it does not represent any enormous maintenance increase while has some positive points. Do you have an effecient manner in which to implement the introduction of error codes? Ilia That's not the problem (see patch below). The problem is changing the whole source to use error-codes and having a scheme for the codes. There is no shortcut we can take here. Error codes need to be applied by humans based on their perception of what goes wrong. A team of volunteers putting in a day or two, and some tools to help them, should be enough. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Wed, 27 Nov 2002, Sascha Schumann wrote: On Wed, 27 Nov 2002, Stig S. Bakken wrote: On Tue, 2002-11-26 at 14:57, Andrei Zmievski wrote: On Tue, 26 Nov 2002, Edin Kadribasic wrote: On Tue, 26 Nov 2002, Maxim Maletsky wrote: I rather propose. And, it seems to interest many on the list. Don't forget that there seem to be many who strongly opose your suggestion. Myself included. -1 on localized error messages +1 on errno-style error codes -1 on errno-style error codes. They are not versatile enough or easy to manage. They are a lot more versatile and manageable than having to use substring/regexp matching on human-readable text. What I'm going for here is a way for scripts to detect _why_ fopen fails, other than checking the error message. If we do get localized error messages at one point, this is even more important. Do you have any other suggestions? - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
-1 on errno-style error codes. They are not versatile enough or easy to manage. They are a lot more versatile and manageable than having to use substring/regexp matching on human-readable text. What I'm going for here is a way for scripts to detect _why_ fopen fails, other than checking the error message. If we do get localized error messages at one point, this is even more important. Do you have any other suggestions? In order to succeed over a long period of time, error tokens need to be versatile enough to satisfy this set of requirements. - the conflict potential should be low (can conflicts between independently released modules be avoided and if yes, how) - they should be easily recognizable by humans and automatons (so that e.g. bugs.php.net can easily insert the English error message for any given error code) - management overhead should be as low as possible (do we need a central registry and to what extent) Could you explain how you think that errno-style codes achieve these tasks? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Sat, 30 Nov 2002, Sascha Schumann wrote: -1 on errno-style error codes. They are not versatile enough or easy to manage. They are a lot more versatile and manageable than having to use substring/regexp matching on human-readable text. What I'm going for here is a way for scripts to detect _why_ fopen fails, other than checking the error message. If we do get localized error messages at one point, this is even more important. Do you have any other suggestions? In order to succeed over a long period of time, error tokens need to be versatile enough to satisfy this set of requirements. - the conflict potential should be low (can conflicts between independently released modules be avoided and if yes, how) - they should be easily recognizable by humans and automatons (so that e.g. bugs.php.net can easily insert the English error message for any given error code) - management overhead should be as low as possible (do we need a central registry and to what extent) Could you explain how you think that errno-style codes achieve these tasks? Sascha, I asked if you had any suggestions because I really wanted to hear if you had any suggestions, not because I wanted to dive into a verbal trench war. It doesn't have to be errno-style error codes, as long as the solution has the right balance between completeness and simplicity to make sure that all extension and PEAR package maintainers start using them. But assuming that our goals are fairly similar after all, I take the liberty of re-phrasing your mail as two suggestions: 1. make a naming scheme for error codes/symbols that is scalable, easily machine readable but also human readable 2. partition the error symbol space with a resolution to optimize management overhead Are we on wavelength yet? - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
At 12:00 30.11.2002, Sascha Schumann wrote: -1 on errno-style error codes. They are not versatile enough or easy to manage. They are a lot more versatile and manageable than having to use substring/regexp matching on human-readable text. What I'm going for here is a way for scripts to detect _why_ fopen fails, other than checking the error message. If we do get localized error messages at one point, this is even more important. Do you have any other suggestions? In order to succeed over a long period of time, error tokens need to be versatile enough to satisfy this set of requirements. - the conflict potential should be low (can conflicts between independently released modules be avoided and if yes, how) - they should be easily recognizable by humans and automatons (so that e.g. bugs.php.net can easily insert the English error message for any given error code) - management overhead should be as low as possible (do we need a central registry and to what extent) Could you explain how you think that errno-style codes achieve these tasks? - Sascha +1 If you write a README.ERROR_CODES and we can get a consensus on it i will commit the functions needed to main.c as already posed. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Just an update, I have made a 117m thread on PHP-IT wondering what Italian users think of porting error messages to their language. Apparently, users seemed to be already used to English errors and this idea wasn't completely accepted by everyone (some people agreed, though). Objections to it were similar to what we had here. However, error codes were very well welcomed because of several reasons including searching the docs and for web help, eventual ability catching/recognizing errors run-time, possibility of triggering core errors, etc. Shall we still consider introducing error codes to PHP? IMO, it does not represent any enormous maintenance increase while has some positive points. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On November 28, 2002 12:56 pm, Maxim Maletsky wrote: Shall we still consider introducing error codes to PHP? IMO, it does not represent any enormous maintenance increase while has some positive points. Do you have an effecient manner in which to implement the introduction of error codes? Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
At 18:59 28.11.2002, Ilia A. wrote:
On November 28, 2002 12:56 pm, Maxim Maletsky wrote:
Shall we still consider introducing error codes to PHP? IMO, it does not
represent any enormous maintenance increase while has some positive
points.
Do you have an effecient manner in which to implement the introduction of
error codes?
Ilia
That's not the problem (see patch below). The problem is changing the
whole source to use error-codes and having a scheme for the codes.
marcus
cvs -z3 -q diff main.c php.h (in directory S:\php4-HEAD\main)
Index: main.c
===
RCS file: /repository/php4/main/main.c,v
retrieving revision 1.518
diff -u -r1.518 main.c
--- main.c 21 Nov 2002 14:56:06 - 1.518
+++ main.c 28 Nov 2002 18:06:48 -
@@ -385,16 +385,25 @@
/* }}} */
/* {{{ php_verror */
+PHPAPI void php_verror(const char *docref, const char *params, int type,
const char *format, va_list args TSRMLS_DC)
+{
+ php_verror_ex(NULL, docref, params, type, format, args TSRMLS_CC);
+}
+/* }}} */
+
+/* {{{ php_verror_ex */
/* php_verror is called from php_error_docrefn functions.
* Its purpose is to unify error messages and automatically generate
clickable
* html error messages if correcponding ini setting (html_errors) is
activated.
* See: CODING_STANDARDS for details.
*/
-PHPAPI void php_verror(const char *docref, const char *params, int type,
const char *format, va_list args TSRMLS_DC)
+PHPAPI void php_verror_ex(const char *error_code, const char *docref,
const char *params, int type, const char *format, va_list args TSRMLS_DC)
{
char *buffer = NULL, *docref_buf = NULL, *ref = NULL, *target = NULL;
char *docref_target = , *docref_root = ;
char *function, *p;
+ char *error_code_separator1 = error_code ? : ;
+ char *error_code_separator2 = error_code ? : ;
int buffer_len = 0;
buffer_len = vspprintf(buffer, 0, format, args);
@@ -442,9 +451,9 @@
}
}
if (PG(html_errors)) {
- php_error(type, %s(%s) [a
href='%s%s%s'%s/a]: %s, get_active_function_name(TSRMLS_C), params,
docref_root, docref, docref_target, docref, buffer);
+ php_error(type, %s(%s) [a
href='%s%s%s'%s/a]: %s%s%s%s, get_active_function_name(TSRMLS_C),
params, docref_root, docref, docref_target, docref, error_code_separator1,
error_code, error_code_separator2, buffer);
} else {
- php_error(type, %s(%s) [%s%s%s]: %s,
get_active_function_name(TSRMLS_C), params, docref_root, docref,
docref_target, buffer);
+ php_error(type, %s(%s) [%s%s%s]:
%s%s%s%s, get_active_function_name(TSRMLS_C), params, docref_root, docref,
docref_target, error_code_separator1, error_code, error_code_separator2,
buffer);
}
if (target) {
efree(target);
@@ -453,7 +462,7 @@
docref = get_active_function_name(TSRMLS_C);
if (!docref)
docref = Unknown;
- php_error(type, %s(%s): %s, docref, params, buffer);
+ php_error(type, %s(%s): %s%s%s%s, docref, params,
error_code_separator1, error_code, error_code_separator2, buffer);
}
if (PG(track_errors) EG(active_symbol_table)) {
@@ -475,6 +484,18 @@
}
/* }}} */
+/* {{{ php_error_ex */
+/* See: CODING_STANDARDS for details. */
+PHPAPI void php_error_ex(const char *error_code, const char *docref
TSRMLS_DC, int type, const char *format, ...)
+{
+ va_list args;
+
+ va_start(args, format);
+ php_verror_ex(error_code, docref, , type, format, args TSRMLS_CC);
+ va_end(args);
+}
+/* }}} */
+
/* {{{ php_error_docref */
/* See: CODING_STANDARDS for details. */
PHPAPI void php_error_docref(const char *docref TSRMLS_DC, int type,
const char *format, ...)
@@ -487,6 +508,18 @@
}
/* }}} */
+/* {{{ php_error_ex1 */
+/* See: CODING_STANDARDS for details. */
+PHPAPI void php_error_ex1(const char *error_code, const char *docref
TSRMLS_DC, const char *param1, int type, const char *format, ...)
+{
+ va_list args;
+
+ va_start(args, format);
+ php_verror_ex(error_code, docref, param1, type, format, args
TSRMLS_CC);
+ va_end(args);
+}
+/* }}} */
+
/* {{{ php_error_docref1 */
/* See: CODING_STANDARDS for details. */
PHPAPI void php_error_docref1(const char *docref TSRMLS_DC, const char
*param1, int type, const char *format, ...)
@@ -499,6 +532,21 @@
}
/* }}} */
+/* {{{ php_error_ex2 */
+/* See: CODING_STANDARDS for details. */
+PHPAPI void php_error_ex2(const char *error_code, const char *docref
TSRMLS_DC, const char *param1, const char *param2, int type, const char
*format, ...)
+{
+
Re: [PHP-DEV] [PATCH] Redirect on Error
Ilia A. [EMAIL PROTECTED] wrote... : On November 28, 2002 12:56 pm, Maxim Maletsky wrote: Shall we still consider introducing error codes to PHP? IMO, it does not represent any enormous maintenance increase while has some positive points. Do you have an effecient manner in which to implement the introduction of error codes? I believe that it could be done gradually like the way docref was introduced. It might also be an alternative function of something similar. One important things will remain is the naming convention for errors - allocating the numbers in a logical ways. In my first thoughts I'd propose this format: PHP1234 where 12 means the extension and 34 is the error. This way, one could check things by parsing error strings or by calling some built in function which returns the extension name for the error, for instance. I think there could be many utilities for it. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Mon, 25 Nov 2002, Alexander Wagner wrote: On Monday 25 November 2002 23:29, Daniel Lorch wrote: You're right. We should think about writing a colorful GUI for PHP, so scripts just can be clicked together. Oh, and it definitively should support skins.. I don't think this would work. But if it did, it's place wouldn't be inside the language. Either in an IDE or in a PHP-application. PHP often is used for skinning a website, btw. It was a _joke_. But if there were a good idiot-proof IDE, it would definately help these people. It would have to be free (beer), of course. People who spend 2,50€ a month on webspace won't spend a fortune on an IDE. On the other hand, you lose a lot of flexibility this way. At some point, people will have to touch the code. And there should be as few obstacles as possible. I can absolutely understand your argumentation (which you forgot to CC to the list, by the way) and being a regular to PHP-DE (german PHP users mailinglist), I am also in touch with people you described. But what's wrong about just HREF'ing to the manual, which is localized anyway? You'd have to put a href in every single error-message. Ugly. Either this, or people won't find it. We already do that anyway. 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] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Alexander Wagner wrote: On Tuesday 26 November 2002 00:07, Jani Taskinen wrote: Remember. I'm talking about the people that have to be spoon-fed. Well..to be quite honest: I don't care about such people. To be honest, they tend to piss me off a little (at least some do). Getting rid of these stupid questions... ah... dreaming again... They're not working with PHP, they just use it for fun. Every _serious_ developer definately knows enough english.. Not necessarily. There are still those that are too young, and those that are too old. PHP has a very wide userbase. But you're not that wrong... anybody who is serious will find a way to understand it. But PHP is very popular among people who are _not_ serious. Some become serious. After the got in touch with programming. After they got their first site to work. Removing obstacles is mostly a good thing. PHP is very easy to use already. This is just one point where it still can improve. IMO it doesn't improve anything; people who don't want to understand undefined function also dont want to understand undefiniertes Funktion, it's all arabic techo-speak for them anyway. Then how does it help if you explain either undefined function or undefiniertes Funktion to them? 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] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: On Mon, 25 Nov 2002 15:21:06 -0500 Sterling Hughes [EMAIL PROTECTED] wrote: Educate users to speak the base amount of english required, I18N'ing the language is just going to lead to headaches from a user perspective (incorrect translations, slower performance, translations for english speakers) and a developer perspective (having to lookup tokens, understanding another language, getting bug reports with horrible error messages). That is why we have error codes :) Are you saying that Oracle is wrong giving the ability to localize even SQL error messages? These does not have to ever happen, but in my Italian team the guys are simply rocking - they find out instantly what they did wrong to a query because it is in their language. Sets the language to what you speak and you will develop faster wherever you're coming from. I don't agree with that, I had no idea what a 'afrolmenu' was when I got a weird error message in Word; after all it just seemed to be a dropdown box. As of bug reports - as long as every error has its own error code everyone in the world can find out what the error means. How different is that from simply translating the documentation? Did you think on how to manage all those error codes in internal (php4/ext) extensions, external (pear/pecl) and third party extensions? It would be a hell to maintain it all; it's just not practical. 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] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: On Mon, 25 Nov 2002 16:15:29 -0500 Sterling Hughes [EMAIL PROTECTED] wrote: Not at all, i don't expect them to speak fluent english, just to understand the small subset of english errors and programming terms. I've conversed with plenty of PHP users (second-hand at least) where they didn't know english, yet understood the error codes. Users need not know english, they can download a quicksheet. If you see Constant 3 And I tell you it means: Undefined constant, assuming string after a while that term will become like your own language, especially if its as simple as copying pasting, and clicking search. There are millions of IT people that do not know what either one of undefined, constant and assuming would exactly mean. Just in your two examples. The same would be try for the italian or dutch localized error, it would be as arabic for them as the english version. 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] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: This can be easily avoided. When I have to report an Oracle error in Italian on an English page, I simply type the error code. We need to introduce error codes in PHP, that would really solve the trouble. and it would make us enter the maintainers-hell 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] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Marcus Börger wrote: For example: php_error_docref(NULL TSRMLS_CC, E_WARNING, Error %d, error) would convert to: php_error_docref(NULL TSRMLS_CC, E_WARNING, PHP-42, error) and in the init code we would register these errors: register_error_message(PHP-42, Error %d) and now translation tables for these error messages are possible. Bloat alert! Do you have any idea how expensive those hash looks ups are? And I would _never_ want to maintain that for any code I write. And how would you handle clashes in here? It's a bad idea. 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] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: Yes, this is the way to go. but, I would still prefer to have to pass it only a code like: php_error(255, data, data, data); where in an XML structure we can predefine everything else. XML?!? More bloat is hardly needed, thank you! Not to forget that it's a hell to maintain for PHP extension developers, like me. 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] [PATCH] Redirect on Error
On Mon, 25 Nov 2002, Ilia A. wrote:
On November 25, 2002 08:24 pm, Maxim Maletsky wrote:
php_error(225);
whereas 255 is defined some string in many languages appering like this:
Warning (255): Undefined Variable.
One writes in bugs.php.net:
Non dovrei ricevere questo errore:
Attenzione (225): Variabile non predefinita.
in questo codice:
if($var) {
}
perche?
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.
Same is true for me...
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] [PATCH] Redirect on Error
On Mon, 25 Nov 2002, George Schlossnagle wrote: By the way, could you please advise by how much I will need to increase the power of my server(s) to maintain the same level of performance? Why would this need to kill your performance if you're not throwing errors? imagine registering 20 extensions * 40 (that's about the average) functions * 5 error messages per function, that's 1600 inserts into a hash table on every MINIT. (Atleast in the way that was proposed here) 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] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Sascha Schumann wrote: Also please think about the billions of people who are not in such a privileged situation of having Internet access all the time. Think of school labs which are not permanently connected; think of poor countries where access is not easily available; think of home users with time-metered dial-up access. For all of those, relying on the online documentation might not be an option. http://www.php.net/download-docs.php 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] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Derick Rethans wrote: On Mon, 25 Nov 2002, George Schlossnagle wrote: By the way, could you please advise by how much I will need to increase the power of my server(s) to maintain the same level of performance? Why would this need to kill your performance if you're not throwing errors? imagine registering 20 extensions * 40 (that's about the average) functions * 5 error messages per function, that's 1600 inserts into a hash table on every MINIT. (Atleast in the way that was proposed here) Either a) registration happens on-the-fly = no penalty for standard performance b) registration is not necessary and we just perform a cdb lookup - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
PO Just to defend phpdoc a bit, this statistic is based on PO a php manual generated on April 25, 2002, which is when PO zend.com/manual/ was last updated. Also, missing functions That's not exactly true. The phpfunc is updated much more frequently than the manual (since it takes _a real lot_ of time to build the full manual...) - usually, daily. Also, as far as I understand, the numbers are taken from manual/PHP sources, not from generated manual. So if something is not correct, it's because I messed something up or something changed in the manual and phpfunc script no longer catch it - but not because it's not updated. Can you point to some function that is defined but listed as not defined? Did the manual structure change substantially? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Stanislav Malyshev wrote:
PO Just to defend phpdoc a bit, this statistic is based on
PO a php manual generated on April 25, 2002, which is when
PO zend.com/manual/ was last updated. Also, missing functions
That's not exactly true. The phpfunc is updated much more frequently than
the manual (since it takes _a real lot_ of time to build the full
manual...) - usually, daily. Also, as far as I understand, the numbers are
taken from manual/PHP sources, not from generated manual.
So if something is not correct, it's because I messed something up or
something changed in the manual and phpfunc script no longer catch it -
but not because it's not updated. Can you point to some function that is
defined but listed as not defined? Did the manual structure change
substantially?
Yes, phpfunc updates daily and that is good (although it continues
to say last updated sept. 22). There are documented functions
listed as not documented but your last comment seems to decipher
why. Sorry to assume where those statistics are based although
this looks related as April 25 is close to April 17, which
is around when the big change happened.
The manual structure did substantially change at around April
17, 2002. Now the functions are in their own xml files, and
they all live in the reference/ directory. The old xml files
still exist but aren't updated anymore. So:
Old: en/functions/{extension}.xml
New: en/reference/{extension}/functions/{function}.xml
It sounds like this is where the problem lives. As a reference,
glob() was initially documented about six months ago and sha1()
about six days.
Regards,
Philip
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Ilia A. [EMAIL PROTECTED] wrote... : On November 25, 2002 09:22 pm, Maxim Maletsky wrote: 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 If my co-workers and I cannot communicate in the same language we will probably go our separate ways within a week. Afterall, how can we work together if we don't have a common language between us. By the way, could you please advise by how much I will need to increase the power of my server(s) to maintain the same level of performance? nah... not really. I, at work, have my OS, keyboard and everything else set in en-us, while everyone else in Italian. Of course - this is the Ministry of Economy and Finance of Italy :) This is not the point yet. A team sets the language in php.ini, who needs it different can alter it. 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. It would probably flexible solution, but terribly complex. Why? Having to only pass numbers in error and one XML file to edit is not *that* complex. Whole PHP internals is complex itself, if for that. Let's consider the process, a developer decides to add sanity check with a warning. They write the code and now need to modify an XML file with an error message, reference the XML entry from their code. Commit all this to CVS and hope they did not messup. Yup. Also, how and when XML parsing will be merged inserted into C code? Won't you be adding an XML parser decency to PHP? This is something to have discussed. I am definitely not the best guy to know what is better for this case. My only point is this: ERROR STRINGS **OUT** OF THE C CODE! Then, whether we use XML or not is another topic. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
PO Yes, phpfunc updates daily and that is good (although it continues
PO to say last updated sept. 22). There are documented functions
Sept. 22 is code update date (i.e., that's the last time the file
structure, etc. changed). I think there indeed needs to be something more
clear to state this.
PO Old: en/functions/{extension}.xml
PO New: en/reference/{extension}/functions/{function}.xml
PO
PO It sounds like this is where the problem lives. As a reference,
PO glob() was initially documented about six months ago and sha1()
PO about six days.
Oh. Now I see. So each function now has one individual file? I guess that
requires update to phpfunc module. I will check into this.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
And, most importantly, what the hell doi I care of losing 0.12 secs for a Fatal Error dysplay? -- Maxim Maletsky [EMAIL PROTECTED] George Schlossnagle [EMAIL PROTECTED] wrote... : By the way, could you please advise by how much I will need to increase the power of my server(s) to maintain the same level of performance? Why would this need to kill your performance if you're not throwing errors? -- 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] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: Ilia A. [EMAIL PROTECTED] wrote... : If my co-workers and I cannot communicate in the same language we will probably go our separate ways within a week. Afterall, how can we work together if we don't have a common language between us. By the way, could you please advise by how much I will need to increase the power of my server(s) to maintain the same level of performance? nah... not really. I, at work, have my OS, keyboard and everything else set in en-us, while everyone else in Italian. Of course - this is the Ministry of Economy and Finance of Italy :) This is not the point yet. A team sets the language in php.ini, who needs it different can alter it. Let's consider the process, a developer decides to add sanity check with a warning. They write the code and now need to modify an XML file with an error message, reference the XML entry from their code. Commit all this to CVS and hope they did not messup. Yup. I don't think so. Also, how and when XML parsing will be merged inserted into C code? Won't you be adding an XML parser decency to PHP? This is something to have discussed. I am definitely not the best guy to know what is better for this case. My only point is this: ERROR STRINGS **OUT** OF THE C CODE! NO WAY. And don't shout on the mailinglist. 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] [PATCH] Redirect on Error
It can be parsed run time at a small cost, which in this case of errors, as many here agree, can be used. -- Maxim Maletsky [EMAIL PROTECTED] John Coggeshall [EMAIL PROTECTED] wrote... : Because errors need to be loaded into memory by some mechanism, stored in a hash table? Meaning that during startup I will be penalized for this process. Hash table has it own overhead as well meaning that PHP memory usage will increase, for a server running 200-300 apache children constantly even a small increase will count. This will also make PHP shell scripting impractical due to the high start costs of a PHP binary. I agree with George on this, loading everything at startup isn't necessary. Errors can be loaded by some mechanism on-the-fly. John Ilia -- 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
[EMAIL PROTECTED] (Marcus Börger) wrote... : WE can use cdb (constant databse) which is very fast and we have the code bundled now. The documnet group might want work on error messages XML based. We may write a script wich will generate a cdb file from that XML file. I thought af it - I think this can be one of the best solutions. However i would VERY MUCH appreciate having english error messages hard coded into the source. AND those i18n error messages only activateable by an ini setting. I disagree. Leaving english comments in C code is obvious, but the errors that get printed to user's screens should be out of C code. I know, it will hassle some lazy us while coding, but nevertheless, it will help documentation ppl to translate errors easlier without knowing how extensions are set :) I also think that error messages will be tranlated much shorter as they inspire more translators to work on. They's cool :) -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
At 11:22 26.11.2002, Maxim Maletsky wrote: Ilia A. [EMAIL PROTECTED] wrote... : On November 25, 2002 09:22 pm, Maxim Maletsky wrote: 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 If my co-workers and I cannot communicate in the same language we will probably go our separate ways within a week. Afterall, how can we work together if we don't have a common language between us. By the way, could you please advise by how much I will need to increase the power of my server(s) to maintain the same level of performance? nah... not really. I, at work, have my OS, keyboard and everything else set in en-us, while everyone else in Italian. Of course - this is the Ministry of Economy and Finance of Italy :) This is not the point yet. A team sets the language in php.ini, who needs it different can alter it. 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. It would probably flexible solution, but terribly complex. Why? Having to only pass numbers in error and one XML file to edit is not *that* complex. Whole PHP internals is complex itself, if for that. Let's consider the process, a developer decides to add sanity check with a warning. They write the code and now need to modify an XML file with an error message, reference the XML entry from their code. Commit all this to CVS and hope they did not messup. Yup. Also, how and when XML parsing will be merged inserted into C code? Won't you be adding an XML parser decency to PHP? This is something to have discussed. I am definitely not the best guy to know what is better for this case. My only point is this: ERROR STRINGS **OUT** OF THE C CODE! -MAX_LONG on this. I assume none of the php-dev coders will loose connection between the error message and the source where the error happens. And why if you would do as i wrote before no one forbids you to even overwrite the english error message. And for me it is a requirement before accepting i18n error messages that you can still have error message in english text without any external data file. marcus Then, whether we use XML or not is another topic. -- 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
Re: [PHP-DEV] [PATCH] Redirect on Error
Derick Rethans [EMAIL PROTECTED] wrote... : IMO it doesn't improve anything; people who don't want to understand undefined function also dont want to understand undefiniertes Funktion, it's all arabic techo-speak for them anyway. Then how does it help if you explain either undefined function or undefiniertes Funktion to them? Derick It is just as true. But, there is also another side of the coin - having errors internationalized will sound like PHP-translated not only DOCS translated - an extra tool to tell that Open Source cares of usability. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
And, most importantly, what the hell doi I care of losing 0.12 secs for a Fatal Error dysplay? I don't like the whole idea of having localized error messages. People have to use English when programming PHP anyway, and nobody is insane enough (yet) to suggest to translate function names. I don't think Parse error is any more difficult to understand than register_shutdown_function(). People use manual for understanding things like this. And I do care about unnecessary performance loss. But most of all I care about maintenance nightmare that this localization would put us in. If some of the pro-localization ever bother to read the php-bugs you would know that even a simple matter of using the correct .ini or .dll file can be too much for your target audience. Adding some CDB file to it is not going to help. The other side is maintaining the translation in the PHP code itself. This is just too large a task for the current team. I think it would be far more useful that some energy is spent on keeping PHP manual up to date so say our Italian users would have some clue about streams once PHP 4.3.0 hits the street. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : IMO it doesn't improve anything; people who don't want to understand undefined function also dont want to understand undefiniertes Funktion, it's all arabic techo-speak for them anyway. Then how does it help if you explain either undefined function or undefiniertes Funktion to them? It is just as true. But, there is also another side of the coin - having errors internationalized will sound like PHP-translated not only DOCS translated - an extra tool to tell that Open Source cares of usability. I don't care what others think about the usability, I only know that adding these localized things brings more work for me when working on PHP. 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] [PATCH] Redirect on Error
XML or not XML is not yet the question. It can be something else having its own XML version. What is the browsercap then? Somthing of that nature for core PHP, but creating that file from a Documentation XML error file. -- Maxim Maletsky [EMAIL PROTECTED] Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: Yes, this is the way to go. but, I would still prefer to have to pass it only a code like: php_error(255, data, data, data); where in an XML structure we can predefine everything else. XML?!? More bloat is hardly needed, thank you! Not to forget that it's a hell to maintain for PHP extension developers, like me. 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
I apologize for shouting, didn't mean to be offensive. What I want to say is that error messages are string and should, IMHO, be reference instead of hardcoded in the C code. -- Maxim Maletsky [EMAIL PROTECTED] Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: Ilia A. [EMAIL PROTECTED] wrote... : If my co-workers and I cannot communicate in the same language we will probably go our separate ways within a week. Afterall, how can we work together if we don't have a common language between us. By the way, could you please advise by how much I will need to increase the power of my server(s) to maintain the same level of performance? nah... not really. I, at work, have my OS, keyboard and everything else set in en-us, while everyone else in Italian. Of course - this is the Ministry of Economy and Finance of Italy :) This is not the point yet. A team sets the language in php.ini, who needs it different can alter it. Let's consider the process, a developer decides to add sanity check with a warning. They write the code and now need to modify an XML file with an error message, reference the XML entry from their code. Commit all this to CVS and hope they did not messup. Yup. I don't think so. Also, how and when XML parsing will be merged inserted into C code? Won't you be adding an XML parser decency to PHP? This is something to have discussed. I am definitely not the best guy to know what is better for this case. My only point is this: ERROR STRINGS **OUT** OF THE C CODE! NO WAY. And don't shout on the mailinglist. 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: This can be easily avoided. When I have to report an Oracle error in Italian on an English page, I simply type the error code. We need to introduce error codes in PHP, that would really solve the trouble. and it would make us enter the maintainers-hell It's not really that much of hell. just adding an English comment like: /* Fail if this data no good */ php_error(354, bad_data); Huh, what is code 354? What is the exact message? Comments dont help, and then you need to update the message at two locations! Woohoo! even more work. Can save the whole thing. Naming conventions and coding style used commonly can be the solution. Yeah, and you just tell us what to do. 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] [PATCH] Redirect on Error
At 11:55 26.11.2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: This can be easily avoided. When I have to report an Oracle error in Italian on an English page, I simply type the error code. We need to introduce error codes in PHP, that would really solve the trouble. and it would make us enter the maintainers-hell It's not really that much of hell. just adding an English comment like: /* Fail if this data no good */ php_error(354, bad_data); Tht is silly because there is no connection between 354 and the comment above. And then what am i presented if i do not have a message file. And a greater problem would be startup errors - those that occur before the message file could be loaded. Can save the whole thing. Naming conventions and coding style used commonly can be the solution. -- 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
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: Ilia A. [EMAIL PROTECTED] wrote... : If my co-workers and I cannot communicate in the same language we will probably go our separate ways within a week. Afterall, how can we work together if we don't have a common language between us. By the way, could you please advise by how much I will need to increase the power of my server(s) to maintain the same level of performance? nah... not really. I, at work, have my OS, keyboard and everything else set in en-us, while everyone else in Italian. Of course - this is the Ministry of Economy and Finance of Italy :) This is not the point yet. A team sets the language in php.ini, who needs it different can alter it. Let's consider the process, a developer decides to add sanity check with a warning. They write the code and now need to modify an XML file with an error message, reference the XML entry from their code. Commit all this to CVS and hope they did not messup. Yup. I don't think so. Also, how and when XML parsing will be merged inserted into C code? Won't you be adding an XML parser decency to PHP? This is something to have discussed. I am definitely not the best guy to know what is better for this case. My only point is this: ERROR STRINGS **OUT** OF THE C CODE! NO WAY. And don't shout on the mailinglist. I apologize for shouting, didn't mean to be offensive. What I want to say is that error messages are string and should, IMHO, be reference instead of hardcoded in the C code. Can you please also reply _below_ the other comments, it's annoying to following discussions when you quote above. 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] [PATCH] Redirect on Error
Derick, that's the price of usability. Open Source always suffered from that, and forever will if the usability will not be considered as one of the main benefits, especially for a programming language as PHP. I agree on 110% that it will be harder to maintain the code. I myself will never use any non-english errors in my PHP setups and will always spend precious minutes grepping for error code. But, this will benefit the whole project. It is not a stupid idea - it is usability. -- Maxim Maletsky [EMAIL PROTECTED] Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: [EMAIL PROTECTED] (Marcus Börger) wrote... : However i would VERY MUCH appreciate having english error messages hard coded into the source. AND those i18n error messages only activateable by an ini setting. I disagree. Leaving english comments in C code is obvious, but the errors that get printed to user's screens should be out of C code. No, I won't want the C code less maintainable and have to search for error codes all the time. I know, it will hassle some lazy us while coding, but nevertheless, it will help documentation ppl to translate errors easlier without knowing how extensions are set :) It's giving coders more work, work which looks like documenting; and we all know that coders dont like to document. And being lazy has nothing to do with it, it's just all practical. Dont forget that most coders work on PHP because they _need_ the function they are working on in their jobs. 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: ERROR STRINGS **OUT** OF THE C CODE! NO WAY. And don't shout on the mailinglist. I apologize for shouting, didn't mean to be offensive. What I want to say is that error messages are string and should, IMHO, be reference instead of hardcoded in the C code. I know that you wanted to say that; it just does make things even harder. 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] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : It's giving coders more work, work which looks like documenting; and we all know that coders dont like to document. And being lazy has nothing to do with it, it's just all practical. Dont forget that most coders work on PHP because they _need_ the function they are working on in their jobs. that's the price of usability. Open Source always suffered from that, and forever will if the usability will not be considered as one of the main benefits, especially for a programming language as PHP. We didn't suffer from this at all, and why is PHP not usable enough? We have tenth of thousand users. I agree on 110% that it will be harder to maintain the code. I myself will never use any non-english errors in my PHP setups and will always spend precious minutes grepping for error code. But, this will benefit the whole project. It is not a stupid idea - it is usability. Then why care if you don't need it? Why do more work because only others want/need it? IMO that's just plain dumb. 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] [PATCH] Redirect on Error
They should definitely be in the C code. Look at gettext as a pretty good example. Taking them out is seriously inferior to having them in - it makes maintenance much tougher, and PHP itself less robust. Suddenly, if you don't have some external file, errors would show up as stupid error numbers. What are we looking forward to? Having something like Error 29871 and then having to look up error 29871 and seeing it means Unable to find external error message database? No, please. About the topic of internationalized error messages in general - I think the cons outweigh the pros. If we were, however, to ever internationalize them - it would have to be optional, and with the full hardcoded error messages inside the code remaining intact. Zeev At 13:01 26/11/2002, Maxim Maletsky wrote: I apologize for shouting, didn't mean to be offensive. What I want to say is that error messages are string and should, IMHO, be reference instead of hardcoded in the C code. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Since error code domains need to be centrally assigned so that they don't overlap, I'd suggest to simply set up a central data repository with assigned error code domains and a per-domain set of mappings. The error codes should be easily recognizable (%foo-123%), so that e.g. the bugs.php.net parser can present the English error message automatically. There is really no need for XML at this point in time. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : IMO it doesn't improve anything; people who don't want to understand undefined function also dont want to understand undefiniertes Funktion, it's all arabic techo-speak for them anyway. Then how does it help if you explain either undefined function or undefiniertes Funktion to them? It is just as true. But, there is also another side of the coin - having errors internationalized will sound like PHP-translated not only DOCS translated - an extra tool to tell that Open Source cares of usability. I don't care what others think about the usability, I only know that adding these localized things brings more work for me when working on PHP. That sounds selfish of us, Derick. PHP is an Open Source and has to compete with commercial applications where this is being one of the highest priorities, often even higher than overall performance. PHP has already accomplished remarkable performance and efficiency values, it also has done good job in usability. Only because coders will have to open an extra file when looking for an error string, should not mean that this programming language musts abandon these values. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: This can be easily avoided. When I have to report an Oracle error in Italian on an English page, I simply type the error code. We need to introduce error codes in PHP, that would really solve the trouble. and it would make us enter the maintainers-hell It's not really that much of hell. just adding an English comment like: /* Fail if this data no good */ php_error(354, bad_data); Huh, what is code 354? What is the exact message? Comments dont help, and then you need to update the message at two locations! Woohoo! even more work. Can save the whole thing. Naming conventions and coding style used commonly can be the solution. Yeah, and you just tell us what to do. I rather propose. And, it seems to interest many on the list. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: I apologize for shouting, didn't mean to be offensive. What I want to say is that error messages are string and should, IMHO, be reference instead of hardcoded in the C code. The default messages must stay; there is no need to _always_ install a message catalogue. PHP should work fine without it. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: It is just as true. But, there is also another side of the coin - having errors internationalized will sound like PHP-translated not only DOCS translated - an extra tool to tell that Open Source cares of usability. I don't care what others think about the usability, I only know that adding these localized things brings more work for me when working on PHP. That sounds selfish of us, Derick. It sure does sound like that, but what is wrong with that? PHP is an Open Source and has to compete with commercial applications where this is being one of the highest priorities, often even higher than overall performance. PHP has already accomplished remarkable performance and efficiency values, it also has done good job in usability. Only because coders will have to open an extra file when looking for an error string, should not mean that this programming language musts abandon these values. Absolutely it should. We're not making it any less usable anyway by not adding localized errors. 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] [PATCH] Redirect on Error
At 13:05 26/11/2002, Maxim Maletsky wrote: Derick, that's the price of usability. Open Source always suffered from that, and forever will if the usability will not be considered as one of the main benefits, especially for a programming language as PHP. I agree on 110% that it will be harder to maintain the code. I myself will never use any non-english errors in my PHP setups and will always spend precious minutes grepping for error code. But, this will benefit the whole project. It is not a stupid idea - it is usability. That's quite arguable, Maxim. I personally find error internationalized error messages as very annoying, and I have quite a bit of experience in that. Fact is, especially in a technical area such as PHP, lots of information is lost or gets degraded when you translate it. I'm sure that there are people who would prefer localized error messages, but my guess is that they won't be the majority of users. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: I rather propose. And, it seems to interest many on the list. Don't forget that there seem to be many who strongly opose your suggestion. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
At 13:11 26/11/2002, Maxim Maletsky wrote: That sounds selfish of us, Derick. No, it doesn't. If we're going to attempt at doing something that has a high risk of screwing up PHP and slow down its QA and support, we should be mature enough to know our limits. If we don't, the ones that would suffer eventually would actually be the users. Knowing your limits is a virtue, and taking unnecessary risks, while may seem noble, will often lead to much worse results. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
At 12:05 26.11.2002, Zeev Suraski wrote: At 13:05 26/11/2002, Maxim Maletsky wrote: Derick, that's the price of usability. Open Source always suffered from that, and forever will if the usability will not be considered as one of the main benefits, especially for a programming language as PHP. I agree on 110% that it will be harder to maintain the code. I myself will never use any non-english errors in my PHP setups and will always spend precious minutes grepping for error code. But, this will benefit the whole project. It is not a stupid idea - it is usability. That's quite arguable, Maxim. I personally find error internationalized error messages as very annoying, and I have quite a bit of experience in that. Fact is, especially in a technical area such as PHP, lots of information is lost or gets degraded when you translate it. That is the exact reason why i always buy books in english and no german translations. I'm sure that there are people who would prefer localized error messages, but my guess is that they won't be the majority of users. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Zeev Suraski [EMAIL PROTECTED] wrote... : They should definitely be in the C code. Look at gettext as a pretty good example. Taking them out is seriously inferior to having them in - it makes maintenance much tougher, and PHP itself less robust. Suddenly, if you don't have some external file, errors would show up as stupid error numbers. What are we looking forward to? Having something like Error 29871 and then having to look up error 29871 and seeing it means Unable to find external error message database? I think it can be stable enough since once you add an error in code you would add it to the message database. No, please. About the topic of internationalized error messages in general - I think the cons outweigh the pros. If we were, however, to ever internationalize them - it would have to be optional, and with the full hardcoded error messages inside the code remaining intact. It, of course, would be optional. Set by local setting in php.ini or runtime. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Sascha Schumann [EMAIL PROTECTED] wrote... : Since error code domains need to be centrally assigned so that they don't overlap, I'd suggest to simply set up a central data repository with assigned error code domains and a per-domain set of mappings. The error codes should be easily recognizable (%foo-123%), so that e.g. the bugs.php.net parser can present the English error message automatically. There is really no need for XML at this point in time. What if we were to store more data for the same error which is still mapped the same. That is where I thought of XML, which is not the one to use here, because it would allow more properties per error. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
hi, I fired off a mail to PHP-DE asking the average PHP user about localization of error messages. My mail might be a bit biased, so if you have something to say, do it now. I will summarize the results here. Ok, here's the summary of my NON-representative poll to PHP-De about localization of error messages in PHP: Pro: 1 Contra: 8 Some thoughts that were brought up: - PHP developers should not waste their time on localization, instead focus on increasing verbosity of existing error messages (a meaningless error message in english will be meaningless in every other language as well). - The english used in error messages is only a small subset of the whole language (come on, everyone knows enough MTV-english to understand error messages). However, other countries might have more problems as their languages don't come from the same language family. -daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
At 09:47 26.11.2002, Derick Rethans wrote: On Tue, 26 Nov 2002, Marcus Börger wrote: For example: php_error_docref(NULL TSRMLS_CC, E_WARNING, Error %d, error) would convert to: php_error_docref(NULL TSRMLS_CC, E_WARNING, PHP-42, error) and in the init code we would register these errors: register_error_message(PHP-42, Error %d) and now translation tables for these error messages are possible. Bloat alert! Do you have any idea how expensive those hash looks ups are? And I would _never_ want to maintain that for any code I write. And how would you handle clashes in here? It's a bad idea. Derick You pointed me to my failure here :-) php_error_docref(NULL TSRMLS_CC, E_WARNING, Error %d, error) should convert to php_error_docref(NULL TSRMLS_CC, E_WARNING, PHP-42, Error %d, error) and now loading any external data is optional and registering error messages is no longer needed. And such conversion can easily be done automagically by a sed script. Some people already accepted bundeled cdb as a good message storage. This would require 2 or 3 file lookups per message. And again you shouldn't have one single error message in setups where time is money. In those scenarios you are expected to have *no* error. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
hi, Some thoughts that were brought up: Oh, another one: - Localization is stupid and we might lose our existing userbase, namely more proficient PHP developers- -daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Zeev Suraski [EMAIL PROTECTED] wrote... : At 13:11 26/11/2002, Maxim Maletsky wrote: That sounds selfish of us, Derick. No, it doesn't. If we're going to attempt at doing something that has a high risk of screwing up PHP and slow down its QA and support, we should be mature enough to know our limits. If we don't, the ones that would suffer eventually would actually be the users. Knowing your limits is a virtue, and taking unnecessary risks, while may seem noble, will often lead to much worse results. Let's say, as a user, I get this error for not defining a variable: Notice: Undefined variable: var in E:\CVS\PHP\php4\Release_TS\tests\release.php on line 20 What if that error would be: Notice (235): Undefined variable: var in E:\CVS\PHP\php4\Release_TS\tests\release.php on line 20 Docref... FAQ... etc ... where 1. Underfined Variable is translated to ohter languages. In this example it is just a simple english, but there are other, more complex ones. 2. 235 is the error code. One can type it in google: Notice (235) and get lots of info. Still possible even now, by typing error message instead. What i love about Oracle is its error code format: ORA-25688 - you type it anywhere and get find tons of solutions instantly. 3. Docref and FAQ links to a documentaion and FAQ pages on php.net where there would be descriptions of errors and relevant solutions. Very, very handy. It is what Marcus was doing, but, he needed to add new functions to it, referencing by code will be more flexible as you could edit the storage only. 4. User could use and extend this error reporting techniques on his own. These are just my thoughts of what I would see usable about it all. IMO, the current error reporting will be someday dedesigned anyway - it does need a redesign. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: These are just my thoughts of what I would see usable about it all. IMO, the current error reporting will be someday dedesigned anyway - it does need a redesign. wha? I don't see any reason why it should be redesigned at all, it's just fine as it is. 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] [PATCH] Redirect on Error
Can you guys please quit bickering and focus on the concrete proposal which is on the table. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Let me do the same for Italian -- Maxim Maletsky [EMAIL PROTECTED] Daniel Lorch [EMAIL PROTECTED] wrote... : hi, I fired off a mail to PHP-DE asking the average PHP user about localization of error messages. My mail might be a bit biased, so if you have something to say, do it now. I will summarize the results here. Ok, here's the summary of my NON-representative poll to PHP-De about localization of error messages in PHP: Pro: 1 Contra: 8 Some thoughts that were brought up: - PHP developers should not waste their time on localization, instead focus on increasing verbosity of existing error messages (a meaningless error message in english will be meaningless in every other language as well). - The english used in error messages is only a small subset of the whole language (come on, everyone knows enough MTV-english to understand error messages). However, other countries might have more problems as their languages don't come from the same language family. -daniel -- 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] [PATCH] Redirect on Error
At 12:46 26.11.2002, Maxim Maletsky wrote: Zeev Suraski [EMAIL PROTECTED] wrote... : At 13:11 26/11/2002, Maxim Maletsky wrote: That sounds selfish of us, Derick. No, it doesn't. If we're going to attempt at doing something that has a high risk of screwing up PHP and slow down its QA and support, we should be mature enough to know our limits. If we don't, the ones that would suffer eventually would actually be the users. Knowing your limits is a virtue, and taking unnecessary risks, while may seem noble, will often lead to much worse results. Let's say, as a user, I get this error for not defining a variable: Notice: Undefined variable: var in E:\CVS\PHP\php4\Release_TS\tests\release.php on line 20 What if that error would be: Notice (235): Undefined variable: var in E:\CVS\PHP\php4\Release_TS\tests\release.php on line 20 Docref... FAQ... etc ... where 1. Underfined Variable is translated to ohter languages. In this example it is just a simple english, but there are other, more complex ones. 2. 235 is the error code. One can type it in google: Notice (235) and get lots of info. Still possible even now, by typing error message instead. What i love about Oracle is its error code format: ORA-25688 - you type it anywhere and get find tons of solutions instantly. Then why strip the module from the error code. I like that hint in the oracle messages much. 3. Docref and FAQ links to a documentaion and FAQ pages on php.net where there would be descriptions of errors and relevant solutions. Very, very handy. It is what Marcus was doing, but, he needed to add new functions to it, referencing by code will be more flexible as you could edit the storage only. I could have done without but wanted to add more flexibility (show important function parameters and allo to use another link) and pass around TSRM parameter for speed reasons. 4. User could use and extend this error reporting techniques on his own. These are just my thoughts of what I would see usable about it all. IMO, the current error reporting will be someday dedesigned anyway - it does need a redesign. -- Maxim Maletsky [EMAIL PROTECTED] There were some good points to consider in these threads but i disagree that we need a complete redesign. As myself and even more Sascha showed i18n messages can easiliy be added to the current system. When it is up to add error code more work is needed without a question. The thing i fear most about further changes is that we either need new API functions to handle the error codes or we end up in endlessly bugs about php not compileable because some errors need to be changed. That is one of the reason i left the change from php_error() to new php_error_docref() to the authors of the modules and gave them a nice tool to aid them. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Sascha Schumann wrote: Can you guys please quit bickering and focus on the concrete proposal which is on the table. I think starting with a concrete proposal before it's not clear if we even want this localized errors thing seems rather time-wasting. What you call bickering, I call discussing, and IMO we're not yet done discussing if we want this at all. 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] [PATCH] Redirect on Error
PO It sounds like this is where the problem lives. As a reference, PO glob() was initially documented about six months ago and sha1() PO about six days. OK, I have updated the phpfunc to use new manual structure. The number of undocumented functions is down to 12% now :) -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
I think starting with a concrete proposal before it's not clear if we even want this localized errors thing seems rather time-wasting. What you call bickering, I call discussing, and IMO we're not yet done discussing if we want this at all. Well, there won't be a consensus regarding i18n facilities any time soon on php-dev. I can post some hilarious quotes from your funny IRC channel to demonstrate that point. Hence, the only way to move this forward is to actually code something up and enable extension authors to provide i18n error messages. The first step consists of adding the necessary look-up code to PHP itself; the second step is building the infrastructure for maintaining and generating message catalogues; the third step consists of assigning error codes to extensions; and as the final step, translators can actually commence to build the message catalogues. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Edin Kadribasic wrote: On Tue, 26 Nov 2002, Maxim Maletsky wrote: I rather propose. And, it seems to interest many on the list. Don't forget that there seem to be many who strongly opose your suggestion. Myself included. -Andrei http://www.gravitonic.com/ * The best source is the source code. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002 08:57:33 -0500 Andrei Zmievski [EMAIL PROTECTED] wrote: Don't forget that there seem to be many who strongly opose your suggestion. Myself included. Same here (strongly oppose). pierre -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] Redirect on Error
Alrighty :) I'm not going to force-feed localization down anyone's throat myself, and since there are some who seem almost pissed at the idea... Well :) Looks like there's just not a need for it. Anyway... So what of my actual patch we were discussing at some point? I never got a real answer as to if it would be suitable to commit. John -Original Message- From: James Aylett [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 6:36 AM To: 'PHP Developers Mailing List' Subject: RE: [PHP-DEV] [PATCH] Redirect on Error From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On What is so hard to understand in word 'FATAL'? If your script doesn't work, what use is it to make it show the cryptic 500 error?? I'm -10 for adding anything like this, even if and even more then if it's optional. Returning a 500 is one of the easiest ways to automatically audit of fatal problems in your script, because it is (usually) pretty trivial to grab such status codes out of the access log. This is incredibly useful in build and test environments (we have automated processes trawling the logs on our dev, stage and production servers looking for problems). Indeed, you could go a step further with an ISAPI or Apache custom error handler (and presumably NSAPI, which I don't have experience of) to have immediate notification (useful if you've got a bunch of non-technical people testing out an interface). From a user point of view, you can return an entity (say, an HTML page) with a 500 error. Yes, this requires output buffering, but since this is all being mooted as an optional variant on error handling, that really shouldn't be counted against it. From the point of view of a non-human agent accessing such a page, you really /should/ return 500 so it's obvious that the request wasn't serviced properly. Returning an unparseable mess of pseudo-HTML really isn't useful in that many circumstances. I'm not qualified to comment on how feasible this sort of thing is for PHP, especially on all the SAPIs it supports, but as a user of PHP it is an option I'd be interested in. Cheers, James --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.370 / Virus Database: 205 - Release Date: 05/06/2002 ___ _ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ _ -- 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] [PATCH] Redirect on Error
At 03:21 PM 11/25/2002 -0500, Sterling Hughes wrote: If this thread was about error messages of a C compiler, I would agree that users can be expected to understand English. That is a completely different level you are dealing with then. However, PHP needs to take beginners into account. Simply assuming that everyone must understand English is arrogant. Whereas assuming that PHP users are too stupid to understand english is not at all arrogant? :) PHP is used by people around the world; it is used by many as first computer language who just started out to conquer a new area of knowledge. They do not necessarily speak English adequatly or are able to make sense of technical English terms. fine - provide documentation / translations for what these error codes mean in the documentation (on a per-translation basis, or in an extra page listing all the translation). php_error_docref() already does this I believe (cookie variable, or just click on the link). This issue came up years ago with a certain operating system. If localized error messages are provided, they must be presented together with a unique message id. That unique token enables people who speak a different language to interprete the error code/message and provide support/answers as necessary. Great, I'll look up IE55343 everytime i get a question about an undefined variable. What you're missing is that currently to program PHP, you need a reasonable understanding of english. To my knowledge mandarin does not have the string length, most everything in the programming world is in english, therefore, a basic understanding of english becomes a prerequisite. Educate users to speak the base amount of english required, I18N'ing the language is just going to lead to headaches from a user perspective (incorrect translations, slower performance, translations for english speakers) and a developer perspective (having to lookup tokens, understanding another language, getting bug reports with horrible error messages). The whole i18n thing can be solved by just listing the translations of the error codes on the doc page, let's do that, instead of bloating the PHP infrastructure. I'm 100% with Sterling on this one. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Thu, 2002-11-21 at 23:42, Jani Taskinen wrote: What is so hard to understand in word 'FATAL'? If your script doesn't work, what use is it to make it show the cryptic 500 error?? I'm -10 for adding anything like this, even if and even more then if it's optional. Just forget this. How much Kossu does it take to have a -10 voting power? ;-) - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 2002-11-26 at 02:03, Maxim Maletsky wrote: On Mon, 25 Nov 2002 22:18:32 +0100 (CET) Derick Rethans [EMAIL PROTECTED] wrote: On Mon, 25 Nov 2002, Sascha Schumann wrote: Frankly, so far the discussion has been primarily developer-focused, which is not too surprising. The developers are rarely exposed to support requests from newbies in various non-English forums. Thank god not; would you like to see your bugreports in french, or hebrew or finnish? If the error message is in a foreign language, people are going to report bugs in that language too, and I dont think QA is waiting for that. Even with an error number attached is going to be annoying; I myself would not even bother. If PHP is supposed to become easier to use, then native language error messages would be a big hit. Who says that PHP needs to be even easier then it already is? I think with the millions of users there are we're doing pretty okay I'd say. This can be easily avoided. When I have to report an Oracle error in Italian on an English page, I simply type the error code. We need to introduce error codes in PHP, that would really solve the trouble. If we go for errno-style error codes, they will be context-sensitive, that is they have a meaning only when you know what call caused the code. ODBC-style error messages are less context-sensitive, but again more complex. It is unrealistic to think that good, localized, error messages can be done through just a code abstraction. That being said, I don't buy into the localized error message argumentation. I realize that PHP is being, or has the potential of being, used by people with poor English skills, but the language itself, along with its close to 2000 bundled functions, is in English. Would Italian error messages really make PHP more accessible for Italians when the functionfor getting stream context options is called stream_context_get_options()? PHP-generated error messages are for developers after all. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 2002-11-26 at 14:57, Andrei Zmievski wrote: On Tue, 26 Nov 2002, Edin Kadribasic wrote: On Tue, 26 Nov 2002, Maxim Maletsky wrote: I rather propose. And, it seems to interest many on the list. Don't forget that there seem to be many who strongly opose your suggestion. Myself included. -1 on localized error messages +1 on errno-style error codes (for PHP 5) - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Wed, 27 Nov 2002, Stig S. Bakken wrote: On Tue, 2002-11-26 at 14:57, Andrei Zmievski wrote: On Tue, 26 Nov 2002, Edin Kadribasic wrote: On Tue, 26 Nov 2002, Maxim Maletsky wrote: I rather propose. And, it seems to interest many on the list. Don't forget that there seem to be many who strongly opose your suggestion. Myself included. -1 on localized error messages +1 on errno-style error codes -1 on errno-style error codes. They are not versatile enough or easy to manage. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On 27 Nov 2002 00:54:59 +0100 Stig S. Bakken [EMAIL PROTECTED] wrote: On Tue, 2002-11-26 at 14:57, Andrei Zmievski wrote: On Tue, 26 Nov 2002, Edin Kadribasic wrote: On Tue, 26 Nov 2002, Maxim Maletsky wrote: I rather propose. And, it seems to interest many on the list. Don't forget that there seem to be many who strongly opose your suggestion. Myself included. -1 on localized error messages +1 on errno-style error codes (for PHP 5) - Stig Yeah, let's then vote: +0.5 localizing (oh well, got convinced it won't happen for now) +1.0 error codes --- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 2002-11-26 at 02:15, Maxim Maletsky wrote: On Tue, 26 Nov 2002 00:30:55 +0200 (EET) Jani Taskinen [EMAIL PROTECTED] wrote: Just forget this. I'm not native english speaker, but I REALLY don't want to see any errors in any other language but english. (does Perl/Python/etc have multi-lingual errors btw?) --Jani The world's most powerful database server does - Oracle. And, just type something out of the place and you will get them dozens :) So what, PHP and Oracle are different worlds: PHP humbly relies on volunteers spending their precious spare time. Oracle hire and fire people. I'm not saying that localized error messages are bad, I just don't think it's right for PHP to have them, at least not now, and at least not with the maintenance/support overhead it gives us. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 2002-11-26 at 12:11, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : IMO it doesn't improve anything; people who don't want to understand undefined function also dont want to understand undefiniertes Funktion, it's all arabic techo-speak for them anyway. Then how does it help if you explain either undefined function or undefiniertes Funktion to them? It is just as true. But, there is also another side of the coin - having errors internationalized will sound like PHP-translated not only DOCS translated - an extra tool to tell that Open Source cares of usability. I don't care what others think about the usability, I only know that adding these localized things brings more work for me when working on PHP. That sounds selfish of us, Derick. How on earth can you say that? Derick has received an _throphy_ for spending his spare time on the painful process of managing PHP releases, he knows what he is talking about, and it is not a selfish opinion. Maintenance overhead hurts PHP. And our maint.overhead curve is going up. We should strive to _reduce_ that overhead, not increase it. That way php-dev will be more productive and give even the our users what they really need: a (continously) solid product. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 2002-11-26 at 13:31, Sascha Schumann wrote: I think starting with a concrete proposal before it's not clear if we even want this localized errors thing seems rather time-wasting. What you call bickering, I call discussing, and IMO we're not yet done discussing if we want this at all. Well, there won't be a consensus regarding i18n facilities any time soon on php-dev. I can post some hilarious quotes from your funny IRC channel to demonstrate that point. Hence, the only way to move this forward is to actually code something up and enable extension authors to provide i18n error messages. The first step consists of adding the necessary look-up code to PHP itself; the second step is building the infrastructure for maintaining and generating message catalogues; the third step consists of assigning error codes to extensions; and as the final step, translators can actually commence to build the message catalogues. What is the point of doing all this work if php-dev rejects it? - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On 27 Nov 2002 01:49:54 +0100 Stig S. Bakken [EMAIL PROTECTED] wrote: On Tue, 2002-11-26 at 12:11, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : IMO it doesn't improve anything; people who don't want to understand undefined function also dont want to understand undefiniertes Funktion, it's all arabic techo-speak for them anyway. Then how does it help if you explain either undefined function or undefiniertes Funktion to them? It is just as true. But, there is also another side of the coin - having errors internationalized will sound like PHP-translated not only DOCS translated - an extra tool to tell that Open Source cares of usability. I don't care what others think about the usability, I only know that adding these localized things brings more work for me when working on PHP. That sounds selfish of us, Derick. How on earth can you say that? Derick has received an _throphy_ for spending his spare time on the painful process of managing PHP releases, he knows what he is talking about, and it is not a selfish opinion. I am in no way insulting Derick for his great work. Caring of usability is what I also think of an importance. Open Source is very often critized for that - we should care, IMO. Maintenance overhead hurts PHP. And our maint.overhead curve is going up. We should strive to _reduce_ that overhead, not increase it. That way php-dev will be more productive and give even the our users what they really need: a (continously) solid product. As you said - PHP is a big project and maintainance overhead hurts it. Just this is not the limit, I think - we can add such innovations as error codes on upcoming major releases. Unless a common agreement isn't reached. --- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
The question is: why would your production code have fatal errors? A fatal error occurs because of one of the following reasons: 1) parse error 2) engine instability 3) segfault (well, kinda, its nothing catchable, but it is about as fatal as you can get :) 2 3 are very very rare cases, and are almost always bugs in PHP itself. case 1, well, if you've tested your code properly (or at all) you shouldn't be getting this error... I don't get why revising the error scheme (even Maxim's proposal) is really that useful, it seems like a lot of extra work for something that is good enough (i'd say ideal). As for multi-lingual errors, no, no, no, no, no! ohh yeah, and no! I can just imagine the support requests coming to php-general@ (and my private inbox, which unfortunately gets comparable traffic these days) with foreign error strings. Most programming is in english these days, including function names, external libraries, classes, etc. Also, to implement this with any reasonable efficiency, we couldn't use dynamic locales, which will make it quite annoying for external contractors to work on pieces of code. Multi-lingual error codes open's up pandora's box, let's not go there. In conclusion to both (imho):: English is fine. Uncatcheable parse errors is also fine. -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] Redirect on Error
Multi-lingual error codes open's up pandora's box, let's not go there. I have to disagree with you here Sterling. Worrying about support for non-english errors in php-general, etc is a bad, bad excuse not to implement them. The benefits of a completely constant-based error system (with human-friendly errors just because we like them) is worth consideration and I really feel is a positive addition to PHP. The only pandora's box your worried about (at least from the sound of your e-mail) was your inbox size ;) Or am I missing something? In conclusion to both (imho):: English is fine. Uncatcheable parse errors is also fine. ?php $answer = ($fine == $best); echo Result: $answer; ? Result: false ;) John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Multi-lingual error codes open's up pandora's box, let's not go
there.
I have to disagree with you here Sterling. Worrying about support for
non-english errors in php-general, etc is a bad, bad excuse not to
implement them. The benefits of a completely constant-based error system
(with human-friendly errors just because we like them) is worth
consideration and I really feel is a positive addition to PHP. The only
pandora's box your worried about (at least from the sound of your
e-mail) was your inbox size ;) Or am I missing something?
you're missing alot.
Its not inbox size, when you get multi-lingual error messages you have more
than one problem.
1) Support. This makes it hell for companies and users alike to support.
Sure, there are localized mailing lists, but chances are if you are a
programmer these days you can at least read english enough to understand
the error messages. English is soo prevelant in the computer world (ie,
terminology is most often borrowed, unless your french and send Courier
Electronique messages), that its really a non-issue. Also finding a
translation of the error messages shouldn't be that hard.
If you want to support a multilingual error messages, perhaps a page that
translates all the error messages for multi-lingual users to look up the
translation is a good medium, but putting it into php leads to our next
problem.
2) Implementation. Compile time generation of error messages is a very
bad thing, changing error messages on a binary can lead to a pain in the
ass when you need to take over a project, and *gasp* all the error
messages are in Mandarin, english translations of errors should always
be available.
If you do this at execution time, you either need an extra php function
set_error_language(), which is kinda silly, or you need to respect locales
which isn't thread safe. Add to that the overhead of parsing the error
messages for every language, and execution time really doesn't become a
reality.
Also, you have translator error in many cases. I know plenty of people
from other countries who go to google.com/en, just to force the language
to english. If the translator makes a slight error in the translation,
you've just given the end user a headache and a half trying to figure out
where the undefined function was, even though it was an undefined variable :)
3) Everything else is in english. Well, ok, the documentation is partially
translated, but most things in the programming world are english. Chances
are that users can learn what the error messages are without much trouble,
at least its easy enough to counterbalance the amount of effort required
to properly internationalize error messages.
In conclusion to both (imho)::
English is fine. Uncatcheable parse errors is also fine.
?php
$answer = ($fine == $best);
echo Result: $answer;
?
Result: false
?php
if (!isset($question)) {
print Who cares about the answer\n;
}
?
Result: Who cares about the answer
These things should really come about via necessity. I very rarely see
the question how can i catch parse errors on my production site, if
you really need, you can turn off display_errors, and that should do it.
The fact is, you shouldn't be needing code to catch a parse error, if you
do, there is something wrong with the way you program, not with php.
-Sterling
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On November 25, 2002 01:58 pm, John Coggeshall wrote: Multi-lingual error codes open's up pandora's box, let's not go there. I have to disagree with you here Sterling. Worrying about support for non-english errors in php-general, etc is a bad, bad excuse not to implement them. The benefits of a completely constant-based error system (with human-friendly errors just because we like them) is worth consideration and I really feel is a positive addition to PHP. The only pandora's box your worried about (at least from the sound of your e-mail) was your inbox size ;) Or am I missing something? In conclusion to both (imho):: English is fine. Uncatcheable parse errors is also fine. I for one completely agree with Sterling. Localization of errors in wrong because it creates an inconsistent behavior, each user will see a different error depending on the locale they are using. This will not only make things confusing but make resolving bugs errors so much more difficult for both PHP developers as well as users themselves. Consider that a hosting provider in France decides to compile their PHP with error messages localized in French. Suddenly all their non-French speaking clients of that provider cannot understand what the PHP error messages say. Not only that. but what will happen with distributable PHP applications when a user reports an error to the developer(s) and that error is localized. 9 out of 10 times the developer will ignore the report because he has no clue what the error means. Most common fatal error is a parse error, it is the result of carelessness. In a production enviroment there is no reason why it should happen. I see no reason to add complex redirection code which only obfuscated the cause of the problem. Most people don't associate error 500 with a PHP process, this is usually something reserved to CGI, meaning that people will look for the cause of the problem in the completely wrong place. As for adding XML and other nastiness, why?!?! Error reporting should be dead simple and not involve compile time or realtime parsing and so on. Ideally the error reporting mechanism would set an error code inside $php_errno and then a user can either handle the error themselves in a appropriate manner or use something akin to php_errno(); to display the text explanation for the error itself (this is a bastardized version of the error reporting mechanism proposed by Stig Bakken). Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Mon, 25 Nov 2002, Sterling Hughes wrote: I have to disagree with you here Sterling. Worrying about support for non-english errors in php-general, etc is a bad, bad excuse not to implement them. The benefits of a completely constant-based error system (with human-friendly errors just because we like them) is worth consideration and I really feel is a positive addition to PHP. The only pandora's box your worried about (at least from the sound of your e-mail) was your inbox size ;) Or am I missing something? you're missing alot. Its not inbox size, when you get multi-lingual error messages you have more than one problem. 1) Support. This makes it hell for companies and users alike to support. Sure, there are localized mailing lists, but chances are if you are a programmer these days you can at least read english enough to understand the error messages. English is soo prevelant in the computer world (ie, terminology is most often borrowed, unless your french and send Courier Electronique messages), that its really a non-issue. Also finding a translation of the error messages shouldn't be that hard. If you want to support a multilingual error messages, perhaps a page that translates all the error messages for multi-lingual users to look up the translation is a good medium, but putting it into php leads to our next problem. And don't forget the poor folks at PHP QA who suddenly have to understand 22 languages, as 'programmers' who get error message assume that they can report bugs in that language too. The fact is, you shouldn't be needing code to catch a parse error, if you do, there is something wrong with the way you program, not with php. +1 on that. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - The 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] [PATCH] Redirect on Error
Sterling Hughes writes: you're missing alot. Its not inbox size, when you get multi-lingual error messages you have more than one problem. 1) Support. [snip] 2) Implementation. [snip] 3) Everything else is in english. [snip] There are other problems too, but these are the biggies. Can't imagine what this'll do to the workload for the QA folks. I can appreciate the motive for multi-language error messages, but its asking for trouble on a huge scale. If english is good enough for programmers and air traffic controllers all over the world, its good enough for PHP error messages. :) These things should really come about via necessity. I very rarely see the question how can i catch parse errors on my production site, if you really need, you can turn off display_errors, and that should do it. Yup. When used with the logging stuff [syslog,logfile], it works quite well. The fact is, you shouldn't be needing code to catch a parse error, if you do, there is something wrong with the way you program, not with php. Bingo. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
If this thread was about error messages of a C compiler, I would agree that users can be expected to understand English. That is a completely different level you are dealing with then. However, PHP needs to take beginners into account. Simply assuming that everyone must understand English is arrogant. PHP is used by people around the world; it is used by many as first computer language who just started out to conquer a new area of knowledge. They do not necessarily speak English adequatly or are able to make sense of technical English terms. This issue came up years ago with a certain operating system. If localized error messages are provided, they must be presented together with a unique message id. That unique token enables people who speak a different language to interprete the error code/message and provide support/answers as necessary. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
If this thread was about error messages of a C compiler, I would agree that users can be expected to understand English. That is a completely different level you are dealing with then. However, PHP needs to take beginners into account. Simply assuming that everyone must understand English is arrogant. Whereas assuming that PHP users are too stupid to understand english is not at all arrogant? :) PHP is used by people around the world; it is used by many as first computer language who just started out to conquer a new area of knowledge. They do not necessarily speak English adequatly or are able to make sense of technical English terms. fine - provide documentation / translations for what these error codes mean in the documentation (on a per-translation basis, or in an extra page listing all the translation). php_error_docref() already does this I believe (cookie variable, or just click on the link). This issue came up years ago with a certain operating system. If localized error messages are provided, they must be presented together with a unique message id. That unique token enables people who speak a different language to interprete the error code/message and provide support/answers as necessary. Great, I'll look up IE55343 everytime i get a question about an undefined variable. What you're missing is that currently to program PHP, you need a reasonable understanding of english. To my knowledge mandarin does not have the string length, most everything in the programming world is in english, therefore, a basic understanding of english becomes a prerequisite. Educate users to speak the base amount of english required, I18N'ing the language is just going to lead to headaches from a user perspective (incorrect translations, slower performance, translations for english speakers) and a developer perspective (having to lookup tokens, understanding another language, getting bug reports with horrible error messages). The whole i18n thing can be solved by just listing the translations of the error codes on the doc page, let's do that, instead of bloating the PHP infrastructure. -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
hi,
What you're missing is that currently to program PHP, you need a reasonable
understanding of english. [..]
I agree with Sterlin. I mean, what's next? Also localize language constructs?
?php
während (EUR i=0; EUR i5; ++EUR i) {
ausgabe(Hallo);
wenn (EUR i % 5) {
[..]
}
}
Uah.. terrible.
-daniel
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Whereas assuming that PHP users are too stupid to understand english is not at all arrogant? :) Wrong, Sterling. Beginning PHP users might neither have formal education in computer science _nor_ foreign languages. The reason here is not about intellect; it is about requiring certain knowledge. Presuming that someone else must speak your language is quite self-centered. Alas, if your view was correct (users must understand English), then we could just scrap the whole translation effort. I don't think that it's realistic. What you're missing is that currently to program PHP, you need a reasonable understanding of english. I don't think so. The translations of the PHP manual do a fine job at relaying all necessary information about programming in PHP to speakers of foreign languages. Educate users to speak the base amount of english required, I18N'ing the language is just going to lead to headaches from a user perspective (incorrect translations, slower performance, translations for english speakers) The performance is negligible -- error messages are displayed during the development phase, not in a production environment where run-time behaviour is important. The incorrect translations argument applies to all translations, regardless where and when they are displayed. Online translations can be centrally maintained, of course, which is an advantage. This can be addressed by providing stand-alone message catalogues which can be downloaded by administrators. and a developer perspective (having to lookup tokens, understanding another language, getting bug reports with horrible error messages). The whole i18n thing can be solved by just listing the translations of the error codes on the doc page, let's do that, instead of bloating the PHP infrastructure. Frankly, so far the discussion has been primarily developer-focused, which is not too surprising. The developers are rarely exposed to support requests from newbies in various non-English forums. If PHP is supposed to become easier to use, then native language error messages would be a big hit. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Mon, 25 Nov 2002, Daniel Lorch wrote:
hi,
What you're missing is that currently to program PHP, you need a reasonable
understanding of english. [..]
I agree with Sterlin. I mean, what's next? Also localize language constructs?
Dont you ever steal my jokes again :) But indeed, this would be the next
step...
?php
während (EUR i=0; EUR i5; ++EUR i) {
ausgabe(Hallo);
wenn (EUR i % 5) {
[..]
}
}
Uah.. terrible.
Definitely :)
derick
--
-
Derick Rethans http://derickrethans.nl/
PHP Magazine - The 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] [PATCH] Redirect on Error
On Mon, 25 Nov 2002, Sascha Schumann wrote: Frankly, so far the discussion has been primarily developer-focused, which is not too surprising. The developers are rarely exposed to support requests from newbies in various non-English forums. Thank god not; would you like to see your bugreports in french, or hebrew or finnish? If the error message is in a foreign language, people are going to report bugs in that language too, and I dont think QA is waiting for that. Even with an error number attached is going to be annoying; I myself would not even bother. If PHP is supposed to become easier to use, then native language error messages would be a big hit. Who says that PHP needs to be even easier then it already is? I think with the millions of users there are we're doing pretty okay I'd say. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - The 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] [PATCH] Redirect on Error
On Mon, 25 Nov 2002, Daniel Lorch wrote: hi, What you're missing is that currently to program PHP, you need a reasonable understanding of english. [..] I agree with Sterlin. I mean, what's next? Also localize language constructs? Daniel, Sterling is arguing in favor of having localized error messages. There is only disagreement about _where_ to provide these messages from. From my background, I can just say that having localized error messages is invaluable. They need to be accessible all the time though. You certainly don't want your developers to sit around and twist their thumbs because the WAN link is down or php.net stopped responding due to full harddisks. Adding such an external requirement is great in a place where you are online all the time. In many parts of the world, that is unrealistic though. But since a certain mindset seems to be prevailing here, localized (inline) error messages will continue to be the domain of professional tools. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Whereas assuming that PHP users are too stupid to understand english is not at all arrogant? :) Wrong, Sterling. Beginning PHP users might neither have formal education in computer science _nor_ foreign languages. The reason here is not about intellect; it is about requiring certain knowledge. Presuming that someone else must speak your language is quite self-centered. Alas, if your view was correct (users must understand English), then we could just scrap the whole translation effort. I don't think that it's realistic. Not at all, i don't expect them to speak fluent english, just to understand the small subset of english errors and programming terms. I've conversed with plenty of PHP users (second-hand at least) where they didn't know english, yet understood the error codes. Users need not know english, they can download a quicksheet. If you see Constant 3 And I tell you it means: Undefined constant, assuming string after a while that term will become like your own language, especially if its as simple as copying pasting, and clicking search. What you're missing is that currently to program PHP, you need a reasonable understanding of english. I don't think so. The translations of the PHP manual do a fine job at relaying all necessary information about programming in PHP to speakers of foreign languages. And they'll do a fine job of explaining the error codes too. Educate users to speak the base amount of english required, I18N'ing the language is just going to lead to headaches from a user perspective (incorrect translations, slower performance, translations for english speakers) The performance is negligible -- error messages are displayed during the development phase, not in a production environment where run-time behaviour is important. how do you see this being implemented? The incorrect translations argument applies to all translations, regardless where and when they are displayed. Online translations can be centrally maintained, of course, which is an advantage. This can be addressed by providing stand-alone message catalogues which can be downloaded by administrators. yes, if they update it. If its in the docs, you don't really have to worry about users using an outdated version of the translation. and a developer perspective (having to lookup tokens, understanding another language, getting bug reports with horrible error messages). The whole i18n thing can be solved by just listing the translations of the error codes on the doc page, let's do that, instead of bloating the PHP infrastructure. Frankly, so far the discussion has been primarily developer-focused, which is not too surprising. The developers are rarely exposed to support requests from newbies in various non-English forums. If PHP is supposed to become easier to use, then native language error messages would be a big hit. I agree. Unfortunately I think you mean a big bonus. :))) -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
At 21:21 25.11.2002, Sterling Hughes wrote: If this thread was about error messages of a C compiler, I would agree that users can be expected to understand English. That is a completely different level you are dealing with then. However, PHP needs to take beginners into account. Simply assuming that everyone must understand English is arrogant. Whereas assuming that PHP users are too stupid to understand english is not at all arrogant? :) PHP is used by people around the world; it is used by many as first computer language who just started out to conquer a new area of knowledge. They do not necessarily speak English adequatly or are able to make sense of technical English terms. fine - provide documentation / translations for what these error codes mean in the documentation (on a per-translation basis, or in an extra page listing all the translation). php_error_docref() already does this I believe (cookie variable, or just click on the link). php_error_docref() simply points to the function descriptions. But there could be error descriptions which would then be translated. However most of us do not describe errors and errors are changing sometimes marcus This issue came up years ago with a certain operating system. If localized error messages are provided, they must be presented together with a unique message id. That unique token enables people who speak a different language to interprete the error code/message and provide support/answers as necessary. Great, I'll look up IE55343 everytime i get a question about an undefined variable. What you're missing is that currently to program PHP, you need a reasonable understanding of english. To my knowledge mandarin does not have the string length, most everything in the programming world is in english, therefore, a basic understanding of english becomes a prerequisite. Educate users to speak the base amount of english required, I18N'ing the language is just going to lead to headaches from a user perspective (incorrect translations, slower performance, translations for english speakers) and a developer perspective (having to lookup tokens, understanding another language, getting bug reports with horrible error messages). The whole i18n thing can be solved by just listing the translations of the error codes on the doc page, let's do that, instead of bloating the PHP infrastructure. -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
fine - provide documentation / translations for what these error codes mean in the documentation (on a per-translation basis, or in an extra page listing all the translation). php_error_docref() already does this I believe (cookie variable, or just click on the link). php_error_docref() simply points to the function descriptions. But there could be error descriptions which would then be translated. However most of us do not describe errors and errors are changing sometimes Right. When the user gets to the function descriptions, they can then click on the language they wish to see that in (and I believe a cookie is created when you do that, so you always see the manual in your language). -Sterling marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
hi, Daniel, Sterling is arguing in favor of having localized error messages. s/agree/disagree/ :) Do what you think is right. However, I think it just adds another level of unnecessary complexity. We can safely assume a certain level of intelligence when dealing with php developers (developers as in developing IN PHP). PHP is not a application as in Windows XP or Media Player, but it's a development environment where the users necessarily has to be confronted with a couple of error messages. For the sake of brevity, these are kept in english and this shouldn't change, IMAO. Developers don't have to be spoon-fed. Really. -daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
I'm a bit late here, with an example which probably sounds interesting;
that is a computer language which was actually developed in Japan as a
product mainly for educational use, which enables you to program in nearly
complete Japanese syntax. I thnik it's undoubtfully great, but I have
never seen it become popular by now.
I guess part of the reason is that most of the folks there take it for
granted that they have to be familiar with English as well as the
behaviour of the computer.
Anyway, I'm +0 for the localization of messages.
Moriyoshi
Daniel Lorch [EMAIL PROTECTED] wrote:
hi,
What you're missing is that currently to program PHP, you need a reasonable
understanding of english. [..]
I agree with Sterlin. I mean, what's next? Also localize language constructs?
?php
während (EUR i=0; EUR i5; ++EUR i) {
ausgabe(Hallo);
wenn (EUR i % 5) {
[..]
}
}
Uah.. terrible.
-daniel
--
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] [PATCH] Redirect on Error
On Monday 25 November 2002 21:55, Sascha Schumann wrote: Whereas assuming that PHP users are too stupid to understand english is not at all arrogant? :) Wrong, Sterling. Beginning PHP users might neither have formal education in computer science _nor_ foreign languages. Perfectly true. Some people just lack education, or are too young or too old. The average newbie: - uses M$ Windows - with a WAMP-all-in-one package, or, failing to know such things exist, uploads to some free webspace for testing - thinks PHP-Nuke is the high art of programming - doesn't even know that there is such a thing as a manual I happen to help these people rather often... there are a lot of them. If you just put a translation online... believe me, they're never going to find it. The people who will find it probably won't need it. If you want these people to find this translation, you'd have to put the url into every error-message. And provide a way to change the root-url, so it can be downloaded The strength of PHP is that, for some reason, it's so easy to use that even people with no programming background at all use it, very often with a complete lack of skill and a minimum of effort. From the perspective of newbies, translated error-messages are definately the right thing (tm). If you want them to find the translation, you have to present it in a way that they cannot possibly miss it. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
I'm not really arguing for or against this, but since when did speaking english become a corollary of being intelligent? And even if we accept the rather ridiculous hypotheis that all php developers can comprehend english, what if they don't want to, or are more confident using their native tongue in day-to-day work? Why deny that to them on prinicple? Plenty of products support multi-lingual errors in the way John describes. In fact there's an argument that constant-based error codes are even easier to describe than verobose english descriptions, as they leave no room for ambiguity due to re-phrasing. Daniel Lorch wrote: hi, Daniel, Sterling is arguing in favor of having localized error messages. s/agree/disagree/ :) Do what you think is right. However, I think it just adds another level of unnecessary complexity. We can safely assume a certain level of intelligence when dealing with php developers (developers as in developing IN PHP). PHP is not a application as in Windows XP or Media Player, but it's a development environment where the users necessarily has to be confronted with a couple of error messages. For the sake of brevity, these are kept in english and this shouldn't change, IMAO. Developers don't have to be spoon-fed. Really. -daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
I'm not really arguing for or against this, but since when did speaking english become a corollary of being intelligent? And even if we accept the rather ridiculous hypotheis that all php developers can comprehend english, what if they don't want to, or are more confident using their native tongue in day-to-day work? Why deny that to them on prinicple? Well, speaking english as a corollary for intelligence, perhaps not, education most likely. I've spoken to very few PhDs abroad that don't speak english, I've spoken to quite a few Supermarket checkout people that don't speak english. But that's another discussion. :-) Plenty of products support multi-lingual errors in the way John describes. In fact there's an argument that constant-based error codes are even easier to describe than verobose english descriptions, as they leave no room for ambiguity due to re-phrasing. They also make it incredibly unintuitive :) There needs to be a medium between maintainability and sanity. Understanding basic english can be a requirement. If they really have problems, they can read the docs which explain the errors to users who don't speak english... The question is - what language does this different? Perl, Python, Ruby, Java, C++, C all have english only error messages. Anyhow, until someone comes up with a viable implementation, the thought of whether this belongs in the language is pretty much right. :) -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
hi, I'm not really arguing for or against this, but since when did speaking english become a corollary of being intelligent? And even if we accept the rather ridiculous hypotheis that all php developers can comprehend english, what if they don't want to, or are more confident using their native tongue in day-to-day work? Why deny that to them on prinicple? I wasn't trying to equate intelligence with the knowledge of a language (ok, I did, but that wasn't my point, really). We are arguing about implementing localized error messages, because we think it will a) attract more people to PHP b) faciliate their (and our) lives While I think that localization can bring SOME advantages, the disadvantages will overweigh. Error messages are really very brief and only consist of a few words, which can be quickly looked up. However, what about the maintenance headache when you are assigned to a project written in a foreign language? I would prefer to have the developers getting used (yes, meaning educate them) to english being a universal language, for both the language constructs, error messages, documentation. This will be more advantageous in the long run. -daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
I almost agree with you, but please note that error message translation is not always the simple thing because the word order varies by language. For example, Warning: Argument %1 to array_diff() is not an array in - on line %2 the above message should be translated into Japanese romaji script as following: Keikoku: %2 gyou me - array_diff() no %1 banme no hikisu ga hairetsu de ha arimasen. %2 gyou me means line %2, and %1 banme no hikisu means Argument %1, where gyou me and banme are suffixes that indicate the order of subjects. This trivial example implies that sprintf() cannot be used for error message reporting at all in this case, which may result in a mess. Regards, Moriyoshi Alexander Wagner [EMAIL PROTECTED] wrote: On Monday 25 November 2002 21:55, Sascha Schumann wrote: Whereas assuming that PHP users are too stupid to understand english is not at all arrogant? :) Wrong, Sterling. Beginning PHP users might neither have formal education in computer science _nor_ foreign languages. Perfectly true. Some people just lack education, or are too young or too old. The average newbie: - uses M$ Windows - with a WAMP-all-in-one package, or, failing to know such things exist, uploads to some free webspace for testing - thinks PHP-Nuke is the high art of programming - doesn't even know that there is such a thing as a manual I happen to help these people rather often... there are a lot of them. If you just put a translation online... believe me, they're never going to find it. The people who will find it probably won't need it. If you want these people to find this translation, you'd have to put the url into every error-message. And provide a way to change the root-url, so it can be downloaded The strength of PHP is that, for some reason, it's so easy to use that even people with no programming background at all use it, very often with a complete lack of skill and a minimum of effort. From the perspective of newbies, translated error-messages are definately the right thing (tm). If you want them to find the translation, you have to present it in a way that they cannot possibly miss it. regards Wagner -- codito ergo sum -- 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] [PATCH] Redirect on Error
On Monday 25 November 2002 23:08, Daniel Lorch wrote: I would prefer to have the developers getting used (yes, meaning educate them) to english being a universal language, for both the language constructs, error messages, documentation. Don't. You shouldn't think of PHP-users as developers in this sense. Read my other mail. I mean the don't even want to program and least amount of effort-part. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
