--- Gabor Hojtsy <[EMAIL PROTECTED]> wrote:
> > May I suggest you just duplicate the entire
> current manual structures for
> > the new manual(s) and don't add any translation
> directories. That way
> when
> > someone decides they have to have the new manual
> in their native language
> > you d
> May I suggest you just duplicate the entire current manual structures for
> the new manual(s) and don't add any translation directories. That way
when
> someone decides they have to have the new manual in their native language
> you don't have to work so hard to support it. They will eventuall
At 03:40 AM 8/12/02 -0700, Jesus M. Castagnetto wrote:
>1) Language Reference
>
>2) Functions Reference (aka Library Reference)
>
>3) PHP Internals and Extension Development
fwiw +1 on this.
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/un
At 12:22 PM 8/12/02 +0200, Gabor Hojtsy wrote:
> > > +1 @goba for his suggestion of splitting
> > +1 (wasn't that discussed during the doc meeting?)
>
>We talked about something like this, but putting up a build
>system without translation support is completely different
>than thinking about trans
On Mon, 12 Aug 2002, Jesus M. Castagnetto wrote:
> In any case, if you really want to be clear on what
> you mean, we should have the following:
>
> 1) Language Reference
>
> 2) Functions Reference (aka Library Reference)
>
> 3) PHP Internals and Extension Development
I like this division. Th
> Hmm, ambiguous? Maybe I am missing something and
> "Developer" == "User" in a non-English and non-Spanish
> European/Slavic/Oriental language?
The problem is that a major part of our user base think that
they develop IN PHP, so they are PHP developers... Just search
for "java developer" or "c d
--- Gabor Hojtsy <[EMAIL PROTECTED]> wrote:
> > > +1 @goba for his suggestion of splitting
> > +1 (wasn't that discussed during the doc meeting?)
>
> We talked about something like this, but putting up
> a build
> system without translation support is completely
> different
> than thinking about
> > +1 @goba for his suggestion of splitting
> +1 (wasn't that discussed during the doc meeting?)
We talked about something like this, but putting up a build
system without translation support is completely different
than thinking about translations. So the real question now
is if everybody agree
Hi,
On Mon, Aug 12, 2002 at 01:20:03AM +0200, Friedhelm Betz wrote:
> +1 @goba for his suggestion of splitting
+1 (wasn't that discussed during the doc meeting?)
> +1 @jesus for "PHP Users Manual" and a "PHP Developers Manual"
-1 too ambigous.
> -1 @goba and @jome for "PHP Inner Workings Manual" s
+1 for splitting
-1 for 'PHP Developers' Manual' vs 'PHP Users' Manual', there is a huge
amount of confusion about this as we all know. Other software projects
don't generally have the same issue with this ..
'PHP Sourcerers' Manual' vs 'PHP Manual'? - we need something _that_
obvious IMHO.
>
Hi all,
Monday, August 12, 2002, 12:24:52 AM, you wrote:
> Not sure if people using PHP for development will be
> confused, in particular if we have a:
> "PHP Users Manual" and a "PHP Developers Manual"
> Other software projects use different approaches, e.g.
> Python (http://www.python.org/d
Not sure if people using PHP for development will be
confused, in particular if we have a:
"PHP Users Manual" and a "PHP Developers Manual"
Other software projects use different approaches, e.g.
Python (http://www.python.org/doc/) where the
different bits are separated, whereas the PostgreSQL
ha
> Well, I know about this "PHP Developer" problem... While this is not
> a problem for eg. MySQL, where it's clear who is a user and a developer,
> it's not that simple for PHP... Maybe we can leave the PHP Manual as
> it is know and just name that new manual with a good title, such as
> "PHP Inne
> I think a split is a good idea though I think a name change could be
> confusing (don't know if that's what you're suggesting?). A lot of web
> developers probably considers themselves PHP developers and will
> go to "PHP Developers manual" even though they're looking for
> information which is
> OK, just before we do anything with this steams stuff, we need to define our
> further goals. As the Zend API docs and the extending PHP 3 section of the
> manual are "too developer specific", and there is more PHP developer
> documentation to come, we already discussed a split of the manual int
15 matches
Mail list logo