At 02:03 26.11.2002, 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.
When using error codes we could supply a error-message-loader.
php_error_docref would than not use fmt parameter but a number.
The modules would then have to register their normal errors.
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.
Main problem left is that we have to stick to error-code naming rules.
We should always use the extensionname followed by a number.
Exeptions would be "main", "standard" and "zend".
marcus
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
