subject: [Wikipedia-l] Year in music

body:
I didn't care for it from the beginning, especially since it seems to be solely dedicated to The Year in Rock Music, and all other genres are ignored.  Also, I don't like that he's predicting the future with "2003 in music", etc.
Zoe
 rose.parks at att.net wrote:Hi,

Having finally checked the Recent Changes last night and read some of
the "Year XXXX in music" articles, I agree with Mr. Manske. I think this is
not a good idea and foresee this followed by "Year XXXX in painting," "Year
XXXX in dance," "Year XXXX in literature."
Further, the articles are rather summary, listing publication of songs,
performers' highpoints, deaths etc.
I would think this information will be incorporated in Wikipedia in some
other form eventually, if it isn't already. For me. it is hard to find much
meaning in these entries, as events appear out of context. For this reason, I
think we should consider whether this is a good idea, before it goes much
further.

As Ever,

Ruth Ifcher

--

> Someone's creating articles like "1974 in music".Can't that just go
> under [[1974]]?
>
> Magnus
>
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikipedia-l

_______________________________________________
Wikipedia-l mailing list
Wikipedia-l at wikipedia.org
http://www.wikipedia.org/mailman/listinfo/wikipedia-l

---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20021225/33b9403a/attachment.htm


list: wikien-l

source: pipermail-mbox

from_name: Ray Saintonge

subject: [WikiEN-l] Proposal: make summary mandatory

body:
tarquin wrote:

> Pierre Abbat wrote:
>
>> On Tuesday 24 December 2002 16:53, Axel Boldt wrote:
>>
>>
>>> I would like to propose that we make filling out the summary field
>>> mandatory on ever edit.
>>>
> I forget sometimes.
> It wouldn't be wise to trust what an unknown IP writes in the summary
> -- any vandal could write "spelling correction" to fool us.

I like the summary line too, but I also often forget.  Making mandatory
entries could just as easily lead to people entering useless entries
like "comment" or a single random key stroke, just for the sake of
fulfilling the requirement.

Eclecticology


list: wikitech-l

from_name: Paul Ebermann

subject: [Wikitech-l] Re: Proposal: make summary mandatory

body:
"Giskart" skribis:

> Axel Boldt wrote:
> > I would like to propose that we make filling out the summary field
> > mandatory on ever edit. Reasons:
> >
> > * it makes the job of vandals and vandal bots harder, since they have
> > to come up with a meaningful summary each time.
> > * it makes the history page of an article vastly more useful; now I
> > often find myself employing the bisection method to find out when a
> > particular bit of information was inserted.
>
> Filling in the summary field is in general a good thing to do, but
> sometimes I find it stupid because the work it put in writing the notice
> for the summary field is more work than the change of the article.
>
> A pulldown menu whit some default comments seems a good way.

I use the auto-completion of my browser for
this task ...

So please allow the default comments to be
configured by the user, if you inclue them.

Paul


from_name: Brion Vibber

subject: [Wikitech-l] TeX

body:
On mer, 2002-12-25 at 13:36, Tomasz Wegrzanowski wrote:
> It seems it hasn't been commited to CVS and put on production Wikipedias yet.
>
> Brion, are there any problems with this diff ?

I haven't had a chance to look at it -- it's Winter Economic Frenzy
Holiday and I'm a little busy. :)

> I'd really like to have <math> available as soon as possible.

I'll try and get it set up today or tomorrow.

-- brion vibber (brion @ pobox.com)


from_name: tarquin

body:
version-to-version diff like on Meatball would be useful in working out
who did what.
(see it in action here:
http://wiki.beyondunreal.com/wiki?action=history&id=Door )

Pierre Abbat wrote:

>On Tuesday 24 December 2002 16:53, Axel Boldt wrote:
>
>
>>I would like to propose that we make filling out the summary field
>>mandatory on ever edit.
>>
I forget sometimes.
It wouldn't be wise to trust what an unknown IP writes in the summary --
any vandal could write "spelling correction" to fool us.


list: wikipedia-l

from_name: Nicholas Knight

subject: [Wikipedia-l] Year in music

body:
If you have knowledge of other genres of music, there's no reason you can't
add information on them at all. The disposition towards rock is merely
because that's what's currently being added, presumably because those working
on it know more about it than other subjects. If you have knowledge of jazz,
classical, whatever, there's no reason you can't be adding that information.

On Wednesday 25 December 2002 11:52 am, Zoe wrote:
> I didn't care for it from the beginning, especially since it seems to be
> solely dedicated to The Year in Rock Music, and all other genres are
> ignored.  Also, I don't like that he's predicting the future with "2003 in
> music", etc. Zoe


from_name: Sheldon Rampton

subject: [Wikitech-l] Re: A few questions

body:
Derek Moore wrote:

>Tehehe, me too, actually!  I was pretty impressed for wikitech-l when
>Sheldon appeared.  You's a pseudo-celebrity amongst radicals, Sheldon.

Great! Does that mean I get groupies? ;)

Wikipedia is a natural place for me to show up. For one thing, I've
always been a bit of a computer hacker. (I founded the computer club
at my high school and got suspended from school once for hacking into
a university computer so I could learn COBOL.) Also, my last book
with John Stauber was titled "Trust Us, We're Experts: How Industry
Manipulates Science and Gambles With Your Future." We did a lot of
writing and thinking about the scientific method and the influence of
funding on research outcomes, and also about the nature and
limitations of academic peer review. I recently adapted part of
"Trust Us" for a medical journal, and when they asked me to offer
solutions for some of the problems that we posed, the best answers I
could come up with were: (1) better standards of disclosure regarding
funding and other possible conflicts of interest related to published
research; and (2) maintaining and expanding an "information commons"
in which research results are treated as public property and kept
freely available to everyone. One of the big problems for the
integrity of research these days is that corporate-sponsored research
tends to produce proprietary knowledge, which inhibits full
publication of data, methodology and other information. Companies
have good reasons from their point of view for not wanting to release
discoveries that they have paid for and from which they hope to
profit. However, there have been cases where companies have
deliberately suppressed data showing that their products are unsafe
or ineffective. Even where this sort of misconduct isn't occurring,
restrictions on proprietary information present a barrier to full
vetting and sharing of research results.

Believe it or not, I actually thought I was coming up with a new idea
when I first used the term "information commons." I was familiar with
the concept of open source software, but I hadn't really given the
concept much attention other than to think it might be nice if the
same approach could be adapted to things other than computer
software. Then last month I attended a conference in Amsterdam where
I heard about Wikipedia for the first time and thought, "Damn! These
people are already doing it!"
--
--------------------------------
|  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
--------------------------------


from_name: Magnus Manske

body:
tarquin wrote:

>>> I would like to propose that we make filling out the summary field
>>> mandatory on ever edit.
>>>
> It wouldn't be wise to trust what an unknown IP writes in the summary
> -- any vandal could write "spelling correction" to fool us.

In fact, most of the newbie experiments and "mini-vandals" I found due
to an empty subject line...

Magnus


from_name: rose.parks at att.net

subject: [Wikipedia-l] Year in music

body:
Hi,

     Having finally checked the Recent Changes last night and read some of
the "Year XXXX in music" articles, I agree with Mr. Manske. I think this is
not a good idea and foresee this followed by "Year XXXX in painting," "Year
XXXX in dance," "Year XXXX in literature."
     Further, the articles are rather summary, listing publication of songs,
performers' highpoints, deaths etc.
     I would think this information will be incorporated in Wikipedia in some
other form eventually, if it isn't already. For me. it is hard to find much
meaning in these entries, as events appear out of context. For this reason, I
think we should consider whether this is a good idea, before it goes much
further.

                         As Ever,

                            Ruth Ifcher

--

> Someone's creating articles like "1974 in music".Can't that just go
> under [[1974]]?
>
> Magnus
> <http://www.wikipedia.org/wiki/1974_in_music>
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikipedia-l


from_name: Tom Parmenter

in_reply_to:
<3E09DC00.7020102@epost.de> (message from Magnus Manske on Wed,
	25 Dec 2002 17:25:36 +0100)

body:
Rule or no rule, an empty summary field is bad manners.

You can always cut and paste something from your change.  The
statement that writing a summary can be more onerous than making the
change is ludicrous.

Tom Parmenter
Ortolan88


subject: [Wikipedia-l] Year in music

body:
I see nothing wrong with the "the year in music 1981" entries.  Most of
what goes there would not go in a "1981" entry.  It would be fine to
link Joan Jett's "I love rock and roll" from the rock and roll anthem
page to the year in music, but I don't think you'd link it to 1981.

Nor do I see anything wrong with having parallel entries for "the year
in dance", "the year in books" or whatever anyone might want to put
together.

Like the regular year entries, they are sketchy now, but I see no
reason that the year in music (pottery, anthropology) shouldn't start
with a brief essay on the overall year.

For instance, "the year in music 1966" might say that the Beatles had
six songs in the top ten (whatever it was) but the most popular song
of the year was "The Ballad of the Green Berets".  There's an awful
lot of social history flowing together in "the year in music 1966".

Tom Parmenter
Ortolan88

|From: rose.parks at att.net
|X-Authenticated-Sender: cm9zZS5wYXJrc0BhdHQubmV0
|Sender: wikipedia-l-admin at wikipedia.org
|Reply-To: wikipedia-l at wikipedia.org
|Date: Wed, 25 Dec 2002 17:37:04 +0000
|
|Hi,
|
|     Having finally checked the Recent Changes last night and read some of
|the "Year XXXX in music" articles, I agree with Mr. Manske. I think this is
|not a good idea and foresee this followed by "Year XXXX in painting," "Year
|XXXX in dance," "Year XXXX in literature."
|     Further, the articles are rather summary, listing publication of songs,
|performers' highpoints, deaths etc.
|     I would think this information will be incorporated in Wikipedia in some
|other form eventually, if it isn't already. For me. it is hard to find much
|meaning in these entries, as events appear out of context. For this reason, I
|think we should consider whether this is a good idea, before it goes much
|further.
|
|                         As Ever,
|
|                            Ruth Ifcher
|
|--
|
|> Someone's creating articles like "1974 in music".Can't that just go
|> under [[1974]]?
|>
|> Magnus
|> <http://www.wikipedia.org/wiki/1974_in_music>
|>
|


from_name: Fred Bauder

subject: [Wikipedia-l] Year in music

references:
<20021225173704.NDRM9286.mtiwmhc11.worldnet.att.net@mtiwebc18>
 (rose.parks@att.net)
 <20021225173704.NDRM9286.mtiwmhc11.worldnet.att.net@mtiwebc18>

