Re: [PHP-DEV] Concrete suggestion re: i18n messages

2002-11-27 Thread Steph
- Original Message - From: "Sascha Schumann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 26, 2002 11:21 AM Subject: [PHP-DEV] Concrete suggestion re: i18n messages > A possible implementation would look like this: > > A new in

Re: [PHP-DEV] Concrete suggestion re: i18n messages

2002-11-26 Thread Philip Olson
> > No, it does not to me. It means that translators need to have access to > > the php4/ cvs module, which is something I'm very against. > > Agreed.. The default messages stay in the source code and > are easily reachable for the developer. > > (That is something I very much dislik

Re: [PHP-DEV] Concrete suggestion re: i18n messages

2002-11-26 Thread Jani Taskinen
On Tue, 26 Nov 2002, Wez Furlong wrote: >If I wanted localized error messages, then this would be the way to do >it. Perhaps merging this with the php_error_docref might be slightly >better. > >However, I'm personally -1000 on such things; there are many reasons, >most of them have already been r

Re: [PHP-DEV] Concrete suggestion re: i18n messages

2002-11-26 Thread Wez Furlong
If I wanted localized error messages, then this would be the way to do it. Perhaps merging this with the php_error_docref might be slightly better. However, I'm personally -1000 on such things; there are many reasons, most of them have already been raised here, so I won't repeat them now, but the

Re: [PHP-DEV] Concrete suggestion re: i18n messages

2002-11-26 Thread Maxim Maletsky
Derick Rethans <[EMAIL PROTECTED]> wrote... : > On Tue, 26 Nov 2002, Sascha Schumann wrote: > > > > ext/session/errors/en.cat > > > > Sounds good. > > No, it does not to me. It means that translators need to have access to > the php4/ cvs module, which is something I'm very against. I a

Re: [PHP-DEV] Concrete suggestion re: i18n messages

2002-11-26 Thread Sascha Schumann
On Tue, 26 Nov 2002, Derick Rethans wrote: > On Tue, 26 Nov 2002, Sascha Schumann wrote: > > > > ext/session/errors/en.cat > > > > Sounds good. > > No, it does not to me. It means that translators need to have access to > the php4/ cvs module, which is something I'm very against. Agreed..

Re: [PHP-DEV] Concrete suggestion re: i18n messages

2002-11-26 Thread Derick Rethans
On Tue, 26 Nov 2002, Sascha Schumann wrote: > > ext/session/errors/en.cat > > Sounds good. No, it does not to me. It means that translators need to have access to the php4/ cvs module, which is something I'm very against. Derick -- ---

Re: [PHP-DEV] Concrete suggestion re: i18n messages

2002-11-26 Thread Sascha Schumann
> This does not cover message catalogues for extensions yet -- > similar to the ini-directory, the php_error_ex function could > try a number of message catalogues in a defined msg-catalogue > directory, before falling back to the English format message. (I'm referring to separ

Re: [PHP-DEV] Concrete suggestion re: i18n messages

2002-11-26 Thread Sascha Schumann
> ext/session/errors/en.cat Sounds good. > Also, a logic to always use english error as default. Note that the English format messages stay in the source code. This does not cover message catalogues for extensions yet -- similar to the ini-directory, the php_error_ex functio

Re: [PHP-DEV] Concrete suggestion re: i18n messages

2002-11-26 Thread Maxim Maletsky
Sascha Schumann <[EMAIL PROTECTED]> wrote... : > A possible implementation would look like this: > > A new ini setting is added. > > php.error_lang > > A new function is provided. > > php_error_ex(int type, const char *err_code, const char *fmt, ...); > > The

[PHP-DEV] Concrete suggestion re: i18n messages

2002-11-26 Thread Sascha Schumann
A possible implementation would look like this: A new ini setting is added. php.error_lang A new function is provided. php_error_ex(int type, const char *err_code, const char *fmt, ...); The function tries to lookup the key in php-.cat. If it exists, the v