I agree this is probably worth looking at right away (after I fix
the bug Jan and Karen found about links not updating properly
when creating an article from one with previous broken links).
You Wrote:
>I like the new software in general, but (and I know we've talked
about it before) I really do not think the current search system is
ideal. It's just not correct. Do a search for "pi" or "george w
bush" or "malcolm x" and see. You and I know that we need
three-character terms, but the average user will not, and will be
surprised, misled, and maybe even contemptuous to see the incorrect
search results:
>
>"No article title matches"
>"No article text matches"
>
>
>If it's too difficult to allow searches for terms of any length, then
maybe the software could ignore the terms that are under 3 characters
and search for the remaining terms.
>
>I think also that the search page should have a warning about how
searches for 3 character words work.
>
>At the very least, the returned message should not report that we do
not have an article on a topic when some of the search terms are three
characters or less.
>
>cheers,
>
>kq
>
>00
> The sidebar is still a little dodgy in netscape. When I logged
> in the sidebar was superimposed on top of the main text. Changing
> to 'floating left' seems to have repaired the problem. 'Fixed left'
> works ok too. 'Fixed right' causes the display error.
Yeah, I had to give up on that one--I can't get the "right"
sidebar to work on IE, Mozilla, and NS 4.X all at once, so I
picked the former two. "Fixed left" is the default (except
for old users who already had it set on the right).
> 'Random page' takes me to the same page every single time... I'm
> not sure whether that's a bug or not.
Sounds like one to me...but since it works for me, you'll
have to give me a more detailed description of what you're
doing to reproduce this error.
> There is text showing up in red here and there and I'm not sure
> why. My favourite feature in the wikipedia is the ability to show
> up nonexistent links in red - it jumps out at you from the page
> rather than your having to search for little blue question marks...
> I can't find it in my preferences, so I guess it's been removed
> from this version? Oh, Ok, I just found it. It wasn't obvious to
> me that 'highlight links to empty topics' meant 'show them in red'.
"Red: sounded a little too hard-coded to me...it prevents me from
taking advantage of whatever other form of highlighting might be
useful in the future, or whatever might work better with a
different skin.
> I made a test page via a link, but when I click on 'what links
> here'? It says that there are no links to the page. The link did
> not show up until I went back and edited the 'Interest' page again.
Jan reported the same error. I'll have to investigate this.
Can either of you reproduce this reliably?
> Something a little strange in a circular redirect. I linked
> from 'Interest' to 'Interested' which is a redirect to 'Intrest'.
> 'Intrest' in turn redirects back to 'Interest'. Intrest now
> appears to be uneditable. When I attempt to edit the
> intermediary page 'Interest' shows up in the edit window.
I'll have a look at that too. I was able to get around it
by typing the URL directly, but it should still work.
0
I like the new software in general, but (and I know we've talked about it before) I really do not think the current search system is ideal. It's just not correct. Do a search for "pi" or "george w bush" or "malcolm x" and see. You and I know that we need three-character terms, but the average user will not, and will be surprised, misled, and maybe even contemptuous to see the incorrect search results:
"No article title matches"
"No article text matches"
If it's too difficult to allow searches for terms of any length, then maybe the software could ignore the terms that are under 3 characters and search for the remaining terms.
I think also that the search page should have a warning about how searches for 3 character words work.
At the very least, the returned message should not report that we do not have an article on a topic when some of the search terms are three characters or less.
cheers,
kq
0
> To my mild shock, I have just read a copyright notice at
> 1911encyclopedia.org: "... The Contents are licensed only
> for the personal, household, educational use by a single
> individual. Reproducing Content on another site or
> redistributing Content is forbidden. Taking Content from this
> site and editing it and posting it on another site is also
> forbidden...
> Full text: http://www.1911ency.org/legal.htm
They can _claim_ anything they like, but they're full of hot
air. Scanning is not "creative expression" protected by
copyright. The 1911 text is public domain--it belongs as
much to you and me as it does to them, regardless of whatever
legal-sounding bullshit they care to post.
0
To my mild shock, I have just read a copyright notice at 1911encyclopedia.org:
".....
Use on Other Web Sites. The Contents are licensed only for the personal,
household, educational use by a single individual. Reproducing Content on
another site or redistributing Content is forbidden. Taking Content from this
site and editing it and posting it on another site is also forbidden. Framing
of this site is forbidden.
......"
Full text: http://www.1911ency.org/legal.htm
Sound familiar (esp. the editing part)? Should we de-list this resource from
[[wikipedia:Public domain resources]] and only use the very incomplete
Project Gutenberg or should we risk an expensive lawsuit by PageWise? I know
their claim is almost certainly bull sh*t, but our blatant use of their
material nontheless would probably be enough to start expensive legal
proceedings.
<sarcasm>They did modify the public domain info by introducing OCR errors, in
effect creating a derivative work.</sarcasm>
Companies that do wholesale copies of public domain material and then slap an
onerous copyright onto the unimproved text make me sick.
--maveric149
> If the reason was to improve performance, then maybe list
> redirects to an article separately under a heading like
> "Pages that redirect here" (a good idea either way). Then
> maybe also have a link next to each of these redirects to
> "Pages that link to {redirect's name}".
It wasn't a performance issue--just a matter of personal
choice, but since there's now two complaint I suppose I'm
outvoted. Very well then, I'll have the page show the current
list (pages that link here), followed by pages that link to
each of those pages on the first list that are redirects.
I just don't want the two mixed together.
0
On Thursday 04 July 2002 12:01 pm, Toby Bartels wrote:
> There were many changes that I like, but several that were bad.
> Listing the latter in order of decreasing importance:
>
> <What links here> no longer indicates what links through redirects.
> I think that this is a significant loss of function.
I agree -- I in fact submitted a bug report on this but it was rejected. The
current 'pedia wikiware lists articles linked through redirects in a separate
section and each item linked that way has "(via [[{redirect's name}]])" right
next to it. I'm pretty sure Brion is the one who did this and he was prompted
to do so by a feature request I made so that articles like [[Sutter's Fort]]
wouldn't be counted as orphans just because it is only linked to other
articles by [[Sutters Fort]].
I can understand if this feature was dropped for fat-cutting reasons in order
to improve performance, but I have not received an indication that this is
the reason. If the reason was to improve performance, then maybe list
redirects to an article separately under a heading like "Pages that redirect
here" (a good idea either way). Then maybe also have a link next to each of
these redirects to "Pages that link to {redirect's name}".
--maveric149
On Thursday 04 July 2002 12:01 pm, you wrote:
> What I meant by the disamiguation block idea was this:
>
> have the article for Paris, the city in France on the page [[Paris]]
> with the block there.
> The idea was that the principal article on Paris is on the simple-name
> page, so at least a proportion of people following a [[paris]] link land
> immediately on what they want.
>
> I don't see much point in putting a disamiguation block on [[Paris,
> France]] and making [[Paris]] a mere redirect.
Unfortunately, [[City, Nation]] is now the general naming convention for
cities -- even for famous ones like Paris, France (of course, with US cities
being at [[City, State]] due to internal conflicts). Ideally, [[Paris]] would
be only a disambiguation page pointing to the various uses of the term. But
since the most famous Paris has been and will continue to be mostly linked by
someone typing [[Paris]], it is not yet possible to make [[Paris]] into a
disambiguation page (as Bryan would like) -- at a bare minimum all the
current links to [[Paris]] would have to be fixed to point to the correct
articles first (but then it would be a maintenance issue to constantly
recheck and fix links -- that's why I would prefer [[Paris]] to remain a
redirect to [[Paris, France]]).
You simply can't have consistency in naming conventions and have blatant and
obvious exceptions like the most famous Paris AND also be able to preserve
past and future direct links UNLESS pages like [[Paris]] redirect to [[Paris,
France]] and any disambiguation occurs at the target.
The disambiguation block is just to catch anybody who might have gotton lost
by clicking on [[Paris]] intending to go to [[Paris, Texas]] or [[Paris
(mythical figure)]] (Is this figure known by any other longer name than
simply "Paris"? I hate having to use parentheticals.)
I don't think people will be confused by landing at [[Paris, France]] by
clicking on [[Paris]] -- at the top of the page it already says "Redirected
from [[Paris]]" or something like that. And since this bock will be minimal
in size, I also don't think it would seem too out of place by people clicking
through from a link to [[Paris, France]].
Hum, I just thought of something potentially cool: Have a software feature
that deals with these types of disambiguation issues. This feature would work
by amending a short disambiguation block to the top of [[Paris, France]]
whenever some one got there by clicking on [[Paris]].
One way for a contributor to code this would be to add the text for the
disambiguation block below the #REDIRECT [[Paris, France]] that is now at
[[Paris]]. Then, the only time somebody will see the disambiguation block is
when they clicked on [[Paris]]. Not sure if this would be worth the effort
just to minimize some minor ugliness at [[Paris, France]] for those that
click to that article directly. Coding crew -- what do you think?
But then we could just quickly say: "[[Paris]] redirects here. This article
is about Paris, France....blah, blah, blah," and try to keep that to a single
line at 800 x 600 for those with standard sized font's (least common
denominator is, unfortunately, MS Windows defaults).
--maveric149
> <What links here> no longer indicates what links through redirects.
> I think that this is a significant loss of function.
I need to be convinced that this is the right thing to do.
The redirect pages themselves /are/ listed, and you can likewise
see a list of what links to them. If the function automagically
skipped over redirects to list two-level links mixed with one-
level links, the list would be a bad picture of the real state
of the database. Maybe it could list them separately (i.e.,
just do a second lookup for every link page found that is a
redirect). That's not a bad idea.
> The watchlist no longer watches User: pages or Wikipedia: pages.
> It's bad enough that User talk: and Wikipedia talk: weren't
> watched; now it's worse.
I don't know what you're talking about here. You can add any page
from any namespace to your watchlist, and it will work just fine.
In addition, if you watch an encyclopedia page, it will automatically
add the corresponding talk page to the watch.
> There are a few links that are now available only from the Quickbar:
> <Watch this page>, <What links here>, and <User contributions>.
> Can these *please* at least be listed at the bottom of the page?
That's a reasonable thing. Please add it as a feature request to
Sourceforge so it won't get lost.
> The watchlist also no longer displays nonexistent pages that I'm
> watching. You may not believe it, but I actually look at this list.
That's an interesting idea. Likewise, add it to the tracker.
> A construction like "[[thing]]s" no longer mimics "[[things|thing]]"
> if the page [[thing]] doesn't exist. This is difficult to read.
That's reasonable too, please add it.
> "~~~" doesn't change to my name in the <Preview> anymore, only
> in the <Save>.
May have to live with that one, at least for a while. But add
it to the tracker.
> The red colour of unwritten links is different from before --
> in fact, hard to distinguish from the purple colour of followed
> links.
It was previously the exact red color of followed links, and I
made it a darker red so it wouldn't conflict. If your followed
links are purple, that's a personal browser setting. Most
browsers use red.
> BTW, I haven't had any problems with response times --
> indeed, <130.94.122.197> is much faster than <www.wikipedia.com>!
There are no users on it yet. We won't know about performance
until it actually gets some traffic.
0
>The watchlist no longer watches User: pages or Wikipedia: pages.
>It's bad enough that User talk: and Wikipedia talk: weren't watched;
>now it's worse.
That's a feature I would like: I watch my username so I don't have to
check it every day for messages.
kq
0