--- 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
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 into
two s,
16 matches
Mail list logo
