In mysqli-client-encoding.xml, I ran into that :
See also
mysqli_client_encoding.
mysqli_real_escape_string.
Is that a policy for see also sections?
Nope, should be:
and .
or:
, and .
So there is no problem if you put it into a refsect (it was actually a
plan to
On Tue, 30 Mar 2004, Damien Seguy wrote:
> Hi guys,
>
> In mysqli-client-encoding.xml, I ran into that :
>
>
> See also
>
> mysqli_client_encoding.
> mysqli_real_escape_string.
>
>
>
> Is that a policy for see also sections?
Nope, should be:
and .
or:
, an
Hi guys,
In mysqli-client-encoding.xml, I ran into that :
See also
mysqli_client_encoding.
mysqli_real_escape_string.
Is that a policy for see also sections?
Dams.
Just a quick remark.
I really think that the manual sections on 'implode' and 'explode'
should refer to 'serialize' and 'unserialize' in their see also lists.
Otherwise you have the best online manual I know. Keep up the good work.
Regards,
Oscar
Hi Oscar,
I saw your note this morning
(htt
Just a quick remark.
I really think that the manual sections on 'implode' and 'explode' should
refer to 'serialize' and 'unserialize' in their see also lists.
Otherwise you have the best online manual I know. Keep up the good work.
Regards,
Oscar
--
PHP Documentation Mailing List (http://www.ph
Why our own tag for see also would be better?
- 98% [approx] of see alsos are not that exoticaly worded, as you
have done in your example
- with our own tags, no translation would be needed for this part
- there will be an ability to automatically recognize see also parts,
which can serio
Ford, Mike [LSS] wrote:
That someone was wrong -- at least according to how I had it drummed into me
at school lo! these many years ago.
it depents on what style guide you read (and maybe which continent you are on?)
the Chicago Manual of Style says ", and", the Minnesota Universty Styleguide
sa
> -Original Message-
> From: Hartmut Holzgraefe [mailto:[EMAIL PROTECTED]
> Sent: 19 June 2003 20:35
>
> Gabor Hojtsy wrote:
> >> Adding our own things to docbook is not a good idea, as it
> will need
> >> more modifications to our stylesheets. Also, it will make it less
> >> flexible i
"Derick Rethans" <[EMAIL PROTECTED]>; "Philip Olson"
<[EMAIL PROTECTED]>; "Friedhelm Betz" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Thursday, June 19, 2003 7:34 PM
Subject: Re: [PHP-DOC] see also
> Gabor Hojtsy wrote:
> >> Add
Gabor Hojtsy wrote:
Adding our own things to docbook is not a good idea, as it will need
more modifications to our stylesheets. Also, it will make it less
flexible in cases like:
Why our own tag for see also would be better?
- 98% [approx] of see alsos are not that exoticaly worded, as you
Adding our own things to docbook is not a good idea, as it will
need more modifications to our stylesheets. Also, it will make
it less flexible in cases like:
See also: foo for an example and
foo2 for more information on blah.
I think we just should set a standard if we;'re going to add a
On Thursday 19 June 2003 19:48, Derick Rethans wrote:
[...]
>
> I think we just should set a standard if we;'re going to add a : or not
> (I don't really care, as long as it is consistent).
I don't care either, the reason I asked was exactly that sometimes is written
with and sometimes without c
On Thu, 19 Jun 2003, Gabor Hojtsy wrote:
> >>with or without : ?
> >>
> >>Deep in my mind I remember Dams changed a couple of see also's to be written
> >>without :
> >
> > Officially it should be without. Hold off on any mass
> > changes though until the doc meeting figures out the
> > format
with or without : ?
Deep in my mind I remember Dams changed a couple of see also's to be written
without :
Officially it should be without. Hold off on any mass
changes though until the doc meeting figures out the
format for "See also" as rumor has it a new tag or
similar will exist for them.
I
On Thu, 19 Jun 2003, Friedhelm Betz wrote:
>
> with or without : ?
>
> Deep in my mind I remember Dams changed a couple of see also's to be written
> without :
Officially it should be without. Hold off on any mass
changes though until the doc meeting figures out the
format for "See also" as r
> with or without : ?
>
> Deep in my mind I remember Dams changed a couple of see also's to be
> written without :
In the french translation we do like so :
See also
function1,
function2,
function3 and
function4.
Maybe it can be applied to the english documentation.
Cheers,
Mehdi
--
PHP
with or without : ?
Deep in my mind I remember Dams changed a couple of see also's to be written
without :
Friedhelm
--
schau mal rein:
http://www.jungle-world.com/
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Snipped proposed versions:
>
>
> somefunc1
> somefunc2
>
>
> If we want a more list like construct, it's a bit more markup heavy:
>
>
>
> somefunc1
>
>
> somefunc2
>
>
What would be the advantage of using the list? The first
one looks much nicer except one question, I
So would it be possible to do just
array_filter
array_walk
And have a stylesheet add things like "See also", ",", "and" and "."? So
that the actual format for the See also is totally consistent for every
language?
Dirkjan
> Well, there is already a seealso tag in Docbook which is sadl
> So would it be possible to do just
>
>
> array_filter
> array_walk
>
>
> And have a stylesheet add things like "See also", ",", "and" and "."? So
> that the actual format for the See also is totally consistent for every
> language?
Something like this, yes. But with a "bit" more markup
So would it be possible to do just
array_filter
array_walk
And have a stylesheet add things like "See also", ",", "and" and "."? So
that the actual format for the See also is totally consistent for every
language?
Dirkjan
> Well, there is already a seealso tag in Docbook which is sadl
> > (Sent this to goba only by accident)
> >
> > Maybe it might even be useful to have something like a "seealso.xml"
which
> > has like
> >
> >
> > array_search
> >
> >
> > Or something like that (this is probably not a useful structure)? This
way,
> > you can keep all of the See also separa
On Sat, 11 Jan 2003, Dirkjan Ochtman wrote:
> (Sent this to goba only by accident)
>
> Maybe it might even be useful to have something like a "seealso.xml" which
> has like
>
>
> array_search
>
>
> Or something like that (this is probably not a useful structure)? This way,
> you can keep
(Sent this to goba only by accident)
Maybe it might even be useful to have something like a "seealso.xml" which
has like
array_search
Or something like that (this is probably not a useful structure)? This way,
you can keep all of the See also separate from the function reference and
closel
I can maybe see a "See Also" for rand() and *possibly* microtime(), but
md5() should not be confused with unique ids. wrapping md5() around any
of the aforementioned functions (including uniqid()) actually makes the
resultant string LESS random, and LESS unique.
-Pollita
> I recommend a "See Als
I recommend a "See Also" in /reference/misc/functions/uniqid.xml to
md5() and rand()
Thanks
Fernando Correa da Conceição
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
Should 'see also' include a ':' or not?
See also: foo(), bar(), and blah().
See also foo(), bar(), and blah().
I prefer the ':' but am okay without.
Regards,
Philip Olson
Hartmut Holzgraefe wrote:
> i will not believe this until i have *seen* that eg. the parameter
> list rendering for optional arguments comes out easier than it is
> in DSSSL ;)
>
> from my rather limit XSLT experience it is easier to use on simple
> problems but can become a complete nightmare o
Lars Torben Wilson wrote:
> Existing support for the DSSSL stylesheets may be more
> comprehensive, but IMHO XSL is so much easier to work with that it's
> worth the effort to move toward it.
i will not believe this until i have *seen* that eg. the parameter
list rendering for optional arguments
Egon Schmid wrote:
> We use since 1997 The Chicago Manual of Style and now EOD.
Where is this decision documented?
Is it in the howto?
NO!
Is it in the README?
NO!
Is it in the list archive?
The one i know of doesn't go back beyond 1999, so most likely:
NO!
the only useful reference regardin
> > I can devote some to do it, but is there anyone who wants to use XSL?
> > When I asked same question year ago, almost noone respond. If there will
> > be no usage of XSL, why to cutomize stylesheets?
> >
> > Jirka
>
> I do, I do! Existing support for the DSSSL stylesheets may be more
> compreh
Jirka Kosek wrote:
> Hartmut Holzgraefe wrote:
>
>
>>it's things like automatic linking and adding () for
>>references in normal text,
>>
>
> I thought that this I have hacked year ago.
so you just found out how much i looked into the xsl files :)
>>rendering optional parameters a bit mo
> > it's things like automatic linking and adding () for
> > references in normal text,
>
> I thought that this I have hacked year ago.
>
> > rendering optional parameters a bit more
> > clever ... and ... and ... and ...
>
> I can devote some to do it, but is there anyone who wants to use XSL
Jirka Kosek writes:
> Hartmut Holzgraefe wrote:
>
> > it's things like automatic linking and adding () for
> > references in normal text,
>
> I thought that this I have hacked year ago.
>
> > rendering optional parameters a bit more
> > clever ... and ... and ... and ...
>
> I can devote some
Hartmut Holzgraefe wrote:
> it's things like automatic linking and adding () for
> references in normal text,
I thought that this I have hacked year ago.
> rendering optional parameters a bit more
> clever ... and ... and ... and ...
I can devote some to do it, but is there anyone who wants t
Egon Schmid wrote:
> I don´t have something against a rendering a "see also" block. But
> rendering the content with a list would be a nightmare. We had a
> discussion at which place should be comma in this list. This depends
> on the language and I can guess it will be look very funny in
> Arabi
Egon Schmid wrote:
> Commit it and I hope Goba and Hartmut will not missuse it.
please define "missuse"
--
Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77
Jirka Kosek wrote:
> Gabor Hojtsy wrote:
>
>
>>Two reasons, speed and customization level. Not all DSSSL customizations
>>are ported to XSL customizations. This is in the TODO in BUILD SYSTEM
>>
>
> If you tell my which, I can port them.
well, have a look at the dsl subdir ;)
it's things lik
Egon Schmid wrote:
>>DocBook stylesheets contain code for inserting puncation between
>>
> list
>
>>items -- for example between authors in bibliography. This code is
>>localized. Porting this code for our purposes shouldn't be hard.
>>
>
> Oh, haven´t known that.
come on, that's what the mod
> We use since 1997 The Chicago Manual of Style and now EOD.
Not sure why I brought it up actually.
Philip
Egon Schmid wrote:
> Oh, haven´t known that. Can it do the following in English:
>
> See also: func1 and func2.
> See also: func1, func2, and func3.
>
> and for German or Hungarian:
>
> Siehe auch: func1 und func2.
> Siehe auch: func1, func2 und func3.
>
> Look at the commas.
Yes, exactly. (
From: "Philip Olson" <[EMAIL PROTECTED]>
> > See also: func1 and func2.
> > See also: func1, func2, and func3.
> >
> > and for German or Hungarian:
> >
> > Siehe auch: func1 und func2.
> > Siehe auch: func1, func2 und func3.
>
> Btw, it's okay english (perfectly acceptable) to not put a comma
bef
> See also: func1 and func2.
> See also: func1, func2, and func3.
>
> and for German or Hungarian:
>
> Siehe auch: func1 und func2.
> Siehe auch: func1, func2 und func3.
Btw, it's okay english (perfectly acceptable) to not put a comma before
the and here, so:
See also: func1, func2 and func3
Gabor Hojtsy wrote:
> Two reasons, speed and customization level. Not all DSSSL customizations
> are ported to XSL customizations. This is in the TODO in BUILD SYSTEM
If you tell my which, I can port them.
--
-
Jirka Kosek
From: "Jirka Kosek" <[EMAIL PROTECTED]>
Egon Schmid wrote:
> > I don´t have something against a rendering a "see also" block.
But
> > rendering the content with a list would be a nightmare. We had a
> > discussion at which place should be comma in this list. This
depends
> > on the language and
Egon Schmid wrote:
> I don´t have something against a rendering a "see also" block. But
> rendering the content with a list would be a nightmare. We had a
> discussion at which place should be comma in this list. This depends
> on the language and I can guess it will be look very funny in
> Arabi
From: "Jirka Kosek" <[EMAIL PROTECTED]>
> I finished modification of DSSSL stylesheets. They are 100%
backward
> compatible -- rendering is changed only on notes with
role="seealso". If
> you decide not to use it, you can always delete this rule in
future.
> Egon, can I commit it before I forget
> I don´t have something against a rendering a "see also" block.
> But rendering the content with a list would be a nightmare. We had a
> discussion at which place should be comma in this list. This depends
> on the language and I can guess it will be look very funny in
> Arabic.
>
> > I see no pr
From: "Jirka Kosek" <[EMAIL PROTECTED]>
Egon Schmid wrote:
> > Jirka, please don´t make changes for the rendering of the "see
also"
> > notes until there is a solution for the incomplete PDF manuals.
IMHO
> > it is an overkill.
> You mean: overkill = too much markup?
Yes.
> In general you are
> > HTML Help will definetly render the see also parts with different
> > style. Now I have implemented some auto detection with some
> > ugly text processing, searching for "see also:" commas and "and"
> > words, and detected the see also parts this way for the HTML Help
> > generation. This is n
Egon Schmid wrote:
> Jirka, please don´t make changes for the rendering of the "see also"
> notes until there is a solution for the incomplete PDF manuals.
how are these two topics related? have i missed something?
> IMHO it is an overkill.
> It is much better to write the "see also" notes
Gabor Hojtsy wrote:
>
> > In general you are right, but marking some block as "seealso" can be
> > very usefull when rendering and converting to other formars (e.g. HTML
> > Help).
>
> HTML Help will definetly render the see also parts with different
> style. Now I have implemented some auto det
> In general you are right, but marking some block as "seealso" can be
> very usefull when rendering and converting to other formars (e.g. HTML
> Help).
HTML Help will definetly render the see also parts with different
style. Now I have implemented some auto detection with some
ugly text processi
Egon Schmid wrote:
> Jirka, please don´t make changes for the rendering of the "see also"
> notes until there is a solution for the incomplete PDF manuals. IMHO
> it is an overkill.
You mean: overkill = too much markup?
In general you are right, but marking some block as "seealso" can be
very u
> > As nobody else complained,
>
> didn't i?
Yes, sorry :) Jirkas, idea solves the list problem,
as I can see, while also allows us to use simple text if a list
is not appropriate. What do you think abut this?
Goba
> > IMHO is on semantic level very close to seealso. Using role
> > is standard DocBook way to make it different from standard note.
>
> Jirka, please don´t make changes for the rendering of the "see also"
> notes until there is a solution for the incomplete PDF manuals. IMHO
> it is an overkill.
Gabor Hojtsy wrote:
> As nobody else complained,
didn't i?
--
Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77
From: "Jirka Kosek" <[EMAIL PROTECTED]>
> Gabor Hojtsy wrote:
>
> > > What is the exact syntax, will we still be defining commas and
'and'
> > > within the blocks?
> >
> > Yes. It seems that using lists is much more complex for the
rendering,
> > as it involves adding commas and and words only wh
>
>
> print
> echo
>
>
>
> Once again, you must wrap it inside para:
>
>
>
> print, and
> the notes on the CGI
> security page
>
>
>
> IMHO is on semantic level very close to seealso. Using role is
> standard DocBook way to make it different from standard note.
IMHO we can go
Gabor Hojtsy wrote:
> > What is the exact syntax, will we still be defining commas and 'and'
> > within the blocks?
>
> Yes. It seems that using lists is much more complex for the rendering,
> as it involves adding commas and and words only where needed
> programatically.
>
>
> print, and
>
> > > If I understand it correctly, see-also block is very simillar to
> > > admonitions (note, warning, ...). So what about putting see-also
inside
> > > note
> > >
> > >
> > > ...
> > >
> > >
> > > Stylesheet can render it differently than note w/o role="seealso".
> >
> > As nobody else compla
> > If I understand it correctly, see-also block is very simillar to
> > admonitions (note, warning, ...). So what about putting see-also inside
> > note
> >
> >
> > ...
> >
> >
> > Stylesheet can render it differently than note w/o role="seealso".
>
> As nobody else complained, I think we ca
> If I understand it correctly, see-also block is very simillar to
> admonitions (note, warning, ...). So what about putting see-also inside
> note
>
>
> ...
>
>
> Stylesheet can render it differently than note w/o role="seealso".
As nobody else complained, I think we can go on with this styl
> > Well, that can also be fine, and better then para,
> > because it is actually a list, and not a para, as
> > it can be seen :)) The second one is better in
> > "keys need to be typed" sense :) But, we have
> > see also parts, where we have some functions and
> > some parts refereced, and to ex
Gabor Hojtsy wrote:
> Well, that can also be fine, and better then para,
> because it is actually a list, and not a para, as
> it can be seen :)) The second one is better in
> "keys need to be typed" sense :) But, we have
> see also parts, where we have some functions and
> some parts refereced,
> what about
>
>
>echo
>print
>printf
>
>
> or
>
>
>echo
>print
>printf
>
>
> ?
Well, that can also be fine, and better then para,
because it is actually a list, and not a para, as
it can be seen :)) The second one is better in
"keys need to be typed" sense
Gabor Hojtsy wrote:
>>>I would like to have a special rendering
>>>
>>+1 to something like this, will be cool to have 'See also' a bit more
>>structured.
>>
>
> I would like to see something like:
>
>
> echo, print,
> and printf
>
>
> Or even:
>
>
> echo
> print
> printf
>
wh
> > I would like to have a special rendering
>
> +1 to something like this, will be cool to have 'See also' a bit more
> structured.
I would like to see something like:
echo, print,
and printf
Or even:
echo
print
printf
And let the DSSSL code to the rendering work, put
in coma
> I would like to have a special rendering
+1 to something like this, will be cool to have 'See also' a bit more
structured.
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
70 matches
Mail list logo
