RE: [PHP-DOC] RE: phpweb / download-docs.php
Title: RE: [PHP-DOC] RE: phpweb / download-docs.php >Yes, it would be good to get some opinions from the people >administrating the servers what would be a good strategy for >naming files to avoid those 87 redirects Sascha mentioned >about. It makes sysadmin work just hell to remember what >they are and why... It is not just about the sysadmin work. By naming the files php_manual_$LANG.$FORMAT, people downloading the manual can easily identify, what manual it is, what language it is in, and what is the format. Now: manual.tar.gz wont help you identify what manual is this, or in what language is it... >About a big directory, there's at most only 11*11 (currently) in >distributions/manual, it's not much, and if we follow Gobas >recommendation about naming the files, I don't think it >will be cluttered. OK. >Another thing is the directories containing on-line >html-manuals... that could be split up to several subdirs. >It's near reaching the limits what's reasonable with ext2. >Or does it reside on reiserfs? Well, the downloadable packs are containing the same files. So if it is a problem for ext2, it is urgently need to be fixed, as then is it not unzipable in most users environments... Also we can decide if we want to produce "short" type of manuals, as people do at Nexen. This way we can pack a small compressed file with the most important functions and extensions, and left off the less used ones. It would be popular IMHO. The biggest deal in this is who will decide, what are the most used functions, and how can we make this short type without any make errors (as there will be internal links pointing to nowhere - into the part we left out). Goba
[PHP-DOC] RE: Manual in Brazilian Portuguese
Title: RE: Manual in Brazilian Portuguese Hi! Forwarding this to the appropriate list: [EMAIL PROTECTED], as there are the people responsible for translations. Goba [one [EMAIL PROTECTED]] >-Original Message- >From: Felipe Augusto Pereira [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, August 15, 2001 4:35 AM >To: [EMAIL PROTECTED] >Subject: Manual in Brazilian Portuguese > > >Dear friend, > > I would like to know how is going the translation of the manual to >Portuguese. How can somebody help to translate it? > >[]'s > >Felipe Augusto Pereira >[EMAIL PROTECTED] >Diretor da Ultramix - o seu portal >http://www.ultramix.com.br >Coordenador de Informática do Colégio Neo Planos >http://www.neoplanos.com.br >ICQ-48456507 Recife - PE > > >
[PHP-DOC] RE: phpweb / download-docs.php
Title: RE: phpweb / download-docs.php Wouldn't it be better to change these now to be distributions/manual/pdf/... distributions/manual/chm/... As in the near future (I hope so), the folowing formats will also be there: distributions/manual/html/... distributions/manual/text/... distributions/manual/palm/... This way the formats wont make a big directory... Hope this can work :) What about the manual naming conventions, I tried to suggest earlier? Is it ok, to modify the _Makefile in phpdoc_, the _PDF generator_ and _CHM generator_ scripts to output such files as: php_manual_$LANG.$FORMAT [See the whole list in my previous letter] Goba
RE: [PHP-DOC] Re: ID change in docs
Title: RE: [PHP-DOC] Re: ID change in docs >> Hotsjy and Damien. > >Hojtsy it is, sorry! (why didn't your parents call you 'Joe' ;-)... Heh :) Hojtsy is actually my family name. My given name is Gabor (Gabriel in English). In Hungary, we write our names in family name, given name order. See phpdoc/hu/Translators. Anyway, it is the best, to call me Goba, as it is my nick :) It comes from Gabor... Goba
RE: [PHP-DOC] cvs: phpdoc / faqurls.ent
Title: RE: [PHP-DOC] cvs: phpdoc / faqurls.ent >> I thought the same, but then the many mails came into my mind, >> asking that what link should be followed on that page. A >> http://cvs.php.net/co.php/php4/INSTALL?r=latest format would >> be absolutely good. Of cource pointing to the latest release. Isn't >> there a syntax like this in Chora? > >But http://cvs.php.net/co.php/php4/INSTALL takes you to the latest >revision. Why would you need an r=latest? I garbled up this URL with http://cvs.php.net/cvs.php/php4/INSTALL which actually wont do a chechkout, just print out versions. You are absolutely right :) Goba
RE: [PHP-DOC] cvs: phpdoc / README /en/chapters config.xml install.xml intro.xml security.xml
Title: RE: [PHP-DOC] cvs: phpdoc / README /en/chapters config.xml install.xml intro.xml security.xml > Modified files: > /phpdoc README > /phpdoc/en/chapters config.xml install.xml >intro.xml security.xml > Log: > Standardized comment at the end of XML-files (includes >vi-line too now) >@@ -239,7 +237,7 @@ > A normal paragraph that can contain lots of stuff. For example > > Code examples >- >+ > /* Do all indentation with spaces, not tabs, just to be sure. > * Don't try pushing the code to the right by adding spaces in > * front, this is the style sheet's job. Again, please do not mix the changes of the doc and the supporting material. Here you added the role for this tag. IMHO, these two commits should be separate: - Standardized comment at the end of XML-files - Adding missing role attribute This makes translators life happier. Thanks, Goba
RE: [PHP-DOC] cvs: phpdoc /en/functions dbplus.xml ming.xml mysql .xml /nl/functions apache.xml
Title: RE: [PHP-DOC] cvs: phpdoc /en/functions dbplus.xml ming.xml mysql .xml /nl/functions apache.xml >> 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 was not possible? I must miss something. >What is your problem with that? The syntax was >not used in the documentation. This is the time, we start using it. >This doesn't mean, we should not improve our XML files, but to >change all void to is the wrong direction. So the DocBook man says is the right syntax to express that a function has no arguments, right?. We used void for the same purpouse. So this was wrong according to the DocBook manual. We can agree on this I think. Then we are trying to change to the right way, and the only problem is that the DSSSL style sheets are not supporting this syntax with printing out (void), as you would like to see it. Now I have changed the DSSSL style sheet to print out (void). This way we are using the right DocBook tag, and we print out what you would like to see. Then why this is the wrong direction? Goba
RE: [PHP-DOC] cvs: phpdoc /en/functions dbplus.xml ming.xml mysql .xml /nl/functions apache.xml
Title: RE: [PHP-DOC] cvs: phpdoc /en/functions dbplus.xml ming.xml mysql .xml /nl/functions apache.xml >> 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. Goba
RE: [PHP-DOC] Re: phpdoc /fr bookinfo.xml
Title: RE: [PHP-DOC] Re: phpdoc /fr bookinfo.xml >> 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. Erm... you can copy the revision to a text file, and store it with the temporary english copy and the translated file, but this way is much more convinient. Goba
[PHP-DOC] see also tags?
Title: see also tags? Hi! Is there any chance to use some uniform DocBook structure, to represent the SeeAlso sections? There is a SeeAlso tag in docbook, but it is only allowed in indexterm, and it is not too good news, that we need to wrap a see also section in an indexterm, hm... Goba
RE: [PHP-DOC] Re: phpdoc /fr bookinfo.xml
Title: RE: [PHP-DOC] Re: phpdoc /fr bookinfo.xml >> 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? Goba
RE: [PHP-DOC] Re: phpdoc /fr bookinfo.xml
Title: RE: [PHP-DOC] Re: phpdoc /fr bookinfo.xml >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 :). If we can make this a standard, this script will work for other languages, and will give much-much better results than the status.php (as it checks only the date). It will be even more better if we divide the files into smaller pieces as Hartmut suggested, as we can see every functions and chapters exact state. :)) Goba
RE: [PHP-DOC] Re: phpdoc /fr bookinfo.xml
Title: RE: [PHP-DOC] Re: phpdoc /fr bookinfo.xml >>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? >Indeed, revision tags most of the time useful, even though you don't >use it right now. Maybe I just can see it now :)) Goba
RE: [PHP-DOC] Re: phpdoc /fr bookinfo.xml
Title: RE: [PHP-DOC] Re: phpdoc /fr bookinfo.xml >> Modified files: >> /phpdoc/fr bookinfo.xml >> Log: >> Adding the revision tag > >Is that needed for translations? > >The reason I added them to 'en', was because translations are >relative to a >en-revision. For translations, that is not true. IMO, it is >best if there is >a En-Revision: 1.XX comment, which is manually updated and reflects the >revision of the _english_ version, the translation is up-to-date to. > >Of course you can also add the $Revision tag if you think it is useful. 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 :)) Goba
RE: [PHP-DOC] cvs: phpdoc /tr bookinfo.xml
Title: RE: [PHP-DOC] cvs: phpdoc /tr bookinfo.xml > > > > > OzgurAKAN > > Erm. Please do not modify this part, as you translate. Ozgur AKAN is not the author of the manual, he is a translator. Look in the 'de' or 'hu' bookinfo.xml for examples, about how you can list translators. Leave the original names alone, please > > 2001 > the Turkish PHP Documentation Group >(www.php.org.tr) > ... and the original copyright... Please see the 'hu' bookinfo.xml for an example of the Hungarian copyright Goba
RE: [PHP-DOC] Creating a directory?
I have added that dir. This is done like this: cvs add tr in the phpdoc root. The same method is for adding a file: cvs add tr/Translators Note that it is not enough to add a file, you should also commit the contents: cvs commit tr/Translators Goba -Original Message-From: Hojtsy Gábor [mailto:[EMAIL PROTECTED]]Sent: Monday, August 06, 2001 11:12 AMTo: 'Ozgur AKAN'; '[EMAIL PROTECTED]'Subject: RE: [PHP-DOC] Creating a directory? First, is tr the official country code for Turkish, we should use? Hope so :) Goba -Original Message-From: Ozgur AKAN [mailto:[EMAIL PROTECTED]]Sent: Monday, August 06, 2001 11:05 AMTo: [EMAIL PROTECTED]Subject: [PHP-DOC] Creating a directory? Hi,I have an account for cvs.php.net. How can I create a directory under/phpdoc?We want to translate the manual to Turkish so we need /phpdoc/tr directoryto work on.Thanks, Ozgur AKANwww.PHP.org.tr
RE: [PHP-DOC] Creating a directory?
First, is tr the official country code for Turkish, we should use? Hope so :) Goba -Original Message-From: Ozgur AKAN [mailto:[EMAIL PROTECTED]]Sent: Monday, August 06, 2001 11:05 AMTo: [EMAIL PROTECTED]Subject: [PHP-DOC] Creating a directory? Hi,I have an account for cvs.php.net. How can I create a directory under/phpdoc?We want to translate the manual to Turkish so we need /phpdoc/tr directoryto work on.Thanks, Ozgur AKANwww.PHP.org.tr
RE: [PHP-DOC] Looking for Win32 build/compile documentation
Title: RE: [PHP-DOC] Looking for Win32 build/compile documentation >I'm looking for documentation about building/compiling PHP4 >and extensions on the Win32 platform. I have searched the >PHP site extensively, plus I've looked for any third-party >docs that might help, but none appear to exist. >If someone has this info, please send it to me. So you are looking for windows installation instructions. What should you try? This page: http://php.net/install-windows :)) contains information about building and compiling too. Goba
[PHP-DOC] PDF with internal links
Title: PDF with internal links Hi! Jouni, maybe you could contact the people who generated the XML documentations PDF format at W3C. They used some html2ps utility, and the links are fine ;) Goba
RE: [PHP-DOC] cvs: phpdoc / global.ent
Title: RE: [PHP-DOC] cvs: phpdoc / global.ent >Yes, and unfortunately having a terrible hangover... That was your choice... :) >And I was also hinting that Egon should translate those two snippets in >de/language-defs.ent. Note that I'm not saying he *could*... :) FAQ is quite international. Most of the translators left it. We have a good wording for FAQ (GYIK), but maybe other languages have no. PEAR is the name of that thing, so it should not be translated IMHO. Most of the translators done the job of translating, with droping out the "the" word from the PEAR entity. I have done the same. It was not clear that you are thinking about this, as this was in your letter: > Egon, this is something we have already been using quite many years. Now, > please fix that file :-; (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) I tried to understand this paragraph in connection with the DE language entities file. But nothing helped me to understand. These two new entities are not there for "quite many years"... Why are those guys are crazy? > What the hell do they think about What is your problem with them. I think it was the best solution to put that 4.0.6 there... > 'FAQ' is not recent, many of those questions finally > answered are years old You are right at this point. Somebody *should* pick this up and try to update things. Goba
RE: [PHP-DOC] cvs: phpdoc / global.ent
Title: RE: [PHP-DOC] cvs: phpdoc / global.ent >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 Goba
RE: [PHP-DOC] cvs: phpdoc / global.ent
Title: RE: [PHP-DOC] cvs: phpdoc / global.ent
>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!
Goba
RE: [PHP-DOC] cvs: phpdoc / global.ent
Title: RE: [PHP-DOC] cvs: phpdoc / global.ent >If Damien use his French ENTITY's, there is nothing wrong to >put them into global.ent. globals.ent should contain global entities, as the name suggest. Language only entities should go IMHO to language-defs.ent (see hu dir). We started faqurls.ent for the same reason. This way you can find entities where they should be. Goba
RE: [PHP-DOC] cvs: phpdoc / global.ent
Title: RE: [PHP-DOC] cvs: phpdoc / global.ent OK, this works, I was bad. the l letter is one line below :) But you should consider my other suggestions :)) Goba >+>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... Goba
RE: [PHP-DOC] cvs: phpdoc / global.ent
Title: RE: [PHP-DOC] cvs: phpdoc / global.ent > 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... Goba
RE: [PHP-DOC] Re: FAQ : new version
Title: RE: [PHP-DOC] Re: FAQ : new version >Damien Seguy wrote: > >> If anyone has objections, I'll commit all this tonight, so we can get >> wider feed back. > >Stig's name has some weird character (3/4) in surname. Probably >processing issue. Should be written as Sæther as I can remember :) Goba
RE: [PHP-DOC] Setting up PHP documentation for building
Title: RE: [PHP-DOC] Setting up PHP documentation for building >It might be looking for the php4 sources. In the parent >directory of the phpdoc tree, checkout the php4 tree also... >then try running configure again. BTW, >emacs is just the best phpdoc editor out there, IMHO. You may >consider just working directly on that debian box. =) No, no. You do not need the php4 source tree to build the manuals. It is not true... :)) Goba
[PHP-DOC] in_array example buggy
Title: in_array example buggy Hi! The in_array example (with strict check) is buggy in the online manual... Please correct this. Goba
RE: [PHP-DOC] Re: pdf manuals
Title: RE: [PHP-DOC] Re: pdf manuals >> The same stands for CHM manuals. Maybe we can get some >> space (and bandwidth) by zipping them. As they are ziped >> at dev.nexen.net (special version French manuals). > >I found that zipping them takes more space than the original ones, so I >don't think that's wise to do. It seems that MicroShit already >compressed >them or something. Anyway, can you share your development results about improving the manual format, and access, so we can improve the official ones at phpdoc and phpweb? :) Goba
RE: [PHP-DOC] Re: pdf manuals
Title: RE: [PHP-DOC] Re: pdf manuals > But another small suggestion (just to use the opportunity:) : > Since we have html for online-access, the manual becomes bigger > and bigger, and pdf was already BIG before: > What do you think about providing them also compressed to save traffic? The same stands for CHM manuals. Maybe we can get some space (and bandwidth) by zipping them. As they are ziped at dev.nexen.net (special version French manuals). Goba
RE: [PHP-DOC] Re: [PHP-DEV] Security?
Title: RE: [PHP-DOC] Re: [PHP-DEV] Security? > > But, I do think it would be worthwhile to go through these and add a > > section to the documentation highlighting the pitfalls and explaining how > > to avoid them. > There is a security chapter in the manual now... We should put this up there... Goba
[PHP-DOC] make errors
Title: make errors Hartmut is there any way to correct the make errors, we posted some letters ago? Goba
RE: [PHP-DOC] italian manual creation problem
Title: RE: [PHP-DOC] italian manual creation problem > 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? Many manuals are suffering from the same problem. Our hungarian one too :( >>> running make test ... touch .manual.xml CONFIG_FILES=manual.xml CONFIG_HEADERS= ./config.status creating manual.xml SP_ENCODING=ISO-8859-2 SGMLSCMD -i lang-hu -s /local/mirror/phpdoc/phpdocxml.dcl manual.xml /bin/sh: SGMLSCMD: command not found make: *** [test] Error 127 Goba
