I think it would be nice if the Wiki syntax could facilitate footnoting of articles. For example:
Some text.<footnote>foo</footnote> Some more text.<footnote>bar</footnote> Even more text.
could produce the following HTML:
Some text.<A HREF="#1">(1)</A> Some more text.<A HREF="#2">(2)</A> Even more text. <OL> <LI><A NAME="1">foo</LI> <LI><A NAME="2">bar</LI> </OL>
Sheldon Rampton wrote:
I think it would be nice if the Wiki syntax could facilitate footnoting of articles.
I don't think footnotes are suitable for webpages. Unlike paper, the user has to travel (potentially) a long way for related information. I have been trying to reintegrate them into the text where I see them in articles -- I suggest we try and write without them
Sheldon Rampton wrote:
I think it would be nice if the Wiki syntax could facilitate footnoting of articles.
I don't think footnotes are suitable for webpages. Unlike paper, the user has to travel (potentially) a long way for related information. I have been trying to reintegrate them into the text where I see them in articles -- I suggest we try and write without them
It can be some time useful to make a sentence/paragraph more easy to read and redirect the reader to a more detailed paragraph (for exemple in the article introduction).
Aoineko
--- Guillaume Blanchard gblanchard@arcsy.co.jp wrote:
Sheldon Rampton wrote:
I think it would be nice if the Wiki syntax
could facilitate
footnoting of articles.
I don't think footnotes are suitable for webpages. Unlike paper, the user has to travel (potentially)
a long way for
related information. I have been trying to reintegrate them into the
text where I see them in
articles -- I suggest we try and write without
them
It can be some time useful to make a sentence/paragraph more easy to read and redirect the reader to a more detailed paragraph (for exemple in the article introduction).
Aoineko
hello Aoineko,
hidden anchors then ? :-)
__________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
On Mon, Mar 10, 2003 at 01:46:07PM +0000, tarquin wrote:
Sheldon Rampton wrote:
I think it would be nice if the Wiki syntax could facilitate footnoting of articles.
I don't think footnotes are suitable for webpages. Unlike paper, the user has to travel (potentially) a long way for related information. I have been trying to reintegrate them into the text where I see them in articles -- I suggest we try and write without them
Related useful feature would be a way to link to places in articles.
[[Foo#Bar|Something]]
[[Foo#Bar]] = [[Foo#Bar|Bar]] [[#Bar|Something]] = [[Current Article#Bar|Something]] [[#Bar]] = [[Current Article#Bar|Bar]]
Archors may be generated automatically from headers.
Which mysql privileges should wikiuser have?
How about sysops?
Developers?
(Fred Bauder fredbaud@ctelco.net): Which mysql privileges should wikiuser have?
How about sysops?
Developers?
The maintenance directory has a script "buildusers.sql" that grants all the needed privileges to users "wikiuser", "wikiadmin", and "wikisql". Developer status is a function of the software and isn't manifested as a different MySQL user.
Bascially, wikiuser can do anything but create and change the database, and most of the normal wiki functions happen as that user. Wikisql is a restricted user that can only select; it is used for the direct SQL query function of Sysops to limit potential damage. Wikiadmin is not used by the software at all, but is used by the build scripts and such. It is meant for those with real access to the server.
On Mon, 2003-03-10 at 19:39, Fred Bauder wrote:
Which mysql privileges should wikiuser have?
See buildusers.sql in the maintenance subdirectory.
How about sysops?
SQL query access for sysops goes through the 'wikisql' user. Should be in buildusers.sql as well... Basically, read-only access to all tables except for the password and e-mail fields in the user table.
Developers?
SQL query access for developers goes through wikiuser, same as the wiki interface.
Note that the user 'wikiadmin' is used only by the maintenance scripts (createdb.php, rebuildLinks.php etc) and, optionally, manual maintenance.
-- brion vibber (brion @ pobox.com)
Hey, Fred, I hope you'll keep some notes, however sketchy, on how you're getting all this done, and then if those notes were on the meta.wikipedia.com, other people could add/edit them over time, to help other people install the software.
Fred Bauder wrote:
Which mysql privileges should wikiuser have?
How about sysops?
Developers?
Wikitech-l mailing list Wikitech-l@wikipedia.org http://www.wikipedia.org/mailman/listinfo/wikitech-l
Well, my experience is interesting. I am using space from a web-hosting service, cheap but with minimal support (this can get nasty when you don't have root access to the server; you have to not only figure out what to do but beg someone else to do it). I did invest in some books which have been illuminating.
PHP & MySQL for Dummies and Build Your Own Database Driven Website Using PHP & MySQL.
I'll try to get something onto meta (I don't know how much embarrassment I can stand though).
Fred
From: Jimmy Wales jwales@bomis.com Reply-To: wikitech-l@wikipedia.org Date: Tue, 11 Mar 2003 05:37:36 -0800 To: wikitech-l@wikipedia.org Subject: Re: [Wikitech-l] Mysql privileges
Hey, Fred, I hope you'll keep some notes, however sketchy, on how you're getting all this done, and then if those notes were on the meta.wikipedia.com, other people could add/edit them over time, to help other people install the software.
Fred Bauder wrote:
Which mysql privileges should wikiuser have?
How about sysops?
Developers?
Wikitech-l mailing list Wikitech-l@wikipedia.org http://www.wikipedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@wikipedia.org http://www.wikipedia.org/mailman/listinfo/wikitech-l
Well, if you can handle the embarassment, you're the perfect guy for this. :-) There's a lot of stuff that developers forget that other people don't have as background knowledge. Coming in "fresh" you have an important perspective.
Fred Bauder wrote:
Well, my experience is interesting. I am using space from a web-hosting service, cheap but with minimal support (this can get nasty when you don't have root access to the server; you have to not only figure out what to do but beg someone else to do it). I did invest in some books which have been illuminating.
PHP & MySQL for Dummies and Build Your Own Database Driven Website Using PHP & MySQL.
I'll try to get something onto meta (I don't know how much embarrassment I can stand though).
Fred
From: Jimmy Wales jwales@bomis.com Reply-To: wikitech-l@wikipedia.org Date: Tue, 11 Mar 2003 05:37:36 -0800 To: wikitech-l@wikipedia.org Subject: Re: [Wikitech-l] Mysql privileges
Hey, Fred, I hope you'll keep some notes, however sketchy, on how you're getting all this done, and then if those notes were on the meta.wikipedia.com, other people could add/edit them over time, to help other people install the software.
Fred Bauder wrote:
Which mysql privileges should wikiuser have?
How about sysops?
Developers?
Wikitech-l mailing list Wikitech-l@wikipedia.org http://www.wikipedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@wikipedia.org http://www.wikipedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@wikipedia.org http://www.wikipedia.org/mailman/listinfo/wikitech-l
Fred Bauder wrote:
Well, my experience is interesting. I am using space from a web-hosting service, cheap but with minimal support (this can get nasty when you don't have root access to the server; you have to not only figure out what to do but beg someone else to do it). I did invest in some books which have been illuminating.
The most frustrating message you can get when you're trying to solve a problem on a stand-alone home computer is "See system administrator." :-)
Ec
How does one disable editing by bots such as the one RamMan used?
Fred
On Tue, Mar 11, 2003 at 07:33:46AM -0700, Fred Bauder wrote:
How does one disable editing by bots such as the one RamMan used?
There is no easy way to do so. Your server has no means to distinguish between a human editor or a bot.
The technique used by most websites to get rid of bots is to force the user to type in a text that is presented to the user in an image. Ideally, the image should be hard to scan by a computer.
Regards,
JeLuF
On Tue, Mar 11, 2003 at 06:41:18PM +0100, Jens Frank wrote:
On Tue, Mar 11, 2003 at 07:33:46AM -0700, Fred Bauder wrote:
How does one disable editing by bots such as the one RamMan used?
There is no easy way to do so. Your server has no means to distinguish between a human editor or a bot.
The technique used by most websites to get rid of bots is to force the user to type in a text that is presented to the user in an image. Ideally, the image should be hard to scan by a computer.
This is extremely stupid technique of course - it does much more to annoy users than to prevent an attack. Just make a policy that bots should not be used on your site.
One of the great and amazing discoveries of wikipedia is that while there are a few jerks out there of course, the general population of the Internet as a whole is not filled with rabid savages looking to wreck websites.
Brion blocks abusive bots from time to time, but it's not often a big problem. I'd say for a smaller site just starting out, there's almost no chance of a bot doing anything.
--Jimbo
On Mon, Mar 10, 2003 at 01:46:07PM +0000, tarquin wrote:
Sheldon Rampton wrote:
I think it would be nice if the Wiki syntax could facilitate footnoting of articles.
I don't think footnotes are suitable for webpages. Unlike paper, the user has to travel (potentially) a long way for related information. I have been trying to reintegrate them into the text where I see them in articles -- I suggest we try and write without them
Related useful feature would be a way to link to places in articles.
[[Foo#Bar|Something]]
[[Foo#Bar]] = [[Foo#Bar|Bar]] [[#Bar|Something]] = [[Current Article#Bar|Something]] [[#Bar]] = [[Current Article#Bar|Bar]]
Archors may be generated automatically from headers.
Yesss... anchors can solve the problem but we are not liable enough to have the right to use this feature ;o)
Aoineko
Guillaume Blanchard wrote:
Yesss... anchors can solve the problem but we are not liable enough to have the right to use this feature ;o)
aaarg! anchors are bad.
if you need to drop into the middle of an article then you have two articles that ought to be split.
could we drop it?
Yesss... anchors can solve the problem but we are not liable enough to
have
the right to use this feature ;o)
aaarg! anchors are bad.
if you need to drop into the middle of an article then you have two articles that ought to be split.
could we drop it?
I don't think split article is always the solution ;o) I agree only in the case of very long article. Split article make it less readable, less printable and over all make it more longer to load for slow connection. Imho say "anchors are bad" is the better way to answer the Tomasz problem. I'm very disappointed that decision maker don't believe we are smart enough to use anchor in the right way.
Aoineko
On Tue, Mar 11, 2003 at 09:25:34PM +0900, Guillaume Blanchard wrote:
Yesss... anchors can solve the problem but we are not liable enough to
have
the right to use this feature ;o)
aaarg! anchors are bad.
if you need to drop into the middle of an article then you have two articles that ought to be split.
could we drop it?
I don't think split article is always the solution ;o) I agree only in the case of very long article. Split article make it less readable, less printable and over all make it more longer to load for slow connection. Imho say "anchors are bad" is the better way to answer the Tomasz problem. I'm very disappointed that decision maker don't believe we are smart enough to use anchor in the right way.
There are some articles for which one article + anchors are good design. I'm talking mostly about internal anchors here.
Example: http://pl.wikipedia.org/wiki/S%C5%82owniczek_japo%C5%84ski
I have minor edits turned off in Recent Changes.
The bug is this:
Suppose I see a page which has had one edit made to it. I click the "diff" link -- but what I see is the diff for a more recent minor edit, which was not listed in RC.
What I *should* see is either: a) the diffs of both edits, the major and the subsequent minor. b) the diff showing what the major edit added -- ie the "last" of the major edit. Of course, this leaves me in the dark about the more recent edit, and is somewhat misleading. this option is therefore less preferable IMO
Guillaume Blanchard wrote:
I'm very disappointed that decision maker don't believe we are smart enough to use anchor in the right way.
No, I don't think it's that. I for one cannot see a "right way" of using anchors. please give an example of a specific article which would be improved with anchors
On Tue, Mar 11, 2003 at 03:49:15PM +0000, tarquin wrote:
please give an example of a specific article which would be improved with anchors
Tarquin wrote:
please give an example of a specific article which would be improved with anchors
Any article which refers to other sections of itself would be so improved under the proposal to support only [[#bar]] and interpret == bar == as <h2><a name="bar">bar</h2> instead of <h2>bar</h2>.
Since the only example so far is from [[pl:]], which maybe you don't read, see [[Real number]] for another. (The references are in the section "The complete ordered field", to the sections Axioms and Completeness.) You might want to break up [[Real number]] (I'd break off the constructions), but you'd hardly break off Axioms and Completeness into separate articles. You might rewrite "The complete ordered field" to avoid the references, but there's no need to -- supporting [[#bar]] gives *options*.
-- Toby
On Tue, 11 Mar 2003 13:10:06 -0800, Toby Bartels toby+wikipedia@math.ucr.edu wrote:
Tarquin wrote:
please give an example of a specific article which would be improved with anchors
Any article which refers to other sections of itself would be so improved under the proposal to support only [[#bar]] and interpret == bar == as <h2><a name="bar">bar</h2> instead of <h2>bar</h2>.
While I support this idea for internal links, I'd say lets be forward looking and use the much simpler <H2 id="bar">bar</h2> - although bar should be a single word, since spaces are not allowed in fragment identifiers unless urlencoded. Using ID would not work in the zombie browser (Netscape 4), but NN4 is so bad that I frankly don't care about supporting it. The information wills till be there.
Any article which refers to other sections of itself would be so improved under the proposal to support only [[#bar]] and interpret == bar == as <h2><a name="bar">bar</h2> instead of <h2>bar</h2>.
There was less objection (and frankly, very little reason to object) to the original design of anchor links which simply made [[foo#bar]] behave exactly as expected. There was more objection to the syntax I chose for target anchors ([[##bar]]), and the idea of being able to use target anchors in the first place.
Some of those objections might be addressed by agreeing to not allow /arbitrary/ anchors, but make all H2s implicit anchors. So that, for example,
== This is a subhead ==
is rendered as
<a name="thisisasubhead"><h2>This is a subhead</h2></a>
That way, one can /only/ link internally to sections of an article that are already clearly marked as sections. Likewise, you could name a section "Endnotes" and use it for that purpose, and it would be clearly marked as such. There would be the slight annoyance that links would only point to the endnotes section as a whole, not to each individual note, though auto-numbering of links and lists might compensate for that a bit:
Darwin [[#endnotes]] believed that... ... == Endnotes == # ''Origin of Species'', Charles Darwin, 1875, pp 185..190.
would render as:
Darwin <a href="#endnotes">1</a> believed that... ... <a name="endnotes"><h2>Endnotes</h2><a> <ol> <li><em>Origin of Species</e>, ...
and so on.
On Tue, 11 Mar 2003 17:48:35 -0600, Lee Daniel Crocker lee@piclab.com wrote:
Any article which refers to other sections of itself would be so improved under the proposal to support only [[#bar]] and interpret == bar == as <h2><a name="bar">bar</h2> instead of <h2>bar</h2>.
There was less objection (and frankly, very little reason to object) to the original design of anchor links which simply made [[foo#bar]] behave exactly as expected. There was more objection to the syntax I chose for target anchors ([[##bar]]), and the idea of being able to use target anchors in the first place.
Some of those objections might be addressed by agreeing to not allow /arbitrary/ anchors, but make all H2s implicit anchors. So that, for example,
== This is a subhead ==
is rendered as
<a name="thisisasubhead"><h2>This is a subhead</h2></a>
An inline element (<a>) may not contain a block element (<h2>)
<a name="thisisasubhead"><h2>This is a subhead</h2></a>
An inline element (<a>) may not contain a block element (<h2>)
Yep, didn't check that. Make it
<h2><a name="thisisasubhead">This is a subhead</a></h2>
and otherwise the idea remains the same.
Lee Daniel Crocker wrote:
<a name="thisisasubhead"><h2>This is a subhead</h2></a>
An inline element (<a>) may not contain a block element (<h2>)
Yep, didn't check that. Make it
<h2><a name="thisisasubhead">This is a subhead</a></h2>
and otherwise the idea remains the same.
<h2><a name="thisisasubhead"></a>This is a subhead</h2>
Don't include the name in the <a>, I think that will could it acquire hovering properties (underlining, etc) which we don't want
Tarquin wrote:
Lee Daniel Crocker wrote:
<h2><a name="thisisasubhead">This is a subhead</a></h2>
<h2><a name="thisisasubhead"></a>This is a subhead</h2>
Don't include the name in the <a>, I think that will could it acquire hovering properties (underlining, etc) which we don't want
Which browsers do this? Is this more than just a guess? The reason that I ask is that W3C warns that
"User agents should be able to find anchors created by empty A elements, "but some fail to do so. -- http://www.w3.org/TR/1998/REC-html40-19980424/struct/links.html#h-12.2
So we could be between a rock and a hard space if both problems occur.
(OTOH, perhaps <h2>This is a subhead<a name="This_is_a_subhead"> </a></h2> will be a decent hack that works for everybody.)
And I do suggest recognising the spaces as we normally do in our URLs, to avoid confusing people by doing them differently.
-- Toby
On Wed, 12 Mar 2003 11:15:12 -0800, Toby Bartels toby+wikipedia@math.ucr.edu wrote:
Tarquin wrote:
Lee Daniel Crocker wrote:
<h2><a name="thisisasubhead">This is a subhead</a></h2>
<h2><a name="thisisasubhead"></a>This is a subhead</h2>
Don't include the name in the <a>, I think that will could it acquire hovering properties (underlining, etc) which we don't want
Which browsers do this? Is this more than just a guess?
Yes - all those which comply with the standards: Opera, Mozilla, and IIRC, IE5/Mac. Opera7, incidentally, is the first browser to fully comply with the standards and allow hover styling on all elements. However, it is also true
And I do suggest recognising the spaces as we normally do in our URLs, to avoid confusing people by doing them differently.
removing whitespace is NOT a matter of choice. What delimits the end of an URL? Whitespace.
So <A href="#The Middle"> and <a href="#The end"> ought both resolve to the same anchor: <a name="The"> There is a risk that they will match <A name="The beginning">. Some browsers do allow spaces at present, but it shouldn't be relied upon.
Finally, the name attribute is more or less deprecated in favour of "id". It doesn't appear at all by XHTML 1.1. As I mentioned previously, the only browser with any significant market share which doesn't support internal links to id is Netscape 4. Which I think we can live with. Netscape 4 users must surely be aware that many features of the modern web don't work for them.
On Thu, Mar 13, 2003 at 09:50:12AM +1300, Richard Grevers wrote:
removing whitespace is NOT a matter of choice. What delimits the end of an URL? Whitespace.
So <A href="#The Middle"> and <a href="#The end"> ought both resolve to the same anchor: <a name="The"> There is a risk that they will match <A name="The beginning">. Some browsers do allow spaces at present, but it shouldn't be relied upon.
Can't we just s/ /_/g as we usually do with URLs ?
Richard Grevers wrote:
Toby Bartels wrote:
Tarquin wrote:
Don't include the name in the <a>, I think that will could it acquire hovering properties (underlining, etc) which we don't want
Which browsers do this? Is this more than just a guess?
Yes - all those which comply with the standards: Opera, Mozilla, and IIRC, IE5/Mac. Opera7, incidentally, is the first browser to fully comply with the standards and allow hover styling on all elements. However, it is also true
Standards don't require underlining upon hovering for an <a> tag. They don't require anything; this is up to the browser to determine. (They do require the browser to listen if the <a> tag itself specifies some sort of behaviour like this, but ours won't.)
Are you remembering these browsers as underlining <a name> tags, or are you remembering them as being compliant with standards? I ask because IE5.1 for Mac OS X does not do anything with <a name> under default settings; I just checked.
In any case <h2>The header<a name="The_header"> </a></h2> will still work. This would be a good idea *anyway*, since people sometimes put links inside of a header, but you can't nest <a> tags.
And I do suggest recognising the spaces as we normally do in our URLs, to avoid confusing people by doing them differently.
removing whitespace is NOT a matter of choice. What delimits the end of an URL? Whitespace.
I don't think that you understood my suggestion. I suggest recognising the spaces *as*we*normally*do* in our URLs, which you can see in the example above (and in my last post): underscores. Thus, [[Main Page]] has the URL http://www.wikipedia.org/wiki/Main_Page, and [[#The header]] can have the (local) URL <#The_header>.
Finally, the name attribute is more or less deprecated in favour of "id". It doesn't appear at all by XHTML 1.1. As I mentioned previously, the only browser with any significant market share which doesn't support internal links to id is Netscape 4. Which I think we can live with. Netscape 4 users must surely be aware that many features of the modern web don't work for them.
"name" is not deprecated in HTML 4.01, which is what we use. It has another point over "id", which is that "id" can't include HTML character entities. This is not so significant, however, since we need to allow for an analogue of the pipe trick anyway, in case people put markup inside of a header (as sometimes happens). And Netscape 4 users will be fine as long as they're on the right page. All the same, there's no need to switch from "name" to "id" until we switch from HTML to XHTML, and "name" is slightly better for now.
-- Toby
tarquin wrote:
aaarg! anchors are bad.
if you need to drop into the middle of an article then you have two articles that ought to be split.
Absolutely. Thus we shouldn't support [[foo#bar]]. (These would be impossible to maintain anyway, since people would change the names of anchors in [[foo]]).
OTOH, if you need to move around in a single article, then this doesn't follow. Thus we could support [[#bar]]. (And maintenance would be confined to a single article's edits.)
could we drop it?
If there keep being people that want anchors, then apparently not. You may find the conclusion crystal-clear and flagrantly obvious, but others -- who have had this conversation with you before -- don't. So asking to drop it won't convince them (but might insult them).
-- Toby
wikitech-l@lists.wikimedia.org