body:
>I see nothing wrong with the "the year in music 1981" entries.  Most of
>what goes there would not go in a "1981" entry.  It would be fine to
>link Joan Jett's "I love rock and roll" from the rock and roll anthem
>page to the year in music, but I don't think you'd link it to 1981.
>
>Nor do I see anything wrong with having parallel entries for "the year
>in dance", "the year in books" or whatever anyone might want to put
>together.

I agree. I'm busy putting the year in books pages on my own website. By the
time you go through the bestsellers for a year, important books that
weren't best sellers, link to authors bios and website, you have a pretty
intereresting page that includes a lot of detail that would just clutter up
a year page.

Fred


from_name: Jonathan Walther

subject: [Wikitech-l] mod_rewrite configuration

body:
On Wed, Dec 25, 2002 at 07:47:30PM -0600, Derek Moore wrote:
>Check this out:
>
>http://www.wikipedia.org//
>
>I typo'd that earlier.  Check it out.  I'm sure the above is a fairly
>common typo, so somebody might wanna fix the mod_rewrite rules to allow for
>it.

Speaking of which, I got my Wikipedia configuration ironed out; here it
is for anyone who is interested.  Brion, could something like this be
incoroporated into the INSTALL file?  In mod_wiki I would like to alter
the design such that direct access to php or other scripts can be
abolished.  That may require using POST for everything, and Javascript.
The handling of the "&" character throws gum in the works.

I had to "touch" the logfile before the Wikipedia software would run.

httpd.conf:

Alias /mywiki-style          /usr/src/newcodebase/stylesheets
Alias /mywiki-upload         /usr/src/newcodebase/images
Alias /mywiki-wiki.phtml     /usr/src/newcodebase/wiki.phtml
Alias /mywiki-redirect.phtml /usr/src/newcodebase/redirect.phtml
RewriteEngine On
RewriteRule ^/mywiki$        /usr/src/newcodebase/wiki.phtml?title=
RewriteRule ^/mywiki/(.*)$   /usr/src/newcodebase/wiki.phtml?title=$1

LocalSettings.php:

$wgServer          = "http://reactor-core.org";
$wgStyleSheetPath  = "$wgServer/mywiki-style";
$wgScript          = "/mywiki-wiki.phtml";
$wgRedirectScript  = "/mywiki-redirect.phtml";
$wgArticlePath     = "$wgServer/mywiki/$1";
$wgUploadPath      = "http://reactor-core.org/mywiki-upload";
$wgUploadDirectory = "/usr/src/newcodebase/images";
$wgLogo            = "$wgUploadPath/wiki.png";
$wgDebugLogFile    = "$wgUploadDirectory/logfile";

I hope this helps someone!

Jonathan

--
                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw at reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20021225/e65fe04f/attachment.pgp>


from_name: Derek Moore

subject: [Wikitech-l] mod_rewrite configuration

body:
Check this out:

http://www.wikipedia.org//

I typo'd that earlier.  Check it out.  I'm sure the above is a fairly common
typo, so somebody might wanna fix the mod_rewrite rules to allow for it.

Peace out,

Derek

_________________________________________________________________
The new MSN 8: smart spam protection and 3 months FREE*.
http://join.msn.com/?page=features/junkmail&xAPID=42&PS=47575&PI=7324&DI=7474&SU=
http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_smartspamprotection_3mf


subject: [Wikitech-l] mod_rewrite configuration

body:
> On Wed, Dec 25, 2002 at 07:47:30PM -0600, Derek Moore wrote:
> >Check this out:
> >
> >http://www.wikipedia.org//
> >
> >I typo'd that earlier.  Check it out.  I'm sure the above is a fairly
> >common typo, so somebody might wanna fix the mod_rewrite rules to allow for
> >it.

I'll tweak the rewrite rules later; in the meantime I've replaced the
classic Apache welcome page with a nice simple redirect-to-main-wiki-
page.

On mer, 2002-12-25 at 18:55, Jonathan Walther wrote:
> Speaking of which, I got my Wikipedia configuration ironed out; here it
> is for anyone who is interested.  Brion, could something like this be
> incoroporated into the INSTALL file?  In mod_wiki I would like to alter
> the design such that direct access to php or other scripts can be
> abolished.  That may require using POST for everything, and Javascript.
> The handling of the "&" character throws gum in the works.

Should be straightforward -- just use %26 wherever it represents content
and & where it's a magic query string component separator:

http://foobar/wiki/Beeswax_%26_Honey
http://foobar/wiki/Beeswax_%26_Honey?action=edit
http://foobar/wiki/Special:Whatlinkshere?target=Beeswax_%26_Honey&limit=500

The URL-building functions may need tweaking to know to use the question
mark to start building a query string. (And remember Apache's
mod-rewrite de-URL-encodes the path components before you get to them;
that's why we use a patched ampescape function to re-encode the
ampersands in titles being moved from the path to the query string.)

> I had to "touch" the logfile before the Wikipedia software would run.

Check the ownerhsip/permissions on your upload directory. If it can't
create the log file, you may not be able to upload files either. The dir
should be writable by the webserver's process.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Year in music

body:
Whoever 216.234.195.244
<http://www.wikipedia.org/w/wiki.phtml?title=Special:Contributions&target=216.234.195.244>
is (from around Fort Worth), (s)he is adding births and deaths to these
pages, which should be on the year page.

