[PHP-DOC] #25915 [Opn]: Spelling error in /mirrors.php

2003-10-19 Thread midg3t at mail dot com
 ID:   25915
 User updated by:  midg3t at mail dot com
 Reported By:  midg3t at mail dot com
 Status:   Open
 Bug Type: Documentation problem
 Operating System: na
 PHP Version:  Irrelevant
 New Comment:

While reviewing my submission I came across the following error.

"We would like to advice you to choose a mirror site close to use in
your everyday work."

The word "advice" should be "advise". The sentence's meaning is a
little unclear. It might be better to mention something about
geographical location rather than "close to use in your ... work".

I suggest:

We suggest you to choose a mirror site geographically close to you.

Things are getting a little bit complicated here. I don't want to sound
like a nut, but I think the whole paragraph needs re-writing. I'll
leave that up to you (unless you'd like me to suggest something).


Previous Comments:


[2003-10-20 01:17:52] midg3t at mail dot com

Fixed summary, it referred to the wrong page (brain fart). The page
this bug relates to is as follows:

http://www.php.net/mirrors.php



[2003-10-20 01:12:42] midg3t at mail dot com

Description:

"This means that you don't loose anything, if you go with a local
mirror site, but you gain speed."

The word "loose" means something along the lines of "not fitting". I
think the word "loose" should be replaced by "lose", being the verb
form of "lost".

The first comma in the sentence is redundant -- the sentence reads
better without it.

Suggested fix:

"This means that you don't lose anything if you go with a local mirror
site, but you gain speed."






-- 
Edit this bug report at http://bugs.php.net/?id=25915&edit=1


[PHP-DOC] #25915 [Opn]: Spelling error in /mirrors.php

2003-10-19 Thread midg3t at mail dot com
 ID:   25915
 User updated by:  midg3t at mail dot com
-Summary:  Spelling error in Classes and Objects doc
 Reported By:  midg3t at mail dot com
 Status:   Open
 Bug Type: Documentation problem
 Operating System: na
 PHP Version:  Irrelevant
 New Comment:

Fixed summary, it referred to the wrong page (brain fart). The page
this bug relates to is as follows:

http://www.php.net/mirrors.php


Previous Comments:


[2003-10-20 01:12:42] midg3t at mail dot com

Description:

"This means that you don't loose anything, if you go with a local
mirror site, but you gain speed."

The word "loose" means something along the lines of "not fitting". I
think the word "loose" should be replaced by "lose", being the verb
form of "lost".

The first comma in the sentence is redundant -- the sentence reads
better without it.

Suggested fix:

"This means that you don't lose anything if you go with a local mirror
site, but you gain speed."






-- 
Edit this bug report at http://bugs.php.net/?id=25915&edit=1


[PHP-DOC] #25915 [NEW]: Spelling error in Classes and Objects doc

2003-10-19 Thread midg3t at mail dot com
From: midg3t at mail dot com
Operating system: na
PHP version:  Irrelevant
PHP Bug Type: Documentation problem
Bug description:  Spelling error in Classes and Objects doc

Description:

"This means that you don't loose anything, if you go with a local mirror
site, but you gain speed."

The word "loose" means something along the lines of "not fitting". I think
the word "loose" should be replaced by "lose", being the verb form of
"lost".

The first comma in the sentence is redundant -- the sentence reads better
without it.

Suggested fix:

"This means that you don't lose anything if you go with a local mirror
site, but you gain speed."


-- 
Edit bug report at http://bugs.php.net/?id=25915&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=25915&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=25915&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=25915&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=25915&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25915&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=25915&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25915&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=25915&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25915&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25915&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=25915&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25915&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=25915&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=25915&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25915&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=25915&r=float


[PHP-DOC] #25913 [Com]: Update for global entities and PHP history (patch included)

2003-10-19 Thread didou at nexen dot net
 ID:   25913
 Comment by:   didou at nexen dot net
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Documentation problem
 Operating System: Irrelevant
 PHP Version:  Irrelevant
 New Comment:

Not sure that a bug report is a good place to propose a patch for the
documentation (as there's _no_ bug), but I'm +1 with you commit if make
test succeed :)

didou


Previous Comments:


[2003-10-19 17:10:42] [EMAIL PROTECTED]

Description:

The following diff changes the global entities that refer to PEAR
packages so that they conform to PEAR's new URL scheme. (The old links
will work as well, but it's cleaner that way.) Additionally it adds
links to PEAR, PHP QA and PHP-GTK in the PHP history. I have phpdoc
karma myself, but I'm not sure if the history patch conforms with what
you expect.

? en/reference/cybermut/functions.xml
? en/reference/monetra/functions.xml
Index: en/appendices/history.xml
===
RCS file: /repository/phpdoc/en/appendices/history.xml,v
retrieving revision 1.21
diff -u -r1.21 history.xml
--- en/appendices/history.xml   16 Jul 2003 18:30:49 -  1.21
+++ en/appendices/history.xml   19 Oct 2003 21:07:47 -
@@ -168,11 +168,11 @@
   
PEAR

-PEAR, the PHP Extension and Application Repository (originally,
-PHP Extension and Add-on Repository) is PHP's version of
-foundation classes, and may grow in the future to be one
-of the key ways to distribute both PHP and C-based PHP
-extensions among developers.
+PEAR, the PHP Extension and
+Application Repository (originally, PHP Extension and Add-on
+Repository) is PHP's version of foundation classes, and may grow
in
+the future to be one of the key ways to distribute both PHP and
+C-based PHP extensions among developers.


 PEAR was born in discussions held in the PHP Developers'
@@ -189,15 +189,19 @@
 for database access, content caching, mathematical
 calculations, eCommerce and much more.

+   
+More information about PEAR can be found in the manual.
+   
   
 
   
PHP Quality Assurance Initiative

-The PHP Quality Assurance Initiative was set up in the
-summer of 2000 in response to criticism that PHP releases
-were not being tested well enough for production
-environments. The team now consists of a core group of
+The PHP Quality Assurance
+Initiative was set up in the summer of 2000 in response
to
+criticism that PHP releases were not being tested well enough for
+production environments. The team now consists of a core group of
 developers with a good understanding of the PHP code
 base. These developers spend a lot of their time
 localizing and fixing bugs within PHP. In addition
@@ -210,9 +214,9 @@
   
PHP-GTK

-PHP-GTK is the PHP solution for writing client side
-GUI applications. Andrei Zmievski remembers the planing
-and creation process of PHP-GTK:
+PHP-GTK is the PHP solution
for
+writing client side GUI applications. Andrei Zmievski remembers
the
+planing and creation process of PHP-GTK:


 
Index: entities/global.ent
===
RCS file: /repository/phpdoc/entities/global.ent,v
retrieving revision 1.133
diff -u -r1.133 global.ent
--- entities/global.ent 14 Oct 2003 05:12:44 -  1.133
+++ entities/global.ent 19 Oct 2003 21:07:55 -
@@ -66,7 +66,7 @@
 http://www.faqts.com/knowledge_base/view.phtml/aid/1/fid/40";>
 ftp://ftp.gnu.org/pub/gnu/emacs/";>
 http://www.gnu.org/software/emacs/windows/";>
-http://pear.php.net/Mail_Mime";>
+http://pear.php.net/package/Mail_Mime";>
 http://www.zend.com/zend/spotlight/sendmimeemailpart1.php";>
 http://www.oreilly.com/catalog/progintemail/noframes.html";>
 
@@ -187,7 +187,7 @@
 http://www.potentialtech.com/ppl.php";>
 http://www.ros.co.nz/pdf/";>
 http://www.pdflib.com/corporate/tm.html";>
-http://pear.php.net/Net_DNS";>
+http://pear.php.net/package/Net_DNS";>
 http://snaps.php.net/win32/PECL_STABLE/";>
 http://www.verisign.com/products/payflow/pro/index.html";>
 https://manager.verisign.com/";>
@@ -215,6 +215,7 @@
 http://museum.php.net/";>
 news://news.php.net/";>
 http://news.php.net/";>
+http://pear.php.net/manual/";>
 http://pear.php.net/";>
 http://qa.php.net/";>
 http://groups.google.com/[EMAIL PROTECTED]">







-- 
Edit this bug report at http://bugs.php.net/?id=25913&edit=1


Re: [PHP-DOC] #25913 [NEW]: Update for global entities and PHP history (patch included)

2003-10-19 Thread Steph
2 'n's in 'planning' ...

- Original Message -
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, October 19, 2003 9:10 PM
Subject: [PHP-DOC] #25913 [NEW]: Update for global entities and PHP
history (patch included)


> From: [EMAIL PROTECTED]
> Operating system: Irrelevant
> PHP version:  Irrelevant
> PHP Bug Type: Documentation problem
> Bug description:  Update for global entities and PHP history (patch
included)
>
> Description:
> 
> The following diff changes the global entities that refer to PEAR
packages
> so that they conform to PEAR's new URL scheme. (The old links will
work as
> well, but it's cleaner that way.) Additionally it adds links to PEAR,
PHP
> QA and PHP-GTK in the PHP history. I have phpdoc karma myself, but I'm
not
> sure if the history patch conforms with what you expect.
>
> ? en/reference/cybermut/functions.xml
> ? en/reference/monetra/functions.xml
> Index: en/appendices/history.xml
> ===
> RCS file: /repository/phpdoc/en/appendices/history.xml,v
> retrieving revision 1.21
> diff -u -r1.21 history.xml
> --- en/appendices/history.xml 16 Jul 2003 18:30:49 - 1.21
> +++ en/appendices/history.xml 19 Oct 2003 21:07:47 -
> @@ -168,11 +168,11 @@
>
> PEAR
> 
> -PEAR, the PHP Extension and Application Repository (originally,
> -PHP Extension and Add-on Repository) is PHP's version of
> -foundation classes, and may grow in the future to be one
> -of the key ways to distribute both PHP and C-based PHP
> -extensions among developers.
> +PEAR, the PHP Extension and
> +Application Repository (originally, PHP Extension and Add-on
> +Repository) is PHP's version of foundation classes, and may grow
in
> +the future to be one of the key ways to distribute both PHP and
> +C-based PHP extensions among developers.
> 
> 
>  PEAR was born in discussions held in the PHP Developers'
> @@ -189,15 +189,19 @@
>  for database access, content caching, mathematical
>  calculations, eCommerce and much more.
> 
> +   
> +More information about PEAR can be found in  +url="&url.php.pear.manual;">the manual.
> +   
>
>
>
> PHP Quality Assurance Initiative
> 
> -The PHP Quality Assurance Initiative was set up in the
> -summer of 2000 in response to criticism that PHP releases
> -were not being tested well enough for production
> -environments. The team now consists of a core group of
> +The PHP Quality Assurance
> +Initiative was set up in the summer of 2000 in response
to
> +criticism that PHP releases were not being tested well enough for
> +production environments. The team now consists of a core group of
>  developers with a good understanding of the PHP code
>  base. These developers spend a lot of their time
>  localizing and fixing bugs within PHP. In addition
> @@ -210,9 +214,9 @@
>
> PHP-GTK
> 
> -PHP-GTK is the PHP solution for writing client side
> -GUI applications. Andrei Zmievski remembers the planing
> -and creation process of PHP-GTK:
> +PHP-GTK is the PHP solution
for
> +writing client side GUI applications. Andrei Zmievski remembers
the
> +planing and creation process of PHP-GTK:
> 
> 
>  
> Index: entities/global.ent
> ===
> RCS file: /repository/phpdoc/entities/global.ent,v
> retrieving revision 1.133
> diff -u -r1.133 global.ent
> --- entities/global.ent 14 Oct 2003 05:12:44 - 1.133
> +++ entities/global.ent 19 Oct 2003 21:07:55 -
> @@ -66,7 +66,7 @@
>   "http://www.faqts.com/knowledge_base/view.phtml/aid/1/fid/40";>
>  ftp://ftp.gnu.org/pub/gnu/emacs/";>
>  http://www.gnu.org/software/emacs/windows/";>
> -http://pear.php.net/Mail_Mime";>
> +http://pear.php.net/package/Mail_Mime";>
>   "http://www.zend.com/zend/spotlight/sendmimeemailpart1.php";>
>   "http://www.oreilly.com/catalog/progintemail/noframes.html";>
>  
> @@ -187,7 +187,7 @@
>  http://www.potentialtech.com/ppl.php";>
>  http://www.ros.co.nz/pdf/";>
>  http://www.pdflib.com/corporate/tm.html";>
> -http://pear.php.net/Net_DNS";>
> +http://pear.php.net/package/Net_DNS";>
>  http://snaps.php.net/win32/PECL_STABLE/";>
>   "http://www.verisign.com/products/payflow/pro/index.html";>
>  https://manager.verisign.com/";>
> @@ -215,6 +215,7 @@
>  http://museum.php.net/";>
>  news://news.php.net/";>
>  http://news.php.net/";>
> +http://pear.php.net/manual/";>
>  http://pear.php.net/";>
>  http://qa.php.net/";>
>   "http://groups.google.com/[EMAIL PROTECTED]">
>
>
>
> --
> Edit bug report at http://bugs.php.net/?id=25913&edit=1
> --
> Try a CVS snapshot (php4):
http://bugs.php.net/fix.php?id=25913&r=trysnapshot4
> Try a CVS snapshot (php5):
http://bugs.php.net/fix.php?id=25913&r=trysnapshot5
> Fixed in CVS:
http://bugs.php.net/fix.php?id=25913&r=f

[PHP-DOC] cvs: phpdoc /en/reference/strings/functions chr.xml

2003-10-19 Thread Mehdi Achour
didou   Sun Oct 19 17:13:22 2003 EDT

  Modified files:  
/phpdoc/en/reference/strings/functions  chr.xml 
  Log:
  Initialize $str to make the example less confusing
  
Index: phpdoc/en/reference/strings/functions/chr.xml
diff -u phpdoc/en/reference/strings/functions/chr.xml:1.3 
phpdoc/en/reference/strings/functions/chr.xml:1.4
--- phpdoc/en/reference/strings/functions/chr.xml:1.3   Fri May 30 12:47:59 2003
+++ phpdoc/en/reference/strings/functions/chr.xml   Sun Oct 19 17:13:22 2003
@@ -1,5 +1,5 @@
 
-
+
 
   

@@ -20,6 +20,7 @@
   
 

[PHP-DOC] #25913 [NEW]: Update for global entities and PHP history (patch included)

2003-10-19 Thread [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Operating system: Irrelevant
PHP version:  Irrelevant
PHP Bug Type: Documentation problem
Bug description:  Update for global entities and PHP history (patch included)

Description:

The following diff changes the global entities that refer to PEAR packages
so that they conform to PEAR's new URL scheme. (The old links will work as
well, but it's cleaner that way.) Additionally it adds links to PEAR, PHP
QA and PHP-GTK in the PHP history. I have phpdoc karma myself, but I'm not
sure if the history patch conforms with what you expect.

? en/reference/cybermut/functions.xml
? en/reference/monetra/functions.xml
Index: en/appendices/history.xml
===
RCS file: /repository/phpdoc/en/appendices/history.xml,v
retrieving revision 1.21
diff -u -r1.21 history.xml
--- en/appendices/history.xml   16 Jul 2003 18:30:49 -  1.21
+++ en/appendices/history.xml   19 Oct 2003 21:07:47 -
@@ -168,11 +168,11 @@
   
PEAR

-PEAR, the PHP Extension and Application Repository (originally,
-PHP Extension and Add-on Repository) is PHP's version of
-foundation classes, and may grow in the future to be one
-of the key ways to distribute both PHP and C-based PHP
-extensions among developers.
+PEAR, the PHP Extension and
+Application Repository (originally, PHP Extension and Add-on
+Repository) is PHP's version of foundation classes, and may grow in
+the future to be one of the key ways to distribute both PHP and
+C-based PHP extensions among developers.


 PEAR was born in discussions held in the PHP Developers'
@@ -189,15 +189,19 @@
 for database access, content caching, mathematical
 calculations, eCommerce and much more.

+   
+More information about PEAR can be found in the manual.
+   
   
 
   
PHP Quality Assurance Initiative

-The PHP Quality Assurance Initiative was set up in the
-summer of 2000 in response to criticism that PHP releases
-were not being tested well enough for production
-environments. The team now consists of a core group of
+The PHP Quality Assurance
+Initiative was set up in the summer of 2000 in response to
+criticism that PHP releases were not being tested well enough for
+production environments. The team now consists of a core group of
 developers with a good understanding of the PHP code
 base. These developers spend a lot of their time
 localizing and fixing bugs within PHP. In addition
@@ -210,9 +214,9 @@
   
PHP-GTK

-PHP-GTK is the PHP solution for writing client side
-GUI applications. Andrei Zmievski remembers the planing
-and creation process of PHP-GTK:
+PHP-GTK is the PHP solution for
+writing client side GUI applications. Andrei Zmievski remembers the
+planing and creation process of PHP-GTK:


 
Index: entities/global.ent
===
RCS file: /repository/phpdoc/entities/global.ent,v
retrieving revision 1.133
diff -u -r1.133 global.ent
--- entities/global.ent 14 Oct 2003 05:12:44 -  1.133
+++ entities/global.ent 19 Oct 2003 21:07:55 -
@@ -66,7 +66,7 @@
 http://www.faqts.com/knowledge_base/view.phtml/aid/1/fid/40";>
 ftp://ftp.gnu.org/pub/gnu/emacs/";>
 http://www.gnu.org/software/emacs/windows/";>
-http://pear.php.net/Mail_Mime";>
+http://pear.php.net/package/Mail_Mime";>
 http://www.zend.com/zend/spotlight/sendmimeemailpart1.php";>
 http://www.oreilly.com/catalog/progintemail/noframes.html";>
 
@@ -187,7 +187,7 @@
 http://www.potentialtech.com/ppl.php";>
 http://www.ros.co.nz/pdf/";>
 http://www.pdflib.com/corporate/tm.html";>
-http://pear.php.net/Net_DNS";>
+http://pear.php.net/package/Net_DNS";>
 http://snaps.php.net/win32/PECL_STABLE/";>
 http://www.verisign.com/products/payflow/pro/index.html";>
 https://manager.verisign.com/";>
@@ -215,6 +215,7 @@
 http://museum.php.net/";>
 news://news.php.net/";>
 http://news.php.net/";>
+http://pear.php.net/manual/";>
 http://pear.php.net/";>
 http://qa.php.net/";>
 http://groups.google.com/[EMAIL PROTECTED]">



-- 
Edit bug report at http://bugs.php.net/?id=25913&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=25913&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=25913&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=25913&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=25913&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25913&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=25913&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25913&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=25913&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25913&r=notenoughinfo
Submitted twice: 

[PHP-DOC] #25910 [Csd->Bgs]: Error in example 1 in the mysql_fetch_field doco

2003-10-19 Thread didou
 ID:  25910
 Updated by:  [EMAIL PROTECTED]
 Reported By: dissent at 0--0 dot org
-Status:  Closed
+Status:  Bogus
 Bug Type:Documentation problem
 PHP Version: Irrelevant
 New Comment:

This correction is bogus. The example was just fine.


Previous Comments:


[2003-10-19 11:49:48] [EMAIL PROTECTED]

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.





[2003-10-19 11:11:02] dissent at 0--0 dot org

Description:

In the english version of the manual, the documentation for
mysql_fetch_field, there's an error in example 1.  The second line in
the while loop should use $i, not $result.

The line

   $meta = mysql_fetch_field($result);

Should be:

   $meta = mysql_fetch_field($i);
 

Expected result:

while ($i < mysql_num_fields($result)) {
   echo "Information for column $i:\n";
   $meta = mysql_fetch_field($i);
   if (!$meta) {
   echo "No information available\n";
}

Actual result:
--
while ($i < mysql_num_fields($result)) {
   echo "Information for column $i:\n";
   $meta = mysql_fetch_field($result);
   if (!$meta) {
   echo "No information available\n";
}





-- 
Edit this bug report at http://bugs.php.net/?id=25910&edit=1


[PHP-DOC] cvs: phpdoc /en/reference/mysql/functions mysql-fetch-field.xml

2003-10-19 Thread Mehdi Achour
didou   Sun Oct 19 16:55:05 2003 EDT

  Modified files:  
/phpdoc/en/reference/mysql/functionsmysql-fetch-field.xml 
  Log:
  unfixing #25910 as it was bogus
  
Index: phpdoc/en/reference/mysql/functions/mysql-fetch-field.xml
diff -u phpdoc/en/reference/mysql/functions/mysql-fetch-field.xml:1.8 
phpdoc/en/reference/mysql/functions/mysql-fetch-field.xml:1.9
--- phpdoc/en/reference/mysql/functions/mysql-fetch-field.xml:1.8   Sun Oct 19 
11:49:30 2003
+++ phpdoc/en/reference/mysql/functions/mysql-fetch-field.xml   Sun Oct 19 16:55:05 
2003
@@ -1,5 +1,5 @@
 
-
+
 
   

@@ -107,7 +107,7 @@
 $i = 0;
 while ($i < mysql_num_fields($result)) {
 echo "Information for column $i:\n";
-$meta = mysql_fetch_field($i);
+$meta = mysql_fetch_field($result, $i);
 if (!$meta) {
 echo "No information available\n";
 }


[PHP-DOC] Re: cvs: phpdoc /en/reference/mysql/functions mysql-fetch-field.xml

2003-10-19 Thread Mehdi Achour
Hi Ali,

From the documentation :

  object mysql_fetch_field ( resource result [, int field_offset])

The example was good, it also may have be :

  $meta = mysql_fetch_field($result, $i);

But in no way

  $meta = mysql_fetch_field($i);

I'm reverting and marking #25910 as bogus. Please pay more attention 
next time, bugs can also be bogus ;)

didou



ali		Sun Oct 19 11:49:30 2003 EDT

  Modified files:  
/phpdoc/en/reference/mysql/functions	mysql-fetch-field.xml 
  Log:
  fixes #25910
  
  
Index: phpdoc/en/reference/mysql/functions/mysql-fetch-field.xml
diff -u phpdoc/en/reference/mysql/functions/mysql-fetch-field.xml:1.7 phpdoc/en/reference/mysql/functions/mysql-fetch-field.xml:1.8
--- phpdoc/en/reference/mysql/functions/mysql-fetch-field.xml:1.7	Wed Jul  9 11:07:29 2003
+++ phpdoc/en/reference/mysql/functions/mysql-fetch-field.xml	Sun Oct 19 11:49:30 2003
@@ -1,5 +1,5 @@
 
-
+
 
   

@@ -107,7 +107,7 @@
 $i = 0;
 while ($i < mysql_num_fields($result)) {
 echo "Information for column $i:\n";
-$meta = mysql_fetch_field($result);
+$meta = mysql_fetch_field($i);
 if (!$meta) {
 echo "No information available\n";
 }


Re: [PHP-DOC] commit files with the web interface

2003-10-19 Thread André L F S Bacci
Nuno Lopes wrote:
>> This is important, because usual CVS users will still do
>> translations. Also it is important for this system to handle
>> colissions. It is not at all sure that the cronjob will be able to
>> commit the changes, if one CVS user changes the file between the
>> moment someone edits it in the online app, and the cron runs.
>> Therefore I would vote for immediate commits. Also if this app would
>> use cron, then it should handle the problem of multiple change
>> requests regarding the same file in the scope of the application
>> itself. Imagine that it commits the first change, then it will not
>> be possible to committ the second change, because it does not
>> contain the previous change (it is not updated). So it seems to me
>> that everything stands behind immediate commits.
>>
>> Goba
>
> Lets try with imediate commits. The cron job will only be used to
> checkout and update the db.
>
> One more thing: I was thinking in not translating the whole file at
> once. I'll explain: The script would parse the file and return a
> couple of senteces, only. The user would translate them and then they
> would go to the db. Then he would receive a couple of more sentences.
> I think this way is better, because you may translate only half file
> a day and the user wouldn't need to scroll up and down to translate.
> What do you think about this?
>
> Nuno

In a old old old system for web translating, I idealized a structure like
this:

/source
The main checkout and updated version of originals and translations (with a
read-only user)

/wips/wip1
/wips/wip2 ...
One directory per file traslation. Would be a ~common but partial~ directory
checkout of file translated (or new) file and respective CVS/Root,
CVS/Repository and CVS/Entities (partial). When a translation is done, the
commit can be simple and the wipX directory is erased.

[]s

André Æ


Re: [PHP-DOC] commit files with the web interface

2003-10-19 Thread Gabor Hojtsy
OK, I'm gonna do this. I will let the admin to add new users without CVS
account. Those users will commit with a default account. Later, if they want
to continue translating, encurage them to get a CVS account.
Great. As I have said before, getting a CVS account is also a kind of 
reward (you also get a @php.net email addr. for example :)

One more thing: I was thinking in not translating the whole file at once.
I'll explain: The script would parse the file and return a couple of
senteces, only. The user would translate them and then they would go to the
db. Then he would receive a couple of more sentences. I think this way is
better, because you may translate only half file a day and the user wouldn't
need to scroll up and down to translate. What do you think about this?
Erm, this should be better asked from the possible users of the system. 
I will most probably manage with the CVS interface I already know... 
From the useability perspective it might be a good idea to only present 
a portion of the file for the user, so in case the browser suddenly goes 
away (happens for me on windows and linux too), then the already 
translated parts will be in...

Goba


Re: [PHP-DOC] commit files with the web interface

2003-10-19 Thread Nuno Lopes
> I think that this system should use Joe's account (imaginary), if he has
> one, but if he has no cvs account, then it should be committed with a
> default translation group account. It is important to keep as much
> information in the CVS logs as possible, so cvs commits should reflect
> the user who changed the file.

OK, I'm gonna do this. I will let the admin to add new users without CVS
account. Those users will commit with a default account. Later, if they want
to continue translating, encurage them to get a CVS account.



> This is important, because usual CVS users will still do translations.
> Also it is important for this system to handle colissions. It is not at
> all sure that the cronjob will be able to commit the changes, if one CVS
> user changes the file between the moment someone edits it in the online
> app, and the cron runs. Therefore I would vote for immediate commits.
> Also if this app would use cron, then it should handle the problem of
> multiple change requests regarding the same file in the scope of the
> application itself. Imagine that it commits the first change, then it
> will not be possible to committ the second change, because it does not
> contain the previous change (it is not updated). So it seems to me that
> everything stands behind immediate commits.
>
> Goba

Lets try with imediate commits. The cron job will only be used to checkout
and update the db.

One more thing: I was thinking in not translating the whole file at once.
I'll explain: The script would parse the file and return a couple of
senteces, only. The user would translate them and then they would go to the
db. Then he would receive a couple of more sentences. I think this way is
better, because you may translate only half file a day and the user wouldn't
need to scroll up and down to translate. What do you think about this?


Nuno


Re: [PHP-DOC] commit files with the web interface

2003-10-19 Thread Gabor Hojtsy
I need your oppinion about the way how commits will work in the web
interface to translate the manual.
There was an idea to solve the problem of being always changing CVS dir with
the user's information.
The solution would be to have just a CVS account (that hot solution) and all
commits would be done by the admin of the project. I'll explain:
A translator would translate a file. Then, that file would be marked as
'to-review'. Then, the admin would read the file, and make any changes (if
necessary), and the file would be marked as 'to-commit'. At the end of day
(throught a cron job) an update script would run and checkout any changes to
files and would commit/add the new translations.
With this solution, we would have better quality translations and we would
have just one CVS account for each project.
Any comments?
I think that this system should use Joe's account (imaginary), if he has 
one, but if he has no cvs account, then it should be committed with a 
default translation group account. It is important to keep as much 
information in the CVS logs as possible, so cvs commits should reflect 
the user who changed the file.

This is important, because usual CVS users will still do translations. 
Also it is important for this system to handle colissions. It is not at 
all sure that the cronjob will be able to commit the changes, if one CVS 
user changes the file between the moment someone edits it in the online 
app, and the cron runs. Therefore I would vote for immediate commits. 
Also if this app would use cron, then it should handle the problem of 
multiple change requests regarding the same file in the scope of the 
application itself. Imagine that it commits the first change, then it 
will not be possible to committ the second change, because it does not 
contain the previous change (it is not updated). So it seems to me that 
everything stands behind immediate commits.

Goba


Re: [PHP-DOC] commit files with the web interface

2003-10-19 Thread Fernando Correa da Conceição
-Mensagem Original-
De: "Nuno Lopes" <[EMAIL PROTECTED]>
Para: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Enviada em: domingo, 19 de outubro de 2003 15:52
Assunto: [PHP-DOC] commit files with the web interface


> Hello,
>
> I need your oppinion about the way how commits will work in the web
> interface to translate the manual.
>
> There was an idea to solve the problem of being always changing CVS dir
with
> the user's information.
>
> The solution would be to have just a CVS account (that hot solution) and
all
> commits would be done by the admin of the project. I'll explain:
> A translator would translate a file. Then, that file would be marked as
> 'to-review'. Then, the admin would read the file, and make any changes (if
> necessary), and the file would be marked as 'to-commit'. At the end of day
> (throught a cron job) an update script would run and checkout any changes
to
> files and would commit/add the new translations.
> With this solution, we would have better quality translations and we would
> have just one CVS account for each project.
>

This is better than previous in use only one acount and I person view the
files before commit. More one sugestion, the script at cron do a "make test"
before commit to make sure the manual compiles.

>
> Any comments?
>
>
> Nuno Lopes
>


[PHP-DOC] commit files with the web interface

2003-10-19 Thread Nuno Lopes
Hello,

I need your oppinion about the way how commits will work in the web
interface to translate the manual.

There was an idea to solve the problem of being always changing CVS dir with
the user's information.

The solution would be to have just a CVS account (that hot solution) and all
commits would be done by the admin of the project. I'll explain:
A translator would translate a file. Then, that file would be marked as
'to-review'. Then, the admin would read the file, and make any changes (if
necessary), and the file would be marked as 'to-commit'. At the end of day
(throught a cron job) an update script would run and checkout any changes to
files and would commit/add the new translations.
With this solution, we would have better quality translations and we would
have just one CVS account for each project.


Any comments?


Nuno Lopes


[PHP-DOC] #25910 [Opn->Csd]: Error in example 1 in the mysql_fetch_field doco

2003-10-19 Thread ali
 ID:  25910
 Updated by:  [EMAIL PROTECTED]
 Reported By: dissent at 0--0 dot org
-Status:  Open
+Status:  Closed
 Bug Type:Documentation problem
 PHP Version: Irrelevant
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2003-10-19 11:11:02] dissent at 0--0 dot org

Description:

In the english version of the manual, the documentation for
mysql_fetch_field, there's an error in example 1.  The second line in
the while loop should use $i, not $result.

The line

   $meta = mysql_fetch_field($result);

Should be:

   $meta = mysql_fetch_field($i);
 

Expected result:

while ($i < mysql_num_fields($result)) {
   echo "Information for column $i:\n";
   $meta = mysql_fetch_field($i);
   if (!$meta) {
   echo "No information available\n";
}

Actual result:
--
while ($i < mysql_num_fields($result)) {
   echo "Information for column $i:\n";
   $meta = mysql_fetch_field($result);
   if (!$meta) {
   echo "No information available\n";
}





-- 
Edit this bug report at http://bugs.php.net/?id=25910&edit=1


[PHP-DOC] cvs: phpdoc /en/reference/mysql/functions mysql-fetch-field.xml

2003-10-19 Thread ali
ali Sun Oct 19 11:49:30 2003 EDT

  Modified files:  
/phpdoc/en/reference/mysql/functionsmysql-fetch-field.xml 
  Log:
  fixes #25910
  
  
Index: phpdoc/en/reference/mysql/functions/mysql-fetch-field.xml
diff -u phpdoc/en/reference/mysql/functions/mysql-fetch-field.xml:1.7 
phpdoc/en/reference/mysql/functions/mysql-fetch-field.xml:1.8
--- phpdoc/en/reference/mysql/functions/mysql-fetch-field.xml:1.7   Wed Jul  9 
11:07:29 2003
+++ phpdoc/en/reference/mysql/functions/mysql-fetch-field.xml   Sun Oct 19 11:49:30 
2003
@@ -1,5 +1,5 @@
 
-
+
 
   

@@ -107,7 +107,7 @@
 $i = 0;
 while ($i < mysql_num_fields($result)) {
 echo "Information for column $i:\n";
-$meta = mysql_fetch_field($result);
+$meta = mysql_fetch_field($i);
 if (!$meta) {
 echo "No information available\n";
 }


[PHP-DOC] #25910 [NEW]: Error in example 1 in the mysql_fetch_field doco

2003-10-19 Thread dissent at 0--0 dot org
From: dissent at 0--0 dot org
Operating system: 
PHP version:  Irrelevant
PHP Bug Type: Documentation problem
Bug description:  Error in example 1 in the mysql_fetch_field doco

Description:

In the english version of the manual, the documentation for
mysql_fetch_field, there's an error in example 1.  The second line in the
while loop should use $i, not $result.

The line

   $meta = mysql_fetch_field($result);

Should be:

   $meta = mysql_fetch_field($i);
 

Expected result:

while ($i < mysql_num_fields($result)) {
   echo "Information for column $i:\n";
   $meta = mysql_fetch_field($i);
   if (!$meta) {
   echo "No information available\n";
}

Actual result:
--
while ($i < mysql_num_fields($result)) {
   echo "Information for column $i:\n";
   $meta = mysql_fetch_field($result);
   if (!$meta) {
   echo "No information available\n";
}

-- 
Edit bug report at http://bugs.php.net/?id=25910&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=25910&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=25910&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=25910&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=25910&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25910&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=25910&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25910&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=25910&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25910&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25910&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=25910&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25910&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=25910&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=25910&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25910&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=25910&r=float


[PHP-DOC] cvs: phpdoc /en/chapters config.xml

2003-10-19 Thread Stanislav Malyshev
stasSun Oct 19 07:57:47 2003 EDT

  Modified files:  
/phpdoc/en/chapters config.xml 
  Log:
  add docs about configuring PHP via registry
  
  
Index: phpdoc/en/chapters/config.xml
diff -u phpdoc/en/chapters/config.xml:1.111 phpdoc/en/chapters/config.xml:1.112
--- phpdoc/en/chapters/config.xml:1.111 Fri Sep 12 16:11:18 2003
+++ phpdoc/en/chapters/config.xml   Sun Oct 19 07:57:47 2003
@@ -1,5 +1,5 @@
 
-
+
  
   Runtime Configuration
 
@@ -197,6 +197,25 @@
 

 
+   
+Changing PHP configuration via the Windows 
registry
+ 
+  When running PHP on Windows, the configuration values can be
+  modified on per-directory basis using the Windows registry. The
+  configuration values are stored in the registry key 
+  HKLM\SOFTWARE\PHP\Per Directory Values, 
+  in the sub-keys corresponding to the path names. For example, configuration 
+  values for the directory c:\inetpub\wwwroot would
+  be stored in the key HKLM\SOFTWARE\PHP\Per Directory
+  Values\c\inetpub\wwwroot. The settings for the
+  directory would be active for any script running from this
+  directory or any subdirectory of it. The values under the key
+  should have the name of PHP
+  configuration directive and the string value. PHP
+  constants in the values would not be parsed. 
+ 
+   
+   

 Other interfaces to PHP
 


Re: [PHP-DOC] Documentation download

2003-10-19 Thread Gabor Hojtsy
The notice on the documentation download page stating
that non-window versions of the documentation will be
coming soon, has been there for weeks now. 

Has there been any progress towards getting that
documentation online (for download)?
If wget worked for me, I'd use it...
We have been experimenting with a new build system, but we will probably 
switch back to the old one, and build the manuals the old way again. 
Still we need some time.

Sorry for the inconvinience,
Goba