>
> >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
