Larry Sanger <lsanger(a)nupedia.com> writes:
> Why should we revert to an inferior technology just to save you a little
> convenience?
Can someone please explain, from the perspective of a user and contributor
rather than a software engineer, why the old wiki technology is considered
(by some) to have been inferior?
On an unrelated *cough* note:
-----------------------------------------------------------------------------
Fatal error: Call to undefined function: array_key_exists() in
/home/wiki-newest/work-http/special_recentchanges.php on line 152
-----------------------------------------------------------------------------
--
Gareth Owen
"Wikipedia does rock. By the count on the "brilliant prose" page, there
are 14 not-bad articles so far" -- Larry Sanger (12 Jan 2001)
Hello, I wondered if any of the programmers out there could help me. When I first started contributing to wikipedia, I took it upon myself to add all the country info in the CIA World Factbook. This was before Larry hashed out all the consequences of subpages, and so I just followed the established model instead of creating a new one. Now all the countries of the world except for a few of the A's are in subpage format, and between all the individual entries and the [[countries of the world]] page, that's a lot of influence towards creating subpages. I've worked on converting the pages, but the process is slow and tedious. So I wanted to know if it would be possible to write a script to convert those pages, and if anyone out there has the time and inclination to do so. I'd do it myself except my last programming experience was in BASIC. <g>
thanks,
kq
p.s. I really don't know how long it might take to write this script, so if it's some ridiculous amount of time, just forget about it.0
Please make the colors go away!!! And (same old song, different tune)
WHY make such a huge change without explaining it where people will see
this??? It isn't intuitive for people to go to FAQ when there has been
a change -- why not just let them know ahead of time -- and as a blurb
on Recent Changes, since that's where most of the addicted start????
Julie
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
>Actually, to my knowledge LMS is just about the only one who's
>strongly anti-subpages in any form (look for the previous discussion
>on this issue). If he's still the final arbiter of all Wikipedia
>functionality, then this is a moot point. If, however, we're back to
>policy by consensus, then it won't be too hard. But Mr. Wales needs
to
>tell us what the story is there.
>
>-tc
LMS is not strongly against subpages in any form, as you will see if
you upgrade your monitor from monochrome to 16 colors. Read
carefully. People do deserve that respect. Larry is against
subpages in the main, encyclopedia-article namespace; he is not
against them in "meta-" namespaces. Furthermore, I am equally
against them, for the reasons he has elaborated, and have expressed
as much. LMS is not the final arbiter of all Wikipedia
functionality, in spite of your assertions to the contrary, though he
does have considerable influence over Wikipedia's course. Most
people realize that. A few insist on oversimplification, with
increasingly frustrating results.
kq
0
>Actually, to my knowledge LMS is just about the only one who's
>strongly anti-subpages in any form (look for the previous discussion
>on this issue). If he's still the final arbiter of all Wikipedia
>functionality, then this is a moot point. If, however, we're back to
>policy by consensus, then it won't be too hard. But Mr. Wales needs
>to tell us what the story is there.
I'm definitely on Larry's side here as well, and I know there were
others as well back when those discussions were taking place. The
fact that a few newcomers who weren't involved in those debates now
find the issue puzzling is no reason to think it wasn't a consensus
decision at the time. And even if it was something less than an
overwhelming consensus, Larry's opinion does count for more than
ours, and should. This ain't a democracy; we have a single, specific
goal here, and we should do what supports the goal--making a good
encyclopedia--even if it gets in the way of doing less important
things, like making the creation of a specific kind of article a bit
easier.
0
One thing that would speed up the management of uploads would
be to have a link from each entry on the log:uploads page to the
upload itself (or a page containing the upload and the meta-information
that would be collected as described in other proposals).
That way, inspecting the new uploads would be considerably quicker.
--
------------------------------------------------------------
Robert Merkel rgmerk(a)mira.net
Go You Big Red Fire Engine
-- Unknown Audience Member at Adam Hills standup gig
------------------------------------------------------------
>What exactly do you mean? As the one who made pretty much all the
>Sept. 11 pages, I can tell you that the subpage functionality made
it
>much easier--I certainly wouldn't have been able to deal with all of
>the information in there if I didn't make some kind of subpagery. I'm
>certainly not tied to the particular implementation of the
UseModWiki,
>but the ability to generate pages tied into another page without
>having to type the entire title every time is extremely useful.
>
>-TC
that strikes me as ridiculous. Ctrl+c, ctrl+v.
kq.
0
> An additional advantage could be tha ability to cope
> with new data types. I
> think of SVG, as an example. The code for including
> such a file is quite
> different, but for the user, it would be the same as
> a jpg
> ("{{IMG:foobar.svg}}").
Why not just [[Image:foobar.svg]] in the Image
namespace? I was wondering how this would apply for
the non-English wikipedias, but then I realized they
could still just use the old way... (linking by URL)
Chuck
=====
Come to my homepage! Venu al mia hejmpagxo!
http://amuzulo.babil.komputilo.org/
====
Venu al la senpaga, libera enciklopedio
esperanta reta! http://eo.wikipedia.com/
_________________________________________________________
Do You Yahoo!?
Información de Estados Unidos y América Latina, en Yahoo! Noticias.
Visítanos en http://noticias.espanol.yahoo.com
This might be the time for a new idea (beware!;)
As you can see on the upload page, it gets quite crowded and loads very
slow. And we only have a few images up there.
So, there are some mechanisms we could try to clean this up and fix the
unwanted uploads issue:
1. Create subdirectories for categories ("biology" etc.)
2. Create SourceForge-style subdirectories, by the first and the first two
letters. "foobar.jpg" would go to "f/fo/foobar.jpg".
3. Create a binary namespace.
Personally, I'd vote for #2. We won't have to create a category scheme (as
in #1), and the tech would be easy (in contrast to #2). It would also group
images quite efficiently.
Now, what I had in mind was this: The current way of linking to images is
fine (just type in the URL!), but *additionally*, we could have another
scheme for linking wikipedia-internal images. Example: "{{IMG:foobar.jpg}}".
Now, the software could automatically determine the correct URL, based on
the storage scheme. It would also enable us to find unlinked images quite
easily.
An additional advantage could be tha ability to cope with new data types. I
think of SVG, as an example. The code for including such a file is quite
different, but for the user, it would be the same as a jpg
("{{IMG:foobar.svg}}").
Just dumping my random thoughts on you,
Magnus