On November 25, 2002 07:57 pm, 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.
Oracle is by far the most bloated piece of software in existence, adopting ideas from it is hardly a good idea. It is so complex, that perhaps localization was the only way they could make it usable for international users. > > Sets the language to what you speak and you will develop faster wherever > you're coming from. > And the next logical step from that would be to develop in the language you speak and this is how you get PHP code that makes Perl look good. Right now code written by French developer can be understood by a Chinese developer, with the eventual evolution of your suggestion understanding code would require the knowledge of the language the author decided to use in addition to PHP. > 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? Bugs imply a problem with either PHP itself or in some cases an application written in PHP. In those cases the person resolving the bug will be the original developer who if he cannot understand the problem will pipe it to /dev/null. I don't know how you evaluate your time, but most people just don't have the time to look up error code XYZ in the big error-code codebook. With PHP we already have enough difficulty resolving the bugs we have, adding more complexity by introducing i18n will only lead to more valid reports being ignored because no one has the time to 'translate' the problem. I mean consider the PHP documentation project, most translations are notoriously behind and even the English translation need much work. Realistically, I think that even if you did introduce i18n in error message most would still remain in English with maybe 20-30% of messages being translated in popular locales like German and French and even lower in less common locales. With such low translation level you are only going to introduce confusion, which is the exact opposite of what you are trying to do. Ilia -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
