Ah yes, this makes sense and his last post did clarify that
(hindsight is 20/20!). Sounds like a good idea to document all
these types of changes so to the original question on when: ASAP! :-)
Yes, that's a good idea. :) Most of the functionality in the core
language will not be changin
Ah sure! Some protos may need changes, and some functions may need
tweaking, of course. But all this will need to be made manually and
thus will take a long time..
I think we can start by describing the general behaviour of the
extension on the reference.xml page and then, as time permits,
Yes, that's a good idea. :) Most of the functionality in the core
language will not be changing so the documentation effort can start
immediately. I would offer to document some things myself, but
honestly, I think that my time is best spent finishing up core stuff,
doing Unicode upgrades o
I'm unsure if I follow what you mean here Gabor, please clarify.
If we do this soon then later we'll undo it all because when PHP
6.0.0 is released every [appropriate] function will be unicode
compatible so repeating this thousands of times throughout the
manual won't be useful. The appro
On Jul 19, 2006, at 2:34 PM, Gabor Hojtsy wrote:
Philip, I assumed what is supposed to be documented is not just a
boolean switch: "this is unicode compatible" / "this is not yet
unicode compatible", but there are behaviour changes, special
options, or anything (I am not actually following
As far as I have seen adding an entity was the suggested method, which
should not be a problem for translators to adapt to IMHO. In case this
entity is just a "this has unicode support" text, and nothing more, and if
all text handling functions will indeed have Unicode support, then adding
thes
Philip, I assumed what is supposed to be documented is not just a boolean
switch: "this is unicode compatible" / "this is not yet unicode
compatible", but there are behaviour changes, special options, or anything
(I am not actually following PHP 6 development). In case it is just a
boolean swit
On Wed, 19 Jul 2006, Nuno Lopes wrote:
I have already started documenting the Unicode stuff about one year ago
(http://php.net/unicode). Most is already out-of-date, but it is a start
point.
What we were discussing is if we should change every page to mention that it
is unicode-safe/aware/comp
Fine, but what I was saying is that the behavior of number of functions
will change, slightly or more than slightly, depending on unicode
semantics mode being on or on the type of data passed to them. Those
changes need to be documented.
-Andrei
On Jul 19, 2006, at 2:17 PM, Nuno Lopes wrote:
Hi Goba!
I have already started documenting the Unicode stuff about one year ago
(http://php.net/unicode). Most is already out-of-date, but it is a start
point.
What we were discussing is if we should change every page to mention that it
is unicode-safe/aware/compatible/whatever. We were all a
Our policy was always to document functionality when people have time
and willingness to do so, even for funtionality available in stable
versions in the future. The new Unicode stuff needs to be marked as such,
but IMHO has its place in the documentation. People need to see that there
is a lig
> Since all appropriate functions will be unicode compatible in PHP 6.0.0
> this seems like information overload and not something that should be
> mentioned in every functions documentation. Perhaps have a list offsite,
> maybe on docweb, for alpha/beta testers.
Good point. I agree.
This list alr
But we have a big problem: the translators. We can't simply modify all files
and then say to translators that they are lagging behind the English
version.
That said, I can only agree with Philip, from a practical point of view. In
the first alpha version I expect most (if not all) functions to b
I think this information could be useful since people will most likely
want to use online manual even before PHP 6.0 final is out. Making them
go to a separate site to look up which function is Unicode-safe or not
is not very user-friendly.
-Andrei
Since all appropriate functions will be unic
I think what we discussed last time was this:
unicode - for parameters that are -required- to be Unicode strings
binary - for parameters that are -required- to be binary strings
string - for parameters that can be either type
-Andrei
On Jul 19, 2006, at 10:41 AM, Sean Coates wrote:
Ano
On Jul 19, 2006, at 10:41 AM, Sean Coates wrote:
Welcome,
I just wanted to shoot a quick email to the list to see when we could
start work on docs for Unicode upgrades (PHP 6). The main thing,
IMO, is
having a way to mark functions as Unicode compatible and also have a
section (per-functi
Welcome,
> I just wanted to shoot a quick email to the list to see when we could
> start work on docs for Unicode upgrades (PHP 6). The main thing, IMO, is
> having a way to mark functions as Unicode compatible and also have a
> section (per-function) for any Unicode-related notes. Any other thoug
Hey guys,
I just wanted to shoot a quick email to the list to see when we could
start work on docs for Unicode upgrades (PHP 6). The main thing, IMO,
is having a way to mark functions as Unicode compatible and also have a
section (per-function) for any Unicode-related notes. Any other
thought
philip Wed Jul 19 16:30:37 2006 UTC
Modified files:
/phpdoc TODO
Log:
TODO: A tool to check/validate all 'See Also' links
http://cvs.php.net/viewvc.cgi/phpdoc/TODO?r1=1.57&r2=1.58&diff_format=u
Index: phpdoc/TODO
diff -u phpdoc/TODO:1.57 phpdoc/TODO:1.58
philip Wed Jul 19 16:04:12 2006 UTC
Modified files:
/phpdoc/en/reference/apache/functions apache-getenv.xml
Log:
Fix see also, closes bug #38145
http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/apache/functions/apache-getenv.xml?r1=1.8&r2=1.9&diff_for
ID: 38145
Updated by: [EMAIL PROTECTED]
Reported By: chad at herballure dot com
-Status: Open
+Status: Closed
Bug Type:Documentation problem
PHP Version: Irrelevant
New Comment:
This has been fixed in CVS and will show up online at some point in the
future, thank you
From: chad at herballure dot com
Operating system:
PHP version: Irrelevant
PHP Bug Type: Documentation problem
Bug description: Typo in apache_getenv's 'see also': apache_sentenv
Description:
The 'see also' section of apache_getenv should point to apache_setenv,
From: phpbugs at personal dot formauri dot es
Operating system:
PHP version: Irrelevant
PHP Bug Type: Documentation problem
Bug description: strspn: Wrong example in Spanish version
Description:
Concerning the spanish version of the documentation:
http://es2.ph
ID: 38130
User updated by: btherl at yahoo dot com dot au
Reported By: btherl at yahoo dot com dot au
Status: Assigned
Bug Type: Documentation problem
Operating System: Linux
PHP Version: Irrelevant
Assigned To: philip
New Comment:
Sorry, ex
ID: 38130
User updated by: btherl at yahoo dot com dot au
Reported By: btherl at yahoo dot com dot au
Status: Assigned
Bug Type: Documentation problem
Operating System: Linux
PHP Version: Irrelevant
Assigned To: philip
New Comment:
Thanks fo
25 matches
Mail list logo
