On November 25, 2002 08:24 pm, Maxim Maletsky wrote:
> On Mon, 25 Nov 2002 20:14:56 -0500 "Ilia A." <[EMAIL PROTECTED]> wrote:
> > 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.
>
> Complex because does a lot - it is, in a way, an Operating Sytems on its
> own.. But, as you can say yourself - localization of errors does help.
>
> > > 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.
>
> ???? Hello?/?? we're talking about errors here, not page content.
> Hopefuly that does not become the same :)
Actually I am talking in users using their native language to name their
functions & variables and actually write them in that language. So, a person
could use ISO-8859-15 encoding or cp1251 encoding because afterall it is
easier to understand the code that way.
> When you get an error while developing, seeing it in your own language,
> whichever it is - English, Chinese, Russian or Japanese - it will be the
> language you will set it to and thus the best for you, developer. What's
> so wrong with that?
Because when I work on a server where the language is set to Japanese which, I
unfortunately do not know, I will have no idea what the error is.
> > > 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.
>
> 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.
> > 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.
>
> I don't think so. There are much less error strings than manual pages -
> these got tranlsated well, and so will error string.
Really? Let's see on average each function generates @ least one warning
message, so we have @least as many warnings as we have functions. Warning
messages get constantly re-arranged, by having a separate database for them
making changes to warning messages will become more complex then writing the
actual code. So, people will in many cases cut corners and just RETURN_FALSE;
without giving a detailed explanation. Most developers like to write code,
not modify XML files & and write essays for proof look @
http://www.zend.com/phpfunc/statistics.php, according to that page ~14% of
all functions in PHP are not documented in the English language.
Ilia
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
