It is my understanding that this was the consensus, so I have disabled
the "minor edit" checkbox for anonymous users. The reasoning here is
that an anon can never gain the trust necessary to have his edits
ignored by some users.
Note that the checkbox is simply not rendered, an anon can theoretically
still get an edit marked as minor with URL magic. I'll try to get to
that later.
Regards,
Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de
>But it should do it that way. <pre> is for raw code listings, and
>Wikipedia software should neither interpret anything inside it
>nor leave any HTML characters unescaped.
I disagree. <pre> is for preformatted text, not literal text. <nowiki> is
for literal text. <pre> + <nowiki> is for preformatted, literal text.
Otherwise you can't have [[...]]-style wiki links inside a <pre> block,
which is something people might want, among other things. <pre> in
Wikipedia should operate like <pre> in the rest of the world, if we want
usin' Wikipedia to be natural and inuitive, that is.
How else would you propose being able to do the equivalent of:
<pre>
<pre>
a preformatted
block of text is
looks quite like this
</pre>
</pre>
if <pre> operated as you suggest?
Derek
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
On Sunday 05 January 2003 04:00 am, brion vibber wrote:
> The obvious thing is to include the larger image in the image
> description page of the smaller image (and hence the click-through from
> articles containing the smaller image), and this is *exactly* what a
> number of people started doing when the image upload system was first
> put in place.
>
> For reasons still not clear to me, a number of prominent members of the
> Wikipedia community found this to be anathema and stamped out the
> practice.
That was LDC's call and I have just been following through on enforcing the
image policy he wrote (and which wasn't opposed to by anyone on the mailing
list BTW). At first I too wanted to place the larger image in the image
description page of the smaller image but LDC convinced me that this isn't a
good idea since it would cultivate an expectation in visitors that clicking
on an image will bring them to a page that has a larger version of the same
image when in fact most images in Wikipedia do not have larger versions at
all (then visitors soon wouldn't know what to expect). Enforcing this leaves
us with a more consistent situation: Image description pages are where the
descriptions and copyright info for the images are. If you want to have a
link to a larger version of the image then provide a media link in the
article itself.
I still am not too happy with the situation though since it flies in the face
of the webstandard that if you click on an image you are usually taken to a
larger version of that image.
It would be nice if this behavior were made to be a bit smarter: if an image
is displayed on the image description page of foo.jpg then mouse pointers
become little hands when over image foo.jpg in an article and clicking once
brings you to the image description page (this is the current behavior for
all images). But if there is no image displayed on the image description page
of foo.jpg ([[:image:foo.jpg]]) then mouse pointers would /not/ become little
hands when over displayed image foo.jpg and a person would have to click the
image twice to get to the image description page.
It would also be nice to have any text in [[:image:foo.jpg]] be displayed as
mouse over text whenever a mouse pointer is over the displayed foo.jpg (with
or without an image displayed [[:image:foo.jpg]]).
-- Daniel Mayer (aka mav)
Currently image pages only link to the actual image files they refer to.
You have to choose a revision from the history or follow the filename link
to view the image. This is problematic because it makes it hard to have
links like "Large version" in the articles without using the dreaded
external links. (Unless I am missing something, that is.)
I suggest an image page be structured like this:
Image
Caption
== Image history ==
..
== Image links ==
..
What do you think?
Regards,
Erik
Brion Vibber wrote:
>Sounds reasonable, send a diff and I'll see about it.
How do I "send a diff"? Do I just email you the text of the changes I
want, or post it to this list?
--
--------------------------------
| Sheldon Rampton
| Editor, PR Watch (www.prwatch.org)
| Author of books including:
| Friends In Deed: The Story of US-Nicaragua Sister Cities
| Toxic Sludge Is Good For You
| Mad Cow USA
| Trust Us, We're Experts
--------------------------------
Brion Vibber wrote:
>It's just crazy enough to sound interesting. :) Sufficiently free-form
>that it shouldn't be too hard to edit or too hard to figure out when you
>see one.
>
>The Wiktionary folks might be interested in something like this, too --
>I recommend you head over to wiktionary.org and see if you can get
>anyone's attention.
I spent a few minutes there but couldn't find anyplace that serves as
a venue for discussing things with anyone. There's no listserv and no
"metapedia" (metactionary?).
Also, I noticed a problem with the domain name. I get to Wiktionary
OK with the following URL:
http://wiktionary.org/
However, I get redirected to WIKIPEDIA if I enter the following:
http://www.wiktionary.org/
--
--------------------------------
| Sheldon Rampton
| Editor, PR Watch (www.prwatch.org)
| Author of books including:
| Friends In Deed: The Story of US-Nicaragua Sister Cities
| Toxic Sludge Is Good For You
| Mad Cow USA
| Trust Us, We're Experts
--------------------------------
Hi Erik Moeller and Members,
I did a search on "aural + CSS" in google and found that the W3C has a
working group on this subject, as of 2/2001, that 2 members had their own
implementations of a browser using aural CSS, and that IBM's Home Page Reader
is referred to as a aural CSS-enabled-wrapper for Internet Explorer 5. I
realize by the date that this is not as recent as one would hope, but there is
nothing newer on the subject.
Home Page Reader is available as a 30 day trial download from IBM (or was.)
The search also lead to a number of tutorials on aural CSS.
For W3C working group notes see:
http://www.openebook.org/members/ps/20010214.htm
As Ever,
Ruth Ifcher
--
> On Don, 2003-01-02 at 19:43, Richard Grevers wrote:
> > Proper, but in all practicality, pointless. I have done quite a bit of
> > testing of websites in various talking browsers. Most use the IE rendering
> > engine and simply read the text that ends up on screen. They are almost
> > totally dependent on punctuation, and don't respect breaks in HTML (even
> > list items or table cells). Thus the entire left-hand bar on Wikipedia
> > would be read as one long sentence - "Main page recent changes random page
> > current events" etc. None of them know anything about CSS.
>
> I've done a search a few months ago and found a couple that claimed to
> be aural CSS compliant. Can't find them again, though. This may be the
> Linux project you referred to: http://emacspeak.sourceforge.net/
>
> I don't know if these are actually used. But it seems to me that it's a
> better long-term plan to use these standards rather than to accomodate
> the idiosyncratic behavior of current speech browsers.
>
> I'd also like to get feedback from blind/disabled users on this.
>
> Regards,
>
> Erik
> --
> FOKUS - Fraunhofer Insitute for Open Communication Systems
> Project BerliOS - http://www.berlios.de
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikitech-l
With our current system it is fairly trivial to reset a user's password
against their will. We don't even check the interval in which the
password is requested. I suggest we use Scoop's system of password
mailing:
* When the user requests a password, check if he has requested one
within the last two hours or so
* If so, show error message
* If he hasn't, send the user a confirmation mail with an URL
* When the user clicks the URL, send the user the new password.
Anyone who disagrees with this proposal will get their password reset by
me 300 times ;-)
Regards,
Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de
Should we render links in Recentchanges? Many people are already using
them in their changelog comments. Disadvantage: RC might get slower,
esp. if we check for brokenness.
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de