>| I agree, but I'd also add semicolon and colon characters
>| to that list.
>...and single, double quotation marks, parentheses, and dashes.
Double quotes aren't legal in URLs, so they're not an issue.
But single quotes and hyphens are very common and I think it
would be a very bad idea not to treat those as URL chars in all
cases. I'm even bothered a little bit by question marks and
exclamation points, but there is a workaround
([http://x.com/y?http://x.com/y?]), so I think it will be OK.
I think colon and semicolon would be OK as well.
> I vote for punctuation cropping, too.
That seems to be a growing consensus. The remaining questions,
then, are the exact details. Exactly which characters do we want
to consider "punctuation", and under what circumstances? My
suggestion is this: After parsing URLs the way it does now, if the
URL ends with one, and exactly one, of the characters period, comma,
question mark, or exclamation; then remove that character and
assume it punctuates the sentence. Otherwise, leave the URL alone.
On Wednesday 24 July 2002 05:56 pm, LDC wrote:
> A timely announcement: Xiph and Real just announced that they will be
> collaborating to make Ogg Vorbis plugins for RealPlayer and other
> software. Since it's now standard in WinAmp as well, I now see no
> reason at all to use any other format.
I enthusiastically 100% agree. <emphasis>We should do ///everything///
reasonable in our power to promote free (libre) file formats.</emphasis>
This is especially true nowadays when the companies that control the
predominant proprietary file formats are trying to wrest even more control
over media files. We have established a fairly significant web presense and I
do believe our choice to go completely free would not go unfelt or unnoticed.
We could even decide to do the same for png/jpg and other cases where there
are totally valid and functional free (libre) alternatives to proprietary
file formats. We could even draft a press release for this and get some well
deserved publicity. Of course, we would have to systematically convert all
that we currently have (at least plan to do so eventually).
On Wednesday 24 July 2002 05:56 pm, Pierre Abbat wrote:
> I have it in no other format. Do you know of a program that converts Real
> Audio into something else?
>
> phma
If we do go this route, we must provide pointers to people where and how they
can convert their audio files (I'm pretty sure conversion of jpegs to pngs
could be done on the fly by the server using a GIMP script -- doing the same
for sound files would be too CPU intensive). This will probably have a side
effect of reducing the number of sound files uploaded to wikipedia but I say
so be it for the greater good.
--mav
Does the Image: namespace still contain ALL the images used in ALL the
differerent language versions of the wikipedia? I'm looking at orphaned
images and wondering what to do about the large number of orphans with
labels/captions/titles in languages other than English. Do I just
pretend they're not there?
eg. 'auge.gif' - a German diagram of the human eye, with labels. Looks
like it comes from a textbook.
'angulorecto.png' - a Right Angle, labelled in a language I can't
identify.
--
Karen AKA Kajikit
You can take the dragon out of Alfandra, but you can never take Alfandra
out of the dragon (or the Kitty)...
Come and visit my part of the web:
Kajikit's Corner: http://Kajikit.netfirms.com/
Aussie Support Mailing List: http://groups.yahoo.com/group/AussieSupport
Allergyfree Eating Recipe Swap:
http://groups.yahoo.com/group/Allergyfree_Eating
and now Ample Aussies Mailing List:
http://groups.yahoo.com/group/ampleaussies/
Love and huggles to all!
A timely announcement: Xiph and Real just announced that they will be
collaborating to make Ogg Vorbis plugins for RealPlayer and other
software. Since it's now standard in WinAmp as well, I now see no
reason at all to use any other format.
Pierre, if you can give me that RealAudio sound you uploaded in some
other format (any other--wav, aiff, au, or even raw bytes), I'll
recode it into an Ogg so that we'll both be able to hear it.
This is a general reply to a couple of mails relating to the new
software's Recent Changes page.
It was a guiding principle of my new design that it be *fast*. I
think the performance of this page is critical to usability. Speed
is a feature too. So if you're going to suggest features, make sure
they are either (1) not hindrances to performance, or (2) really,
truly, vitally necessary.
1) If you wan't 1000, 2500, or more changes, you can do that by
editing the URL directly. They are removed as links from the page so
that robots won't spider them, putting a load on the server. The
occasional human use shouldn't be a problem. If enough people
complain, I might consider putting 1000 back, though the need for it
might be supplanted by other features mentioned below.
I'd also be happy to put in some shorter time limits: currently the
shortest is "1 day", but I can see that it might be useful to have,
say, "3 hours", "6 hours", and "12 hours". This would make it
possible to extend the limit to a bigger number and still have a
reasonably fast query, because the time limit really trims down the
result set and makes things fast.
Along those lines, I've had enough requests to restore the "show only
new changes" feature, and that feature can actually speed up the
database query, so I plan to put that back.
Yes, it is confusing that the "diff" link on early edits shows a
recent diff. I agree that this is a bug, and I will fix it as soon
as I can figure out a good method. This one just happens to be
trickier than it looks, but it's not a performance issue, so I'm all
in favor of doing it right.
Any other desired feature that limits the set of pages returned is
also likely to get a favorable hearing. Maybe a feature that shows
only pages beginning with a certain letter or string, pages edited by
certain people, etc. If we can design a reasonable interface for it,
these kinds of changes must meet a lower burden of acceptance because
they will generally be fast.
The tricky one is consolidating multiple edits to a page into one
entry on the Recent Changes page, the way UseMod and Phase II did.
This is a big performance hit. Perhaps a later redesign of the
database would make it more reasonable, or perhaps a new
implementation will come to mind that cures the problem, but for now
I just don't want to burden the server with extra work for what is,
to me, a cosmetic change that doesn't add functionality.
>Warning: Can't connect to MySQL server on '127.0.0.1' (111) in
>/usr/local/apache/htdocs/w/DatabaseFunctions.php on line 15
That was me too. Took it down for about 2 minutes to restart
it with different MySQL logging options. It's fine now.
Since Monday, my script is seeing *average* response times ranging
from 0.8 to 1.5 seconds from all Wikipedia pages that I sample, with 99%
of calls served in less than 5 seconds. The only exception is the Recent
Changes pages on the non-English Wikipedias, which take up to 4 seconds on
average. (The ping roundtrip time alone from Sweden to San Diego is .2
secs, so the theoretical "room for improvement" is only 0.6 - 1.3 secs.)
--
Lars Aronsson (lars(a)aronsson.se)
tel +46-70-7891609
http://aronsson.se/http://elektrosmog.nu/http://susning.nu/
On Wednesday 24 July 2002 05:56 pm, you wrote:
> So far the votes are tied 2-2:
>
> Crop final punctuation from links: Brion, Tony
> Include final punctuation in links: Lee, Jan
>
> -- brion vibber (brion @ pobox.com)
I say crop the final punctuation /if/ we decide to let the software recognize
URLs minus the http:// as weblinks (which I think would be the user friendly
thing to do anyway).
There are /far/ more valid reasons why somebody would naturally want to write
"blah, blah, blah www.napster.com." than there are webpages with punctuation
marks at the end of their URLs.
--mav
Yes, I'm the one who screwed up the "changed by" field on a lot of
records that makes recent changes and history lists look weird. The
data is reconstructable, and I'm working on it. I even tried the
update on my own server before trying it on the live one, but it
failed anyway. Live and learn. And keep good backups.