We can
1. Move all contents to the year pages and redirect
2. block the user (I don't want that, but how to get his/her attention?)

Magnus

Zoe wrote:

> I didn't care for it from the beginning, especially since it seems to
> be solely dedicated to The Year in Rock Music, and all other genres
> are ignored.  Also, I don't like that he's predicting the future with
> "2003 in music", etc.
>
> Zoe
>
>  */rose.parks at att.net/* wrote:
>
>     Hi,
>
>     Having finally checked the Recent Changes last night and read some of
>     the "Year XXXX in music" articles, I agree with Mr. Manske. I
>     think this is
>     not a good idea and foresee this followed by "Year XXXX in
>     painting," "Year
>     XXXX in dance," "Year XXXX in literature."
>     Further, the articles are rather summary, listing publication of
>     songs,
>     performers' highpoints, deaths etc.
>     I would think this information will be incorporated in Wikipedia
>     in some
>     other form eventually, if it isn't already. For me. it is hard to
>     find much
>     meaning in these entries, as events appear out of context. For
>     this reason, I
>     think we should consider whether this is a good idea, before it
>     goes much
>     further.
>
>     As Ever,
>
>     Ruth Ifcher
>
>     --
>
>     > Someone's creating articles like "1974 in music".Can't that just go
>     > under [[1974]]?
>     >
>     > Ma! gnus
>     >
>     >
>     > _______________________________________________
>     > Wikipedia-l mailing list
>     > Wikipedia-l at wikipedia.org
>     > http://www.wikipedia.org/mailman/listinfo/wikipedia-l
>
>     _______________________________________________
>     Wikipedia-l mailing list
>     Wikipedia-l at wikipedia.org
>     http://www.wikipedia.org/mailman/listinfo/wikipedia-l
>
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Mail Plus
> <http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com> -
> Powerful. Affordable. Sign up now
> <http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com>


from_name: Tomasz Wegrzanowski

subject: [Wikitech-l] TeX

body:
On Mon, Dec 23, 2002 at 02:21:24AM +0100, Tomasz Wegrzanowski wrote:
> On Sun, Dec 22, 2002 at 12:56:26PM -0800, Brion Vibber wrote:
> > On Sun, 2002-12-22 at 12:32, Tomasz Wegrzanowski wrote:
> > > texvc is done, testing found no bugs.
> > >
> > > Please install it on all production Wikipedias.
> >
> > Can you put it into CVS or send a diff?
> >
> > I don't want to just copy the test.wikipedia.org files since that's got
> > other not-fully-tested code in it.
>
> Here it is. Patch against most recent CVS.

It seems it hasn't been commited to CVS and put on production Wikipedias yet.

Brion, are there any problems with this diff ?

I'd really like to have <math> available as soon as possible.


subject: [Wikitech-l] mod_rewrite configuration

body:
On Wed, Dec 25, 2002 at 08:39:44PM -0800, Brion Vibber wrote:
>Should be straightforward -- just use %26 wherever it represents content
>and & where it's a magic query string component separator:
>
>http://foobar/wiki/Beeswax_%26_Honey
>http://foobar/wiki/Beeswax_%26_Honey?action=edit
>http://foobar/wiki/Special:Whatlinkshere?target=Beeswax_%26_Honey&limit=500

Actually, Brion, because mod_wiki is a module in it's own right, the
URL can be in any format we like; it doesn't need to be ?foo=bar&x=y
format.  In fact, I had no intention of going through mod_rewrite at
all.  My intention was that you could tell mod_wiki to handle all URL's
that start with a certain prefix.  Because of this, the Apache module
could be distributed separately, without patching Apache at all.

Like so:

<Location /w>
    SetHandler mod-wiki-handler
</Location>

>mark to start building a query string. (And remember Apache's
>mod-rewrite de-URL-encodes the path components before you get to them;

Maybe we could use an alternate minilanguage.  For instance, I'm also
thinking that the namespace should be a variable instead of a part of
the title:

http://foo/w/Whatlinkshere

Then the following would get passed in as POST data:

namespace=Special&target=A%26W+Root+Beer&limit=500

It would be nice to keep compatibility with mod_rewrite though.

How about the following?

http://foo/w/Whatlinkshere#ns=Special&target=A%26W+Root+Beer&limit=500

I also would like language to be a variable, so the URL would become:

http://foo/w/Whatlinkshere#ns=Special&lang=en&target=A%26W+Root+Beer&limit=50

Any objections?  You did tell me earlier that the # character was not
allowed in page titles, and is mod_rewrite likely to escape it?  With
mod_wiki, mod_rewrite shouldn't be needed, but one never knows when one
will want to redirect one URL to another.

>Check the ownerhsip/permissions on your upload directory. If it can't
>create the log file, you may not be able to upload files either. The dir
>should be writable by the webserver's process.

Ah. Thanks for the tip.  I changed the permissions after I tried to do
my first upload, so upload has been working.

Jonathan

--
                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw at reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20021225/067544c9/attachment.pgp>


from_name: Zoe

subject: [Wikipedia-l] Tallini and his 5th World nonsense

body:
Please see http://groups.msn.com/FifthWorld/the5w.msnw, which Tallini linked to from [[Micronation]].  He has an anti-Wikipedia bias that makes no sense, and it's time that he stop whatever it is he's doing and explain just what is going on.

Zoe

---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20021225/d5bbdf27/attachment.htm


subject: [Wikitech-l] mod_rewrite configuration

body:
On mer, 2002-12-25 at 22:51, Jonathan Walther wrote:
> On Wed, Dec 25, 2002 at 08:39:44PM -0800, Brion Vibber wrote:
> >Should be straightforward -- just use %26 wherever it represents content
> >and & where it's a magic query string component separator:
> >
> >http://foobar/wiki/Beeswax_%26_Honey
> >http://foobar/wiki/Beeswax_%26_Honey?action=edit
> >http://foobar/wiki/Special:Whatlinkshere?target=Beeswax_%26_Honey&limit=500
>
> Actually, Brion, because mod_wiki is a module in it's own right, the
> URL can be in any format we like; it doesn't need to be ?foo=bar&x=y
> format.

The backend implementation is not relevant. By using mod_rewrite, the
URL can be in any format we like with the PHP system. But that's no
excuse for making URLs long, confusing, and fragile.

> Maybe we could use an alternate minilanguage.  For instance, I'm also
> thinking that the namespace should be a variable instead of a part of
> the title:
>
> http://foo/w/Whatlinkshere
>
> Then the following would get passed in as POST data:
> namespace=Special&target=A%26W+Root+Beer&limit=500

That, I think, would be annoying, as you couldn't bookmark it or send
someone a URL without digging through backroom docs for the magic
incantation.

> How about the following?
>
> http://foo/w/Whatlinkshere#ns=Special&target=A%26W+Root+Beer&limit=500

Standard URL syntax provides for a query string (starting with "?"), we
shouldn't be afraid to use it. Overloading the anchor syntax (starting
with "#") isn't a good idea, as I believe it won't be sent to the http
server, and is intended to be interpreted by the browser (and would
break the asked-by-some ability to actually use anchors in pages).
Technically you could use the hex-code for #, but that's fragile.
(Somebody's going to try to type it, and it won't work.)

> I also would like language to be a variable, so the URL would become:
>
> http://foo/w/Whatlinkshere#ns=Special&lang=en&target=A%26W+Root+Beer&limit=50

I'd prefer:
http://foo/en/Special:Whatlinkshere?target=A%26W+Root+Beer&limit=50

or, knowing that many special pages operate explicitly on a target, one
could rearrange, folding most of them back into the already existing
"action" sequence:

http://foo/en/A&W_Root_Beer?action=whatlinkshere&limit=50
http://foo/en/User:Billybob?action=contributions

Or even yet, we could take advantage of the path syntax, as long as
special pages are never named with slashes:

http://foo/en/Special:Whatlinkshere/A&W_Root_Beer?limit=50
http://foo/en/Special:Contributions/Billybob

This has the advantage also of preserving ampersand functionality;
ampersands aren't special in the _path_ portion of a URL, so if someone
types them in raw it's okay, whereas it will generally break if someone
puts in a raw ampersand when constructing a query string.

Remember, URLs should be human-readable and human-rememberable if
possible; people *will* try to muck about with them manually. They
*will* e-mail URLs to friends and colleagues. They *will* print them and
send them to other people who will have to type them in. They *will* try
to speak them over the phone. Non-ascii characters and special
punctuation marks can be a pain for this, alas, but we should minimize
the trouble we make in the basic syntax.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Year in music

body:
He's back with another, similar IP. Now [[2003]] already contains:

    * [[2003 in film]]
    * [[2003 in literature]]
    * [[2003 in music]]
    * [[2003 in sports]]
    * [[2003 in television]]

IMHO this is *way* too far out.

I left him a note at Talk:List of musical events
<http://www.wikipedia.org/wiki/Talk:List_of_musical_events>, lacking a
better place. Someone please make him stop, before we have to clean up
all year entries again.

Magnus

Zoe wrote:

> I didn't care for it from the beginning, especially since it seems to
> be solely dedicated to The Year in Rock Music, and all other genres
> are ignored.  Also, I don't like that he's predicting the future with
> "2003 in music", etc.
>
> Zoe
>
>  */rose.parks at att.net/* wrote:
>
>     Hi,
>
>     Having finally checked the Recent Changes last night and read some of
>     the "Year XXXX in music" articles, I agree with Mr. Manske. I
>     think this is
>     not a good idea and foresee this followed by "Year XXXX in
>     painting," "Year
>     XXXX in dance," "Year XXXX in literature."
>     Further, the articles are rather summary, listing publication of
>     songs,
>     performers' highpoints, deaths etc.
>     I would think this information will be incorporated in Wikipedia
>     in some
>     other form eventually, if it isn't already. For me. it is hard to
>     find much
>     meaning in these entries, as events appear out of context. For
>     this reason, I
>     think we should consider whether this is a good idea, before it
>     goes much
>     further.
>
>     As Ever,
>
>     Ruth Ifcher
>
>     --
>
>     > Someone's creating articles like "1974 in music".Can't that just go
>     > under [[1974]]?
>     >
>     > Ma! gnus
>     >
>     >
>     > _______________________________________________
>     > Wikipedia-l mailing list
>     > Wikipedia-l at wikipedia.org
>     > http://www.wikipedia.org/mailman/listinfo/wikipedia-l
>
>     _______________________________________________
>     Wikipedia-l mailing list
>     Wikipedia-l at wikipedia.org
>     http://www.wikipedia.org/mailman/listinfo/wikipedia-l
>
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Mail Plus
> <http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com> -
> Powerful. Affordable. Sign up now
> <http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com>


subject: [Wikipedia-l] Wiktionary moved to wiktionary.org domain

body:
Wiktionary is now moved to its own domain at http://wiktionary.org ,
thanks to maveric149's generous donation! Note that Wiktionary users
will have to re-login to transfer their login cookies to the new domain.

(Note that mav still technically owns the domain as the non-profit is
not set up yet, but has authorized its use for the project in the
meantime.)

(If anyone has trouble accessing the new URL, your local DNS server may
be behind on catching up to updates. It should clear up in a day or two
max.)

Happy non-denominational winter holiday or festivity or nice, normal day
to all!

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] mod_rewrite configuration

body:
On Wed, Dec 25, 2002 at 11:32:50PM -0800, Brion Vibber wrote:
>The backend implementation is not relevant. By using mod_rewrite, the
>URL can be in any format we like with the PHP system. But that's no
>excuse for making URLs long, confusing, and fragile.

True.  What I meant was that by bypassing mod_rewrite, we might no
longer need a special patch for Apache?

>> http://foo/w/Whatlinkshere#ns=Special&target=A%26W+Root+Beer&limit=500
>
>Standard URL syntax provides for a query string (starting with "?"), we
>shouldn't be afraid to use it.

Ok.  Let's say I have an article "Who Killed JFK?" and I want to view
the articles history.  I want to type in the URL, and I can't remember
the hex code for '?'.  What do I do?  Just require people to use the hex
code anyway for cases where the ? is part of the article title?

http://foo/w/Who_Killed_JFK??action=history&limit=10

Also, I'm not clear; what "escaping" does mod_rewrite do?  How does it
determine whether to escape the ? and & or not?  When does it do the
escaping?

So, if I put in the following URL:

http://foo/w/Who_Killed_JFK%3F?action=history

Will mod_rewrite change the second ? to a %3F if I rewrite the URL
somehow?  Will it transform the %3F to a ? if I rewrite the URL somehow?

>I'd prefer:
>http://foo/en/Special:Whatlinkshere?target=A%26W+Root+Beer&limit=50

That's fair enough; do you have a page already written up giving your
reasons for wanting languages to be part of a hierarchy, but not
namespaces?

>or, knowing that many special pages operate explicitly on a target, one
>could rearrange, folding most of them back into the already existing
>"action" sequence:
>
>http://foo/en/A&W_Root_Beer?action=whatlinkshere&limit=50
>http://foo/en/User:Billybob?action=contributions

I heartily approve and endorse that idea.  If noone objects, I will
implement it that way in mod_wiki

>Or even yet, we could take advantage of the path syntax, as long as
>special pages are never named with slashes:
>
>http://foo/en/Special:Whatlinkshere/A&W_Root_Beer?limit=50
>http://foo/en/Special:Contributions/Billybob

I'm having difficulty understanding; could you show me what manglement
would happen under other schemes, that doesn't happen under this one?

>Remember, URLs should be human-readable and human-rememberable if
>possible; people *will* try to muck about with them manually. They
>*will* e-mail URLs to friends and colleagues. They *will* print them and
>send them to other people who will have to type them in. They *will* try
>to speak them over the phone. Non-ascii characters and special
>punctuation marks can be a pain for this, alas, but we should minimize
>the trouble we make in the basic syntax.

I think we are on the same page; I concur with everything you said in
that previous paragraph.

Jonathan

--
                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw at reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20021226/b7518461/attachment.pgp>


subject: [Wikitech-l] mod_rewrite configuration

body:
On ?a?, 2002-12-26 at 00:33, Jonathan Walther wrote:
> On Wed, Dec 25, 2002 at 11:32:50PM -0800, Brion Vibber wrote:
> >The backend implementation is not relevant. By using mod_rewrite, the
> >URL can be in any format we like with the PHP system. But that's no
> >excuse for making URLs long, confusing, and fragile.
>
> True.  What I meant was that by bypassing mod_rewrite, we might no
> longer need a special patch for Apache?

Sure.

> >> http://foo/w/Whatlinkshere#ns=Special&target=A%26W+Root+Beer&limit=500
> >
> >Standard URL syntax provides for a query string (starting with "?"), we
> >shouldn't be afraid to use it.
>
> Ok.  Let's say I have an article "Who Killed JFK?" and I want to view
> the articles history.  I want to type in the URL, and I can't remember
> the hex code for '?'.  What do I do?  Just require people to use the hex
> code anyway for cases where the ? is part of the article title?
>
> http://foo/w/Who_Killed_JFK??action=history&limit=10

See RFC 2396, which defines the structure of URIs.
http://www.ietf.org/rfc/rfc2396.txt

That would break up as:
(scheme)(authority)(path)(query)
(http)(foo)(/w/Who_Killed_JFK)(?action=history&limit=10)

(Technically the question mark is "reserved" in the contents of a query
string, and I'm not sure it's allowed except as the separator from the
path.)

Question mark is simply *not* a valid URL _path_ character, there's
nothing we can do about that that doesn't flaunt standards and break
things, any more than we can decide we want a domain name with a slash
or a colon in it. ;)

> Also, I'm not clear; what "escaping" does mod_rewrite do?  How does it
> determine whether to escape the ? and & or not?  When does it do the
> escaping?

Before Apache gives the path to mod_rewrite, Apache has already
normalized escaped (I should say URL-encoded; %26 etc) characters. So a
path of "/wiki/A%26W_soda" comes to our mod_rewrite rules as
"/wiki/A&W_soda". If we take it and put it raw into a query string:
"title=A&W_soda", no good because that will break into "title=A" and
"W_soda" when PHP interprets the query. That's why we add an explicit
escaping for that character.

> So, if I put in the following URL:
>
> http://foo/w/Who_Killed_JFK%3F?action=history
>
> Will mod_rewrite change the second ? to a %3F if I rewrite the URL
> somehow?  Will it transform the %3F to a ? if I rewrite the URL somehow?

The second ? is interpreted as a separator between path and query before
rewriting comes up.

By default if you create a new query string via a rewrite rule it wipes
out any existing query string completely, replacing it. There's an
option [QSA] to append instead; I haven't yet checked to see if it adds
an ampersand separator or if that needs to be tweaked further.

> >I'd prefer:
> >http://foo/en/Special:Whatlinkshere?target=A%26W+Root+Beer&limit=50
>
> That's fair enough; do you have a page already written up giving your
> reasons for wanting languages to be part of a hierarchy, but not
> namespaces?

Our namespaces aren't really hierarchical: Talk:, User:, User_talk:
etc... We have a flat namespace of namespaces. ;)

> >Or even yet, we could take advantage of the path syntax, as long as
> >special pages are never named with slashes:
> >
> >http://foo/en/Special:Whatlinkshere/A&W_Root_Beer?limit=50
> >http://foo/en/Special:Contributions/Billybob
>
> I'm having difficulty understanding; could you show me what manglement
> would happen under other schemes, that doesn't happen under this one?

Somebody types:
http://foo/en/Special:Whatlinkshere?target=A&W_Root_Beer

they get:

(http)(foo)(/en/Special:Whatlinkshere)((target=A)(W_Root_Beer))

Thus they see links to the page [[A]]. Question marks remain problematic
in the other case, of course. You can't win. ;)

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] mod_rewrite configuration

body:
On Thu, Dec 26, 2002 at 01:23:23AM -0800, Brion Vibber wrote:
>Our namespaces aren't really hierarchical: Talk:, User:, User_talk:
>etc... We have a flat namespace of namespaces. ;)

Didn't someone have the idea that "Talk" pages shouldn't be separate
namespaces, but just a boolean flag?

And when I mentioned hierarchical, what I mean was are there any
objections to having namespace as a component of the path, like so:

http://foo/en/Special/Whatlinkshere?target=A%26W_Root_Beer&limit=50

That is just to illustrate what I meant by namespaces being
hierarchical, I agree with you that something along the following lines
is superior for the particular example above:

http://foo/en/Global/A&W_Root_Beer?action=whatlinkshere&limit=50

Hm. I see a potential problem; no way to gracefully ellide the "Global"
namespace for the default case.  Maybe /en/g/ for the global namespace?
What the heck, why change it from what we use in the Wikipedia links;
law of least surprise says don't change if we don't have to.

But then we should do languages the same way.

http://foo/en:Global:A&W_Root_Beer
http://foo/en::A&W_Root_Beer
http://foo/en:A&W_Root_Beer

Should we support one of the above, or none of them?

Jonathan

--
                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw at reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20021226/f889d465/attachment.pgp>


subject: [Wikitech-l] Re: A few questions

body:
>>>One other way to get the functionality would be to implement HTML anchors
>>>in wiki syntax. That way you could link to [[George W. Bush#people]] to
>>>get to the specific article section. You could also implement page
>>>templates to get a default structure for articles.
>
>>Are HTML anchors currently implemented in wiki syntax?
>
>HTML anchors are not yet implemented, but this is a project I'd be willing
>to tackle. We just need a nifty syntax.

Actually, there really shouldn't need to be any special syntax for anchors.
98% of the time, you'd want an anchor at your headings and nothing more
(well, maybe at your media, too).  That should be as simple as modifying the
wiki syntax parser.  For headings, if the heading was "External links" the
anchor's name could be something like "#external_links" or "#External_links"
or "#External links"...  What do you think, should anchor names be
lower()'d?  Should their spaces be translated to '_' and their punctuation
ignored?  I tend to think "yes" to both questions.  Media embedded in
articles could also probably benefit from anchors.  Again, no need for
additional syntax--it ought to be automagic.  Anchor names for media could
just be the media's filename.

<plug>By the way, for those interested in new and improved wiki syntaxes,
check out Wikitax:
    <http://meta.wikipedia.org/wiki/Wikitax>
    <http://meta.wikipedia.org/wiki/Talk:Wikitax>
Erik, Tomasz, and Nemo have contributed some excellent ideas to the syntax
so far, and everybody else interested is encouraged to do the same.  I,
personally, tend to think the wiki syntax could use plenty of revamping.  If
you tend to think so, too, stop on by and add your ideas, etc.</plug>

Peace out,

Derek

_________________________________________________________________
MSN 8 with e-mail virus protection service: 3 months FREE*.
http://join.msn.com/?page=features/virus&xAPID=42&PS=47575&PI=7324&DI=7474&SU=
http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_eliminateviruses_3mf


from_name: Erik Moeller

subject: [Wikitech-l] mod_rewrite configuration

body:
> On Wed, Dec 25, 2002 at 07:47:30PM -0600, Derek Moore wrote:
>> Check this out:
>>
>> http://www.wikipedia.org//
>>
>> I typo'd that earlier.  Check it out.  I'm sure the above is a fairly
>> common typo, so somebody might wanna fix the mod_rewrite rules to allow for
>> it.

> Speaking of which, I got my Wikipedia configuration ironed out; here it
> is for anyone who is interested.  Brion, could something like this be
> incoroporated into the INSTALL file?

Have you considered applying for developer status? It's fairly easy to get
and makes fixing things much easier.

Regards,

Erik


subject: [Wikitech-l] Re: A few questions

body:
Sheldon,

I presume the conference where you heard about Wikipedia was the World-
InfoCon. If so, did you by any chance hear about it on day two from Volker
Grassmuck? He's a friend of mine, and a couple of weeks before the con he
called me and asked me about cool projects in the area of collaborative
journalism and peer-to-peer networks. I told him about Wikipedia, and he
promised to bring it up at the conference. If that's where you heard about
it, I can take at least some small credit for you being here now :-)

> I'm assuming that you've seen the PR Watch web site. We have a fair
> amount of material there, including archives of PR Watch dating back
> almost to its founding, plus our "Spin of the Day" feature (which
> typically includes 10-15 new items each week).

I knew about the news items, but I didn't know Impropaganda Review. Very
good resource. The advantage of a Disinfopedia is, of course, that as a
collaborative/interactive project, it would attract more attention and
could quickly become a central meeting point for people interested in the
subject.

> Once I have the wiki software tweaked and functioning the way I want,
> I'll seed the Disinfopedia with our existing articles from the
> Impropaganda Review plus some other similar information, and offer it
> under the GNU General Public License. At some future point, we may
> choose to do the same thing with other parts of our web site.

As Derek pointed out, the GPL may not be the best choice, as it was
written for software and contains many software-specific clauses. The GNU
Free Documentation License (FDL) is more specifically tailored towards
documents, and that's why the Wikipedia project uses it. It would also
make Disinfopedia articles compatible with Wikipedia (license
compatibility is a big issue).

See
http://www.wikipedia.org/wiki/Wikipedia%3ACopyrights
for details.

Of course you could also be really hip and use the brand new open content
license generator by the Creative Commons Project:

http://www.creativecommons.org/

Caveat, though, as such a license *may* render Disinfopedia content
incompatible with Wikipedia.

> I've already made a few minor contributions to the "real" Wikipedia,
> and I plan to continue doing so. You've touched here on one of the
> questions that I've been wondering about: Should we set up a separate
> "Disinfopedia," or just use the "real" Wikipedia as a repository for
> the knowledge base I'm trying to develop?

I think a Disinfopedia is just fine, for the reasons you mentioned. NPOV
allows people with vastly different views to work together, but it also
means that an article about, say, the Cato Institute will include glowing
comments from libertarians. Wikipedia doesn't "care" much if these
statements are correct or wrong, only if they are attributed to their
adherents. This may not be what you want if you need to refer people to a
quick summary of the facts. Also, articles are more likely to be
completely rewritten, making them less reliable as a reference.

On the other hand, many articles, such as the Global warming article,
would benefit greatly from a more detailed discussion of the PR wars
surrounding the subjects in question. This needs not be done by you if the
Disinfopedia license is compatible with the Wikipedia license.

> Perhaps the thing to do would be to simply have ONE additional
> namespace, titled "relationships" (plus, of course,
> "relationships_talk"). At the bottom of an article on "George W.
> Bush," there would be a link to an article on Bush's "Relationships
> to People, Organizations, Funders, etc." Assuming the article hasn't
> yet been created, the URL would read:
> http://www.disinfopedia.org/wiki.phtml?title=Relationships:George_W._Bush&ac
> tion=edit

In that case, I would be in favor of ditching the idea altogether, as the
relationship stuff could just as well be embedded into the main articles.
As you say:

> Yet another possibility would be to forego extra namespaces
> altogether, and simply post prominent guidelines explaining the kind
> of structure we're envisioning. I would hope that people would TRY to
> follow our recommended structure, but it would be okay if they
> sometimes deviate from it.

This is one of the problems we are currently facing with the brand new
Wiktionary spin-off project:

http://wiktionary.wikipedia.org/

Dictionary articles are much more structured, and keeping that structure
somewhat consistent has been fairly difficult, owing in large part to the
fact that we have pretty much defined it as we went along with the
project. Make sure you define any policies before you launch, and to
prominently link to them on the editing page.

Regarding templates, you nailed it: They would probably be best namespace-
dependant. Create a new article, and you get the standard article
template. Create a new talk page, you get an empty page. If you use more
namespaces, you can use more templates. But remember that for any new
namespace you have, linking gets more difficult.

Alternatively, you could do all sorts of javascripty stuff on the edit
page (buttons to insert standard text blocks), but I think this would be
too browser-dependant.

>> One other way to get the functionality would be to implement HTML anchors
>> in wiki syntax. That way you could link to [[George W. Bush#people]] to
>> get to the specific article section. You could also implement page
>> templates to get a default structure for articles.

> Are HTML anchors currently implemented in wiki syntax?

HTML anchors are not yet implemented, but this is a project I'd be willing
to tackle. We just need a nifty syntax.

> And what about the idea of creating "pseudo-namespaces"? What I'm
> envisioning here is a way of object-typing prospective articles so
> that page templates could be customized according to object type. For
> example, [[person:George W. Bush]] might create a template with
> sections such as date of birth, career highlights, etc., whereas
> [[organization:Cato Institute]] might create a template with sections
> such as personnel, funders, publications. Has there been much
> discussion about ways of integrating Wiki's free-form approach with
> XML-style object-typing and data-structuring?

Not really, also because we don't really need that much default
structuring on Wikipedia (although having consistent names and style for
links, bibliography etc. would help). Do I understand you correctly when I
assume that when you want a link like [[person:George W. Bush]], you want
to later be able to link to this page by just using [[George W. Bush]],
but use the "person" prefix during page creation to choose a proper
template? In that case, the question would arise what would happen to this
qualifier after the page has been created.

If you want more templates without more namespaces, you could also insert
an extra step during page creation:

        Choose a template

        Person
                This template contains the following ..
        Company
                ...
        ...

Since page creation is not as common as page editing, I think the extra
step wouldn't be too high a price to pay. As an added bonus, you could
alter the table structure of cur, old etc. to store the template class
just in case you want to evaluate it for anything else.

>> PS: "Toxic Sludge is Good for You" should really be available as a GNU FDL
>> e-book. We need to get this book into schools :-)

> Personally, I'd be interested in seeing this happen, but "Toxic
> Sludge" was published by a commercial press, and I don't know how
> they'd feel about releasing it into GNU space.

You could propose a deal, like asking for donations on the ebook page (I
could send you some data that supports the donation model) and giving the
publisher a certain percentage of those donations. You would probably have
a stronger case once the book is out of print, but there's virtually no
data that suggests free online availability would lead to a decline in
print sales -- rather the opposite. See, for example:

http://www.baen.com/library/palaver6.htm
http://www.baen.com/library/palaver7.htm

Try to think like a PR drone -- how can you sell this idea to a publisher?
;-)

> On a related tack, I've been toying with the idea of writing my NEXT
> book as an open source project from start to finish. We would begin
> by posting a chapter outline and letting anyone edit, contribute and
> annotate while we write. Do you think this would work? Would it be
> possible to publish the book commercially and get it into bookstores
> if the writing process took place within a GNU framework? Would the
> GNU license be necessary to attract collaborators?

Yes, I think it would work, but you need to do a lot of editing to keep
the thing consistent. Be sure to name some volunteers as copyeditors to
maintain this consistence. Also, wikis typically evolve a non-linear
structure -- if you want to avoid this, start with a linear skeleton and
discourage the creation of too many new pages.

If the book is profitable, you are sure to get inquiries from contributors
about the distribution of profits. Most agreeable would probably be a
solution where any and all profits are donated to a single charity agreed
upon by all participants.

The GNU license is not necessary and there are others, but I see no reason
not to use it, since it works.

There are some publishers who might be interested in such an undertaking.
O'Reilly has published a few open content books, and not everything
O'Reilly publishes is computing-related, although some connection to the
world of computing and the Net would help to get them interested. Baen
Books provides many books for free download (not open content), but I
think they only do fiction.

Publishing on demand only costs the author a few hundred dollars and
guarantees a virtually unlimited supply (no further charge per book).
Personally I think this would be the most interesting option, but it is
also the most radical. Prices and quality vary greatly here, but it's not
hard to find reviews and I'm sure there are attractive options.

There's also traditional self-publishing. You may wish to read the article
"Adventures in Self-Publishing" on Kuro5hin and possibly contact the
author:

http://www.kuro5hin.org/story/2002/4/12/223216/520

K5 is another highly interesting collaborative writing / discussion site,
BTW, with articles and comments being voted on by readers. Now if you
really want to do something revolutionary, you could transform the PR
Watch website into a combination of a Scoop-powered collaborative weblog
and a Wikipedia-based wiki. :-) It's this combination of weblogs and wikis
that I'm highly interested in; one of my pet projects is to implement a
wiki as part of the Scoop engine that K5 uses.

All best,

Erik


subject: [Wikitech-l] Re: A few questions

body:
Erik Moeller wrote:

>I presume the conference where you heard about Wikipedia was the World-
>InfoCon. If so, did you by any chance hear about it on day two from Volker
>Grassmuck? He's a friend of mine, and a couple of weeks before the con he
>called me and asked me about cool projects in the area of collaborative
>journalism and peer-to-peer networks. I told him about Wikipedia, and he
>promised to bring it up at the conference. If that's where you heard about
>it, I can take at least some small credit for you being here now :-)

You're right, it was at the World-InfoCon, from Volker Grassmuck.
Actually, though, several speakers at the conference talked about
Wikipedia.

>HTML anchors are not yet implemented, but this is a project I'd be willing
>to tackle. We just need a nifty syntax.

How about just including them with section headers? For example, take
the following line of wiki syntax:

=== Geography and Climate ===

Right now this produces the following HTML:

<h3> Geography and Climate </h3>

It shouldn't take a lot of work to make the same wiki syntax produce
the following HTML:

<a name="Geography_and_Climate"><h3> Geography and Climate </h3>

This implementation would only make it possible to insert HTML
anchors at the beginning of section headers, but that should cover
most of the places where people might want to have them. Then to
create a hyperlink to the "Geography and Climate" section of the
"Russia" article, you'd simply use the following syntax:

[[Russia#Geography and Climate]]

>Do I understand you correctly when I
>assume that when you want a link like [[person:George W. Bush]], you want
>to later be able to link to this page by just using [[George W. Bush]],
>but use the "person" prefix during page creation to choose a proper
>template? In that case, the question would arise what would happen to this
>qualifier after the page has been created.

Yes, that's true. The specifics of my proposed implementation are
half-baked. The broader concept, though, is the idea of being able to
object-type articles as a way of imposing some kind of structure.
Maybe this is just fundamentally antithetical to the free-form nature
of Wikipedia, but I see that someone else is thinking along rather
similar lines with the proposal for a "Slotipedia."
--
--------------------------------
|  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
--------------------------------


body:
Zoe wrote:

> Please see http://groups.msn.com/FifthWorld/the5w.msnw, which Tallini
> linked to from [[Micronation]].  He has an anti-Wikipedia bias that
> makes no sense, and it's time that he stop whatever it is he's doing
> and explain just what is going on.
>
"The following entry didn't make into to "Wicked-pedia".

Oooooh! Ouch!
Let's start an "Enemies of Wikipedia" page
;-)*
*


subject: [Wikitech-l] TeX

body:
On dim, 2002-12-22 at 17:21, Tomasz Wegrzanowski wrote:
> Here it is. Patch against most recent CVS.

I've added it to CVS, updated the install docs, added patch-math.sql to
the patch-list.txt, and put test.wikipedia.org on the new CVS version
(plus a slight patch for the InnoDB tables; taw and magnus, I put
innodb.diff into the source dir there for reference in case you change
the running stuff again.)

Quick question before I go installing this: if I set "Leave it as TeX
(for text browsers)", I get HTML-rendered tables and things, not raw
TeX. Is it doing the wrong thing, or is the option mislabeled?

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] TeX

body:
On Thu, Dec 26, 2002 at 01:41:58PM -0800, Brion Vibber wrote:
> On dim, 2002-12-22 at 17:21, Tomasz Wegrzanowski wrote:
> > Here it is. Patch against most recent CVS.
>
> I've added it to CVS, updated the install docs, added patch-math.sql to
> the patch-list.txt, and put test.wikipedia.org on the new CVS version
> (plus a slight patch for the InnoDB tables; taw and magnus, I put
> innodb.diff into the source dir there for reference in case you change
> the running stuff again.)
>
> Quick question before I go installing this: if I set "Leave it as TeX
> (for text browsers)", I get HTML-rendered tables and things, not raw
> TeX. Is it doing the wrong thing, or is the option mislabeled?

There were 3 options first (PNG, HTML, TeX), and 4 later (PNG,
conservative HTML, liberal HTML, TeX).
Are you sure you have right version of Language*.php ?
If it's too old label TeX would mean liberal HTML.


subject: [Wikitech-l] TeX

body:
Tomasz Wegrzanowski wrote:

>Are you sure you have right version of Language*.php ?
>
I might accidentially have overwritten Language.php at the test site
while working on the improved Recent Changes. Sorry.

Magnus


subject: [Wikitech-l] Re: A few questions

body:
> How about just including them with section headers? For example, take
> the following line of wiki syntax:

That seems to make sense. I'll give it a try and post an update.

> Yes, that's true. The specifics of my proposed implementation are
> half-baked. The broader concept, though, is the idea of being able to
> object-type articles as a way of imposing some kind of structure.
> Maybe this is just fundamentally antithetical to the free-form nature
> of Wikipedia, but I see that someone else is thinking along rather
> similar lines with the proposal for a "Slotipedia."

It's a reasonable feature to support, the question is whether it can be
done in an easy to use and consistent fashion.

Regards,

Erik


from_name: daniwo59 at aol.com

subject: [WikiEN-l] Re: Proposal: make summary mandatory

body:
What about requiring an edit summary for major edits, and not requiring one
if the minor edit box is checked?

Danny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20021227/af76654c/attachment.htm


from_name: Toby Bartels

subject: [Wikitech-l] TeX

body:
Tomasz Wegrzanowski wrote:

>texvc is done, testing found no bugs.
>Please install it on all production Wikipedias.

*Please* don't.

texvc is full of problems; here are the two primary ones:

1: A simple equation like <math>x + y = z</math> looks ugly
   (uglier than ordinary wiki markup with or witout italics)
   under any user preference -- and simply wrong under the default.

This is primarily because Tomasz has neglected
to implement TeX's spacing algorithm
in the HTML version of the texvc rendering.
Sure, he could now go and programme it.
But why bother when Don Knuth already did?
Which brings us to primary problem 2:

2: The entire philosophy of texvc is wrong from start to finish.

I intended to write an essay on texvc and how it *should* work
on MetaWikipedia -- where such an essay belongs --
once I got back online (today or later in the weekend),
although I didn't know (until reading my email just now)
that I would have this impending deadline to delay its implementation.
I'll try to get it done today (not just sometime this weekend).

In the meantime, I think that installing texvc
wouldn't simply fail to solve our math formatting problems
but would actually make things worse.
Math formatting isn't a pressing issue,
but in the end we will certainly want it.
We should do it right.  texvc is not right.
And it's so much off from right, in fact,
that it will be harder to make things right later
if people start using it now.  (Details in my essay.)

-- Toby


body:
Axel Boldt wrote in part:

>* it makes the job of vandals and vandal bots harder, since they have
>to come up with a meaningful summary each time.

No, they don't -- unless you know of an algorithm
that we can used to detect whether a summary is meaningful.
UseModWiki's "*" default isn't empty, after all --
and "mispeeling" must always work, so they can just use that
(and look like long-time users that know the inside jokes
while they're at it).

>* it makes the history page of an article vastly more useful; now I
>often find myself employing the bisection method to find out when a
>particular bit of information was inserted.

How about when I just write "Much." in the summary?

-- Toby


body:
|From: Daniel Mayer <maveric149 at yahoo.com>
|Sender: wikien-l-admin at wikipedia.org
|Reply-To: wikien-l at wikipedia.org
|Date: Sat, 28 Dec 2002 01:06:28 -0800
|
|On Thursday 26 December 2002 04:00 am, Tom Parmenter wrote:
|> Rule or no rule, an empty summary field is bad manners.
|>
|> You can always cut and paste something from your change.  The
|> statement that writing a summary can be more onerous than making the
|> change is ludicrous.
|>
|> Tom Parmenter
|> Ortolan88
|
|Not when fixing formatting. Having to fill-in an edit summary would
|significantly slow me down so I definitely would object to having to perform
|the needless keystrokes for these mundane changes. However, when I do make an
|edit worth documenting I do so nearly every time and if anything I over
|document. This should stay a 'rule to consider' for at least logged-in users.

If you are slowed down by typing "markup fixes" I suggest drinking
coffee.  If the fixes are mundane, that's what I put in, and usually
make the change Minor.

If the changes are more substantive, I usually take the opportunity to
explain what I am doing "alternate form of article title bolded", or
"album titles in italics, songs in quotes" so that they will appear in
Recent Changes and perhaps pass along the knowledge to someone else.

Rule or no rule, an empty summary statement is bad manners.  The
statement that writing a summary can be more onerous than making the
change is ludicrous.

Tom Parmenter
Ortolan88

|
|It would be OK by me if this was a requirement for non-logged-in users (along
|with taking-away their ability to mark edits as minor). Anything to slow the
|rate of useless experiment page creation AND give non-logged-in users another
|reason to log-in or at least use the preview function is a good thing.
|
|-- Daniel Mayer (aka mav)
|
|WikiKarma payment. Have you had your Wiki today?
|http://www.wikipedia.org/wiki/Herb_Ritts (new)
|
|_______________________________________________
|WikiEN-l mailing list
|WikiEN-l at wikipedia.org
|http://www.wikipedia.org/mailman/listinfo/wikien-l
|


from_name: Pierre Abbat

body:
On Saturday 28 December 2002 04:06, Daniel Mayer wrote:
> Not when fixing formatting. Having to fill-in an edit summary would
> significantly slow me down so I definitely would object to having to
> perform the needless keystrokes for these mundane changes. However, when I
> do make an edit worth documenting I do so nearly every time and if anything
> I over document. This should stay a 'rule to consider' for at least
> logged-in users.

When I fix a typo, I usually put an edit summary that just says "sp". If I
ever make a change and don't put a summary, it's a mistake and the software
should not allow it.

phma


subject: [Wikipedia-l] Wikipedia is down

body:
When I go to www.wikipedia.org, I get the following error messages:

Database error


from_name: Jimmy Wales

subject: [Wikipedia-l] Wikipedia is down

in_reply_to: <1041018035.4036.25.camel@rdaneel.vibber.org>; from brion@pobox.com on Fri, Dec 27, 2002 at 11:40:34AM -0800

body:
Actually, credit goes to Jason for this one.

Brion Vibber wrote:

> On ven, 2002-12-27 at 11:30, Zoe wrote:
> > Database error
> > From Wikipedia, the free encyclopedia.
> > A database query syntax error has occurred. This could be because of an illegal search query (see Searching Wikipedia), or it may indicate a bug in the software. The last attempted database query was: SELECT HIGH_PRIORITY cur_id FROM cur WHERE cur_namespace=0 AND cur_title='Main_Page'
> > from within function "LinkCache::addLink". MySQL returned error "1016: Can't open file: 'cur.MYD'. (errno: 145)".
>
> Jimbo has gotten the server back up; I'm running a check on the database
> tables now.
>
> -- brion vibber (brion @ pobox.com)
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikipedia-l


from_name: Brion Vibber

subject: [Wikipedia-l] Wikipedia is down

body:
On ven, 2002-12-27 at 11:30, Zoe wrote:
> Database error
> From Wikipedia, the free encyclopedia.
> A database query syntax error has occurred. This could be because of an illegal search query (see Searching Wikipedia), or it may indicate a bug in the software. The last attempted database query was: SELECT HIGH_PRIORITY cur_id FROM cur WHERE cur_namespace=0 AND cur_title='Main_Page'
> from within function "LinkCache::addLink". MySQL returned error "1016: Can't open file: 'cur.MYD'. (errno: 145)".

Jimbo has gotten the server back up; I'm running a check on the database
tables now.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Wikipedia is down

body:
But I'm still getting the database error.
Zoe
 Jimmy Wales <jwales at bomis.com> wrote:Actually, credit goes to Jason for this one.

Brion Vibber wrote:

> On ven, 2002-12-27 at 11:30, Zoe wrote:
> > Database error
> > From Wikipedia, the free encyclopedia.
> > A database query syntax error has occurred. This could be because of an illegal search query (see Searching Wikipedia), or it may indicate a bug in the software. The last attempted database query was: SELECT HIGH_PRIORITY cur_id FROM cur WHERE cur_namespace=0 AND cur_title='Main_Page'
> > from within function "LinkCache::addLink". MySQL returned error "1016: Can't open file: 'cur.MYD'. (errno: 145)".
>
> Jimbo has gotten the server back up; I'm running a check on the database
> tables now.
>
> -- brion vibber (brion @ pobox.com)
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikipedia-l
_______________________________________________
Wikipedia-l mailing list
Wikipedia-l at wikipedia.org
http://www.wikipedia.org/mailman/listinfo/wikipedia-l

---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20021227/b2c77ead/attachment.htm


subject: [Wikipedia-l] Wikipedia is down

body:
Ah, now I'm getting the "please wait" message.  Thanks, guys.
Zoe
 Zoe <zoecomnena at yahoo.com> wrote:
But I'm still getting the database error.
Zoe
 Jimmy Wales <jwales at bomis.com> wrote: Actually, credit goes to Jason for this one.

Brion Vibber wrote:

> On ven, 2002-12-27 at 11:30, Zoe wrote:
> > Database error
> > From Wikipedia, the free encyclopedia.
> > A database query syntax error has occurred. This could be because of an illegal search query (see Searching Wikipedia), or it may indicate a bug in the software. The last attempted database query was: SELECT HIGH_PRIORITY cur_id FROM cur WHERE cur_namespace=0 AND cur_title='Main_Page'
> > from within function "LinkCache::addLink". MySQL returned error "1016: Can't open file: 'cur.MYD'. (errno: 145)".
>
> Jimbo has gotten the server back up; I'm running a check on the database
> tables now.
>
> -- brion vibber (brion @ pobox.com)
>
> _______________________________________________
> Wikipedia-l mailing list
> ! Wikipedia-l at wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikipedia-l
_______________________________________________
Wikipedia-l mailing list
Wikipedia-l at wikipedia.org
http://www.wikipedia.org/mailman/listinfo/wikipedia-l

---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now

---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20021227/2248de04/attachment.htm


subject: [Wikipedia-l] Wikipedia is down

body:
On ven, 2002-12-27 at 11:38, Jimmy Wales wrote:
> Actually, credit goes to Jason for this one.

You all start with J, I can't tell you apart. ;)

The check on the English wikipedia will run for a bit longer (the table
was left in a funny state when the server crashed, and MySQL refuses to
read it until it's fixed, hence Zoe's error message); those who just
can't wait until then, try out Meta-Wikipedia or Wiktionary, which are
up:

  http://meta.wikipedia.org
  http://wiktionary.org

The other language wikipedias are also all up except for French, which
I'll run the table check/repair on next.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Wikipedia is down

body:
On ven, 2002-12-27 at 11:53, Zoe wrote:
>
> Ah, now I'm getting the "please wait" message.  Thanks, guys.

Update: the tables are repaired, and I'm now running a backup dump of
the database. Should be done within 30-45 minutes.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Wikipedia is down

body:
Wikipedia is up.

-- brion vibber (brion @ pobox.com)


from_name: Axel Boldt

subject: [Wikitech-l] TeX

body:
--- Erik Moeller <erik_moeller at gmx.de> wrote:
> > No. I'm not going to implement that and I'm strongly against such
> > feature. http://test.wikipedia.org/wiki/Why_we_can't_just_use_LaTeX
>
> I tend to agree here, let's stick with the current solution until we
> find a problem we cannot solve otherwise. This addition was primarily
> intended for mathematics,

Well, if so, it might have been a good idea to involve more of the
people who are actually active in Wikipedia's math area. Right now,
Toby and I have both stated that we are not too fond of the texvc
approach.

> Do we really *want* people to draw
> diagrams etc. in LaTeX? Or shouldn't they just upload them as images?

Or why not upload formulas as images, and be done with the whole
debate?

No, people should definitely be able to create math formulas, chess
diagrams, chemical structure diagrams, music scores and flow charts in
LaTeX, because that's the wiki way: these graphics can then be modified
by directly editing the source code, while uploaded images can only be
redrawn from scratch or pixel edited. Granted, the TeX syntax is often
obscure, but change a little bit here, preview, change a bit there,
preview, and you figure it out. And unlike texvc, it's widely used and
there are tutorials all over the place.

Arguably, the GFDL requires that if I create a graphic with some
scriptable software such as gnuplot, latex, ChemSketch or gimp, I am
required to make available the modifiable source code used to produce
the picture. Legalities aside, it is always a good idea to do so; what
better way than to simply upload *only* the source code and let
Wikipedia deal with the compilation and presentation.

> it's just gibberish, and I'm afraid people might start using it as a
> replacement for things that are currently not supported by our wiki-
> syntax. One of these things is a powerful table and image layout
> syntax.

Image layout and table support is currently available on Wikipedia with
HTML syntax, simpler and more powerful than TeX's gibberish table
support. I don't see how this makes an argument against TeX. What other
examples did you have in mind?

Axel

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


body:
|From: Toby Bartels <toby+wikipedia at math.ucr.edu>
|Content-Disposition: inline
|Sender: wikien-l-admin at wikipedia.org
|Reply-To: wikien-l at wikipedia.org
|Date: Fri, 27 Dec 2002 09:40:39 -0800
|
|Axel Boldt wrote in part:
|
|>* it makes the job of vandals and vandal bots harder, since they have
|>to come up with a meaningful summary each time.
|
|No, they don't -- unless you know of an algorithm
|that we can used to detect whether a summary is meaningful.
|UseModWiki's "*" default isn't empty, after all --
|and "mispeeling" must always work, so they can just use that
|(and look like long-time users that know the inside jokes
|while they're at it).
|
|>* it makes the history page of an article vastly more useful; now I
|>often find myself employing the bisection method to find out when a
|>particular bit of information was inserted.
|
|How about when I just write "Much." in the summary?
|

How about spending five seconds and twenty keystrokes putting in what
you did?

Tom P.
O88

|
|-- Toby
|_______________________________________________
|WikiEN-l mailing list
|WikiEN-l at wikipedia.org
|http://www.wikipedia.org/mailman/listinfo/wikien-l
|


from_name: Daniel Mayer

subject: [WikiEN-l] Re: Make summaries mandatory

body:
>What about requiring an edit summary
>for major edits, and not requiring
>one if the minor edit box is checked?
>
>Danny

Unless there is a byte counter married with the diff
that would only encourage people to mark moderate and
major edits as minor. Vera Cruz already marks all
edits as minor and this is *VERY* annoying.

--Daniel Mayer (aka mav)

WikiKarma Payment. Have you had your Wiki today?
http://www.wikipedia.org/w/wiki.phtml?title=Cartography&diff=0&oldid=540169

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


subject: [Wikitech-l] TeX

body:
>Toby Bartels is a troll and I'm not going to listen any more to what he
>says.

But he may have some valid criticisms that could only make texvc better.
Although he seems to be a bit fundamentalist about what texvc should allow
in his comments on the TeX testing pages; e.g., "...we really don't need TeX
support inline, it should probably not be supported inline. ... Wikipedia's
math should stick to English letters in boldface and italic whenever
possible, for the widest readability, with exceptions only for things (like
[pi]) that are universally rendered in other fonts."

Aside from that, my own observations are this:

1) Fonts seem to be over anti-aliased.  '+', '-', and '=' signs are all
blury, when they should be distinct, straight lines.

2) Fonts seem to be over weighted, i.e., everything looks somewhat bold.

3) Inline math doesn't feel very readable.  PlanetMath's inline equations
feel a bit more readable than texvc's.

Of course, these are rather non-technical criticisms of texvc's font
rendering.  I'd suggest employing whatever font rendering defaults that
PlanetMath is using, as their equations feel much more readable and much
less ugly.

Also, what about <math> ... </math> conflicting with MathML?  If people
employ MathML in an article, does texvc check between the <math> ... </math>
tags to see whether it's MathML or TeX?  Instead of overloading standard
tags, maybe it should be <tex> ... </tex>, and then just let people know
that Wikipedia only supports a subset of TeX for math purposes only.  In any
case, that would make parsing of pages faster, as the "Is this MathML or
TeX?" logic could be thrown out.  The price of that logic may be trivial
now, but what about when Wikipedia is serving hundreds of thousands of pages
a day?  Plus it would make all the texvc input forward-compatible if it's
decided someday that fuller TeX support is needed and that <tex> ... </tex>
tags should be used.

Just my thoughts...

Okay, I'm done now,

Derek

_________________________________________________________________
MSN 8 limited-time offer: Join now and get 3 months FREE*.
http://join.msn.com/?page=dept/dialup&xAPID=42&PS=47575&PI=7324&DI=7474&SU=
http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_newmsn8ishere_3mf


body:
--- daniwo59 at aol.com wrote:
> What about requiring an edit summary for major edits, and not
> requiring one if the minor edit box is checked?

Combine this with not allowing anonymous users to declare minor edits,
and you can count me in.

Axel

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


from_name: Jens Frank

subject: [Wikitech-l] wikipedia down?

body:
Hi,

is wikipedia.org down? I don't get any pages for the last half hour.

Symptoms:
- When telneting to ports 80 or 22, connection is established, but
  no response is sent by wikipedia. This is interesting in the
  case of port 22 since SSHD should send its version string
  before the client sends its version string.

- No response even after 5 minutes waiting.
  => No DNS timeout based problem.

Assumption:
- Out of Memory?
- Fork bombed?

Could someone have a look at it?

	Best regards,

		jens frank

-


subject: [Wikitech-l] TeX

body: Toby Bartels is a troll and I'm not going to listen any more to what he says.


subject: [Wikitech-l] TeX

body:
On Fri, Dec 27, 2002 at 04:26:19PM -0600, Derek Moore wrote:
> Aside from that, my own observations are this:
>
> 1) Fonts seem to be over anti-aliased.  '+', '-', and '=' signs are all
> blury, when they should be distinct, straight lines.
>
> 2) Fonts seem to be over weighted, i.e., everything looks somewhat bold.

These are all pretty much ghostscripts' defaults.
We could experiment with font size (texvc uses 120, some people think even
smaller would look better, but I'm not sure if it would be so on larger
displays too).

> 3) Inline math doesn't feel very readable.  PlanetMath's inline equations
> feel a bit more readable than texvc's.

On default settings texvc has concept of "conservativeness" level.
If math is simple it renders it in properly-italicized HTML, otherwise
it renders it in PNG. In practice most of inline equations will be
rendered in HTML, and most of displayed equations in PNG, so it
will look more or less right. This is most that can be done without
analyzing context where math appears.

> Also, what about <math> ... </math> conflicting with MathML?  If people
> employ MathML in an article, does texvc check between the <math> ...
> </math> tags to see whether it's MathML or TeX?  Instead of overloading
> standard tags, maybe it should be <tex> ... </tex>, and then just let
> people know that Wikipedia only supports a subset of TeX for math purposes
> only.

MathML isn't supposed to be written by humans, so I don't see a problem here.
If some new markup was added, <math> could be extended to alternative markups,
like: <math type="mathml"><mrow>some scary equation</mrow></math>.

> In any case, that would make parsing of pages faster, as the "Is
> this MathML or TeX?" logic could be thrown out.  The price of that logic
> may be trivial now, but what about when Wikipedia is serving hundreds of
> thousands of pages a day?  Plus it would make all the texvc input
> forward-compatible if it's decided someday that fuller TeX support is
> needed and that <tex> ... </tex> tags should be used.

Computation costs would be really negligible. Checking whether something
is MathML or TeX is probably 4 or 5 orders of magnitude less resource-sensitive
than the rest of things we do to render page.


body:
On Thursday 26 December 2002 04:00 am, Tom Parmenter wrote:
> Rule or no rule, an empty summary field is bad manners.
>
> You can always cut and paste something from your change.  The
> statement that writing a summary can be more onerous than making the
> change is ludicrous.
>
> Tom Parmenter
> Ortolan88

Not when fixing formatting. Having to fill-in an edit summary would
significantly slow me down so I definitely would object to having to perform
the needless keystrokes for these mundane changes. However, when I do make an
edit worth documenting I do so nearly every time and if anything I over
document. This should stay a 'rule to consider' for at least logged-in users.

It would be OK by me if this was a requirement for non-logged-in users (along
with taking-away their ability to mark edits as minor). Anything to slow the
rate of useless experiment page creation AND give non-logged-in users another
reason to log-in or at least use the preview function is a good thing.

-- Daniel Mayer (aka mav)

WikiKarma payment. Have you had your Wiki today?
http://www.wikipedia.org/wiki/Herb_Ritts (new)


body:
> -+- daniwo59 at aol.com wrote:
>> What about requiring an edit summary for major edits, and not
>> requiring one if the minor edit box is checked?

> Combine this with not allowing anonymous users to declare minor edits,
> and you can count me in.

With which we are back at my original proposal :->

Regards,

Erik


subject: [Wikitech-l] TeX

body:
> Well, if so, it might have been a good idea to involve more of the
> people who are actually active in Wikipedia's math area. Right now,
> Toby and I have both stated that we are not too fond of the texvc
> approach.

I can understand that - after all, you are familiar with TeX and you want
to use its maximum power. But from a Wikipedia-wide perspective, we have
to keep other factors in mind.

> No, people should definitely be able to create math formulas, chess
> diagrams, chemical structure diagrams, music scores and flow charts in
> LaTeX, because that's the wiki way: these graphics can then be modified
> by directly editing the source code

I know LaTeX and I use it for all my written correspondence. That means
that I also know how unreadable it can get, even if you have the 500 page
Kopka introduction or something similar near your desk. It's possible to
do great things with LaTeX, but then, why not have a Python backend with
some drawing library, or maybe a POV-Ray backend as well ..

Instead of arbitrarily providing such functionality, we should, for all
different types of problems, think carefully what the best tool for the
job is. In Maths, TeX/LaTeX is very popular, so it may well be the best
tool for the job here. But for music, maybe the recently mentioned GNU
Lilypond would be better and easier to learn/use? Basic diagrams might be
best handled in SVG or something like that, for plots a gnuplot backend
might be nice. And so forth, and so on. Aside from the usability
advantage, you also get the geek factor of being able to play with many
different toys.

If we do not do this, we force people who want to participate in the wiki
process to learn tools that may be suboptimal, even though there may be
better and more popular tools for that specific job. From a usability
perspective, that's a bad idea. By limiting initially the scope of TeX
use, we avoid this usability trap. If it turns out that the music people
prefer TeX to Lilypond, we'll send some hired goons to Tomasz and persuade
him to include support for the necessary markup in texvc ;-). etc.

> Image layout and table support is currently available on Wikipedia with
> HTML syntax

Yes, but this is suboptimal because only a relatively small subset of
Wikipedia users knows HTML, and for those who don't, the HTML syntax is
unnecessarily complex. (We also get lots of different table styles because
some HTML wizards love to experiment.) That's why we use the wiki syntax
instead of HTMl all over the place. But tables are tricky, therefore we
haven't implemented them yet (some good proposals exist).

Regards,

Erik


subject: [WikiEN-l] Wikipedia:Shared resources

body:
Expanding an idea by fonzy, I have created a skeleton for Wikipedians to
organize the sharing of information from proprietary resources. See

http://www.wikipedia.org/wiki/Wikipedia%3AShared_resources

The current text that is there:

This page is a reference for Wikipedians in need of certain proprietary
information resources (encyclopedias, CD-ROM archives, expensive books
etc.). The page has a section of resources that are offered and one of
resources that are wanted. These sections are separated into subsections
for specific resource types.

Feel free to offer any type of resource, but please understand that this
page is not intended to facilitate copyright violation -- "shared
resource" implies that you are willing to make use of that resource for
someone else, in your own time. Please provide as much detail as possible
about:

    * version of the resource
    * storage form of the resource (paper, CD-ROM, online archive etc.)

It is assumed that these resources are available to you for free or that
you are willing to cover any costs. Users should note that these shared
usage offers, unless otherwise noted, are only valid for Wikipedia
purposes.

Please add your own resources in the appropriate section.

.. some content follows ..

Regards,

Erik


from_name: tarquin

body:
  Daniel Mayer wrote:

>Not when fixing formatting. Having to fill-in an edit summary would
>significantly slow me down so I definitely would object to having to perform
>the needless keystrokes for these mundane changes. However, when I do make an
>edit worth documenting I do so nearly every time and if anything I over
>document. This should stay a 'rule to consider' for at least logged-in users.
>
>
I'm pretty much the same as Mav. I make a lot of minor edits.
It's not too hard to hit TAB, type "typo" and press RETURN, but makign
summaries mandatory would be a pain.

>It would be OK by me if this was a requirement for non-logged-in users (along
>with taking-away their ability to mark edits as minor).
>
Agreed.

>... give non-logged-in users another
>reason to log-in
>
It's nice when IPs become named users. But some irritating users are
wise to the fact that once they register we have a harder time banning
them for bad behavior (both technically and as a matter of principle...).


subject: [Wikitech-l] Minor fixes to TeX

body:
Patch against the most recent CVS.

Please install texvc on all production Wikipedias.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: texvc_small_fixes.diff.gz
Type: application/octet-stream
Size: 569 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20021228/01ac8aa3/attachment.obj>


subject: [Wikitech-l] TeX

body:
I wrote in part:

>I intended to write an essay on texvc and how it *should* work
>on MetaWikipedia -- where such an essay belongs --
>once I got back online (today or later in the weekend),
>although I didn't know (until reading my email just now)
>that I would have this impending deadline to delay its implementation.
>I'll try to get it done today (not just sometime this weekend).

Well, Wikipedia was down when I wanted to do some testing,
and then I was pretty busy Saturday --
but I stayed up all night to write it!
So see [[m:texvc]] (where much other discussion of texvc could go;
there is already a place for Taw to explain it himself).

http://meta.wikipedia.org/wiki/texvc

-- Toby


from_name: Ray Saintonge

body:
Toby Bartels wrote:

>>it makes the history page of an article vastly more useful; now I
>>often find myself employing the bisection method to find out when a
>>particular bit of information was inserted.
>>
>
>How about when I just write "Much." in the summary?
>
Yes.  If I've made several unrelated and substantive changes to an
article, I certainly do something like that.

Eclecticology


subject: [WikiEN-l] Re: Make summaries mandatory

body:
Daniel Mayer wrote:

>>What about requiring an edit summary
>>for major edits, and not requiring
>>one if the minor edit box is checked?
>>
>>Danny
>>
>
>Unless there is a byte counter married with the diff
>that would only encourage people to mark moderate and
>major edits as minor. Vera Cruz already marks all
>edits as minor and this is *VERY* annoying.
>
I've seen that and it annoys me just as much.  One solution there might
be to remove the preference to "Mark all edits minor by default". If she
has that set it would explain why all her edits are minor.

Eclecticology


subject: [WikiEN-l] Wikipedia:Shared resources

body:
Erik Moeller wrote:

>Expanding an idea by fonzy, I have created a skeleton for Wikipedians to
>organize the sharing of information from proprietary resources. See
>
>http://www.wikipedia.org/wiki/Wikipedia%3AShared_resources
>
>The current text that is there:
>
>This page is a reference for Wikipedians in need of certain proprietary
>information resources (encyclopedias, CD-ROM archives, expensive books
>etc.). The page has a section of resources that are offered and one of
>resources that are wanted. These sections are separated into subsections
>for specific resource types.
>
>Feel free to offer any type of resource, but please understand that this
>page is not intended to facilitate copyright violation -- "shared
>resource" implies that you are willing to make use of that resource for
>someone else, in your own time. Please provide as much detail as possible
>about:
>
>    * version of the resource
>    * storage form of the resource (paper, CD-ROM, online archive etc.)
>
>It is assumed that these resources are available to you for free or that
>you are willing to cover any costs. Users should note that these shared
>usage offers, unless otherwise noted, are only valid for Wikipedia
>purposes.
>
>Please add your own resources in the appropriate section.
>
Along the same line, I've often found interesting web sites which I've
bookmarked for later reference when I can focus my attention on the
subject matter.  Several months later when I'm ready ... poof! it's
gone.  Some of these have useful information, and it's a shame that it
becomes lost because somebody didn't pay his ISP bill.

These sites are covered by copyright, so for the most part we just can't
copy the material onto Wikipedia and make it available to the public.
 Still it  could be in the public interest to copy material from
threatened sites into a restricted access file where it could be revived
if and when the original site could no longer be maintained.  It would
be a lot easier to come to a conditional release agreement while the
site is still functioning than after it has gone under.

Eclecticology


subject: [WikiEN-l] Re: Make summaries mandatory

body:
On dim, 2002-12-29 at 21:17, Tom Parmenter wrote:
> Adding the preference setting "All edits minor by default" was a hasty
> decision.

It can be handy if one is making a great many minor changes (eg mass
spelling, formatting, or link fixes). Here's a thought; what if we can
make it only stick to a single session?

(On the other hand, it's not hard to train oneself to hit tab-space
after the summary.)

-- brion vibber (brion @ pobox.com)


from_name: Tom Parmenter

in_reply_to:
<3E0F3753.7010005@telus.net> (message from Ray Saintonge on Sun,
	29 Dec 2002 09:56:35 -0800)

body:
|From: Ray Saintonge <saintonge at telus.net>
|X-Accept-Language: en-us
|Sender: wikien-l-admin at wikipedia.org
|Reply-To: wikien-l at wikipedia.org
|Date: Sun, 29 Dec 2002 09:56:35 -0800
|
|Toby Bartels wrote:
|
|>>it makes the history page of an article vastly more useful; now I
|>>often find myself employing the bisection method to find out when a
|>>particular bit of information was inserted.
|>>
|>
|>How about when I just write "Much." in the summary?
|>
|Yes.  If I've made several unrelated and substantive changes to an
|article, I certainly do something like that.
|
|Eclecticology
|

How about listing substantive changes, or at least saying "substantive
changes" in the summary?

Tom P.
O88
|


subject: [WikiEN-l] Re: Make summaries mandatory

in_reply_to:
<3E0F394A.8080201@telus.net> (message from Ray Saintonge on Sun,
	29 Dec 2002 10:04:58 -0800)

body:
|From: Ray Saintonge <saintonge at telus.net>
|X-Accept-Language: en-us
|Sender: wikien-l-admin at wikipedia.org
|Reply-To: wikien-l at wikipedia.org
|Date: Sun, 29 Dec 2002 10:04:58 -0800
|
|Daniel Mayer wrote:
|
|>>What about requiring an edit summary
|>>for major edits, and not requiring
|>>one if the minor edit box is checked?
|>>
|>>Danny
|>>
|>
|>Unless there is a byte counter married with the diff
|>that would only encourage people to mark moderate and
|>major edits as minor. Vera Cruz already marks all
|>edits as minor and this is *VERY* annoying.
|>
|I've seen that and it annoys me just as much.  One solution there might
|be to remove the preference to "Mark all edits minor by default". If she
|has that set it would explain why all her edits are minor.
|
|Eclecticology
|

Adding the preference setting "All edits minor by default" was a hasty
decision.

Tom P.
O88


body:
Ortolan88 wrote:

>Eclecticology wrote:

>>Toby Bartels wrote:

>>>How about when I just write "Much." in the summary?

>>Yes.  If I've made several unrelated and substantive changes to an
>>article, I certainly do something like that.

>How about listing substantive changes, or at least saying "substantive
>changes" in the summary?

I was hoping that Axel would reply,
since in my case it will affect him more than anybody else.

In any case, I thought that "Much." would get across the idea
of substantive changes, but if "Many substantive changes" is necessary,
then I can do that.  As long as I don't have to list them individually.

-- Toby


in_reply_to: <200212252246.RAA17571@TheWorld.com>; from tompar@world.std.com on Wed, Dec 25, 2002 at 05:46:04PM -0500

body:
Tom Parmenter wrote:
> Rule or no rule, an empty summary field is bad manners.

I think this pretty much sums it up.

--Jimbo


subject: [Wikipedia-l] Open Publication License?

in_reply_to: <3E108B75.8060104@epost.de>; from magnus.manske@epost.de on Mon, Dec 30, 2002 at 07:07:49PM +0100

body:
Well, it's a little late now.  :-)  We would find it virtually impossible
to switch, I think.

Anyhow, here's GNU's discussion.

http://www.gnu.org/philosophy/license-list.html#FreeDocumentationLicenses

Magnus Manske wrote:

> Wikipedia is currently under GFDL. Would the Open Publication License
> not be more suited?
>
> I just found it at http://www.opencontent.org/openpub/
>
> Just a thought.
>
> Magnus
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikipedia-l


from_name: Viktor Kuncak

subject: [Wikipedia-l] concepts vs. words

body:
I noticed that the Lattice entry lumps together 3 different senses
of the word "Lattice".  I believe these should be separate entries
for each *sense*: [[Lattice algebraic structure]],
[[Lattice in material science]] etc.

Then there should be a disambiguation page that explains
that in the context of algebra, the word "lattice" means
[[Lattice algebraic structure]], in the context of material
science it means [[Lattice in material science]] etc.  In
general, I think that we should not get distracted by the
fact that such entries are grouped together in traditional
printed encyclopedias; this appears to be an artifact of the
primitive lookup operation used in that case.

I would even go as far as marking specially the pages whose
primary purpose is to map words to senses.  The reason is
the following potential useful enhancement of wikipedia.
Image that *every* sense used in wikipedia article has an
entry in wikipedia (or wiktionary).  Then one could build an
interactive tool that would help replace every occurrence of
a word in an article with a unique sense of that word.
Therefore, all words would have unambiguous meaning.  This
might not seem like a great advantage for human readers, but
I believe that wikipedia has a large potential for automated
processing.

  Viktor


subject: [WikiEN-l] Addition of just external link pages

body:
On Monday 30 December 2002 10:52, Magnus Manske wrote:
> 24.189.173.175
> <http://www.wikipedia.org/w/wiki.phtml?title=Special:Contributions&target=2
>4.189.173.175>(among making contributions to many articles) keeps adding new
> "articles" that consist of nothing but "External link" and a link to some
> website.
>
> IMHO these are *not* articles, not even stubs. Therefore, I just deleted
> 3 or 4 of them.

I agree and deleted one too. [[Spass guerilla]] should be put on delenda
though, I think.

phma