Re: Concrete suggestion re: i18n messages

nope, it needs to be ini_set() -able if we're doing this at all .. either that or we keep English as the hard-coded default and trust that production server admins will see the wisdom of that. I don't get why we can't use an error code and spawn an i8n-friendly docref through it? ----- Original Message ----- From: "Sascha Schumann" <sascha@schumann.cx> To: <php-dev@lists.php.net> 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 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 <err_code> key in > php-<php.error_lang>.cat. If it exists, the value will be > used instead of the format <fmt>. The control is then passed > to php_verror(). > > That sounds like 30-50 additional LOC to me. No bloat in > sight. > > The program which generates the .cat files (gen-cat) will > ensure that the error code is prepended to the format > message. That could be a simple C file with another 50 LOC, > parsing input files of the form > > file: file line | line > line: ERROR-CODE MSG > > Each extension can maintain its own file (e.g. cat.session.nl for > the NL version of the session error messages). During > .cat build-time, a single per-language file is generated and > fed through gen-cat. The result can then be used by PHP. > > There, simple and straight-forward. > > - Sascha > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, visit: http://www.php.net/unsub.php > >