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

[Steph]

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" <[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 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 value will be
> used instead of the format .  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
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 dislike about the current
> phpdoc organization.  Every time I want to change something
> in the main English documentation, I need to hunt around for
> remote, well-hidden xml files.  The docs were more
> up-to-date, if these files were easier to access.)

Please explain this a little more with a few specific
examples.  And please write the phpdoc list with these
concerns.  Maybe the structure can be further explained
in the doc HOWTO.  Sometimes I find going to the URL of
the manual page helps figure out the location:

  www.php.net/manual/en/language.variables.predefined.php
  en/language/variables.xml

  www.php.net/manual/en/tokens.php
  en/appendices/tokens.xml (note it's in appendix in manual)

Finding functions and extension information is easy since the 
big change about seven months ago, for example:

  www.php.net/manual/en/function.{functionname}.xml
  en/reference/{extensionname}/functions/{functionname}.xml

  www.php.net/manual/en/ref.{extensionname}.php
  en/reference/{extensionname}/reference.xml

Adding functions is simple, just go into the appropriate
extensions function directory and add the xml file.  On
a related note, the change/split that happened awhile back:

  Old:  en/functions/{extension}.xml
  New:  en/reference/{extension}/functions/{function}.xml
/ini.xml
/reference.xml
/constants.xml
/functions.xml (autogenerated)

Don't edit functions.xml as it's an autogenerated list. Also
note that the Old files are still in CVS for historical and
archival purposes (the changelogs).

It does take a little getting used to but let's discuss it
a little so php-dev people will feel more comfortable.  It
now seems intuitive to me although it's not perfect and
changes are still in progress.  For example finding some
of the configuration directives can be difficult...

Regards,
Philip


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 raised here, so I won't repeat them now,
>but the main issue is with the maintainability of such a thing;
>localization is very hard to maintain on a volunteer basis (just look at
>our manual).
>
>For something as important as error messages, it is better to have the
>"definitive" error message in english and then take advantage of the
>hyperlink generated by php_error_docref which will display more detailed
>information in the localized manual.

+ for this. It's already there, so
let's use it and forget this nonsense of adding some extra work
for developers.

--Jani



>--Wez.
>
>On Tue, 26 Nov 2002, Sascha Schumann 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 function tries to lookup the  key in
>> php-.cat.  If it exists, the value will be
>> used instead of the format .  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 
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>>
>
>
>

-- 
<- For Sale! ->


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 main issue is with the maintainability of such a thing;
localization is very hard to maintain on a volunteer basis (just look at
our manual).

For something as important as error messages, it is better to have the
"definitive" error message in english and then take advantage of the
hyperlink generated by php_error_docref which will display more detailed
information in the localized manual.

--Wez.

On Tue, 26 Nov 2002, Sascha Schumann 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 function tries to lookup the  key in
> php-.cat.  If it exists, the value will be
> used instead of the format .  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 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 agree on this fact, though. Can it be somehow built from phpdoc module?


--
Maxim Maletsky
[EMAIL PROTECTED]



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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..  The default messages stay in the source code and
are easily reachable for the developer.

(That is something I very much dislike about the current
phpdoc organization.  Every time I want to change something
in the main English documentation, I need to hunt around for
remote, well-hidden xml files.  The docs were more
up-to-date, if these files were easier to access.)

- Sascha

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 separately installed extensions here, e.g.
from PECL.)

- Sascha

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 function could
try a number of message catalogues in a defined msg-catalogue
directory, before falling back to the English format message.

- Sascha

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 function tries to lookup the  key in
> php-.cat.  If it exists, the value will be
> used instead of the format .  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.

Per-extension thingies sounds nice to me - would make it easier getting the
patches with these errors from users. But, it should be in it own
directories, thought - having 20 .cat files along your .c files would be
boring.


I'd say:

ext/session/errors/en.cat

etc...

Also, a logic to always use english error as default.

> There, simple and straight-forward.




--
Maxim Maletsky
[EMAIL PROTECTED]



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Concrete suggestion re: i18n messages

[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 value will be
used instead of the format .  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 
To unsubscribe, visit: http://www.php.net/unsub.php