Re: [PHP-DOC] cvs: phpdoc /en/functions dbplus.xml
On Wed, Aug 22, 2001 at 01:36:46AM +0200, Jeroen van Wolffelaar wrote: > > Please revert this patch! I have done this in the meantime and two space > > looks very silly to me. Please read the READMEs in phpdoc. > > Sorry, you said: when I have time, so I concluded you didn't have at the > moment. I quickly looked at it, and saw that it must have been two spaces. > With one space, it doesn't look correct. > > For example here: > > > > > > - Not implemented yet. > > > + Not implemented yet. > > > > > With one space per tab this doesn't line out correctly. > > IMHO, it is correct(ed) now. The most off the indentation looks correct, but the and don't have a proper indentation. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc /en/functions dbplus.xml
On Tue, Aug 21, 2001 at 11:19:47PM -, Jeroen van Wolffelaar wrote: > jeroenTue Aug 21 19:19:47 2001 EDT > > Modified files: > /phpdoc/en/functions dbplus.xml > Log: > According to autoreply Hartmut is N/A for a while, so: > > WS fix (converted tabs to two spaces) Please revert this patch! I have done this in the meantime and two space looks very silly to me. Please read the READMEs in phpdoc. On every page you can read, "sgml-indent-step=1". So your patch is wrong. -Egon > Index: phpdoc/en/functions/dbplus.xml > diff -u phpdoc/en/functions/dbplus.xml:1.5 phpdoc/en/functions/dbplus.xml:1.6 > --- phpdoc/en/functions/dbplus.xml:1.5Tue Aug 21 14:16:46 2001 > +++ phpdoc/en/functions/dbplus.xmlTue Aug 21 19:19:47 2001 > @@ -1,60 +1,60 @@ > > - > + > >DB++ functions > > - > + > > &warn.experimental; > - > - > - Experimental support for db++ database > - > - This paper describes the the db++ extension which enables > - PHP to access db++ relation files through all of the > - search and update methods available in the client/server "C" > - library interface of db++ and to read and process the output of a > - db++ query. > - > - > - > - > - Requirenments > - > - ??? Download where > - > - > - > - > - Installation > - > - Creation and installation of this extension requires the db++ > - client libraries and header files to be installed on your system > - as described above. You have to run configure > - with option --with-dbplus to build this extension. > - > - > - configure looks for the client libraries and > - header files under the default > - path/usr/dbplus/. > - If you have installed db++ in a different place you have add the > - installation path to the configure option like > - this: --with-dbplus=/your/installation/path. > - > - > - > - db++ error codes > - > - > - db++ error codes > - > - > - > - PHP Constant > - db++ constant > - meaning > - > - > + > + > +Experimental support for db++ database > + > + This paper describes the the db++ extension which enables > + PHP to access db++ relation files through all of the > + search and update methods available in the client/server "C" > + library interface of db++ and to read and process the output of a > + db++ query. > + > + > + > + > +Requirenments > + > + ??? Download where > + > + > + > + > +Installation > + > + Creation and installation of this extension requires the db++ > + client libraries and header files to be installed on your system > + as described above. You have to run configure > + with option --with-dbplus to build this extension. > + > + > + configure looks for the client libraries and > + header files under the default > + path/usr/dbplus/. > + If you have installed db++ in a different place you have add the > + installation path to the configure option like > + this: --with-dbplus=/your/installation/path. > + > + > + > +db++ error codes > + > + > + db++ error codes > + > + > + > + PHP Constant > + db++ constant > + meaning > + > + > > > DBPLUS_ERR_NOERR > @@ -251,13 +251,13 @@ > ERR_UNKNOWN > > > - > - > - > - > - > + > + > + > + > + > > - > + > > > dbplus_add > @@ -268,29 +268,29 @@ > > >int dbplus_add > - int relation > - array tuple > + int relation > + array tuple > > > &warn.experimental.func; > > - This function will add a tuple to a relation. The > - tuple data is an array of attribute/value > - pairs to be inserted into the given > - relation. After successfull execution the > - tuple array will contain the complete data > - of the newly created tuple, including all implicitly set domain > - fields like sequences. > + This function will add a tuple to a relation. The > + tuple data is
Re: [PHP-DOC] Re: phpdoc /en/functions dbplus.xml
On Tue, Aug 21, 2001 at 09:27:19PM +0200, Jeroen van Wolffelaar wrote: > You use tabs for indenting. With me, this ruins the layout. I think it might > be better to use spaces, as described in the phpdoc-README No, he is using emacs tabs and this is recommended. The layout was not ruined by Hartmut. There are some strange intentations, if I have time I will correct this. -Egon > - Original Message - > From: "Hartmut Holzgraefe" <[EMAIL PROTECTED]> > Newsgroups: php.doc > To: <[EMAIL PROTECTED]> > Sent: Tuesday, August 21, 2001 8:16 PM > Subject: cvs: phpdoc /en/functions dbplus.xml > > > > hholzgra Tue Aug 21 14:16:47 2001 EDT > > > > Modified files: > > /phpdoc/en/functions dbplus.xml > > Log: > > some additions, still some way to go ... > > > > > -- -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Re: phpdoc /en/language variables.xml
On Mon, Aug 20, 2001 at 11:59:44PM +0200, Hojtsy Gabor wrote: > > We at phpdoc try to at least be near to the XHTML spec, > ^^ > > Erm, I intended to write "phpweb" here. Sorry for the confusion. > > > although we can't conform (because eg. the DSSSL style sheets > > producing ugly HTML). PHP is on the same way, as I can see, > > by nl2br() using as the output. So the manual should follow > > the same path. The same reason is why I lowercased the HTML tags > > in the examples. At least we use HTML in examples ( for example), > > but it is close to XHTML... :)) No, phpdoc was the right wording. This issue have to do with the manual and correct HTML, XHTML, and XML. At phpweb there are no DSSSL stylesheets :) -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Re: phpdoc /en/language variables.xml
On Mon, Aug 20, 2001 at 09:14:59PM +0200, [EMAIL PROTECTED] wrote: > > Log: > > Fix missing HTML quote > > > > (...) > > > - > > + > > This isn't scrictly necessary, only if the value contains characters not in > [a-zA-Z0-9_]. > > I never use the quotes in this context... but it isn't wrong either, of > course. This patch was correct, because every attribute value should be enclosed in quots. It is correct XML and we should not have bad examples in the manual. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc /en/features connection-handling.xml cookies.xml error-handling.xml file-upload.xml http-auth.xml images.xml persistent-connections.xml remote-files.xml safe-mode.xml /en/language basic-syntax.xml constants.xml control-structur
On Sun, Aug 19, 2001 at 07:05:56PM +0200, Hojtsy Gabor wrote: > > IMHO this was not necessary. We have only internal entities. From the > > DocBook - The Definitiv Guide on page 610 or online in the Glossary: > > > > external entity > > An external entity is a general entity that refers to another document. > > Externals entities are often used to incorporate parsable text > > documents, like legal notices or chapters, into larger units, like > > chapters or books. > > So you say we have only internal entities. See what the > XML Recommendations says about internal entites: > > | 4.2.1 Internal Entities > | > | [Definition: If the entity definition is an EntityValue, the defined > | entity is called an internal entity. There is no separate physical > | storage object, and the content of the entity is given in the > | declaration.] > > So there is no physical storage object, the content is in the declaration. > This type of entities are the ones defined in language-defs.ent > and language-snippets.ent. > > OK, what the XML Recommendation says about the External Entities: > > | 4.2.2 External Entities > | > | [Definition: If the entity is not internal, it is an external entity, > | declared as follows:] > | > | External Entity Declaration > | > | [75] ExternalID ::= 'SYSTEM' S SystemLiteral > | | 'PUBLIC' S PubidLiteral S SystemLiteral > | [76] NDataDecl ::= S 'NDATA' S Name > > > You have qouted my "phpdoc/en/pear/standards.xml" modification. > So see how is this defined (as an external entity) in "chapters.ent" : > > > > This perfectly matches the production of an external entity, > qouted above from the XML Recommendation. It looks to me that it is not an external entity. The manual is one document and we don't refer to any external documents. So why should I write in every referenced file on the first line: Jouni, please clarify this a bit. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc /en/features connection-handling.xml cookies.xml error-handling.xml file-upload.xml http-auth.xml images.xml persistent-connections.xml remote-files.xml safe-mode.xml /en/language basic-syntax.xml constants.xml control-structur
On Sun, Aug 19, 2001 at 11:09:19AM -, Hojtsy Gabor wrote: > goba Sun Aug 19 07:09:19 2001 EDT > > Modified files: > /phpdoc/en/features connection-handling.xml cookies.xml > error-handling.xml file-upload.xml > http-auth.xml images.xml > persistent-connections.xml remote-files.xml > safe-mode.xml > /phpdoc/en/language basic-syntax.xml constants.xml > control-structures.xml expressions.xml > functions.xml oop.xml operators.xml > references.xml types.xml > /phpdoc/en/pear about.xml benchmark_timer.xml pear.xml > standards.xml > Log: > External parsed entities _should_ each begin with a text declaration. > See: http://www.w3.org/TR/2000/REC-xml-20001006#sec-TextDecl [..,] > Index: phpdoc/en/pear/standards.xml > diff -u phpdoc/en/pear/standards.xml:1.10 phpdoc/en/pear/standards.xml:1.11 > --- phpdoc/en/pear/standards.xml:1.10 Sat Aug 18 05:23:05 2001 > +++ phpdoc/en/pear/standards.xml Sun Aug 19 07:09:18 2001 > @@ -1,4 +1,5 @@ > - > + > + > >PEAR Coding Standards > IMHO this was not necessary. We have only internal entities. From the DocBook - The Definitiv Guide on page 610 or online in the Glossary: external entity An external entity is a general entity that refers to another document. Externals entities are often used to incorporate parsable text documents, like legal notices or chapters, into larger units, like chapters or books. BTW the above URL is wrong and have not found your recommend spec. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc /de/functions mysql.xml
On Thu, Aug 16, 2001 at 11:24:19PM +0200, Mark Kronsbein wrote: > > > They are in phpdoc/images and since the German PHP manual is in phpdoc/de > > it couldn't be found. Jouni have found this problem today. I got no > > errors because I have a local copy in phpdoc/de/images. > > Okay, but there is no manual/images/ on php.net (yet). So I just wanted > to get rid of these 404 ;) I know that, so I deleted the other grapics also. If there is a new decision about the layout of the online manuals, we can start again a new experiment. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc /de/functions mysql.xml
On Thu, Aug 16, 2001 at 08:33:37PM -, Mark Kronsbein wrote: > mkThu Aug 16 16:33:37 2001 EDT > > Modified files: > /phpdoc/de/functions mysql.xml > Log: > note.gif gibts irgendwie nicht ;) They are in phpdoc/images and since the German PHP manual is in phpdoc/de it couldn't be found. Jouni have found this problem today. I got no errors because I have a local copy in phpdoc/de/images. -Egon > Index: phpdoc/de/functions/mysql.xml > diff -u phpdoc/de/functions/mysql.xml:1.28 phpdoc/de/functions/mysql.xml:1.29 > --- phpdoc/de/functions/mysql.xml:1.28Tue Jul 17 06:07:23 2001 > +++ phpdoc/de/functions/mysql.xml Thu Aug 16 16:33:36 2001 > @@ -154,7 +154,6 @@ > > > > - >Diese Funktion wurde mit PHP 3.0.13 eingeführt und erfordert >MySQL 3.23.3 oder höher. > > @@ -185,7 +184,6 @@ > wird die aktuelle Verbindung geschlossen. > > > - > >Dies ist für gewöhnlich nicht notwendig, weil nichtpersistente >offene Verbindungen automatisch mit Beendigung des PHP-Skripts > > -- -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc /en/functions dbplus.xml ming.xml mysql .xml /nl/functions apache.xml
On Mon, Aug 13, 2001 at 10:18:11AM +0200, Hojtsy Gábor wrote: > >> Egon, we still can't read the reasons why this > >> need to be reverted? Until the reasons, I think it > >> is unnecessary to revert the changes. > > > >I have seen that the transformation of looks very > >ugly. There are other reasons, because we have some DSSSL > >stylesheets which doesn't cover the short IIRC. > > Should we stop improving the xml files, because our DSSSL > style sheets are not perfectly actual to handle the > presentation side? In XML the goal is to present the things > with the meanning, and not to look at the output the first time. > > You know well the docbook manual (maybe others are not, so > an extract whould be good here): > > Processing expectations > --- > > The Void element produces generated text that indicates > the function has no arguments (or returns nothing). > The exact generated text may vary. One common result > is void. > > So the DocBook docs says, one common result is "void". > Then we can implement it for this tag to print void. > As is the best syntax according to docbook, > there is no need to revert the changes, it would > be a step backward. We should go one step further, > and look into how the void word can be printed > with DSSSL IMHO. It was not posible the last 5 years, so I don't see to change the manual in that direction. What is your problem with that? The syntax was not used in the documentation. This doesn't mean, we should not improve our XML files, but to change all void to is the wrong direction. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc /en/functions dbplus.xml ming.xml mysql .xml /nl/functions apache.xml
On Mon, Aug 13, 2001 at 09:50:46AM +0200, Hojtsy Gabor wrote: > >On Sun, Aug 12, 2001 at 10:43:08PM -, Jeroen van Wolffelaar wrote: > >> jeroen Sun Aug 12 18:43:08 2001 EDT > >> > >> Modified files: > >> /phpdoc/nl/functions apache.xml > >> /phpdoc/en/functions dbplus.xml ming.xml mysql.xml > >> Log: > >> More manual -ifying > > > >Please revert those patches. > > > >-Egon > > Egon, we still can't read the reasons why this > need to be reverted? Until the reasons, I think it > is unnecessary to revert the changes. I have seen that the transformation of looks very ugly. There are other reasons, because we have some DSSSL stylesheets which doesn't cover the short IIRC. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Bug #12550 Updated: rand() and mt_rand() don't behave as documented
On Mon, Aug 13, 2001 at 07:29:16AM +0200, Jani Taskinen wrote:
>
> Now you assume that you need to pass arguments to these functions.
> Which is not the case. Here's the proto:
>
> /* {{{ proto int rand([int min, int max])
>Returns a random number */
>
> So revert that patch. mt_rand() / rand() accecpt either 2 parameters or
> none at all. It was at least LESS wrong before. Now it's totally wrong.
>
> --Jani
>
> p.s. Egon, you still haven't explained me why my patch was wrong?
The prototype in the php[3!4] is ok, but in the PHP manual it was wrong.
-Egon
--
All known books about PHP and related books: http://php.net/books.php
Concert Band of the University of Hohenheim: http://www.concert-band.de/
First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc /en/functions dbplus.xml ming.xml mysql.xml /nl/functions apache.xml
On Sun, Aug 12, 2001 at 10:43:08PM -, Jeroen van Wolffelaar wrote: > jeroenSun Aug 12 18:43:08 2001 EDT > > Modified files: > /phpdoc/nl/functions apache.xml > /phpdoc/en/functions dbplus.xml ming.xml mysql.xml > Log: > More manual -ifying Please revert those patches. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Re: rendering, multi-proto's
On Mon, Aug 13, 2001 at 12:34:33AM +0200, Jeroen van Wolffelaar wrote: > > is wrong. > > Why? See the docbook documentation: > > Void -- An empty element in a function synopsis indicating that the > function in question takes no arguments I know the DocBook probably better then you. > > > (void) to indicate no-args is really ugly, IMO, and wrong too. void as > > > return-value is okay, but to indicate no-args?? it is common to have a > list > > > of arguments, there are no arguments -> empty list. > > > > No, it means there is no argument type or return value. > > "_it_ means", to what are you referring? I don't get this. To nothing. > If you mean (void), I disagree, as I argumented in that paragraph. > > > > Anyway, _IF_ (void) would be the correct rendering, change the > > > html-common.dsl to output " (void)" in stead of " ()". That's the > > > appropriate way, this void thing is an ugly hack > > > (IMHO uglier than Jani's/Tom's rand() hack). > > > > Examples? I will look for it tomorrow. > > > > > > > > > > > + 14. In a prototype, if there are multiple - really distinct - > > > > > + possibilities, simply make it two! See math.xml:min() for an > > > example. > > > > > > > > mixed? > > > > > > See min() for example, mixed is not appropriate there. min()s is correct, exept the missing brackets for the optional arguments. > > Simply make it two is IMHO nonsense. But we can agree if there is a "!" > > separator between the arguments, with no spaces between the separator. > > This rates quite high on the WTF-scale... Have you seen how it is rendered > anyway? There are two possible syntaxes for that min() function, and they > should both be named. It isn't for nothing that there are multiple > prototypes allowed in XML, within one funcsynopsis. Again, see the > docbook-docs. I render or validate the PHP docs daily. So I don't see your problem. Multiple prototypes are posible with Hartmut's patch. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Re: rendering, multi-proto's
On Mon, Aug 13, 2001 at 12:08:54AM +0200, Jeroen van Wolffelaar wrote: > > > +If a function requires no arguments, use in stead of > > > +void, since the former renders to " ()", > > > +and not " (void)", the former is of course more correct. > > > + > > > +If a function has an undefined return-value, use 'void'. > > > > void is the correct syntax, because looks > > very ugly in the renderd output. > > I just threw away a mail about that we should change the > function (void) > prototype to > function () > , but then I saw that it was already okay with . is wrong. > (void) to indicate no-args is really ugly, IMO, and wrong too. void as > return-value is okay, but to indicate no-args?? it is common to have a list > of arguments, there are no arguments -> empty list. No, it means there is no argument type or return value. > Anyway, _IF_ (void) would be the correct rendering, change the > html-common.dsl to output " (void)" in stead of " ()". That's the > appropriate way, this void thing is an ugly hack > (IMHO uglier than Jani's/Tom's rand() hack). Examples? I will look for it tomorrow. > > > > > + 14. In a prototype, if there are multiple - really distinct - > > > + possibilities, simply make it two! See math.xml:min() for an > example. > > > > mixed? > > See min() for example, mixed is not appropriate there. Simply make it two is IMHO nonsense. But we can agree if there is a "!" separator between the arguments, with no spaces between the separator. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc / README
On Sun, Aug 12, 2001 at 09:32:35PM -, Jeroen van Wolffelaar wrote: > jeroenSun Aug 12 17:32:35 2001 EDT > > Modified files: > /phpdoc README > Log: > More conventions > > > Index: phpdoc/README > +If a function requires no arguments, use in stead of > +void, since the former renders to " ()", > +and not " (void)", the former is of course more correct. > + > +If a function has an undefined return-value, use 'void'. void is the correct syntax, because looks very ugly in the renderd output. > + 14. In a prototype, if there are multiple - really distinct - > + possibilities, simply make it two! See math.xml:min() for an example. mixed? -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Re: phpdoc /fr bookinfo.xml
On Thu, Aug 09, 2001 at 08:06:35PM +0200, Hojtsy Gabor wrote: > Egon writes: > > > Revision tags in the translated or the original English XML files are > > nonsense. Every translator have to look into the phpdoc tree at > > cvs.php.net. > > WHHYYY? You cannot do a translation with revison tags. So it is nonsense. You can not make a diff between the English and the Hungarian files in the documentation trees. --Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc /en/functions math.xml
On Thu, Aug 09, 2001 at 05:58:49AM -, Jani Taskinen wrote: > sniperThu Aug 9 01:58:49 2001 EDT > > Modified files: > /phpdoc/en/functions math.xml > Log: > Another try with this. This seems to 'compile'. Please revert this patch. -Egon > Index: phpdoc/en/functions/math.xml > diff -u phpdoc/en/functions/math.xml:1.45 phpdoc/en/functions/math.xml:1.46 > --- phpdoc/en/functions/math.xml:1.45 Tue Aug 7 18:25:15 2001 > +++ phpdoc/en/functions/math.xml Thu Aug 9 01:58:49 2001 > @@ -1,4 +1,4 @@ > - > + > >Mathematical Functions >Math > @@ -710,11 +710,8 @@ > > >int mt_rand > - int > - min > - > - int > - max > + > + int min, int max > > > > @@ -1051,11 +1048,8 @@ > > >int rand > - int > - min > - > - int > - max > + > + int min, int max > > > > > -- -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Re: phpdoc /fr bookinfo.xml
On Thu, Aug 09, 2001 at 12:08:32AM +0200, Thomas Schöfbeck wrote: > Sounds also good! > > Let's summarize: > > is already available, > > is OK for Jeroen, Goba, Luca, and me (=3 1/2) > > > is at least for me also OK, > since the "State" saves the manipulation of translators when > committing the translation. > > Any opinions, suggestions, etc.? Revision tags in the translated or the original English XML files are nonsense. Every translator have to look into the phpdoc tree at cvs.php.net. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Re: Space between funcname & arglist (was: Re: [PHP-DOC] cvs: phpdoc /en/functions strings.xml)
On Wed, Aug 08, 2001 at 09:51:50AM +0200, Damien Seguy wrote: > on 8/08/01 0:06, Jeroen van Wolffelaar at [EMAIL PROTECTED] wrote: > > > From PEAR coding standards (function calls): > I got those one from README file in phpdoc/README. > > I do agree with the no space between function name and opening parenthesis. > At least, we should be coherent with the rest of the PHP team on this. > > Before we change this convention, does anyone have opinion about this? > I wonder what was the reason about this (I guess it's one of those fashion > that cross informatics coding world). > > Right now, here is the situation : > no space : +2 > space: 0 I would see a space. The formatted function prototypes have already a space between function name and opening parenthesis. With the space the code is more readable. -1 (space) -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Index
On Wed, Aug 08, 2001 at 12:26:36AM +0200, [EMAIL PROTECTED] wrote: > There is currently one thing lacking for the documentation: An index. I mean > an index with at least all function names, in alphabetic order. > > I know, there are lists on the web (php.net too, I think), but I mean in the > manual itself. It should also contain lemma's like '%', 'string', > 'safe-mode', etc. > > In docbook, there are xml-tags for this. > > 1) Do you agree that an index should be added? Yes :) > 2) Does someone have any experience with this? (the docbook documentation > itself has an index, including all the tags. I think that the way they did > it, would be useful for us too. Assuming that that documentation is written > in DocBook, but hey... our website is in PHP, so I guess so :-) Most books are written with DocBook, the PHP manual also. > 3) If not, does anyone want to do some experiments? My time is limited. But at phpdoc should be Scheme program for sorting such entries. To extract the function names would be easy. > 4) If not, shall I do some experiments? (not committing, of course, until it > works) Yes :) -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Re: phpdoc /fr bookinfo.xml
On Tue, Aug 07, 2001 at 07:39:49PM +0200, Hojtsy Gabor wrote: > > > Let's imagine, you start translating mysql.xml. This is not > > > a small file, so you can't complete it in a day. You copy > > > the mysql.xml file yourself to a separate directory, as > > > you probably won't follow the modifications in the mysql.xml > > > file as you translate, because the translation takes weeks. > > > One week later, when you again have time to translate, you can > > > see the $Revision tag in the copied english file, while the > > > one in CVS is newer, so your point of what you are translating > > > would be lost. > > > > We have some translations from May 2000. The only possibility to get this > > translation into sync with the English version is, compare the file > > modification time with the revisions in cvs.php.net till that time and > > make all modifications since that time. One revision tag is IMHO still > > useless. > > Please read my text above again. That mysql.xml from the en tree > was weeks old, when translated and commited to the de tree > (just imagine). So time is not a good factor. Revision is > exact. You can make a diff, and don't need to make tips, what > revision it was... No. One revision is not enough. We need the revision history and that should no be in the documentation. Your way is also possible, but to what revision? -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Re: phpdoc /fr bookinfo.xml
On Tue, Aug 07, 2001 at 04:55:14PM +0200, Hojtsy Gábor wrote: > >> So we have a $Revision tag in the english file, showing the actual > >> english version number. We can have a comment in the translated > >> version, about what english version number it corresponds to. This > >> way you can do a diff with these two versions, and see what needs > >> to be modified/added in the translated file. I think it just > >helps much. > >> I can't understand what is your problem with this? > > > >I can´t see your point. The information what have been > >modified/added is > >in cvs.php.net. A revision tag is IMHO useless. > > Let's imagine, you start translating mysql.xml. This is not > a small file, so you can't complete it in a day. You copy > the mysql.xml file yourself to a separate directory, as > you probably won't follow the modifications in the mysql.xml > file as you translate, because the translation takes weeks. > One week later, when you again have time to translate, you can > see the $Revision tag in the copied english file, while the > one in CVS is newer, so your point of what you are translating > would be lost. We have some translations from May 2000. The only possibility to get this translation into sync with the English version is, compare the file modification time with the revisions in cvs.php.net till that time and make all modifications since that time. One revision tag is IMHO still useless. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Re: phpdoc /fr bookinfo.xml
On Tue, Aug 07, 2001 at 01:40:12PM +0200, Hojtsy Gábor wrote: > >> this is in fact an "automated look into the en-cvs-tree" for > >more than just > >> one file. > > > >For the other languages it is useless, because we have to look > >into more > >revisions besides the last en revision. Most translated files > >are one or > >two years old. > > So we have a $Revision tag in the english file, showing the actual > english version number. We can have a comment in the translated > version, about what english version number it corresponds to. This > way you can do a diff with these two versions, and see what needs > to be modified/added in the translated file. I think it just helps much. > I can't understand what is your problem with this? I can´t see your point. The information what have been modified/added is in cvs.php.net. A revision tag is IMHO useless. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Re: phpdoc /fr bookinfo.xml
On Tue, Aug 07, 2001 at 11:39:53AM +0200, Thomas wrote: > [EMAIL PROTECTED] wrote: > > > On Tue, Aug 07, 2001 at 10:46:25AM +0200, Thomas wrote: > > > Hojtsy gábor wrote: > > > > > > >>I too think that this is not needed for translations. I can't think > > > > of > > > > >>any situation where I would use this. An En-version comment > > > > >>will be at least usable :)) > > > > >Whenever I find out a partally translated file, I know at once > > > > >which version is was started from, without diff or reading the > > > > >whole file. > > > > > > > > You will now which French version it was. Where it helps you? > > > > > > You're right. I use a tag like (proposed by Jeroen I think) > > > > > > > > > As soon as I have enough files with this tag, I'll write a simple script > > > > > > which shows me the priority (which file is farest behind) of "my" files. > > > > > > The more users in our language follow this, the more useful it will be > > > (but having a system and a common "living" it are different things :). > > > > I think it is useless. If someone translate a file, he or she should look > > for chances in the English cvs.php.net tree. > > this is in fact an "automated look into the en-cvs-tree" for more than just > one file. For the other languages it is useless, because we have to look into more revisions besides the last en revision. Most translated files are one or two years old. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Re: phpdoc /fr bookinfo.xml
On Tue, Aug 07, 2001 at 10:46:25AM +0200, Thomas wrote: > Hojtsy gábor wrote: > > >>I too think that this is not needed for translations. I can't think > > of > > >>any situation where I would use this. An En-version comment > > >>will be at least usable :)) > > >Whenever I find out a partally translated file, I know at once > > >which version is was started from, without diff or reading the > > >whole file. > > > > You will now which French version it was. Where it helps you? > > You're right. I use a tag like (proposed by Jeroen I think) > > > As soon as I have enough files with this tag, I'll write a simple script > > which shows me the priority (which file is farest behind) of "my" files. > > The more users in our language follow this, the more useful it will be > (but having a system and a common "living" it are different things :). I think it is useless. If someone translate a file, he or she should look for chances in the English cvs.php.net tree. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc / global.ent
On Wed, Aug 01, 2001 at 09:41:48AM +0200, Hojtsy Gábor wrote: > >I talked about global.ent, not de/language-defs.ent. We have sometimes > >errors if someone makes a reference to the install chapter. If this > >chapter is not uptodate in this language, the manual building > >would fail. > > OK, I know what you said, but what is Jouni talking about I don't know :) If he doesn't have any beer he will come back. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc / global.ent
On Wed, Aug 01, 2001 at 09:24:34AM +0200, Hojtsy Gábor wrote:
> >I'm not very sure what I'm writing about (had a few beers too
> >much), but
> >it should be possible within the DSSSL / our configuration
> >framework, to
> >just detect which version of a language specific *.ent should
> >be used. I
> >mean after global.ent, overriding or adding something to it,
> >according to
> >the needs of the translation team.
> >
> >There is even a good example of this:
> >
> >cat de/language-defs.ent
> >
> >
> >
> >
> >
> >
> >
> > >Repository">
> >
> >
> >Egon, this is something we have already been using quite many
> >years. Now, please fix that file :-;
>
> I completely can't understand what you are talking about... I can't see
> anything here need to be fixed. It is absolutely right in my mind.
>
> >(But then some crazy guys added that PEAR and
> >FAQ. What the hell do they think about, especially with PEAR, that's
> >somewhat recent. ('FAQ' is not recent, many of those questions finally
> >answered are years old)
>
> What is the problem with these, please explain!
I talked about global.ent, not de/language-defs.ent. We have sometimes
errors if someone makes a reference to the install chapter. If this
chapter is not uptodate in this language, the manual building would fail.
-Egon
--
All known books about PHP and related books: http://php.net/books.php
Concert Band of the University of Hohenheim: http://www.concert-band.de/
First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc / global.ent
On Tue, Jul 31, 2001 at 10:15:46AM +0200, Hojtsy Gábor wrote: > > Added last URL lingering in FR doc.I will remove them in en > >doc too later > > Are these entities used in the en docs? > Some will be good to be there! Eg: > > >+http://www.hyperwave.de/7.17-hg-prot";> > >+http://www.iicm.edu/";> > >+http://www.rfc-editor.org/'> > >+http://www.texinfo.com/";> > > But some are FR only entities: > > >+http://dev.nexen.net/docs/mysql/";> > >+http://www.nexen.net/";> > > I think you should not put these inside globals.ent as > they are not *globals*. IMHO you should put language dependent > entities to your language-defs.ent (at least I used this > techniques to place hu only entities). It is better to only > keep true global entities in globals.ent and language specific > ones in the languages dir. > > >+ >url.symbole_legendre > >"http://www.utm.edu/research/primes/glossary/LegendreSymbol.htm > l"> > > This is not showing up for me, so I can't decide, but the entity > name suggest that this is also not an english page, so maybe > not global... If Damien use his French ENTITY's, there is nothing wrong to put them into global.ent. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] build date lost
On Sun, Jul 29, 2001 at 06:36:30PM +0200, Hojtsy Gabor wrote: > The &php.build-date; part in > the bookinfo.xml means that the manual building date > should be there in all the generated manuals. > > *But they are not!* I have done some experiments some years ago. The only place for a date was to publish the date in the Dedication. > I tried to investigate some things in connection > with this entity and the pubdate element, but found > nothing... > > Why are the dates missing? They are important parts > of the documentation! Ask Norman Walsh or read the DocBook. I really spent some days on this issue and everything doesn't work, except the Dedication. A date in the Dedication looks very ugly. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Turkish Translation of Manual
On Sun, Jul 29, 2001 at 04:23:32PM +, Serdar Soydemir wrote: > I am one of the council-members of Turkiye PHP Users Group, www.php.org.tr. > We are planning to work on Turkish translation of PHP Manual, and we wonder > if anyone else has already begun to work on this project. We would be happy > to help him/his team if anyone has already started. If no one/team is > assigned on this work, we want to create a new Turkish translation branch on > PHP Manual. I don't know of other efforts to translate the PHP manual into Turkish. I have just checked the cvsusers file. > A question for manual maintainers; is it enough to get a CVS account for > /phpdoc/tr and put our translations in them, or we must also work on Jade > and Docbook/DSSSL to help make different versions of manual? A CVS account is needed to put the translated files into /phpdoc/tr. It wold be cool if you can install Jade and DocBook, so you can validate the translation. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc /en preface.xml
On Thu, Jul 26, 2001 at 09:02:57AM -, Hojtsy Gabor wrote: > Modified files: > /phpdoc/enpreface.xml > Log: > Again, we have no RFT versions now... > TeX versions are used to build PDF, so > let it stay (am I right?) We can build RTF versions. The TeX version can be viewed with any dvi viewer. With the dvi files we can build PostScript and PDF versions. Look at the Makefile. For PDF and PostScript versions we have to wait for Jouni Ahto. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] bad posts
On Mon, Jul 23, 2001 at 09:02:48AM -0700, Rasmus Lerdorf wrote: > > Today I have gotten already two or three emails from PHPDOC containing > > something very likely to be email virus (at least, my filters say so and > > they rarely are mistaken). Maybe it worth to set up the list so that ot > > strips MIME attachments? > > Except phpdoc CVS commit messages over a certain size end up as mime > attachments. If it is a mime attachment or not, it doesn't matter. I called my ISP and asked him to delete that email with 1.7MB. I could not transfer my emails from the mailserver to my working space, because that email with 1.7 MB (as attachement or not) will be on the mailserver. Two phone calls and I can read emails as everyday. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Which editor?
On Sun, Jul 22, 2001 at 12:44:31AM +0200, Viktor Jonsson wrote: > Thanks everybody. Weaverslave looks nice. btw I just sent my book about > PHP to my publisher. It will be the first "real" book about about PHP in > Swedish. > Take a look at the cover: http://www.redhat.nu/grafix/framsida.png Cool! Can you send more data about your book. I hope that I or something else can publish your book at php.net/books.php. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Which editor?
On Sun, Jul 22, 2001 at 12:14:25AM +0200, Mark Kronsbein wrote: > > >Which editor do you use when you are editing the XML code to the manual? > > Weaverslave http://www.weaverslave.ws XEmacs is the best editor to manage the PHP manual. I havent used weaverslave. If someone can show the php documentation at our next Stuttgarter PHP meeting, I can hopefully explain why. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Which editor?
On Sat, Jul 21, 2001 at 11:27:10PM +0200, Viktor Jonsson wrote: > Which editor do you use when you are editing the XML code to the manual? XEmacs :) -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Re: pdf manuals (fwd)
On Sat, Jul 21, 2001 at 04:24:41PM +0300, Jouni Ahto wrote: > On Sun, 15 Jul 2001, Jim Winstead wrote: > > On Mon, Jul 16, 2001 at 09:25:16AM +0300, Jouni Ahto wrote: > > > > > > Was there problems, because they don't show up yet on the documentation > > > page, or is it just that nobody did update it? In the former case, I'm > > > still offering help. > > > > the machine that the manual generation runs on doesn't have tex > > installed. we're planning on moving this to a new machine. > > > > hopefully we can have it up and running again by the end of the week. > > Just a suggestion: I got a cable modem home last Wednesday and am once > again connected to the net (with enough speed :). And I've already got a > fully working TeX setup, especially hacked and tuned to produce PHP > PDF-manuals. So, why to waste cycles (the process is quite long and > heavy...) on a machine that would be in better use serving continuously > the developer and user community, when my home machine could do it every > day and then ftp/rsync the results to somewhere while I sleep? Hi Jouni, I really missed you on the LinuxDays in Stuttgart :( We had all days a very good Internet connection. I hope I can see you the next year in Stuttgart. -Egon -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] where can I find select()
On Wed, Jul 18, 2001 at 05:45:33PM +0200, Cornelia Boenigk wrote: > Hello Documentation Professionals > > I searched the whole manual for a function select() which takes five > arguments and shall be used to find out whether a socket has unread > data. > > Could you please help me to find infos? Can I look with you for that function? I'm also on the way to travel into the direction of Tübingen. -Egon -- -- All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Filtering out translations?
On Tue, Jul 17, 2001 at 10:45:35AM +0200, Hojtsy Gabor wrote: > > > I think nearly everybody agreed on splitting up the docs > > > into separate modules, with separate files. At least it > > > seemed to me :)) > > > i only remember hints about how to get the effect manually by > > removing the translations from the local CVS checkout and > > comments about '23MB in the phpdoc repository isn't that > > much, even with a 14.4k Modem' ;) > > Egon's sound is the 'loudest', but that isn't mean his opinion > was the only one (or the dominant) IMHO. I have the option to get a working place at my ISP. My ISP have since 1990 one of the fastest internet access. If you will split the manual in different languages, we have to put the top directory on top of every language. This means it would be a lot more than 23 MB. My 14.4 kB Modem can handle such huge data volumns very well :) -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc /de Translators
On Fri, Jul 13, 2001 at 06:54:24AM -, Martin Kraemer wrote: > martinFri Jul 13 02:54:24 2001 EDT > > Modified files: > /phpdoc/deTranslators > Log: > Does adding both Revisions make things clearer? > > Index: phpdoc/de/Translators > diff -u phpdoc/de/Translators:1.174 phpdoc/de/Translators:1.175 > --- phpdoc/de/Translators:1.174 Wed Jul 11 11:22:28 2001 > +++ phpdoc/de/Translators Fri Jul 13 02:54:23 2001 > @@ -122,7 +122,7 @@ > regex.xml Martin Samesch fertig > satellite.xml > sem.xml Hartmut Holzgraefe fertig > -sesam.xml Martin Kraemer fertig > +sesam.xml Martin Kraemer fertig (1.2 == en Rev. 1.6) > session.xml Martin Samesch fertig > shmop.xml Cornelia Boenigkin Arbeit > snmp.xmlJan Lehnardtin Arbeit We need only the version of the english files. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Type-rendering
On Wed, Jul 11, 2001 at 10:44:33PM +0200, [EMAIL PROTECTED] wrote: > I think it's better to _not_ make integer etc. bold, but only > make it a link. Preferably in some other color (it's a sort of glossary > term). > > Now it really looks as if there is something very importent when a type is > mentioned, and that's not really the case. > > I tried if I could change it myself, to check it, but I got 3k+ errors... > I did however fix the layout of the file a bit, to make it better readable. > > Jeroen > > Btw: the manual didn't build because cvs update does NOT retrieve > new directories... The http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Libs for Win-Installation really needed?
On Wed, Jul 11, 2001 at 06:46:09PM +0200, Thomas Schöfbeck wrote: > during the translation of install.xml I've stumbled twice over this > sentence in the Windows-part: > > ** snip ** > Some extensions require you to have additional libraries installed > on your system for the module to work correctly. The PHP FAQ has > more information on where to get supporting libraries. > ** snip ** > > Have I missed something? > AFAIK there is everything (official) included in the distribution, and > no download or manual compilation should be necessary. > > Pls. correct me if I'm wrong, otherwise I'll change this also. You don´t need additional libraries for the Windows version. They are compiled in. Look at php4win.de or at zend.com. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Re: cvs: phpdoc /de Translators
On Wed, Jul 11, 2001 at 05:54:42PM +0200, Thomas wrote: > unitl which en-Version is it ready? > > I'm still working on up to 1 year old files nobody really cared about, > and have to check always the whole file. > > To prevent this situation in the future, please add the current status > compared with the English version. I think Martin knows what he is doing. -Egon > > martin Wed Jul 11 11:22:29 2001 EDT > > > > Modified files: > > /phpdoc/de Translators > > Log: > > Add myself as responsible > > > > Index: phpdoc/de/Translators > > diff -u phpdoc/de/Translators:1.173 phpdoc/de/Translators:1.174 > > --- phpdoc/de/Translators:1.173 Sat Jul 7 19:08:27 2001 > > +++ phpdoc/de/Translators Wed Jul 11 11:22:28 2001 > > @@ -122,6 +122,7 @@ > > regex.xml Martin Samesch fertig > > satellite.xml > > sem.xml Hartmut Holzgraefe fertig > > +sesam.xml Martin Kraemer fertig > > session.xml Martin Samesch fertig > > shmop.xml Cornelia Boenigkin Arbeit > > snmp.xmlJan Lehnardtin Arbeit > -- -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Setting up PHP documentation for building
On Wed, Jul 11, 2001 at 12:43:28PM +0200, Damien Seguy wrote: > I'm trying to set up some linux box to build the PHP documentation > (hehe, I see Egon's eyes widening...). I helped Thies on the LinuxDays to build the manual on Mandrake. It was working within 15 minutes. > This is debian 2.2.18, and Jade and docbook are already Installed. > I cvs'ed all en tree, and also all files in phpdoc (configure.in, > bightml.in). > autoconf works (at least, it doesn't say anything, and write some files), > but ./configure tells me that it can't find any sources in . and .. > > What am I missing? If everthing is installed, you have to go into your main phpdoc directory. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc / manual.xml.in /en/features safe-mode.xml
On Wed, Jul 11, 2001 at 07:42:54AM +0200, Hojtsy Gabor wrote:
> > Modified files:
> > /phpdoc manual.xml.in
> > Log:
> > Quick and dirty xml-ation of the safe-mode sheet by Rasmus.
> >
> > Doesn't build because of FAQ :(
> >
> >
> > > readfile('/etc/passwd');
> > ?>
> >
>
> Not because of the FAQ, because of you here (use < and >).
> The FAQ builds.
Only a < is needed for a "<", because it's the start of a element name.
The ">" doesn't produce any error.
-Egon
--
LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/
All known books about PHP and related books: http://php.net/books.php
Concert Band of the University of Hohenheim: http://www.concert-band.de/
First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc /en/faq general.xml
On Mon, Jul 09, 2001 at 04:03:30PM -0500, Daniel Beckham wrote: > This breaks `make test'. Will this affect automatic manual generation at > php.net/manual/? I started to correct this already. I need only some beers in the Krone. -Egon > - Original Message - > From: "Damien Seguy" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, July 09, 2001 8:52 AM > Subject: [PHP-DOC] cvs: phpdoc /en/faq general.xml > > > > dams Mon Jul 9 09:52:59 2001 EDT > > > > Added files: > > /phpdoc/en/faq general.xml > > Log: > > Adding first draft for FAQ > > > > > > > > Index: phpdoc/en/faq/general.xml > > +++ phpdoc/en/faq/general.xml > > > > General Information > > General Information about PHP > > > > > > > > This section holds the most general questions about PHP : > > what it is and what it does. > > > > > > > > > > > > What is PHP ? > > > > > > Description > > > > From the manual : > > > > > > PHP is an HTML-embedded scripting language. Much of > > its syntax is borrowed from C, Java and Perl with a couple of unique > > PHP-specific features thrown in. The goal of the language is to > > allow web developers to write dynamically generated pages quickly. > > > > > > A nice introduction to PHP by Stig Sæther Bakken can be found > > here on the Zend > > website. > > > > > > > > > > > > What is the relation between the versions? > > > > > > Description > > > > PHP/FI 2.0 is an early and no longer supported version of PHP. PHP 3 > > is the successor to PHP/FI 2.0 and is a lot nicer. PHP 4 is the > latest > > generation of PHP, which uses the Zend > engine > > under the hood. > > > > > > > > > > > > Can I run several versions of PHP at the same time > ? > > > > > > Description > > > > Yes. See the INSTALL file that is included in > the PHP 4 > > source distribution. > > > > > > > > > > > > What are the differences between PHP 3 and PHP > 4? > > > > > > Description > > > > There are a couple of > articles > > written on this by the authors of PHP4. Here's a > > list of some of the more important new features: > > > > > > Extended API module. > > > > > > Generalized build process under UNIX > > > > > > Generic web server interface that also supports multi-threaded > web servers > > > > > > Improved syntax highlighter > > > > > > Native HTTP session support > > > > > > Output buffering support > > > > > > More powerful configuration system > > > > > > Reference counting > > > > > > Please see the What's new in PHP4 > overview > > for a detailed explanation of these features and more. > > > > > > > > > > > > > -- -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] RFC : [PHP-DOC] FAQ porting to the manual?
On Mon, Jul 09, 2001 at 12:02:01PM +0200, Damien Seguy wrote: > on 8/07/01 12:43, Hojtsy Gabor at [EMAIL PROTECTED] wrote: > > What is the news about $subj? > Here is the suggestion : > > Any XML guru can validate such a file (Egon?)? If I have time :) > I'll be glad to hear any opinion. I'll make the folder and at least > one file later, so as to have a first draft soon. I have no opinion. I´m looking for a new job. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Swedish translation
On Wed, Jul 04, 2001 at 12:35:34AM +0200, Viktor Jonsson wrote: > Is anybody working on a Swedish translation of the PHP manual? I haven't seen anybody working on a Swedish translation. Be patient, all PHP developers will be the next days in Stuttgart. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] italian manual creation problem
On Tue, Jul 03, 2001 at 03:23:40AM +0200, [EMAIL PROTECTED] wrote: > On Tue, Jul 03, 2001 at 02:18:35AM -0400, Simone Cortesi wrote: > > > i was looking at the http://php.net/manual/it/build-it.log file and saw that > > the creation of the files gets interrupted with errors. Could somebody please > > send me to resources that will help me understanding what is going wrong in > > that creation process? > > I can do it in the middle off this night, But I cannot promise you to find > any errors. Will try it now. It is harmless. Only references to non-existent IDs in the English tree. I hope Luca can resolve it. If not, I will try it on our fair LinuxTag at Stuttgart. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] italian manual creation problem
On Tue, Jul 03, 2001 at 02:18:35AM -0400, Simone Cortesi wrote: > i was looking at the http://php.net/manual/it/build-it.log file and saw that > the creation of the files gets interrupted with errors. Could somebody please > send me to resources that will help me understanding what is going wrong in > that creation process? I can do it in the middle off this night, But I cannot promise you to find any errors. Will try it now. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] pdf files !
On Sat, Jun 30, 2001 at 04:03:51PM -0700, Rasmus Lerdorf wrote: > > Do anybody owns PDF files we can upload to the docs > > dir? Maybe we can populate them as the chms files (in > > the distributions directory). > > > > We should be able to host pdf dowloads on all mirrors. > > Well, the new server is up. We just need someone to move the setup from > the old toye server to the new one. It would be nice to get the PDF's > active again and turn them back on in the download page. I think it was > Jouni that set this up before. If Jouni or another volunteer would like > to volunteer to get this automatic build process working again, please > send a note to [EMAIL PROTECTED] and we can get you access to the new server. I hope that Jouni is coming to the LinuxDays. We have a very good connection to the Internet. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc /cs/features http-auth.xml /cs/functions apache.xml array.xml aspell.xml com.xml dir.xml exec.xml filesystem.xml funchand.xml gettext.xml http.xml info.xml mail.xml misc.xml nis.xml readline.xml strings.xml url.xml /de/functio
On Sat, Jun 23, 2001 at 08:35:18PM -, Jeroen van Wolffelaar wrote: > jeroenSat Jun 23 22:35:18 2001 EDT > > Modified files: > /phpdoc/cs/features http-auth.xml > /phpdoc/cs/functions apache.xml array.xml aspell.xml com.xml > dir.xml exec.xml filesystem.xml funchand.xml > gettext.xml http.xml info.xml mail.xml > misc.xml nis.xml readline.xml strings.xml > url.xml > /phpdoc/de/functions apache.xml array.xml aspell.xml calendar.xml > datetime.xml dir.xml errorfunc.xml > filesystem.xml ftp.xml funchand.xml > gettext.xml http.xml ibase.xml imap.xml > info.xml mail.xml math.xml mhash.xml misc.xml > msql.xml mssql.xml mysql.xml network.xml > outcontrol.xml pgsql.xml regex.xml sem.xml > strings.xml swf.xml uodbc.xml url.xml var.xml > /phpdoc/de/language control-structures.xml variables.xml > /phpdoc/es/features http-auth.xml > /phpdoc/es/functions adabas.xml array.xml dir.xml errorfunc.xml > exec.xml filesystem.xml gettext.xml http.xml > mail.xml math.xml misc.xml mysql.xml > pspell.xml readline.xml strings.xml swf.xml > yaz.xml > /phpdoc/es/language variables.xml > /phpdoc/fr/functions math.xml pcre.xml strings.xml > /phpdoc/hk/features http-auth.xml > /phpdoc/hk/functions aspell.xml dir.xml gettext.xml mail.xml > pspell.xml > /phpdoc/hu/features http-auth.xml > /phpdoc/hu/functions aspell.xml calendar.xml errorfunc.xml > gettext.xml readline.xml url.xml var.xml > /phpdoc/hu/language variables.xml > /phpdoc/it/functions apache.xml array.xml aspell.xml calendar.xml > datetime.xml dba.xml dir.xml errorfunc.xml > exec.xml filesystem.xml ftp.xml funchand.xml > gettext.xml http.xml ibase.xml icap.xml > imap.xml info.xml mail.xml math.xml mcrypt.xml > mhash.xml misc.xml msql.xml mssql.xml > mysql.xml network.xml nis.xml pspell.xml > readline.xml regex.xml sem.xml strings.xml > swf.xml uodbc.xml url.xml var.xml yaz.xml > zlib.xml > /phpdoc/it/language variables.xml > /phpdoc/ja/features http-auth.xml > /phpdoc/ja/functions dir.xml errorfunc.xml exec.xml gettext.xml > http.xml math.xml mssql.xml strings.xml > url.xml > /phpdoc/ja/language variables.xml > /phpdoc/kr/features http-auth.xml > /phpdoc/kr/functions apache.xml array.xml aspell.xml calendar.xml > com.xml datetime.xml dba.xml dir.xml > errorfunc.xml exec.xml filesystem.xml ftp.xml > funchand.xml gettext.xml http.xml ibase.xml > icap.xml imap.xml info.xml mail.xml math.xml > mcrypt.xml mhash.xml misc.xml msql.xml > mssql.xml mysql.xml network.xml nis.xml > pgsql.xml pspell.xml readline.xml regex.xml > sem.xml strings.xml swf.xml uodbc.xml url.xml > var.xml yaz.xml zlib.xml > /phpdoc/kr/language variables.xml > /phpdoc/nl/features http-auth.xml > /phpdoc/nl/functions apache.xml com.xml datetime.xml dir.xml > strings.xml url.xml > /phpdoc/pt_BR/functions apache.xml url.xml > /phpdoc/pt_BR/languagevariables.xml > Log: > Changed all identifiers between and/or tags > that had ONLY the first letter uppercase to all-lowercase Please don't make such megapatches. After deleting over 700 emails I could again get access to my mailbox. It is IMHO wrong to make the function names as first word in a sentence lower case. Yes, I have looked several times into "The Chicago Manual of Style". PHP functions are case insensitive. There was no need to change this. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German
Re: [PHP-DOC] cvs: phpdoc /en/functions var.xml
On Sat, Jun 23, 2001 at 10:35:48PM +0200, [EMAIL PROTECTED] wrote: > > Great idea :) I like it. But then all php-dev members > > should have phpdoc karma... Because the TODO file should > > be placed in the phpdoc repository. > > Don't they have that? That would be bad... It should be as > easy as possible for them to add documentation :). No, most code contributors don't have access to the phpdoc repository. But it is very easy to get karma. > Anyway, when they add a new function, I'm sure they > want it to be mentioned in the documentation, otherwise > nobody uses it... Good point, But we cannot list all contributors on the author list. I suggest therefore into the starting section a list of contributors with full name and mail-address. Most translations have now an native speaker of that language as editor. The German translation lists all translators on the title page. I hope I haven't forgot one. > I'll add the TODO file soon, then. Can you add then the missing functions? Look at Hartmut's functions tables in the statistics page at: http://www.zugeschaut-und-mitgebaut.de/php or http://zend.com/phpfunc I know Hartmut very well, and he has done so many contributions for the PHP manual and the German translation. If nobody have something against, I put him on the author list. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Re: [php-cvs] cvs: phpdoc /en/functions java.xml
On Fri, Jun 22, 2001 at 12:13:53AM +0200, Sebastian Bergmann wrote: > Sebastian Bergmann wrote: > > sbergmann Fri Jun 22 00:09:36 2001 EDT > > > > Added files: > > /phpdoc/en/functionsjava.xml > > Log: > > Initial commit of Java documentation. > > Can someone please have a look at this and add it to the build > process. I have checked out the en tree and I cant find any errors. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Casing function names: Conclusion = ?
On Wed, May 23, 2001 at 01:27:18AM +0200, [EMAIL PROTECTED] wrote: > All function names in the docs should be lowercase for consistence. No > matter where in the sentence, or how unreadable the function will be. I'm against this. It would result in unreadable and bad to remember function names. > For unreadable func-names, a longer-term renaming would be nice. But > first, get the manual lowercase. Then those php.dev guys will just need > to rename, because we are NOT going to write it mixed case anymore > for readability. I would recommend to make aliases in the source code first. After that we should the change the function names in the manuals. > Just only react if you strongly disagree. If nobody strongly disagrees, > I'll commit the changes somewhere in the next week. Thanks to Torben's > script, and including the stuff etc. I have nothing against Torben, he has also read about my fight with some core developers and now the mysql_*() functions are more readable. You can also use the old syntax. The original functions havent been removed yet. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Function References not showing up in docs for mixed case function names
On Sun, May 20, 2001 at 03:18:26PM -0500, Daniel Beckham wrote: > > This problem with the functions names have been discussed several times. > > Look at the mysql_*() functions, there is everything ok. Zeev made aliases > > so we have now easy functions name which can be rememberd by any average > > user. > > > Sure function names are case-insensitive. But can you imagine to rename a > > function like ImageCopyMerge() or ImageCopyResampled() to imagecopymerge() > > or imagecopyresampled()? > > It took me a few minutes to understand what you were saying, but I see now > that you mean that it's difficult to read those long function names in code. > What does it take to add aliases for these functions? Is having this many > function aliases ok with the development team, etc.? If this is truly an > issue, can we begin making these transitions? I'm not an native English speaker so I'm not surprised that you needs some minutes :) Some years ago there have been disscusions and there have recently beens some discussions to make the function names more user friendly. I have made the suggestion to make function names with underscores and not with capitalized letters. I mean the function name ImageCopyResized should be aliased to image_copy_resized. This discussion arise every now and then. I hope the QA team can make some improvements. I have for myself not the time to change the source code. I'm only looking for the function prototypes within comments. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Function References not showing up in docs for mixed case function names
On Sun, May 20, 2001 at 02:56:31AM -0700, Lars Torben Wilson wrote: > To be honest, I've never noticed this problem before, and I've been > working on the manual for 3 years. But then, I always use lowercase > for function names so I wouldn't necessarily have clued in before > now. :) Add 2 years and your statement is much more correct :) I can remember that you have done this work from a .se or .fi homepage and have seen your notice for your movement to the Amerika. If you have time, come over to Germany and visit me on the LinuxDays. Rasmus told me, he would try to come also. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Function References not showing up in docs for mixed case function names
On Sun, May 20, 2001 at 02:56:31AM -0700, Lars Torben Wilson wrote: > Hojtsy Gabor writes: > > > by Daniel: > > > I would propose that a phpdoc wide change be made so that all functions > > are > > > written in lowercase form. It's not necessary to have them in a mixed > > case > > > created on the author's whim. > > > > > by Jeroen: > > > > > > function-names are NOT case-sensitive in PHP itself... so why not change > > > the stylesheets or something so that it is NOT case-sensitive in the docs > > > either? > > > > > > We've got an excellent DSSSL-fu'er over here :), maybe he or someone > > > else knows how to change that? What do you mean with this? > > XML *IS* case sensitive, and we use XML to make the docs. > > So I think we should be XML compatible with function names too. > > True, but the tool used to document another tool should not define > what is presented to the reader. :) > > I took a quick look through the DSSSL before I committed the patch > which lowercased the Hyperwave tags a couple of days ago, > and it looked as though case-folding was intended, as did the XSL > stylesheet. I haven't had time to look up the syntax used and I'm not > an expert in either though, so I couldn't say for sure and just ended > up running a script over hw.xml to fix the problem. > > To be honest, I've never noticed this problem before, and I've been > working on the manual for 3 years. But then, I always use lowercase > for function names so I wouldn't necessarily have clued in before > now. :) Sorry to reply so late, have been on the road in Germany. This problem with the functions names have been discussed several times. Look at the mysql_*() functions, there is everything ok. Zeev made aliases so we have now easy functions name which can be rememberd by any average user. Sure function names are case-insensitive. But can you imagine to rename a function like ImageCopyMerge() or ImageCopyResampled() to imagecopymerge() or imagecopyresampled()? -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc /en/language oop.xml
On Fri, May 18, 2001 at 09:41:39AM +0200, Kristian Köhntopp wrote: > Daniel Beckham wrote: > > It looks like you might have truncated this sentence in the > > language.oop.serialization section of oop.xml: > > > > > > > > The following information is valid for PHP4 only. In > > PHP3, an > > > > > > Thanks for hinting. I'll fix. Than write PHP 4 and PHP 3. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
[PHP-DOC] Who is responsible for this ..,
bash-2.01$ automake automake: configure.in: `PACKAGE' not defined in configure.in automake: configure.in: `VERSION' not defined in configure.in automake: configure.in: required file `./install-sh' not found automake: configure.in: required file `./mkinstalldirs' not found automake: configure.in: required file `./missing' not found automake: no `Makefile.am' found or specified -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Approving CVS requests (was: to the German-people ...)
On Wed, May 16, 2001 at 07:45:17PM +0200, Jeroen van Wolffelaar wrote: > > It gets annoying with the time. > > [snip] > > > > > Do you have an CVS account? I havent seen any commits. > > > > [snip] > > > > No, I haven't got a CVS-account, I'm still waiting. Please be patient. Rasmus can I get Karma for CVSROOT? The rest behind that accounting system I have tested on my local system. > The php-group isn't really quick in approving CVS-requests indeed. > Of course I understand they're busy, etc, and that they won't approve > every CVS request immediately. Do you mean the php-group or the php-doc team? Both are normally very quick. I have only a lame 14.4 modem, so my patches have some time delays. > But IMHO they should approve requests when it's clear that the contributions > are useful (and Thomas' are). > And if it isn't clear, just send a short mail > 'plz show us some more contributions'. Though this isn't necessary for > Thomas :-) But not every is willing do such a job. Hunting bugs on the various PHP manuals doesnt make every time so much fun. > Otherwise, the danger is that people will stop doing so much effort, and > switch > to another project. Not everybody is that 'volhardend' (insistent?). > This also counts for the installation of the manual-generator. I myself have > spent > hours finding out how to get it working, time I'd rather spent on the manual > itself. I have now a manual-generator for years. Its working on a very old Debian system. But I havent found the time to look for the bugs in Daniel Beulshausens en/pear/printer.xml documentation. > > If something in MY contributed files isn't OK, tell me what wrong, so that > I > > can learn for the next time. I have checked the english documentation and it is ok. > > > I am currently checking the manuals. The most errors (I have counted ten > > > of them) in the english tree. > > Only ten errors in the english tree? I think that's quite optimistic. And if > you mean > typo's, it has probably just increased... For myself too counts: point me at > my errors. The only errors are in the not yet commited pages from Daniel. > > BTW: Have you seen the bad reference for the PHP-DOC in relation to asp, > > etc. in the comparison between WebScriptLangs in "Internet Professionell"? > I > > hope it doesn't get worse, if you really act with everybody like me. > > > > Look at "Dokumentation": If every Käsblättle wrote such nonsense, we can forget PHP in Germany. Another high ranking magazin, iX, writes also sometimes nonsense. The author of that magazin wrote that they needed a whole day to install PHP. The authors wrote in that article, that they cant find any information in the PHP documentation. I'm not sure if he ment the book from Markt+Technik Verlag in Munic. > http://www.zdnet.de/internet/artikel/java/200105/applikationssprachen06_03-w > > c.html > > Is there also an english version for the ppl not speaking german? (I do, but > others > don't) zdnet.de is a German speaking magazin. > > Should I really provide a version for filesystem.xml v1.64, and array.xml > I > > was currently working on, or will it also be ignored only? Please do, nobody will ignore you. Currently I have only some problems with my ISP, webspace, modem and other things. > Yes! any contribution will help improve the documentation. > I'll check and then commit your english contributions. For the german ones, > you should check whether there is anyone at home over there... What is your problem with Germans? I'm sitting at my desk :) -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] To the German-people: filesystem.xml
On Wed, May 16, 2001 at 08:48:48PM +0200, Mark Kronsbein wrote: > > BTW: Have you seen the bad reference for the PHP-DOC in relation to asp, > > etc. in the comparison between WebScriptLangs in "Internet Professionell"? I > > hope it doesn't get worse, if you really act with everybody like me. > > Ive seen it. It was not the first Article which Marco Zierl wrote about > PHP. > Though it was not the first which was nearly 90% wrong. Dont belive > everything > they write. I have deleted another article from this journal by Marco Zierl. He writes IMHO nonsense. By the the way, who have removed the link to the php.net/news.php page? > IMHO the Documentation of PHP is one of the best Documentations of > Opensource Projects Ive ever seen. Auwa, this was a very impressiv statement I ever read on mailinglist. > Just my 0,02 DM ;) Change to EUR and it would be only 0.01 EUR. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] To the German-people: filesystem.xml
On Wed, May 16, 2001 at 12:03:22AM +0200, Thomas wrote: > > > I can't reach Egon Saturday, so I try it here: Could somebody please > confirm > > > the enclosed de/functions/filesystem.xml and de/Translators.xml? > > > > I'm still alive. On weekends I spent the most time in another city ... > > A girlfriend in another town? :) No but something like that. > > Do you have an CVS account? I havent seen any commits. > > Wasn't the discussion last Friday enough, or is it a sport to tease me? > > No, I haven't got a CVS-account, I'm still waiting. Therefore the question > "...please confirm..." above. Till now I was waiting for eighter a commit > or a response to filesystem.xml v1.62 I've mailed to you on Saturday. I am currently checking the manuals. The most errors (I have counted ten of them) in the english tree. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] To the German-people: filesystem.xml
On Tue, May 15, 2001 at 08:42:29PM +0200, Thomas wrote: > I can't reach Egon Saturday, so I try it here: Could somebody please confirm > the enclosed de/functions/filesystem.xml and de/Translators.xml? I'm still alive. On weekends I spent the most time in another city ... > What I've done: > > de/filesystem.xml: > - implemented changes to en-version 1.63, > - corrected some typos, > - rephrased some function-titles, so that > the TOC is easier to read > > de/translators: > - changed the status-info of filesystem.xml to 1.63 Do you have an CVS account? I havent seen any commits. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] phpdoc CVS and translations
On Fri, May 11, 2001 at 04:55:45PM +0200, Thomas wrote:
> I understand Hartmut very well, but I also understand several points of the
> others.
I know him very well. I have been working with him together over a year.
> I think we all here have at least similar aims (if not the same) concerning PHP
> and it's Documentation.
> Since I'm not experienced enough (yet), I don't talk about the "HOW to realize"
> for now, but
> I want to focus on the - IMHO - two main-issues (instead of fighting about one
> single proposal with a great aim):
Dont take my answer personal, could you break your lines with your emailer
down to a readable size?
> 1.) We should have in mind the average user - also a beginner - which downloads
> a documentation. If he finds it in his native language, he'll DL it. He wouldn't
> ever think that it might be not complete. So a missing function in the doc
> doesn't exist in the language.
> -> We really should care that all functions are available in each
> laguage-version of the documentation (no matter if English or already
> translated). If you do it via a script, splitting up files, shouldn't really
> matter, if most of you are against file splitting, make another proposal, or do
> the script-change (or tell me how I can lean it, and I'll do it).
I have always stated, that all people can make contributions to the
manual. Contributions for the manual have been made in the original
english manual first. If there are some errors, it will be corrected, as
soon one of the editors find some time.
> 2.) Resources for Open Source projects:
> iX, a German magazine, brought it to the point: A big issue for Open Source is
> the motivation to get enough resources.
I know iX very well and I have seen articles which are not in my opinion.
> And a voluntary translator should be rather immediately able to translate text
> and not - extremely spoken - being forced to study computer-science before.
> --> I'd suggest to invest a one-time-work in a step-by-step tutorial for the
> needed environment, to prevent the giving up of an possible translator only due
> to technical problems before he has done anything useful for the Project (The
> same is with being ignored: Egon told me I should apply for an CVS-account, but
> done this, I've been ignored completely - not even a "rejected").
Outch, come on. I have told you to use the resources you can easily find.
If you got no CVS account, this means that Rasmus or some other people off
the PHP core havent had the time to make one.
> If you talk about CVS and download-sizes:
> Here we should also have in mind the person, the resource we want, and not what
> the "applicant has to do" (there are enough other technical necessities). So it
> it's possible for the moment to minimize the DL-size with CVS-commands, why not
> again write a step-by-step-tut?
> But pls. have also in mind for the future, that the number of languages could
> grow as well as the number of additional files in the existing languages (not
> yet translated files, etc. -> more MB).
23 MBs is not so much :) It's is only timeconsuming if you try to checkout
the first time. And if you read the PHP-DOC mailinglist, you can be shot
with a 8 MB diff by Rui Hirokawa.
> To make a long story short:
>
> Please don't "beat down" one single proposal, but think cool about the
> user's/translator's needs and about possible ways to realize them (M$ is only
> that big, because it was able to motivate users to buy, and also motivate people
> to work for them. And they motivated People and magazines to advertise for them
> {not like the last PC-Magazine-Article about PHP}).
>
> I think with that focus in mind we can only win!
Please download the manual and translate. If you made some mistakes it
doesnt hurd me. There are now several peoples around me who can correct
it.
If you have some time early July, visit me on the hills in Stuttgart. I
hope Rasmus will also be there and you will get your CVS account very
soon.
-Egon
--
LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/
All known books about PHP and related books: http://php.net/books.php
Concert Band of the University of Hohenheim: http://www.concert-band.de/
First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] phpdoc CVS and translations
On Fri, May 11, 2001 at 10:15:29AM +0200, friedhelm betz wrote: > Hello Hartmut and all other readers of this thread, > Thursday, May 10, 2001, 5:03:09 PM, you wrote: > > > Andrei Zmievski wrote: > >> [...] > >> Since en/ is your main working directory you can just run cvs upd -d > >> from there when you want to update or put "upd -d" in your .cvsrc file. > > > i'm not talking about myself here, i know enough about CVS to do > > all this by hand > > > but the average translator might not be up to that level But I hope you can learn enough :) > > it's not easy to find people that are up to using all the tools > > needed to work on the manual, and everything we can do to make it > > easier or more convenient would be a good thing IMHO > > > and reducing the checkout size from ~25MB to ~6MB for the pure > > english manual and about ~10MB for a complete translation > > with the additional benefit of faster updates could be a good start I have checked the PHP manual on toye and it tooks only a very short time. > i am a average translator and i am a bloody beginner in cvs. > few weeks ago i started to help with german translation. > at my point of view i strongly aggree to hartmut. the easier and more > convenient the more people maybe willing and able to help with the > translation. the point for me as ordinary translator is the > translation itself, not the technical stuff around. > there´s no question i am willing to deal with the basic stuff of cvs > and getting the appropriate files from phpdoc. further on, it would be > nice to reduce the checkout size (poor student with a modem) and i really > don't need all the other languages i am not working on. > a short description from a person familiar with cvs (and > with enough time to do this) how to check out only the needed files > could help for the problem with the checkout size. I have also a very old modem with 14.4 kB. You can stop a checkout and use the next day a update until you have a complete repository. > i can say nothing about the technical background nore the performance, > the building of the manual and so on. > the "missing functions" problem led me to help with translation. > solving the problem of "missing functions" in any way would be great! Look at the functions tables from Hartmut and you can get some idea what we are speaking. www.zugeschaut-und-mitgebaut.de/php/ oder zend.com/phpfunc > just the opinion from a really novice without any knowledge of the > whole technical stuff. Please don't split the manual into several languages. Andrei have told us that even a novice can checkout the language he is interested in. Witthout the root directory the manual is useless. -Egon PS: Dams, the en an fr manuals are ok! -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] ldap-german translation
On Thu, May 10, 2001 at 10:54:13PM +0200, friedhelm betz wrote: > Hello , > a few weeks ago i started the translation of imap-functions. > can any of the (german) translators tell me, how to handle common > english expressions in the german translation? should i try to find > similar german expressions ending up in "horrible" words, or is it ok > to leave them alone? are there any standards or rules? > > at the moment i`m thinking about "Distinguished Name" and "Relative > Distinguished Name". so far my attempts in german sounding terrible. > any suggestions?> No I cant remember :] Can you use DSN? -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] phpdoc CVS and translations
On Thu, May 10, 2001 at 09:37:14AM -0500, Andrei Zmievski wrote: > On Thu, 10 May 2001, Hartmut Holzgraefe wrote: > > i know that this is possible, but it is very unconvenient IMHO > > > > first, "cvs co -l phpdoc" would not be enough, as you'll need the > > dbxml-, images- and perhaps howto-subdirectories, too > > So? cvs upd -d howto dbxml should do quite nicely. I'm against a split into different languages. 23 MB could be handled even with my old 14.4 kB modem. Look at the size for phpweb. > > and not using the -d option is leading to problems whenever a new > > subdirectory is added to the toplevel or 'en'-directory > > Since en/ is your main working directory you can just run cvs upd -d > from there when you want to update or put "upd -d" in your .cvsrc file. All the years I have used "cvs -z9 update -dP" and had no problems. With branching and so on I have problems. > > ok, right now this does not happen that often, but i'm also thinking > > about > > an improved translation infrastructure that would pull in english > > versions at the function level instead of the extension level as we > > have it now (we have a lot of translations that are not that up to date > > right now, but usually this hurts due to missing functions that were > > added after the translation and not so much due to the translated > > parts being outdated) > > Having each function in a separate file? Ack.. I have discussed this with Hartmut. This is a nice idea, but there is actually now way to split the manual into subdirectories (extensions) and then each function in a separate file. > > so after all i'd prefere to have the translations as seperate modules > > in CVS > > > > nothing would change for those of us only working on the original > > > > translators would have to check out the original first as usual with > > > > cvs co phpdoc > > > > and would have to additionaly get their translation language(s) of > > choice > > > > cd phpdoc > > cvs co -d de phpdoc-de > > > > for example > > (similar to what you have to do with Zend and TSRM in the php4 source) > > > > this is a little additional inconvenience on the initial checkout but > > after that you don't have to worry about your cvs settings anymore > > I suppose if there is a really big desire for this from more than one > person, than we could setup aliases in CVSROOT/modules for phpdoc: > > phpdoc -a !de !it !nl phpdoc > phpdoc-de -d de phpdoc/de > > Or something like that. I can live with the current situation. If not I'll remove some unecessary functions to keep the manual small. rtfm() for example :) -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] bool/boolean and int/integer
On Thu, May 10, 2001 at 11:03:02AM +0200, Damien Seguy wrote: > I noticed that docs are using sometimes bool, sometimes boolean to > describe boolean values. Save for integer and int. > > It seems that most frequent occurences are "int" and "bool". Is that > a general rule? I suggest we could harmonize all of this, with only > one expression. I would prefer "int" and "bool" to have short proto lines. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] How do I make only ony function .xml file?
On Thu, May 03, 2001 at 12:44:24PM -0600, Andy Sautins wrote: > >I am working on updating the oci8 extension documentation to reflect some > new functions that were included. I have checked out the phpdoc branch and, > since english is the only language I really know ( sorry ), I'm assuming I'd > need to make the changes to the en/functions/oci8.xml. Right! > My question is, I'd like to iterate a series of change to make sure > everthing is OK ( I'm new to this whole documentation scheme ). What is the > easiest way for me to be able to change the oci8.xml and just > create/re-create the oci8 section of the documentation? I'm a little > confused between the phpdoc/README and phpdoc/README.xsl on what the best > way of generating the HTML version. The easiest way is to copy a similar function block and change the content and let the elements and attributes as is. To validate your additions, install Jade, DocBook and Norman Walshs Modular Stylesheets. The components you need are listed somewhere in the top level directory of phpdoc. It is not so easy to install these programs. But if you have master this you can try: autoconf ./configure make if there is no error you can look after some time in /html for your newly functions. Please use XEmacs if you can, its the best XML-editor I know. There is an psgml-mode. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Please could somebody of the de-translators check this?
On Tue, Apr 24, 2001 at 09:05:10AM +0200, Wolfgang Drews wrote: > > Could you please check which of the stated translators are still > > active, and correct that file in that way, so that new > > people like us can get a picture what is really to be done? > > (Their names could stay, but pls. make a note, that this > > file is "free"). > > Yes, good idea. Especially with the versionstring to put into. Ok, lets > do it this way. I am one of those "bad guys", who had some other > things to do than translating, but i will get back to stuff soon. All new and very old translators have to check cvs.php.net -> phpdoc -> en -> functions. Here is the only place where the version number should go into the German translation. > > Would be really great and helpful if somebody of the experienced > > German people could check and update this! Ask Egon Schmid <[EMAIL PROTECTED]> but be carefull. He is an Oberschwabe living in Stuttgart. > will do as soon as i get to my linuxstation@work. But that will take > till tomorrow, today it's University-Day. So i guess, Egon will be > much faster *g* > > > Last question: Could somebody please change the line 78 in > > /de/translators.xml from > > > > "filesystem.xml Wolfgang Drews + Thomas fertig (not > > sure)" to > > "filesystem.xml Wolfgang Drews + Thomas fertig (bis > > V. 1.61)" ?? > > Egon, can you please add a field for "till versionnumber" ? It is > IMHO a good idea. Then every translator should check his files ASASP. Done. > > P.S.: If intersting, the reason: > > With Thomas Wise, we're 3 new people (I suppose, with Cornelia > > Boenigk), > > Cornelia?? aehm, guess she made a lot of translations already ... Yupp. > Yes, shame on me :) Mutu halt mal wieder mal nach Stugart komma. Kannst mir aber auch den Armin Steiner schicken. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] PHP easter Egg
On Mon, Apr 23, 2001 at 08:50:46PM +0100, James Moore wrote: > Just wait for april 1st there is also a note in the manual about it.. > http://www.php.net/manual/en/function.phpinfo.php I think it is not a function. So it may be a builtin function. Any suggestion? -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] PHP easter Egg
On Mon, Apr 23, 2001 at 09:31:07PM +0200, Damien Seguy wrote: > Here are some PHP easter Egg. > Should we document those? > add this to any PHP 4 script : > This will bring some easter egg picture right from PHP No, we should not document this functions. This functions are very importend for the PHP Core peoples. I need them every first day in April. -Egon> -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] settype doc error
On Sun, Apr 22, 2001 at 10:03:03AM +0200, Hojtsy Gabor wrote:
> The settype doc says: int settype (string var, string type)
> although it should be : int settype (mixed var, string type)
>
> The first argument is not a string.
> If it is, you should write:
>
> $abc = "foo"; settye("abc", "integer");
>
> Indeed you must say: settype($abc, "integer");
>
> An example there would be good. :)
What types can be $abc? If you have some working examples, change the
docs. Don't forget to correct the protos in the source also.
-Egon
--
LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/
All known books about PHP and related books: http://php.net/books.php
Concert Band of the University of Hohenheim: http://www.concert-band.de/
First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] settype doc error
On Sun, Apr 22, 2001 at 10:43:11AM +0200, Hojtsy Gabor wrote: > I have commit problems: > > I am trying to commit the new var.xml file, and I get > > E:\phpcvs>cvs commit phpdoc/en/functions/var.xml > cvs [server aborted]: cannot check in to /repository/CVSROOT/Emptydir > > I get the same when I specify the full CVSROOT: > > E:\phpcvs>cvs -d :pserver:[EMAIL PROTECTED]:/repository commit > phpdoc/en/function > s/var.xml > cvs [server aborted]: cannot check in to /repository/CVSROOT/Emptydir > > I don't know what is the problem... I am correclty logged in, I can > checkout... This cannot be!!!? I don't have a working M$ solution here, but the correct syntax should be: cvs commit -m "Comment ..." relative/path/var.xml cvs -z3 update -dP Don't mix checkouts with updates. If you are in the right directory or folders you can't do checkouts, only updates. -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] settype doc error
On Sun, Apr 22, 2001 at 10:19:46AM +0200, Hojtsy Gabor wrote:
> > > $abc = "foo"; settye("abc", "integer");
> > >
> > > Indeed you must say: settype($abc, "integer");
> > >
> > > An example there would be good. :)
> >
> > What types can be $abc?
>
> Any type. Array, string, integer ... The same stands for
> gettype, where the parameter is shown as mixed (which this
> should be).
>
> > If you have some working examples, change the docs.
>
> OK.
>
> > Don't forget to correct the protos in the source also.
>
> I don't have karma to play in the source, and I am not
> the best in C, so this should be a task for someone else.
For protos you don't to have any knowledge of C. Every in the protos is
hidden within comments.
Only the PHP Core Members can you give karma. I haven't the rights right
now.
-Egon
--
LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/
All known books about PHP and related books: http://php.net/books.php
Concert Band of the University of Hohenheim: http://www.concert-band.de/
First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] Could somebody pls. correct a typo?
On Fri, Apr 20, 2001 at 12:05:39AM +0200, Thomas wrote: > sorry, I still work with 4.03PL1 since the MSSQL-ext. doesn't work in 4.04. Then upgrade. > But shouldn't that be worth a short comment in the doc (like "inserts XHTML >breaks..." instead of "HTML breaks", and > when the change (from what) happened?) , since Browsers like Netscape 4.x don't >react on ? > Or have I missed a section with all these things one has to consider (know) before - >or at least after upgrading - (like > $array[myfield] and the backward-compatible nl2br "doesn't work anymore")? It is documented in the English and German docs. For other languages I don't know. > Is there a consideration for eventually occuring "traps" for the change to 4.05? > I assume that it's not really funny if a user - or worse - ISP upgrades, and than >can't defend against complaints > because of "buggy" scripts (which worked before). > Anil Madhavapeddy wrote: > > > > -> would somebody pls. correct to in both lagunages? > > > > That's not a typo. nl2br() uses XHTML tags since PHP-4.0.4 Thats the correct syntax nowadays. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] German Translators: Could somebody check this please?
On Mon, Apr 16, 2001 at 07:37:03PM +0200, Thomas wrote: > I've translated the about.xml and standards.xml from the PEAR-chapter. Since I can't >post it to php.doc, you can get it > at http://www.t0.or.at/~sunny/Pear_de.zip (note: t0 = tZERO). > > Could somebody please check it, and if it's OK commit it into CVS? (Or if it's not >OK, tell me what should be changed) Send it in an attachement to me. I will have a look at it and if everything is ok, I will commit it. Have you checked it against the latest en tree? We need a version in the Translators file to which version in the en tree it is compatible. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] entity 'edited-by' is broken in japanese manual
On Fri, Apr 06, 2001 at 07:22:51AM +0900, Rui Hirokawa wrote: > On Sat, 24 Mar 2001 01:36:40 +0200 (EET) > Jouni Ahto <[EMAIL PROTECTED]> wrote: > > On Sat, 24 Mar 2001, Rui Hirokawa wrote: > > > In this case, > > > > > > should be > > > > > > Please modify it. > > > > Ok. Done. > > Thanks. > > It's OK for http://snaps.php.net/manual/ja/html, but > the entity Editedby in http://www.php.net/manual/ja/ is still broken. I can't see the entity Editedby in php/ja/bookinfo.xml. I think the former was more correct. You can try to define the two entities "&Edited;" and "&by;" and then make a new new entity with "&Edited; &by;". In the German manual it is already defined in the modular stylesheets and looks like "Herausgegeben von". -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] IMAP docs - function order
On Thu, Mar 29, 2001 at 02:23:28PM -0600, Daniel Beckham wrote: > I just noticed something.. is there a reason that the imap docs are not > sorted by alphanumeric order. Actually, I don't really see any rhyme or > reason to the list as it's currently arranged. If no one objects, I might > go ahead and resort these. Ask Hartmut Holzgraefe <[EMAIL PROTECTED]> about the sorting order. IMHO its useless if we have no subheadings and subheadings may be impossible IIRC. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
[PHP-DOC] Italian PHP Manual have some ...
... errors. Played just with toye and I have found: [eschmid@toye phpdoc]$ make /usr/bin/jade -d html.dsl -V use-output-dir -t sgml ./phpdocxml.dcl manual.xml /usr/bin/jade:./it/functions/oci8.xml:1201:14:E: end tag for element "simpara" which is not open /usr/bin/jade:./it/functions/oci8.xml:1202:9:E: document type does not allow element "para" here; missing one of "footnote", "msgtext", "caution", "important", "note", "tip", "warning", "blockquote", "informalexample" start-tag /usr/bin/jade:./it/functions/oci8.xml:1236:12:E: document type does not allow element "simpara" here; missing one of "footnote", "msgtext", "caution", "important", "note", "tip", "warning", "blockquote", "informalexample" start-tag /usr/bin/jade:./it/functions/oci8.xml:1241:13:E: end tag for "para" omitted, but OMITTAG NO was specified Luca I hope you know that this means. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] resources.xml errors
On Tue, Mar 27, 2001 at 10:48:29PM +0200, Hojtsy Gabor wrote: > > > > The file in the $subj is not too well made... There > > > > are much dirty texts in it made by the automated process... > > > > Is it ready for translating? I dont think so... > > > Obviously, the resource.xml in en tree has been infested by > > > French version. I corrected this text. > > > > Look at cvs.php.net if you can resolve the language problem. > > > > > En version is ugly (where is the last column) and French > > > version is even missing!! > > > Egon, help! What happened? > > En version is much ugly... There are so many > > strings... Useless.. And much more problems... > The texts are not english... It is a very alpha version. Nobody is perfect. Damien and I can disable it for a while until it looks more matured. -Egon -- LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ All known books about PHP and related books: http://php.net/books.php Concert Band of the University of Hohenheim: http://www.concert-band.de/ First and second bestselling book in German: http://www.php-buch.de/
Re: [PHP-DOC] anyone knows what this error is?
On Mon, Mar 12, 2001 at 11:03:45PM +0100, Jirka Kosek wrote: > [EMAIL PROTECTED] wrote: > > > > Stylesheet takes language code for autogenerated text from lang > > > attribute. > > > > The attributes in the book element doesn't have any meaning. This is done > > by the Makefile (LANG=ko) and common.dsl (define %default-language% "ko"). > > But %default-language% is used by DSSSL stylesheet only when there is no > lang attribute in document. Try to change to lang="ko"> or remove lang attribute completely. After this change, > documentation is generated the right way. (In fact I just suppouse this, > because I have no CJK fonts on my machine, so I see just boxes instead > CJK characters;-). Oh yes, I have just thought about them. But I cannot try this on my home maschine, because there the DSSSL stylesheets are too old. I hope you can verify this with the ja/jp manual. -Egon -- http://www.linuxtag.de/ http://php.net/books.php http://www.concert-band.de/ http://www.php-buch.de/
Re: [PHP-DOC] anyone knows what this error is?
On Mon, Mar 12, 2001 at 09:53:00PM +0100, Jirka Kosek wrote: > > "Egon Schmid (@work)" wrote: > > > > Problem is that DSSSL stylesheets does not know "kr" language (Korea?). > > > There is language "ko" in DSSSL stylesheets. IMHO this is error in > > > php-doc, because "kr" is country code (ISO 3166) and "ko" is language > > > code (ISO 639). Short term solution would be to change lang="kr" to > > > lang="ko" in manual.xml. Long term solution is to change "kr" to "ko" in > > > php-doc consistently. > > > > Nope. If you configure --with-lang=kr and look into the Makefile you > > will see a line with "LANG=ko". Since DSSSL 1.59 "ko" is supported. BTW > > I get the same error messages. > > But if you look manual.xml generated by configure you will see > > ... > > &PHPManual; > ... > > Stylesheet takes language code for autogenerated text from lang > attribute. The attributes in the book element doesn't have any meaning. This is done by the Makefile (LANG=ko) and common.dsl (define %default-language% "ko"). When you look into chapters.ent then you can see that the files are coming from the kr directory. It would be very nice, if the Korean people look for other DocBook manuals in Korean language and ask the authors, what they have done. -Egon -- http://www.linuxtag.de/ http://php.net/books.php http://www.concert-band.de/ http://www.php-buch.de/
Re: [PHP-DOC] free translation of php specs
On Mon, Mar 05, 2001 at 09:31:02PM -, James Moore wrote: > I believe there are already some people working on this see: > http://cvs.php.net/viewcvs.cgi/phpdoc/it/ if your company feels inclined to > help then please check out a copy from CVS and start on it, youll need to > get some CVS accounts so you can commit back to the CVS repository. see > http://www.php.net/anoncvs.php for more info and get cracking.. Its also > normaly good form to contact other people mentioned in the translators files > to see what they are up to. Thanks James for your answer. But he should contact the editor of the Italian PHP manual and this is Luca Perugini <[EMAIL PROTECTED]>. In Italy not every author do have an CVS account and so Luca is the person who will commit the translations for the authors. -Egon -- http://www.linuxtag.de/ http://php.net/books.php http://www.concert-band.de/ http://www.php-buch.de/
Re: [PHP-DOC] What happened to phpweb/manual?
On Wed, Feb 28, 2001 at 01:44:05AM +0100, Mark Kronsbein wrote: > > > [EMAIL PROTECTED] wrote: > > Oh I haven't seen any deledeads. But anyway only *.xml files should be > > found in the german tree. You must do something else wrong. > > Not the .xml and not in phpdoc/ I am talking about > phpweb/manual/de/ > > > For German .php files ask Wolfgang or call the php-center. If you don't > > get the needed files I will ask Jade. > > Ill probably need these Files once a Day for a new Project ;) Then checkout phpweb with rsync. But I don't actually know if you can rsyncing the German manual. But this shouldn't be an issue for you :) -Egon -- http://www.linuxtag.de/ http://php.net/books.php http://www.concert-band.de/ http://www.php-buch.de/
Re: [PHP-DOC] What happened to phpweb/manual?
On Wed, Feb 28, 2001 at 01:17:05AM +0100, Mark Kronsbein wrote: > I just wanted to start a new Checkout of the German Manual. > I need the .php Files, so i checked out phpweb/manual/de. > But: All Directories are empty... > > So: what happended to theses Files? Oh I haven't seen any deledeads. But anyway only *.xml files should be found in the german tree. You must do something else wrong. For German .php files ask Wolfgang or call the php-center. If you don't get the needed files I will ask Jade. -Egon -- http://www.linuxtag.de/ http://php.net/books.php http://www.concert-band.de/ http://www.php-buch.de/
Re: [PHP-DOC] Off-topic: adding the printed PHP manuals to books.php
On Fri, Feb 23, 2001 at 06:40:55PM -0800, Jesus M. Castagnetto wrote: > I do not have enough karma (with the new access > system) to make changes to phpweb, that was why I > mentioned the links I saw and that someone may want to > make the additions. I hope you will get some more karma very soon. > Was not aware of the background, origin or problems > that this print had (and is causing), otherwise I > would not have brought them up here. So, now that I > know, I understand why is not important that those get > listed in books.php No problem. It is very close to be solved. > As Rasmus mentioned, moving the manual to the ODL > would be better, because it was designed for > documentation and the GPL is not a perfect fit for the > manual. This was mentioned also. > I did not want to offend or irritate anyone, just > pointing out stuff I found out while carelessly > browsing through online bookstores. I did occassionally the same and have seen that books at amazon.com, amazon.de, and barnes-and-nobles. I hope this company will no longer exists in the near future. -Egon -- http://www.linuxtag.de/ http://php.net/books.php http://www.concert-band.de/ http://www.php-buch.de/
Re: [PHP-DOC] Off-topic: adding the printed PHP manuals to books.php
On Fri, Feb 23, 2001 at 04:41:56PM -0800, Rasmus Lerdorf wrote: > > Since the PHP manual is under the GPL all people around the world think, > > they can copy it and publish it in printed form. This is also the thinking > > mostly all PHP Group and Documentation members. But the publisher have > > now the copyright and this can us protect from distributing the manual as > > usual. Copyright law is not GPL. > > The publisher cannot possibly have the copyright. The authors of the > documentation hold the copyright. I see nothing wrong with them printing > up the documentation. If there were to try to stop others from doing the > same, then we would have a problem. But until I see evidence of that I > don't see the issue. No, you have not gotten the point. If you as a author gets a contract with a publisher to publish your book, then the publisher holds the copyright. He has also the right to ask the author to update it and so on. Have you looked close to the first pages of the mentioned books. There you will see a copyright notice from the publisher. Why I think it is illegal is, he don't have a contract with the original authors and the editors. It is a book on demand and such a thing we probably can manage ourself. In Germany there have been for weeks a voting "how many money will you pay for a printed manual". Feedback was great. -Egon -- http://www.linuxtag.de/ http://php.net/books.php http://www.concert-band.de/ http://www.php-buch.de/
Re: [PHP-DOC] Off-topic: adding the printed PHP manuals to books.php
On Fri, Feb 23, 2001 at 02:38:29PM -0800, Jesus M. Castagnetto wrote: > I think that the printed PHP Manuals should be added > to the books.php list, and/or linked from the docs.php > page too. > > Saw them at Amazon.com: > > http://www.amazon.com/exec/obidos/ASIN/0595132278 > http://www.amazon.com/exec/obidos/ASIN/0595132286 > > Someone with enough karma may want to do these updates > in phpweb. If you do that I will delete it. This is a very old copy of a historical PDF file. Its distributed under the GPL (which is not appropriate for documentation). And the publisher said, he will give a portion of the money he earns to the open source community. He said not to which community. Since the PHP manual is under the GPL all people around the world think, they can copy it and publish it in printed form. This is also the thinking mostly all PHP Group and Documentation members. But the publisher have now the copyright and this can us protect from distributing the manual as usual. Copyright law is not GPL. Only Jouni and Hartmut have seen the problems. I haven't yet received any feedback about the conversation with Rasmus, RMS, and Hartmut at Bruessel about that problem. -Egon -- http://www.linuxtag.de/ http://php.net/books.php http://www.concert-band.de/ http://www.php-buch.de/
Re: [PHP-DOC] PDF bug with "--" operators
On Mon, Feb 19, 2001 at 03:58:32PM -0600, Daniel Beckham wrote: > Yes, it would be a bit harder to read, but I think it might be worth it to > correct readability issues with the PDF version of the manual. Please wait for Jouni. The problem is that we cannot pass a verbatim environment throu TeX. I was glad enough while Jouni produced my private PostScript and PDF versions of the PHP manual. "a" looked like ä", "o" comes out as ö" and so on. With a pure english TeX version this problem don't appear. Probably the right person to blame is Norman Walsh with his modular stylesheets or the author of Jadetex. -Egon > - Original Message - > From: "Damien Seguy" <[EMAIL PROTECTED]> > To: "Daniel Beckham" <[EMAIL PROTECTED]> > Sent: Monday, February 19, 2001 3:39 PM > Subject: Re: [PHP-DOC] PDF bug with "--" operators > > > le 19/02/01 20:20, Daniel Beckham à [EMAIL PROTECTED] a écrit : > > > What would be the best way to turn them into entities, create them and put > > it in global.ent? Or use the &#xx; format? > When I needed it (and I did, with French language), I created the > @#xx; format. It is totally save, and easy to go. > However, it makes it harder to read again. > > Hope this helps. > > Damien Seguy > > > > -- -- http://www.linuxtag.de/ http://php.net/books.php http://www.concert-band.de/ http://www.php-buch.de/
[PHP-DOC] Translators Heads UP
Hello, I was looking into the French PHP manual and I have received the following: /usr/bin/jade:./fr/functions/uodbc.xml:23:19:X: reference to non-existent ID "database-support-options" The cause is the following, ./en/chapters/install.xml has been changed and "database-support-options" are now not defined. In ./en/functions/uodbc.xml the paragraph with the linkend="database-support-options" is only a comment. bash-2.01$ find . -name "*.xml" | xargs grep "database-support-options" ./en/functions/uodbc.xml: linkend="database-support-options">Installation on Unix ./ja/functions/uodbc.xml:UNIXã·ã¹ãã ã¸ã®ã¤ã³ã¹ãã¼ ./it/chapters/install.xml: ./kr/functions/uodbc.xml: linkend="database-support-options">Installation on Unix ./fr/functions/uodbc.xml:Installation sous Unix ./nl/chapters/install.xml: ./nl/functions/uodbc.xml: linkend="database-support-options">Installation on Unix This means the following: ja is ok it don't have a partintro in it/functions/uodbc.xml kr have an english version with partintro for uodbc.xml and in the translated install.xml there is no database-support-options defined. uodbc.xml should be removed, because the ./configure command will automatically substitute a missing file with the english version fr have two old files (install.xml and uodbc.xml) nl have also two old files (install.xml and uodbc.xml) Please check the two files and update. -Egon -- http://www.linuxtag.de/ http://php.net/books.php http://www.concert-band.de/ http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc /en/functions xslt.xml
On Sun, Feb 04, 2001 at 11:50:25PM -, James Moore wrote:
>
> > But this doesn't fit into the scheme of the examples we have already in
> > the manual. When I parse the source code I don't see such a malformed
> > syntax. Ok, someone have used it...
>
> this is true and PEAR also uses } else { so perhaps this is better in the
> manual too
Yes, and all documenters should use four spaces (not tabs) to intend the
examples.
-Egon
--
http://www.linuxtag.de/
http://php.net/books.php
http://www.concert-band.de/
http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc /en/functions xslt.xml
On Sun, Feb 04, 2001 at 11:33:12PM -, James Moore wrote:
>
> > Yes it is not documented. I prefer the } else { style.
>
> Personally I like
>
> if ($foo)
> {
>
> } else
> {
> ...
> }
>
> or
>
> if ($foo)
> {
>
> }
> else
> {
> ...
> }
>
> then all braces are in same col.
But this doesn't fit into the scheme of the examples we have already in
the manual. When I parse the source code I don't see such a malformed
syntax. Ok, someone have used it...
-Egon
--
http://www.linuxtag.de/
http://php.net/books.php
http://www.concert-band.de/
http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc /en/functions xslt.xml
On Sun, Feb 04, 2001 at 04:13:55PM -0700, Ron Chmara wrote:
> Egon Schmid wrote:
> > eschmid Sun Feb 4 14:59:51 2001 EDT
> > Modified files:
> > /phpdoc/en/functionsxslt.xml
> > Log:
> > Indentation in examples should be four spaces.
>
> About this:
>
> > -if (xslt_process($xslData, $xmlData, $result))
> > -{
> > +if (xslt_process($xslData, $xmlData, $result)) {
> > echo "Here is the brilliant in-depth article on learning";
> > -}
> > -else
> > -{
> > +} else {
> > echo "There was an error that occurred in the XSL transformation...\n";
>
> Should we establish a standard for bracket usage? Four spaces is currently
> standardized and documented (phpdoc/README), but bracketing is not, AFAICT.
Yes it is not documented. I prefer the } else { style.
-Egon
--
http://www.linuxtag.de/
http://php.net/books.php
http://www.concert-band.de/
http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc / make_chm.php
On Thu, Feb 01, 2001 at 10:48:17PM -, Jirka Kosek wrote: > jkj Thu Feb 1 14:48:17 2001 EDT > > Modified files: > /phpdoc make_chm.php > Log: > - added support for Czech (tested) and for Japanese (not tested) > - changed manual.html to $indexfile in a whole script > > > Index: phpdoc/make_chm.php > diff -u phpdoc/make_chm.php:1.6 phpdoc/make_chm.php:1.7 > --- phpdoc/make_chm.php:1.6 Sun Jan 14 09:11:38 2001 > +++ phpdoc/make_chm.php Thu Feb 1 14:48:17 2001 > @@ -21,12 +21,14 @@ > // Japanese is not on my list, I don't know why... > $languages = Array ( > > + "cs"=> "0x405 Czech", >"de"=> "0x407 German (Germany)", >"en"=> "0x809 Enlish (United Kingdom)", >"es"=> "0xc0a Spanish (International Sort)", >"fr"=> "0x40c French (France)", >"hu"=> "0x40e Hungarian", >"il"=> "0x410 Italian (Italy)", > + "ja"=> "0x411 Japanese", >"kr"=> "0x412 Korean", >"nl"=> "0x413 Dutch (Netherlands)", >"pt_BR" => "0x416 Portuguese (Brazil)" "il" is Israel, "it" is Italian (Italy. BTW "hk" is missing. -Egon -- http://www.linuxtag.de/ http://php.net/books.php http://www.concert-band.de/ http://www.php-buch.de/
Re: [PHP-DOC] PHP manual
On Tue, Jan 30, 2001 at 07:51:43PM -0500, David Elrom wrote: > > Why r we using TeX ? > > why not some other XML format ? If you want a printed manual, DocBook uses a TeX backend. TeX is better than every XML style shit. -Egon PS: I have read something about Donald E. Knuth the last day. He is now 63 years old. -- http://www.linuxtag.de/ http://php.net/books.php http://www.concert-band.de/ http://www.php-buch.de/
Re: [PHP-DOC] the php manual....
On Sun, Jan 28, 2001 at 02:16:27PM +0100, Hojtsy Gabor wrote: > > 1. What would it take to get the PDF versions into other languages > > besides english? > > I have asked this question some time ago. I guess the answer is > just time. I don't know about any technological problems > generating manuals in other languages... The answer is both, time and technological problems. I am not able to produce the German PDF because I have a German installation of TeX. This way the generation of the German PDF manual makes with a "echo "ach ..." a "echo äch ...". Examples are with this way not readable. If I need a recent PDF manual, I email Jouni and he send me one. There are more limitations in the TeX backend, which needs some patches to TeX itself. > > 2. Why isn't the PDF version being served on a page-by-page basis, as > > well as one big file? It sure would be nice to only put together > > a printed manual of the pages you want (i.e, If you're only using > > MySQL, it would save a lot of paper if you didn't print the Oracle, > > Postgres, Ovrimos, etc. sections.) > > Well you can use a printer program, where you can set what pages to > print... And for downloading it is not too much... Or go to Amazon.com and buy a PHP manual in two parts. -Egon -- http://www.linuxtag.de/ http://php.net/books.php http://www.concert-band.de/ http://www.php-buch.de/
Re: [PHP-DOC] l option added to status.php
On Mon, Jan 29, 2001 at 02:55:19PM -0500, Joao Prado Maia wrote: > > On Sat, 27 Jan 2001, Rasmus Lerdorf wrote: > > > This status table was getting rather large, so I added a language option. > > For example: http://toye.php.net/~rasmus/status.php?l=kr > I recently removed all the old files from the pt_BR tree that didn't get > transtlated yet. Removing from the repository will create problems when a > user tries to visit, say, install.php from the /pt_BR/ directory and the > file was not translated yet ? The normal user will not see XML files. > What I'm really asking is: are you guys checking if all the manual files > are there before creating the HTML files for the online manual, and if > they are not there, copying from the english tree ? No, we can check the transformation from XML to HTML. If there is a non existing XML in the pt_BR tree, the corresponding file from the en tree is used. If someone wants to translate an new file, he or she should copy the newest English version and translate this. Already translated files should be checked with Rasmus' utilities or better, with the current cvs.php.net. -Egon -- http://www.linuxtag.de/ http://php.net/books.php http://www.concert-band.de/ http://www.php-buch.de/
Re: [PHP-DOC] cvs: phpdoc /en/chapters install.xml
On Tue, Jan 23, 2001 at 12:13:10AM -, David Hedbor wrote: > neotron Mon Jan 22 16:13:10 2001 EDT > > Modified files: > /phpdoc/en/chapters install.xml > Log: > Added Caudium installation instructions. Works for me. I haven't seen a silly XML error or warning. -Egon -- http://www.linuxtag.de/ http://php.net/books.php http://www.concert-band.de/ mailto:[EMAIL PROTECTED]
