On Fri, Dec 5, 2008 at 07:28, Kalle Sommer Nielsen <[EMAIL PROTECTED]> wrote:
> 2008/12/4 Hannes Magnusson <[EMAIL PROTECTED]>:
>> Using a revision attribute (like proposed last year, and again
>> recently) on the root elements of all chunks would however possibly
>> make it possible.
>> PhD could
2008/12/4 Hannes Magnusson <[EMAIL PROTECTED]>:
> On Thu, Dec 4, 2008 at 07:20, Kalle Sommer Nielsen <[EMAIL PROTECTED]> wrote:
>> 1) Translation bugs
>> Theres many translation bugs reported [1] reported to the bug tracker
>> and I don't think that many translators check for bugs in there. So I
>>
2008/12/4 Philip Olson <[EMAIL PROTECTED]>:
>> 1) Translation bugs
>> Theres many translation bugs reported [1] reported to the bug tracker
>> and I don't think that many translators check for bugs in there. So I
>> propose we add a link to the docweb site for when you're focusing on a
>> specific
On Thu, Dec 4, 2008 at 07:20, Kalle Sommer Nielsen <[EMAIL PROTECTED]> wrote:
> 1) Translation bugs
> Theres many translation bugs reported [1] reported to the bug tracker
> and I don't think that many translators check for bugs in there. So I
> propose we add a link to the docweb site for when you
1) Translation bugs
Theres many translation bugs reported [1] reported to the bug tracker
and I don't think that many translators check for bugs in there. So I
propose we add a link to the docweb site for when you're focusing on a
specific translation to eg. say:
Project (documentation) bugs
53 o
Right
So I had this idea for sometime now, its actually two ideas for
translations of the manual, which is as follows:
1) Translation bugs
Theres many translation bugs reported [1] reported to the bug tracker
and I don't think that many translators check for bugs in there. So I
propose we add a l
Hi,
Choices:
a) /phpdoc/
b) /phpdoc/entities/
c) /phpdoc/somenewdir/
d) ...
Although it's not really a list of entities the file can go in that
folder. It would be the simplest. Note: this file is not language
specific so only one copy will exist.
Entities might be a good choice.
agreeded
Hi,
Choices:
a) /phpdoc/
b) /phpdoc/entities/
c) /phpdoc/somenewdir/
d) ...
Although it's not really a list of entities the file can go in that folder.
It would be the simplest. Note: this file is not language specific so only
one copy will exist.
Entities might be a good choice.
Why acron
Hello everyone!
This RFC is for a new acronyms.xml and has two main points:
1. File location in phpdoc:
Choices:
a) /phpdoc/
b) /phpdoc/entities/
c) /phpdoc/somenewdir/
d) ...
Although it's not really a list of entities the file can go in that
folder. It would be the simplest. Note: this
Hi,
I've tried to make validation check on my WIN system without
cygwin, jade and nsgmls and found some strange things about PHPDOC
build system. I'll be glad if somebody could read this and answer
my questions. =)
Well, I am trying to decipher what you try to tell us, but sometimes it
is quit
Hello, [EMAIL PROTECTED]
I've tried to make validation check on my WIN system without
cygwin, jade and nsgmls and found some strange things about PHPDOC
build system. I'll be glad if somebody could read this and answer
my questions. =)
RFC/xml_validation seems to be outdated.
I'll quote i
--- Gabor Hojtsy <[EMAIL PROTECTED]> wrote:
[...snip...]
> &reference.objaggregation.functions.aggregation;
>
> So use the dirnames, and the filename without the
> extension at the end. Your sample was not correct,
> as you used "objaggregations" and not
> "objaggregation"
> as you pointed out t
On Mon, 29 Apr 2002, Jesus M. Castagnetto wrote:
> I am documenting the new object aggregation functions,
> and before I add it to the CVS tree, I would like to
> ask some questions:
I would wait with documenting this until all discussions are done on it.
regards,
Derick
>
> 1) I am using en/
> 1) I am using en/reference/objaggregation for the
> functions, is that OK? (got all the appropriate files
> there)
Seems ok. I don't of it there is a better name for
the aggregate extension.
> 2) Consistent w/ (1), all function entities are named
> &reference.objaggregations.function.aggregati
I am documenting the new object aggregation functions,
and before I add it to the CVS tree, I would like to
ask some questions:
1) I am using en/reference/objaggregation for the
functions, is that OK? (got all the appropriate files
there)
2) Consistent w/ (1), all function entities are named
&re
> IMHO this belongs to an appendix. Just make a warning on top, that it
> is a) work in progress and so b) not worth translating yet.
good idea
Hi,
On Wed, 13 Mar 2002 20:18:26 + (GMT)
Philip Olson <[EMAIL PROTECTED]> wrote:
> Is the RFC directory an okay place to put
> work-in-progress goodies? For example, I want
> to start (not finish :) a list of differences
> of windows/*nix for PHP users to consider.
IMHO this belongs to an
Hello,
Is the RFC directory an okay place to put
work-in-progress goodies? For example, I want
to start (not finish :) a list of differences
of windows/*nix for PHP users to consider.
See bug #13321 for more details on this particular
matter.
Regards,
Philip
> I'd like to change the numbering for s from roman to arabic
> in the DSSSL stylesheets as i think that most readers are not that
> familiar with roman numbers that they can decode eg. XLVIII as 48
> *and* roman numbers screw up the indentation in the TOC
+1
The CHM scripts also need some modif
I'd like to change the numbering for s from roman to arabic
in the DSSSL stylesheets as i think that most readers are not that
familiar with roman numbers that they can decode eg. XLVIII as 48
*and* roman numbers screw up the indentation in the TOC
[...]
XLVIII. LDAP functions
XLIX. Mail functio
On Sat, 20 Oct 2001, Jirka Kosek wrote:
> If you want to customize DTD it is always better to create customization
> layer than to directly edit existing DTD. With this approach it is much
> more easy to upgrade to new version DocBook which is used as a base for
> your DTD. The customization DT
Hartmut Holzgraefe wrote:
>
> Jouni Ahto wrote:
>
> > Maybe it should be the time to find out what the current DTD actually is,
> > and what it allows us to do?
>
> very good point!
> (i was always refereing to "the book" which is for V3.1.x AFAIR)
New version of TDG has actualised reference p
On Fri, 19 Oct 2001, Hartmut Holzgraefe wrote:
> Jouni Ahto wrote:
>
> > Maybe it should be the time to find out what the current DTD actually is,
> > and what it allows us to do?
>
>
> very good point!
> (i was always refereing to "the book" which is for V3.1.x AFAIR)
Besides, even if the
Jouni Ahto wrote:
> I really like the part 'Maybe its time to get invloved [typos not fixed]
> into the DocBook project itself, [...]' (Jirka actually is doing exactly
> that). If DocBook can't satisfy a programming projects' needs, someone is
> not modeling something the right way. Currently, I
Hojtsy Gabor wrote:
> As Jirka said, as long as they use the DocBook DTDs
> from the phpdoc repositories dbxml directory, they can
> use tags added there. For other tools not dependant
> on this directory, there would be much-much more
> problems. There are some (IMHO not so elegant) solutions
I
Jouni Ahto wrote:
> Maybe it should be the time to find out what the current DTD actually is,
> and what it allows us to do?
very good point!
(i was always refereing to "the book" which is for V3.1.x AFAIR)
>"./dbxml/docbookx.dtd" [... etc
>
>
> DocBook XML 4.1.2 is the current XML version of DocBook. There are no
> official XML versions of DocBook prior to V4.0.
>
> Maybe it should be the time to find out what the current DTD actually is,
> and what it allows us to do?
If we use 4.1
Hojtsy Gabor wrote:
> These are problems that should be discussed.
thats exactly the reason for me writing the PDF
almost everything i mention in there has already been talked
about on this list in some way without much work going on on it
so i tried to summarize the identified problems and th
On Fri, 19 Oct 2001, Egon Schmid wrote:
> From: "Hojtsy Gabor" <[EMAIL PROTECTED]>
>
> > So reworded: using namespaces to define tags, and use them
> > along DocBook tags. This is exaclty not extending DocBook,
> > but defining a DTD for our custom elements and use those
> > two DTDs (DocBook
> > So reworded: using namespaces to define tags, and use them
> > along DocBook tags. This is exaclty not extending DocBook,
> > but defining a DTD for our custom elements and use those
> > two DTDs (DocBook and PHPDoc) side-by-side.
>
> This may be a misinformation. With tags I am always refferi
From: "Hojtsy Gabor" <[EMAIL PROTECTED]>
> > > - the problem of entities (global.ent) as used in some old
> > >translations and the main tree (deletes can make
unbuildable
> > >manuals)
> >
> > If you speak from old translations, so translate the other
languages
> > yourself.
>
> It is n
OK, it seems my words were not clear. So rewording.
> > - the problem of entities (global.ent) as used in some old
> >translations and the main tree (deletes can make unbuildable
> >manuals)
>
> If you speak from old translations, so translate the other languages
> yourself.
It is not
- Original Message -
From: "Hojtsy Gabor" <[EMAIL PROTECTED]>
To: "Hartmut Holzgraefe" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, October 19, 2001 7:05 PM
Subject: Re: [PHP-DOC] RFC
> > i have just uploaded the draft for the
On Fri, 19 Oct 2001, Hartmut Holzgraefe wrote:
>
> i have just uploaded the draft for the 'beyond' part of my conference
> talk "The manual and beyond" to
>
>http://zugeschaut-und-mitgebaut.de/php/conference-talk.pdf
>
> comments & suggestions are highly appreciated :)
I really like the
> i have just uploaded the draft for the 'beyond' part of my conference
> talk "The manual and beyond" to
>
>http://zugeschaut-und-mitgebaut.de/php/conference-talk.pdf
>
> comments & suggestions are highly appreciated :)
You should speak about
- the problem of entities (global.ent) as use
i have just uploaded the draft for the 'beyond' part of my conference
talk "The manual and beyond" to
http://zugeschaut-und-mitgebaut.de/php/conference-talk.pdf
comments & suggestions are highly appreciated :)
--
Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77
> > Commenting the categories list, I don't think
> > that categories, with only one item should be
> > opened (eg. Search or URL or Data Exchange).
>
> Yes, under Miscellaneous, unless some other module
> too gets moved under those categories.
I see that you have opened them to start discussion
> On Sun, 2 Sep 2001, Jeroen van Wolffelaar wrote:
>
> > I would merge "string/character" and "Variables,types and function
> > handling", and name it:
> > "basic functions", since they are very general-purpose, do NOT have
external
> > depencies (like mysql, etc), and are quite close to the langu
On Sun, 2 Sep 2001, Jeroen van Wolffelaar wrote:
> I would merge "string/character" and "Variables,types and function
> handling", and name it:
> "basic functions", since they are very general-purpose, do NOT have external
> depencies (like mysql, etc), and are quite close to the language.
> Er
I would merge "string/character" and "Variables,types and function
handling", and name it:
"basic functions", since they are very general-purpose, do NOT have external
depencies (like mysql, etc), and are quite close to the language.
Error-handling, program execution are also good candidates for "
On Sun, 2 Sep 2001, Hojtsy Gabor wrote:
> What do you think about these additional groups?
>
> Variables, types and function handling
> Array
> Class-object
> Function handling
> Variable
> Session handling
>
> Miscellaneous:
> Apache-specific
> Error handling and logging
> GNU readli
What do you think about these additional groups?
Variables, types and function handling
Array
Class-object
Function handling
Variable
Session handling
Miscellaneous:
Apache-specific
Error handling and logging
GNU readline
PHP options & information
Program execution
Printer
Semaphore
On Sun, 26 Aug 2001, Egon Schmid wrote:
> It would be nice, if someone could make a first draft about the
> names of new chapters and which sections could be within sections.
Ok, here it is. And it's really a very rough draft... based on bug types
in bug reporting system, but not exactly the s
> > > - New subtitles must be agreed on and added to each language-defs.ent.
> >
> > This is what needs to be the same for the bug system. So if it is
> > not right, we should collect the functions and make a new category
> > system, and start to use it in the bug system and here too.
>
> Somethin
On Sun, 26 Aug 2001, Hojtsy Gabor wrote:
> > - New subtitles must be agreed on and added to each language-defs.ent.
>
> This is what needs to be the same for the bug system. So if it is
> not right, we should collect the functions and make a new category
> system, and start to use it in the bu
On Sun, 26 Aug 2001, Egon Schmid wrote:
> It would be nice, if someone could make a first draft about the
> names of new chapters and which sections could be within sections.
Something very near to the list of bug types bugs.php.net. I think there
actually was a draft some time ago, but I'll h
> Can be done without any hurry before the change:
> - Modify the *.dsl files so that TOC is created the right way. Some small
> fixing with HTML version, a bit more with printable versions. I will
> volunteer, unless Hartmut explicitly requests to have the honour...
> - New subtitles must be
> This topic has popped up a few times before on the list, and I
think I've
> seen even bug report(s?) claiming that the current function
reference
> part makes it hard to find information, because it has grown so
big. But I
> don't remember that we would haver ever deciced either to do it or
not
This topic has popped up a few times before on the list, and I think I've
seen even bug report(s?) claiming that the current function reference
part makes it hard to find information, because it has grown so big. But I
don't remember that we would haver ever deciced either to do it or not do
it...
RE: [PHP-DOC] RFC : [PHP-DOC] FAQ porting to the manual?Would this not be
better suited by using ... blocks instead of
blocks? Since requires a tag, it doesn't quite work
so well as it is currently in cvs. What do you guys think?
Daniel
- Original Message -
From: Hojtsy Gab
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
Title: RE: [PHP-DOC] RFC : [PHP-DOC] FAQ porting to the manual?
>Create a new directory for FAQ (called "faq").
>All main FAQ entry get its own file
>("faq.general","faq.mailing-lists","faq.obtaining","faq.databases"...).
Ri
on 8/07/01 12:43, Hojtsy Gabor at [EMAIL PROTECTED] wrote:
Hi Goba,
> What is the news about $subj?
Here is the suggestion :
Create a new directory for FAQ (called "faq").
All main FAQ entry get its own file
("faq.general","faq.mailing-lists","faq.obtaining","faq.databases"...).
Each file has
$this is the special
variable.
Daniel
- Original Message -
From: "Damien Seguy" <[EMAIL PROTECTED]>
To: "Daniel Beckham" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, July 06, 2001 4:03 AM
Subject: [PHP-DOC]
on 6/07/01 3:48, Daniel Beckham at [EMAIL PROTECTED] wrote:
Hi,
>> The list of reserverd words itself is quite bogus by the way... It really
>> should be reviewed soon.
I did this first draft. The goal was to gather all special words from PHP,
besides function names. I ordered them alphabeticall
> One the other hand, parameter/returned types need often updates (int ->
> boolean), and the 'mixed' type is not always easy to understand.
> That would make more sense to get some consistency on this point.
> I'll try to make an in-depth survey of used types, so as to shape their
use.
Mixed sho
> > RFC (Request for comments):
> > - what's the preferred name for the boolean type?
> > 'bool' or 'boolean'?
>
> Boolean
>
> > - what's the preferred name for the floating point type?
> > 'double' or 'float'?
>
> I think that depends on the context. Technically it should be 'double',
> b
Jeroen van Wolffelaar wrote:
>
> > done (after six hours of heavy DSSSL-Fu :( )
>
> Great :)
>
> I'll keep that in mind, I won't make any more s to types then.
it's not about the XML, my mind just wasn't up to interprete
these strange error messages jade emmits by times ...
the actual patch
on 16/05/01 20:33, Jeroen at [EMAIL PROTECTED] wrote:
>>> - what's the preferred name for the boolean type?
>>> 'bool' or 'boolean'?
>>
>> Boolean
>
> But bool in func-defs, I read in php.dev
> And I meant in func-defs, because the 'real' word is - of course - boolean.
>
IMHO, I finally think
> > - what's the preferred name for the boolean type?
> > 'bool' or 'boolean'?
>
> Boolean
But bool in func-defs, I read in php.dev
And I meant in func-defs, because the 'real' word is - of course - boolean.
> > - what's the preferred name for the floating point type?
> > 'double' or 'float'
> RFC (Request for comments):
> - what's the preferred name for the boolean type?
> 'bool' or 'boolean'?
Boolean
> - what's the preferred name for the floating point type?
> 'double' or 'float'?
I think that depends on the context. Technically it should be 'double',
but people don't necess
Hi,
RFC (Request for comments):
- what's the preferred name for the boolean type?
'bool' or 'boolean'?
- what's the preferred name for the floating point type?
'double' or 'float'?
- Can it be made that string etc will
automagically be rendered as a hyperlink to
language.types.string etc?
62 matches
Mail list logo
