subject: [Wikipedia-l] Alphabetical article index  (was [WikiEN-l] trying hard to do a list right)

body:
Brion Vibber wrote:

>On dim, 2003-02-16 at 17:17, Ray Saintonge wrote:
>
>>Brion Vibber wrote:
>>
>>>How about something like the alphabetical index
>>>for the online AHD: http://www.bartleby.com/61/s0.html ?
>>>
>>That would be a definite improvement over what we don't have now!
>>
>
>Okay, very preliminary version (code is in CVS):
>  http://test.wikipedia.org/wiki/Special:Allpages
>
It looks beautiful!

>There's probably some wiggle room in the ideal number of links per page
>and whatnot. It needs to be made prettier, with backlinks to the top
>level index and forward/back browsing, but the basic functionality is
>there.
>
And I thought I could expect perfection on the first draft. :-)

>Also we need to get a proper sorting system in (see my recent post on
>wikitech-l); for instance if I put this on the Esperanto wiki all the
>accented letters pile up at the end instead of in their proper places:
>  http://eo.wikipedia.org/wiki/Speciala:Allpages
>
Would a table of equivalent values be workable so that for sorting and
searching purposes "?" and "?" would be considered equivalent to "a",
etc. A second level of mini-sort would only be required when accents are
the only thing distinguishing two entries.   Entries in non-Latin
scripts would still need to be handled separately.

There would still be the problem of those languages which really do
consider some of those accented characters as special letters which
sometimes belong at the end of the alphabet.  But that should not be a
worry for the English wikipedia, and modifications could be made for the
others as required for their special rules.

>Other things: currently the list includes redirects. Some redirects
>should definitely stay -- alternate names that would not appear near
>each other, for instance. Others (spelling, caps variations) could maybe
>be dropped, but that's harder to do consistently. Or more simply, we
>could just italicize redirects or something.
>
I agree, but for now it's a step ahead of where we are.  Another
interesting challenge will come from how we deal and reconcile with the
established policy of putting names as [[John Smith]] instead of
[[Smith, John]]

>The generation of the top level index is currently pretty inefficient;
>it makes a separate database query for each chunk of 480 articles, and
>takes a while to generate on a wiki with 100,000+ articles. Before
>putting it on the English wiki live, it'll need to have some sort of
>caching mechanism if it can't be made a lot faster.
>
As much as I find beauty in the proposal, there may be other ways to do
this that are less demanding on the system, but just as easy for the
user..  A tree that requires succesively choosing the first, second and
third letters of the first word might do this.  So would a simple browse
function that asks the user to supply the first few letters to begin his
browse.  This would still contain the opportunity to step back and forth
to adjacent blocks.

Eclecticology


list: wikipedia-l

source: pipermail-mbox

from_name: Brion Vibber

subject:
[Wikipedia-l] Alphabetical article index  (was [WikiEN-l]
	trying hard to do a list right)

body:
On lun, 2003-02-17 at 01:43, Ray Saintonge wrote:
> Brion Vibber wrote:
> >Okay, very preliminary version (code is in CVS):
> >  http://test.wikipedia.org/wiki/Special:Allpages
> >
> It looks beautiful!

Woo-hoo!

> >There's probably some wiggle room in the ideal number of links per page
> >and whatnot. It needs to be made prettier, with backlinks to the top
> >level index and forward/back browsing, but the basic functionality is
> >there.
> >
> And I thought I could expect perfection on the first draft. :-)

What, and leave you nothing to look forward to? ;)

> Would a table of equivalent values be workable so that for sorting and
> searching purposes "?" and "?" would be considered equivalent to "a",
> etc. A second level of mini-sort would only be required when accents are
> the only thing distinguishing two entries.

In order to be at all non-molasses-like, the sorting has to be ingrained
into the indexes in the database.

To summarize my proposal on wikitech-l: this means either creating a
suitable charset plugin for MySQL to work with when building indexes
(can only be set on a server-wide basis -- not good enough for us, as
each language must be treated distinctly) or adding a special sort-key
field for each article. With a separate sort key, we can munge the
titles on a per-language basis so that characters are equivalized or
separated and rearranged such that a simple ASCII-style sort on the
hidden field will turn up the right order.

For English and French, this means simply replacing accented characters
with their base letters. For other languages this may involve adding
dummy high or low ascii chars to force a letter to sort above or below
an equivalent. But in all cases, it's the same basic mechanism -- make
some replacements on a string, then store the result and let the
database do a dumb sort with it.

Not really related, but what might be useful too is a (per-language)
list of index points; we might want the top level index to force
distinct sections for each letter.

ie instead of:
 Aardvark-Audio
 Aural-Catapult
 ...

we force index breaks at the start of each letter:
 Aardvark-Audio
 Aural-Azimuth
 Baal-Buzz
 Cab-Cop
 ....

>  Another
> interesting challenge will come from how we deal and reconcile with the
> established policy of putting names as [[John Smith]] instead of
> [[Smith, John]]

The simplest way is to abolish all alphabetical listings. ;)

> As much as I find beauty in the proposal, there may be other ways to do
> this that are less demanding on the system, but just as easy for the
> user..  A tree that requires succesively choosing the first, second and
> third letters of the first word might do this.  So would a simple browse
> function that asks the user to supply the first few letters to begin his
> browse.  This would still contain the opportunity to step back and forth
> to adjacent blocks.

Well, if you consider this to be a browse function:

  CHDIR C:\WIKI\ESP
  DIR ESP*.*

;)

Part of the usefulness of the all pages index is, at least in theory,
providing a fairly direct path to all pages for search engine spiders;
orphans and islands would still get linked to and indexed. So it's got
to be linkable. That, and the funnest part of browsing is coming across
things you wouldn't have thought of ahead of time -- this is helped by
making some real words visible. Plus, it just establishes context more
clearly to see whole words than a couple of letters jammed together.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20030217/22feb53e/attachment.pgp


list: wikien-l

from_name: Jimmy Wales

subject: [WikiEN-l] empty album pages, years in MTV and KROQ, Baha Men...

body:
Well, he can still login and edit, so it shouldn't be too much of a
burden for him, if he really wants to contribute usefully.

--Jimbo


subject: [Wikipedia-l] Re: Moving Polish Wikipedia to www.wikipedia.pl / Przejscie na www.wikipedia.pl

body:
Daniel Mayer wrote:
> > 1. concensus (is anybody against ?)
> > 2. changing settings of Wikipedia script
> > 3. reversing DNS redirects from
> >     www.wikipedia.pl->pl.wikipedia.org to
> > pl.wikipedia.org->www.wikipedia.pl
> >
> > Who aministrates both names ?
> > Could they please agree how to do the 3rd part ?

> IIRC Jimbo was dead set against this type of move (but redirection
> from a county domain to the .org one is fine).

I'm not *that* dead set against it.  I think there are pro's and
con's.  I think that the biggest 'con' is the cookie issue with
single-signon.  Another big 'con' is that in many cases, top level
domains don't map easily to languages.

For example, en.wikipedia.org should not be moved, ever, to
www.wikipedia.us, or www.wikipedia.co.uk or anything like that.
English is a language, not a country.

In other cases, like pl, the language and the country are very closely
identified.  jp is the same way.

I certainly think that, on the principle of least astonishment,
www.wikipedia.xx should resolve to the correct language wikipedia for
the majority language in that country, in as many countries as
feasible.

We do want to stay on a unified codebase, and I am deadset against
localized editing options, except those driven strictly by language
considerations.

--Jimbo


list: wikitech-l

subject: [Wikitech-l] Current Database Download

body:
On lun, 2003-02-17 at 03:09, Fred Bauder wrote:
> http://www.wikipedia.org/tarballs/cur_table.sql.bz2
>
> "Not found on the server"

Please wait a bit for tonight's dump to be finished and dropped in
place.

> On this subject, it would be nice if a barebones current table were
> available that has the text for the main wikipedia pages and leaves out the
> articles.
>
> As it is the current table contains a great deal I would not want to use and
> is quite cumbersome and difficult to handle.

Hmm, which pages do you mean?

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20030217/d4e32899/attachment.pgp>


subject: [WikiEN-l] Using information from the CDC home page

body:
Zoe wrote:
> Does this mean we can use the information at that website?

Almost everything produced by the United States government is not
subject to copyright.  This means that almost everything on U.S.
government websites is not subject to copyright, but there are
important exceptions.

For example, on the old whitehouse.gov website they had some nice
biographies of all the Presidents.... except they didn't produce them,
they were using them by permission from a copyright book.  We would
not be able to use those.

In general, if the publication is a publication *of the government*,
then it's legal to use it, unless it says otherwise.

--Jimbo


subject: [Wikitech-l] Moving Polish Wikipedia to www.wikipedia.pl / Przejscie na www.wikipedia.pl

in_reply_to: <1045392136.4939.16.camel@rdaneel.vibber.org>; from brion@pobox.com on Sun, Feb 16, 2003 at 02:42:17AM -0800

body:
Brion Vibber wrote:
> I think in general using country codes is going to cause more confusion
> when linking using language codes, which are *not* always the same. But
> if you guys really want it sitting at that location, I at least see no
> reason to stop you.

I agree with Brion completely.  I see some good reasons not to do
this, but they aren't overwhelming.

Who owns the .pl domain name?  Do we have a firm assurance that it
will be transferred to the nonprofit at the appropriate time?

--Jimbo


from_name: Daniel Mayer

body:
On Sunday 16 February 2003 03:08 am, wikitech-l-request at wikipedia.org wrote:
> [en]
> We need:
> 1. concensus (is anybody against ?)
> 2. changing settings of Wikipedia script
> 3. reversing DNS redirects from
>     www.wikipedia.pl->pl.wikipedia.org to
> pl.wikipedia.org->www.wikipedia.pl
>
> Who aministrates both names ?
> Could they please agree how to do the 3rd part ?

IIRC Jimbo was dead set against this type of move (but redirection from a
county domain to the .org one is fine). IMO it is bad enough already that
xx.wikipedia.org looks like a different domain.

I thought we were all one big project at one domain on one server - having
different domains will only tend to enforce a sense of separateness. Also
what happens if the owner of the domain doesn't or can't pay the bill for it
or decides to yank it (not that I think Kpjas would ever do that)? If
something does happen then a lot of links will be broken and I thought that
was something that was greatly frowned upon around here.

--Daniel Mayer (aka mav)


subject: [Wikitech-l] Re: Moving Polish Wikipedia to www.wikipedia.pl / Przejscie na www.wikipedia.pl


subject: [WikiEN-l] The MIT vandal is back

in_reply_to: <3E503FBD.1080805@telus.net>; from saintonge@telus.net on Sun, Feb 16, 2003 at 05:49:49PM -0800

body:
Ray Saintonge wrote:
> This is really just a difference in perspective.  Whereas I was
> approaching this from the perspective of the article, it appears that
> you are appraoching it from the perspective of the contributing vandal.

That's right.  Different cases may differ.  In this particular case,
this is a known person who has repeatedly threatened to vandalize
wikipedia by making subtle edits over a long period of time.  This is
a person who caused several people to work overnight to revert a
series of edits from a series of different ip numbers and login ids.

> If the comment that women are more prone to anorexia were added to an
> article where it at least has a modicum of relevance, a person watching
> this article who otherwise might not have crossed paths with our vandal
> could easily see the unexplained removal of that comment as being itself
> vandalism.

That's right.  We should probably annotate such removals.

Also, it's important to realize that some vandalism may be driven by a
lack of balance in an article in the first place.  In other words, as
unfortunate as it may be, sometimes some vandals may have "a point"
and choose to react to it by going bonkers.

In such cases, the article should be improved, even if by accident
the improvements make the vandal happy!  :-)

--Jimbo


subject: [Wikitech-l] Categories and metadata

body:
I'm all in favor of an eventual transition to some method of
categorization, or even some more general method of including what I
would call 'metadata'.  (Someone else talked about objects in this
context.)

I just caution that we should not just proceed to do this in code.
This will be a major move, and it needs to be carefully discussed
first.  One main thing we want to be careful of is making some
decision today that takes us down a path for the future that's hard to
generalize.


from_name: Anthere

subject: [WikiEN-l] The MIT vandal is back

body:
--- Zoe <zoecomnena at yahoo.com> wrote:
>
> Anthere, you're a woman, aren't you?  Are you trying
> to claim that my fight on this subject is somehow
> gender-based?
> Zoe

Uh ?
Dunno. I don't follow your edits, so I wouldn't be
able to say whether you are biased or not. Probably
not ;-)

But, being women, and being few, I think we are
probably a bit biased in the articles we *choose* to
create, edit or monitor.

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com


from_name: Fred Bauder

subject: [Wikitech-l] Current Database Download

body:
http://www.wikipedia.org/tarballs/cur_table.sql.bz2

"Not found on the server"

On this subject, it would be nice if a barebones current table were
available that has the text for the main wikipedia pages and leaves out the
articles.

As it is the current table contains a great deal I would not want to use and
is quite cumbersome and difficult to handle.

Fred


subject: [WikiEN-l] The MIT vandal is back

body:
--- Tom Parmenter <tompar at world.std.com> wrote:
>
> Reply way down at the bottom.
>
> |From: Anthere <anthere6 at yahoo.com>
> |Date: Sun, 16 Feb 2003 06:53:20 -0800 (PST)
> |
> |Note: forwarded message attached.
> |
> |
> |__________________________________________________
> |
> |Date: Sun, 16 Feb 2003 06:49:35 -0800 (PST)
> |From: Anthere <anthere6 at yahoo.com>
> |Subject: [WikiEN-l] The MIT vandal is back
> |
> |To: wikien-l at wikipedia.com
> |
> |On Fri, Feb 14, 2003 at 12:32:27PM -0800, Zoe
> wrote:
> |>>   It's the exact same wording as the text
> inserted
> |by the MIT >>vandal.  I asked the person inserting
> it
> |to give us some >>information to prove the
> assertion,
> |and I asked if it was true >>for the entire world,
> or
> |only certain cultures.  The person >>declined to do
> |so.
> |
> |>The information is not misogynistic, it is true.
> |Labelling >this person a vandal does a disservice
> to
> |the Wikipedia.  The >traditional treatment in the
> West
> |for hysteria was for the >doctor to massage a
> womans
> |genitals by hand until she got some >relief.  The
> most
> |extreme forms of hysteria are not seen very >much
> in
> |modern times; some attribute this to a greater
> |interest >in giving sexual satisfaction to women.
> The
> |milder forms of
> |>hysteria still abound; if males have a propensity
> for
> |hysteria, >it is socialized out of them at a very
> |young age.
> |
> |>Jonathan
> |
> |Interesting comment Jonathan
> |
> |Made me think of what Clement Rosset says about
> |passion and hysteria...
> |
> |He usually approaches notions by paradox, and
> studied
> |fallacious causes of suffering, in particular the
> |generally accepted idea by which love is the main
> |passion. He says love becomes a passion only when
> it
> |ceases aiming at a real person, but rather toward
> an
> |person or an object absent or unreal. Becoming a
> |passion makes it cease being love. Passion would be
> |the stuborn research of misfortune (or
> unhappiness),
> |and as such be related to hysteria.
> |
> |It's interesting Zoe is fighting so much against
> the
> |addition ''more women than men suffer from
> |[[hysteria]]''...There's no article on hysteria on
> |wikipedia by the way.
> |
>
> If we had an article on hysteria it would be
> described as a
> discredited 19th century diagnosis closely tied to
> the sexual
> repression of women that nonetheless was a major
> stimulus to Sigmund
> Freud's thinking.  No one is diagnosed as hysterical
> today and much of
> Freud's thinking is regarded as historically
> important but
> non-scientific at this point.

Ah ???
Wellll...
First, let's say I had the opportunity to spend more
time than I would have liked in a couple of
psychiatrist hospitals (not for me :-)), and to speak
to more than one psychiatrist in the past 15 years.
The given diagnosis involved the words "hyst?rie",
"n?vrose" and "bouff?es d?lirantes", and hysteria
certainly was a word I heard more than once from the
doctors...and it was also clearly associated with "you
know, she is very lonely...".
But...they don't appear to massage women genitals to
help cure the problem any more :-) (I didnot know that
was done at some point)
However, you will understand I hope that I am not
entirely convinced when you say no one is diagnosed
with hysteria anymore.

Of course, "hysterical" is still very much in use here
too (but maybe is it a non-politically correct word in
the us ?), especially given by men to feminists (with
the very rude comment : "if she had a real man to fill
her up more often, she would not make so much noise")

> It's interesting that when people want to slip in
> something dubious,
> they start with the phrase "It's interesting . . . "
>  If you want to
> state that someone is being hysterical here, say so
> and take the
> consequences.

What is the dubious thing you want to slip here then ?
Do you imply I was accusing both Jonathan and Zoe of
being victims of hysteria ? If so, say it clearly
please

> The other disputed diagnoses, histrionic personality
> disorder, etc.,
> are more common among women (in the west), just as
> antisocial
> personality disorder is more common among men, but
> the diagnosis of
> hysteria is simply not given to either men or women.

Then, I am doubly interested (without any slip) in
someone writing an article on hysteria, for it is
clear to me that french people are still suffering
from it but not english people. And, here, I truely
have no explanation (and imply nothing more than what
I just said)

Anthere

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com


subject: [Wikitech-l] Current Database Download

body:
>> It would be nice if a barebones current table were
>> available that has the text for the main wikipedia pages and leaves out the
>> articles.
>>
>> As it is the current table contains a great deal I would not want to use and
>> is quite cumbersome and difficult to handle.
>
> Hmm, which pages do you mean?
>
> -- brion vibber (brion @ pobox.com)
>

Well the main page and for example:

* [[wikipedia:How to start a page|how to start a page]]
* informal tips on [[wikipedia:Contributing to Wikipedia|contributing to
Wikipedia]]
* editing tasks in general at the [[Wikipedia:Editing FAQ]]
* layout conventions, at the [[Wikipedia:Manual of Style]]
* [[Wikipedia:Naming conventions]] for articles themselves
* ... and finally, the full kaboodle of [[Wikipedia:Utilities|utilities]]
for editors.

And other pages that would be of general utility (or would need to be edited
and revised) for use in an installation of the wikipedia3 software.

How_to_edit_a_page
What_is_an_article
*[[Wikipedia:Overview FAQ]]: general questions about the project
*[[Wikipedia:Readers' FAQ]]: finding, reading and using Wikipedia material
*[[Wikipedia:Contributing FAQ]]: why you might want to contribute, and how
you can do it
*[[Wikipedia:Editing FAQ]]: the nuts and bolts of creating and editing
Wikipedia pages
** [[Wikipedia:How do I do this]] (being merged with other FAQs)
*[[Wikipedia:Administration FAQ]]: sysop status, server administration
*[[Wikipedia:Technical FAQ]]: Wikipedia software and hardware
*[[Wikipedia:Problems FAQ]]: questions relating to present and past
difficulties and criticisms
*[[Wikipedia:Miscellaneous FAQ]]: everything else

etc.

The database as a whole produces a mirror, but if the point is to use the
software to present information in a different way, it would be nice to
start with a minimum and then add whichever articles you wanted to use from
wikipedia, but only those.

Fred


from_name: Zoe

subject: [WikiEN-l] strange problem. is it only me? (for a developer)

body:
You need to clear your cache, I think.  This has happened over the last couple of weeks.  I have the same problem when I'm edting the Oscars lists.  I'll add a new page, then use my Back button to go back to the list of Oscar nominees, and the page I just added still shows as empty.  Sometimes if I Refresh it clears it up, but not always.
Zoe
 daniwo59 at aol.com wrote:Yesterday I looked for an empty link to fill in and came up with [[Madura]], which appeared in [[Islands of Indonesia]]. I wrote a short article, which appears,  but today, looking for another island to write about, I saw that the Madura link on the [[Islands of Indonesia]] page still appears empty. I clicked on it and came to the editing box, with my text there, instead of the page itself. Is this some kind of bug)?

Danny

---------------------------------
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030217/dc26847c/attachment.htm


body:
You need to clear your cache, I think.  This has happened over the last couple of weeks.  I have the same problem when I'm edting the Oscars lists.  I'll add a new page, then use my Back button to go back to the list of Oscar nominees, and the page I just added still shows as empty.  Sometimes if I Refresh it clears it up, but not always.
Zoe
 daniwo59 at aol.com wrote:Yesterday I looked for an empty link to fill in and came up with [[Madura]], which appeared in [[Islands of Indonesia]]. I wrote a short article, which appears,  but today, looking for another island to write about, I saw that the Madura link on the [[Islands of Indonesia]] page still appears empty. I clicked on it and came to the editing box, with my text there, instead of the page itself. Is this some kind of bug)?

Danny

---------------------------------
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030217/dc26847c/attachment-0001.htm


from_name: Richard Grevers

subject: [WikiEN-l] Re: Asimov-still POV

body:
On Wed, 12 Feb 2003 17:30:46 -0800 (PST), Bridget [name omitted for privacy reasons]
<lapollutionestsimauvaise=/E1597aS9LQAvxtiuMwx3w at public.gmane.org> wrote:

>
> Is not, "Bewildering Stories, issue 8" enough? Do we need to say, "Not
> only does Bewildering Stories issue 8 argue that Nightfall is ONE of the
> greatest, but be assured, by wikipedia and our ardent NPOV, that
> Nightfall is considered by many to actually be THE greatest science
> fiction short story EVER.
>
The words "ever" and "never" are absolutes and should have no place in
Wikipedia except in a direct quotoation. After all, best ever also implies
that no better story will be written in the future, somthing that we simply
do not know.
This hyperbole is commonly repeated, however, particularly at the closing
ceremonies of the Olympic Games :-(
"Best yet" and "best to date" are possible alternatives, although once
again "best" is to subjective to use without a particular reference.
--
Richard Grevers


from_name: Ray Saintonge

subject: [Wikipedia-l] last names first

body:
Chuck Smith wrote:

>>I agree, but for now it's a step ahead of where we
>>are.  Another
>>interesting challenge will come from how we deal and
>>reconcile with the
>>established policy of putting names as [[John
>>Smith]] instead of
>>[[Smith, John]]
>>
>
>I think this will be easy to solve in the Esperanto
>version since we use the standard Esperanto convention
>[[John SMITH]] to show last names, since Asians tend
>to put their last names first, like [[ZHU Xin]].  Is
>this technically easy to do on the Esperanto
>wikipedia?  I know Miroslav always complains about
>this lack in the Wikipedia software...
>
Interesting.  Block capitals for surnames is also popular among
genealogists where you often need to skim through a lot of material to
find the relevant ones.  For the moment I'll stay neutral on that idea.

Eclecticology


from_name: daniwo59 at aol.com

body:
Yesterday I looked for an empty link to fill in and came up with [[Madura]],
which appeared in [[Islands of Indonesia]]. I wrote a short article, which
appears,  but today, looking for another island to write about, I saw that
the Madura link on the [[Islands of Indonesia]] page still appears empty. I
clicked on it and came to the editing box, with my text there, instead of the
page itself. Is this some kind of bug)?

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


subject: [WikiEN-l] bizarre vandalism

body:
Someone has been replacing articles with bizarre texts.

138.245.220.134 replaced [[Wikipedia:Always fill summary field]] with
information on the Christian view of long hair, while 130.104.227.101
replaced [[Wikipedia:About]] with an essay on truth.

Keep an eye out for similar changes.

Danny

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030217/5a5351ae/attachment.htm


from_name: Yann Forget

subject: [Wikipedia-l] Links to differents languages for days and years

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I made two small scripts to generate pages for years, decades and days with
links to other languages. However Italian (and some other languages) are
missing from http://meta.wikipedia.org/wiki/Date_formats_for_language_linking

Details on the page above.

Best regards,
Yann

- --
http://www.forget-me.net
Alternatives sur le Net
http://keys.indymedia.org/showkey.py?key=0A34CBDA
gpg --keyserver keys.indymedia.org --recv-key 0A34CBDA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+UK6em4KYjQo0y9oRArwlAJ4+NFysRac4K8oPTtOMBqsy23ycPACfRFY8
ExSG9DIlQNHTSc2ua7/IAjk=
=4Zpr
-----END PGP SIGNATURE-----


subject: [Wikipedia-l] Categories, back to square one

body:
Magnus Manske wrote:

> So, it seems (if I interpret Jimbo's mail on wikitech and the
> discussion here correctly) that most of us would like *some kind* of
> category scheme in wikipedia. I do, too! But, we seem to differ on the
> details (shocked silence!).
>
> So far, I saw three concepts:
> 1. Simple categories like "Person", "Event", etc.; about a dozen total.
> 2. Categories and subcategories, like
> "Science/Biology/Biochemistry/Proteomics", which can be "scaled down"
> to #1 as well ("Humankind/Person" or something)
> 3. Complex object structures with machine-readable meta-knowledge
> encoded into the articles, which would allow for quite complex
> queries/summaries, like "biologists born after 1860".
>
> Pros:
> 1. Easy to edit (the wiki way!)
> 2. Still easy to edit, but making wikipedia browseable by category,
> fine-tune Recent Changes, etc.
> 3. Strong improvement in search functions, meta-knowledge available
> for data-mining.
>
> Cons:
> 1. Not much of a help...
> 2. We'd need to agree on a category scheme, and maintenance might get
> a *little* complicated.
> 3. Quite complex to edit (e.g., "<category type='person'
> occupation='biologist' birth_month='5' birth_day='24'
> birth_year='1874' birth_place='London' death_month=.....>")
>
> For a wikipedia I'd have to write myself, I'd choose #3, but with
> respect to the wiki way, #2 seems more likely to achieve consensus (if
> there is such a thing;-)

I want to thank Magnus for summarizing this recent thread.  It makes it
easier to see where to jump in.

A few months ago I suggested   A system of boxes where a person could
provide a subject codification or categorizastion.  I also suggested at
the same time using Library of Congress Classification as a starting
point which could be modified to suit our needs.  The suggestion did not
fare well.  Among the objections were that it would require a lot of
work to change every article to apply codification, and that people
wouild need to learn a lot of difficult to remember codes.  When I went
so far as to suggest that a "XX" code be used by parents to prevent
their children from downloading certain articles, a few objected on the
grounds that this would be permitting censorship, even though the
criteria for using it this way would reside on an individual's own
computer.  Bowdlerization would remain a personal option.

There are really two issues (boxes and codes) in my proposal, and they
can be considered separately and mostly independantly.

The boxes are the more important of the two, and could function with
whole words as easily as with classification codes.  "Person" could
function as easily as "CT", the LOC code for biography.  The boxes could
easily go beside the summary box on the edit page.  In order to
facilitate cross referencing the ability would be needed to enter more
than one category. This would allow, for example, a person looking for
mathematicians to search the articles which show boxes for both
mathematics and persons.   I would leave it up to the techies to
determine whether this is done as a series of boxes, each with a single
category, or as a single box with a number of appropriately delimited
entries.

Whatever is devised would involve a certain amount of anticipation or
pre-emption.  Some of the categories that we originally employ may end
up totally useless as the scheme develops.  In one sense, however, this
is nothing more than scaling up something that we already do when we
wikify articles.  When we do this we have no idea about which of the
links will lead to an existing article, or one which will never be
created.  One of the functions of our naming conventions is to optimize
the probability that what we write and what we link will converge.  If I
add to a list of Oscar nominated movies, particularly if I'm adding a
movie with a one-word title, I have no certain idea whether that title
will have some other ecyclopediable subject, or whether there have been
other movies with that title.  Researching every such instance as much
as I would like is totally impractical.  Much of our work here depends
on making serendipitous guesses.  Then sombody else finds a use for the
term in a totally unfamiliar area.

There is absolutely no doubt that a lot of work would be required to
classify all the existing articles.  I do note that someone commented in
the last couple of days that some articles had not been revised or
reviewed for a long time.  That's fine; the boxes could be filled as
part of this review.  There's no need to do everything overnight.  I
would suggest, though, if this approach were adopted, that from the
beginning every article be botted with the code "AAA" to mean
unclasified, and any new article created without classification would
automaticaly be coded with "AAA".  In due course this would be useful to
contributors looking for things to classify.  Nobody should need to feel
the burden that all contributors would feel obliged to classify.  Our
present summary box is often left unfilled, and as much as it may annoy
some veterans, it is relatively harmless. The same could be said of a
classification box, perhaps with the caution that inexperienced
Wikipedians might be better to leave it blank until they are familiar
with the categories.

This is already getting long, and I have other obligations.  I'll write
about the second issue later.

Eclecticology


subject: [WikiEN-l] another bizarre vandalism

body:
Now [[Wikipedia:How to edit a page]] has become an essay on privacy by the
same guy. It is too slow to revert. Can someone take a look at that.

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


subject: [Wikitech-l] Current Database Download

body:
On lun, 2003-02-17 at 04:59, Fred Bauder wrote:
> The database as a whole produces a mirror, but if the point is to use the
> software to present information in a different way, it would be nice to
> start with a minimum and then add whichever articles you wanted to use from
> wikipedia, but only those.

As a reminder, you may only use these pages as a base for another wiki
if it, too, will be under GFDL license.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20030217/1270dd0e/attachment.pgp>


subject:
[Wikitech-l] Installing current CVS snapshot: writing articles
	doesn't work?

body:
On lun, 2003-02-17 at 12:29, Thomas Luft wrote:
> After checking the tables I found out that the row cur_random does not
> exist. I checked the buildtables.inc in the maintenance dir and found
> out that there is no cur_random field set up during db creation.

Mea culpa! Yup, I forgot to update the schema again.

I've updated buildTables.inc in CVS; please update and try it again.
(Or, run patch-random-dateindex.sql over the existing database.)

> Is it possible to download a kind of stable version of wikipedia via CVS?

There is no stable version. ;)  Everything's very much under
development, so occasionally it doesn't quite work out of the box.
Someday we'll release stable versions, but until then you gotta work
with it a bit.

> PS: The layout looks a little bit weird with Mozilla and I am unable to
> access the top items (drop down menu, talk, log in), is that normal?

Make sure the stylesheets are installed! Check $wgStyleSheetPath in
LocalSettings.php and make sure the .css files from the 'stylesheets'
subdirectory of the source are copied there.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20030217/54408e54/attachment.pgp>


body:
On lun, 2003-02-17 at 06:59, daniwo59 at aol.com wrote:
> Yesterday I looked for an empty link to fill in and came up with
> [[Madura]], which appeared in [[Islands of Indonesia]]. I wrote a
> short article, which appears,  but today, looking for another island
> to write about, I saw that the Madura link on the [[Islands of
> Indonesia]] page still appears empty. I clicked on it and came to the
> editing box, with my text there, instead of the page itself. Is this
> some kind of bug)?

Yes, known buglet. The page itself hasn't been edited, so it reports
itself as unchanged when your browser asks if it needs to fetch a new
copy or if it can use a cached copy.

Hold down control and hit refresh, this should force a reload.

This should only strike users of Internet Explorer 5.5 or higher. Of
course, that's the vast majority of our users -- which is why caching
was enabled for them to reduce stress on the server from unintended
reloads. ;)

(A better system for invalidating caches by adding a 'last-touched'
timestamp field to the database has been proposed.)

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030217/c4e1fea3/attachment.pgp


from_name: Andre Engels

subject: [Wikipedia-l] readability of recentchanges

body:
On 12 Feb 2003, elian wrote:

>
> Hello,
>
> After the last update which included the links to the user:discussion page
> (which is certainly useful) I have problems to scan RecentChanges for the
> really important things, i.e. the articles which were modified. In English
> it is not such a big problem because "diff" and "hist" and "talk" (and
> "block") are a lot shorter than "Unterschied" "Versionen", "Diskussion"
> and "blockieren" but German RecentChanges are at the moment almost
> unreadable for me.

Well then, would it not be an idea to just use smaller versions for the
German Wikipedia as well? I mean, 'diff' and 'hist' are abbrevations in
English too. So what about 'Unt', 'Vers', 'Disk', 'block'?

> comparison table:
> en: diff hist talk block
> de: Unterschied Versionen Diskussion blockieren
> es: diferencias historia discusion ?
> sv: skillnad historia Diskussion ?
> eo: malsamoj historio Diskuto ?

nl: wijz hist Overleg blokkeer
(wijz=wijziging, hist=historie - although on the page themselves we use
 'voorgeschiedenis' rather than 'historie')

Andre Engels


from_name: Chuck Smith

subject: [Wikipedia-l] last names first

body:
> I agree, but for now it's a step ahead of where we
> are.  Another
> interesting challenge will come from how we deal and
> reconcile with the
> established policy of putting names as [[John
> Smith]] instead of
> [[Smith, John]]

I think this will be easy to solve in the Esperanto
version since we use the standard Esperanto convention
[[John SMITH]] to show last names, since Asians tend
to put their last names first, like [[ZHU Xin]].  Is
this technically easy to do on the Esperanto
wikipedia?  I know Miroslav always complains about
this lack in the Wikipedia software...

Thanks,
Chuck

=====
Interesting fact:  Google returns more
results for "Esperanto" than for "Catalan"
----------------------------------------
Learn Esperanto! - http://www.lernu.net/
Enciklopedio: http://eo.wikipedia.org/

___________________________________________________
Yahoo! M?viles
Personaliza tu m?vil con tu logo y melod?a favorito
en http://moviles.yahoo.es


subject: [Wikipedia-l] Re: Links to differents languages for days and years

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I included the scipts here.
* wikidate.pl is to generate the years and decades,
* wikidays.pl is to generate the days.

Regards,
Yann

Le Lundi 17 F?vrier 2003 10:42, Yann Forget a ?crit :
>
> I made two small scripts to generate pages for years, decades and days with
> links to other languages. However Italian (and some other languages) are
> missing from
> http://meta.wikipedia.org/wiki/Date_formats_for_language_linking
>
> Details on the page above.

- --
http://www.forget-me.net
Alternatives sur le Net
http://keys.indymedia.org/showkey.py?key=0A34CBDA
gpg --keyserver keys.indymedia.org --recv-key 0A34CBDA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+UNJym4KYjQo0y9oRApczAJ46GC71RXjuzcU42B/SFrlbHRpiDwCeMyam
1xgB+Tih+vCtwTpbUXIQ42w=
=dsyo
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wikidate.pl
Type: text/x-perl
Size: 6460 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20030217/b0295d78/attachment.pl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wikiday.pl
Type: text/x-perl
Size: 3001 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20030217/b0295d78/attachment-0001.pl


subject: [Wikitech-l] Pipe trick should work differently

body:
One advantage that Erik does not mention, would be that keeping the pipe
trick in the page text would make it possible for the savvy user who does not
know it to find it out him- or herself. Under the current situation, only
those 'in the know' (or who happen to find a help page where it is explained)
can use it.

Andre Engels

On 12 Feb 2003, Erik Moeller wrote:

> IMHO when I write
>
>         [[Wikipedia:Policies and guidelines|]]
>
> this should not be turned into
>
>         [[Wikipedia:Policies and guidelines|Policies and guidelines]]
>
> after saving. Instead, the link should stay the same, but the "Wikipedia:"
> part should still be omitted. Otherwise, on many pages that have lots of
> links with the namespace prefix omitted, you get lots and lots and lots of
> redundant information, and it becomes very hard to read. The same goes for
>
>         [[The Lord of the Rings: The Fellowship of the Ring (movie)|]]
>
> which should not become
>
>         [[The Lord of the Rings: The Fellowship of the Ring (movie)|The
> Lord of the Rings: The Fellowship of the Ring]].
>
> The (movie) part should instead be omitted "on the fly". This also makes
> it easier to change the pipe trick behavior should that ever be necessary.
> I believe this behavior would be more intuitive. In fact, I expected it to
> work this way and was surprised when I noticed that it doesn't.
>
> A comparison would be the "slash trick" which I have developed for
> subpages.
>
>         [[/foo/]]
>
> becomes a link called "foo" to the subpage /foo of the current page, but
> it is *not* converted into [[/foo|foo]] for this purpose.
>
> Thoughts?
>
> Regards,
>
> Erik
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikitech-l
>


body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

And I forget to say, in the TODO list:

* I can't type some characters of the month (in wikiday.pl for Polish,
Esperanto). Could someone correct this?
* doesn't generate years BC,
* more languages (are missing: Italien, Portuguese, etc. and non-latin
alphabets),
* bottom for fist and last day of each month has to be edited by hand,
* something is needed to generate links for centuries and milleniums.

Yann

Le Lundi 17 F?vrier 2003 13:15, Yann Forget a ?crit :

> I included the scipts here.
> * wikidate.pl is to generate the years and decades,
> * wikidays.pl is to generate the days.

- --
http://www.forget-me.net
Alternatives sur le Net
http://keys.indymedia.org/showkey.py?key=0A34CBDA
gpg --keyserver keys.indymedia.org --recv-key 0A34CBDA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+UNbEm4KYjQo0y9oRAu0PAJ97yKMZ97Ru4xEPcUrqzTMm4i9/IACfTszw
TQR3FxvzQf9Unb6YzBPHMkw=
=lZ3N
-----END PGP SIGNATURE-----


from_name: Tomasz Wegrzanowski

body:
On Mon, Feb 17, 2003 at 03:25:44AM -0800, Jimmy Wales wrote:
> Brion Vibber wrote:
> > I think in general using country codes is going to cause more confusion
> > when linking using language codes, which are *not* always the same. But
> > if you guys really want it sitting at that location, I at least see no
> > reason to stop you.
>
> I agree with Brion completely.  I see some good reasons not to do
> this, but they aren't overwhelming.
>
> Who owns the .pl domain name?  Do we have a firm assurance that it
> will be transferred to the nonprofit at the appropriate time?

Kpjas owns it. CCed to him,


from_name: Magnus Manske

body:
So, it seems (if I interpret Jimbo's mail on wikitech and the discussion
here correctly) that most of us would like *some kind* of category
scheme in wikipedia. I do, too! But, we seem to differ on the details
(shocked silence!).

So far, I saw three concepts:
1. Simple categories like "Person", "Event", etc.; about a dozen total.
2. Categories and subcategories, like
"Science/Biology/Biochemistry/Proteomics", which can be "scaled down" to
#1 as well ("Humankind/Person" or something)
3. Complex object structures with machine-readable meta-knowledge
encoded into the articles, which would allow for quite complex
queries/summaries, like "biologists born after 1860".

Pros:
1. Easy to edit (the wiki way!)
2. Still easy to edit, but making wikipedia browseable by category,
fine-tune Recent Changes, etc.
3. Strong improvement in search functions, meta-knowledge available for
data-mining.

Cons:
1. Not much of a help...
2. We'd need to agree on a category scheme, and maintenance might get a
*little* complicated.
3. Quite complex to edit (e.g., "<category type='person'
occupation='biologist' birth_month='5' birth_day='24' birth_year='1874'
birth_place='London' death_month=.....>")

For a wikipedia I'd have to write myself, I'd choose #3, but with
respect to the wiki way, #2 seems more likely to achieve consensus (if
there is such a thing;-)

Magnus


subject: [Wikitech-l] something is wrong with math

body:
On lun, 2003-02-17 at 11:33, Tomasz Wegrzanowski wrote:
> Brion: have you replaced binaries in /apache/htdocs*/w/math/ directories
>     with new versions ?

Damn, I knew I forgot something... :P

I'll fix it after lunch. (Mmm, lunch.)

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20030217/0e54057e/attachment.pgp>


body:
Karl Eichwalder wrote:

>>3. Quite complex to edit (e.g., "<category type='person'
>>   occupation='biologist' birth_month='5' birth_day='24'
>>   birth_year='1874' birth_place='London' death_month=.....>")
>>
>
>On those issues you can read the documentation on the TEI DTD (Text
>Encoding Initiative - http://www.tei-c.org).
>
I took a look at it.  The complexity seems over the top for some of the
more technophobic people we get here.  Some of the markups may even be
in conflict with Wiki ways.  Besides that it's not clear that it
accomplishes the task of developing a useful kind of indexing for our
purposes.

Eclecticology


subject: [WikiEN-l] Symbols

body:
Magnus Manske wrote:

> For those of you who have the time (I don't, this week), there's a
> (copyrighted) mini-encyclopedia about symbols at
>    http://www.symbols.com/index/wordindex-a.html
> containing about 2.500 entries on different symbols. Maybe we should
> work through the lists there, covering the symbols in the appropriate
> articles, with self-made images, of course :-)

Interesting.  I'm sure it can find a place among the million others on
my things-to-do list :-)

The copyright would likely apply to their texts.  The symbols themselves
are often ancient, and should be public domain.

Eclecticology


subject: [Wikipedia-l] Let Wikipedia mostly categorize itself (was Re: Categories, back to square one)

body:
On Monday 17 February 2003 12:24 pm, Magnus Manske wrote:
> So, it seems (if I interpret Jimbo's mail on wikitech and the discussion
> here correctly) that most of us would like *some kind* of category
> scheme in wikipedia. I do, too! But, we seem to differ on the details
> (shocked silence!).
>
> So far, I saw three concepts:
> 1. Simple categories like "Person", "Event", etc.; about a dozen total.
> 2. Categories and subcategories, like
> "Science/Biology/Biochemistry/Proteomics", which can be "scaled down" to
> #1 as well ("Humankind/Person" or something)
> 3. Complex object structures with machine-readable meta-knowledge
> encoded into the articles, which would allow for quite complex
> queries/summaries, like "biologists born after 1860".
>
> Pros:
> 1. Easy to edit (the wiki way!)
> 2. Still easy to edit, but making wikipedia browseable by category,
> fine-tune Recent Changes, etc.
> 3. Strong improvement in search functions, meta-knowledge available for
> data-mining.
>
> Cons:
> 1. Not much of a help...
> 2. We'd need to agree on a category scheme, and maintenance might get a
> *little* complicated.
> 3. Quite complex to edit (e.g., "<category type='person'
> occupation='biologist' birth_month='5' birth_day='24' birth_year='1874'
> birth_place='London' death_month=.....>")
>
> For a wikipedia I'd have to write myself, I'd choose #3, but with
> respect to the wiki way, #2 seems more likely to achieve consensus (if
> there is such a thing;-)
>
> Magnus

Hm. I agree that #1 would be nearly useless and #3 is asking too much of mere
mortals but #2 smells a lot like subpages. I remember one of the arguments
against subages was that there are multiple ways to express the hierarchy of
most subjects.

So for example, an alternate hierarchy for [[proteomics]] might focus more on
historical development instead; Science/Biology/Molecular
biology/Genetics/Proteomics or depending on  your opinion even
Science/Biology/Molecular biology/Biochemistry/Proteomics. Biographies would
be even more difficult: Biographies/Science/Physics/Albert Einstein vs
Biographies/Science/Physics/Theoretical physics/Albert Einstein vs
Science/Physics/Albert Einstein . But he was also a peace activist so;
Biographies/Politics/Peace activists/Albert Einstein or even
Biographies/Politics/Political movements/Peace activism/Albert Einstein.
Having hierarchies is also bad database design for the above reasons and
because novel and interesting relationships can not be searched for unless a
human has already created a hierarchy specific to that relationship.

What would be much better is to allow a spider to follow links starting from
the Main Page and automaticly classify articles based on what they link to
and what links to them. The spider would check the classification of articles
linked to and from the unclassified article in order to classify it.

Additional tweaks could be added for the spider to determine the
classification of the article based on the presentation of its content and
whether or not they are linked from certain pages that are given more weight.
Our many lists would be very useful here; if something that looks like a
biography to the spider is listed on [[List of astronomers]] then the spider
would classify that article as "astronomer". The classification "astronomer",
in turn, would already be classified under "astronomy", "science" and
probably many other things at varying "weights of relevance".

Biographies, for example, have a certain format (at least in en.wiki) whereby
the birth and death dates are in parenthesis after the name on the first
line. Most of them also state on the first line the country of origin of the
person and their occupation(s). And many are listed on the list of
biographies and lists of people pages and in the birth and death sections of
year and day articles.

All this can be used to classify the article so that the types of queries that
you mention in #3 could be done. Another example is the use of the <math> tag
for writing formula. So having that tag in an article would be /one/ thing
that would be considered by the spider in determining its classification (but
the spider wouldn't categorize the article under "mathematics" unless other
articles linked to and from it are already categorized that way).

And as time goes by we can make this categorization spider more and more
sophisticated. But it will be rather crude at first so a human-powered
feedback mechanism would have to be put into place to tweak the spider. The
many lists that we already have can be a very useful way to prime the spider
to quickly improve its accuracy.

In short, let the complex linking and standardized article formating already
present in Wikipedia determine its own "weighted relationship" categorization
with a minimal amount of human intervention. There is a goldmine of
categorization information already in Wikipedia that hasn't been tapped yet
(like in the BBC program Connections, Wikipedia could eventually be used to
find odd but interesting connections between disparate subjects along with
the more predictable relationships).

Yeah, I know - I'm just dreaming. But it would be a very neat thing to have
and it would greatly minimize the amount of work (and inconsistent guesswork)
that humans would have to do.

But the above is probably already patented by somebody.... Software patents
are evil!

-- Daniel Mayer (aka mav)

WikiKarma:
I expanded and converted [[Titanium]] over to the WikiProject Elements format.


from_name: Lee Daniel Crocker

subject: [Wikipedia-l] Rumors of my death...

body:
It's been a fun couple of months for me, involving spending long
hours at work printing year-end reports and making up for many hours
of productivity lost to my wikihabit, followed immediately by my
buying a house, which is also a big time and money sink.

Anyway, I'm all moved in now (well, at least the important things--
the kitchen and the network), so I hope to get back to contributing.
Finding the new mailing list was simple enough, and I subscribed
with my own address now so I won't have the Nupedia disk-limit
problem any more (my server has a nice 12 gig or so free--that
should handle at least a week or so of list traffic).

I'll have to take a few days to go over the archives as well, but
it looks like Brion and Jimbo and Mav and the gang are doing their
usual bang-up job of keeping the project on track.

--
Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC


from_name: Vicki Rosenzweig

body:
At 01:13 AM 2/16/03 -0800, Zoe wrote:

>While looking at the [[Legionnaires' disease]] page, I noticed a lot of
>information that looked like it had been copied from somewhere.  Indeed,
>it had come from
><http://www.cdc.gov/ncidod/dbmd/diseaseinfo/legionellosis_g.htm>http://www.cdc.gov/ncidod/dbmd/diseaseinfo/legionellosis_g.htm.
>The person who had put it on the page claimed that it was public
>domain.  Looking at the CDC's home page, I find "In general all
>information presented in these pages and all items available for download
>are for public use."
>
>Does this mean we can use the information at that website?

Yes we can. All publications by the US government are in the public domain.
This does *not* apply to publications by other governments: it is a deliberate
choice by the US government.

--
Vicki Rosenzweig
vr at redbird.org
http://www.redbird.org


subject: [Wikipedia-l] Categories, back to square one, part 2

body:
When I suggested a system of codes to enter into coding boxes, I made
reference to a modified version of the Library of Congress
Classification system.  This is not to suggest that it is any better
than anything else; it's just an established system that is a convenient
jumping off point.  Starting from scratch would involve reinventing a
lot of basics.  The LCC is a system based on one, two and sometimes
three letters, a number up to four digits long, a decimal point, and
decimalized alphanumerics of varying lengths.  For practical purposes I
see no reason to go beyond three letters at the beginning, if at all.
 The only conceivable exception for the future would be for a very big
subject area that is just crying for further subdivision.  We would not
be using the system to put numbers on the spines of books to ensure that
the books are put on the right shelf in the library.

The classification system should allow nesting of categories.  Under the
existing LCC "Q" represents sciences in general, "QA" represents
mathematics and no three letter codes are defined in the QAs.  Without
prejudice, this would leave free to define "QAG" to represent geometry.
 From the searcher's point of view, he could find his geometric subject
by searching either Q or QA or QAG, but the result from searching  on Q
could be big and mostly useless to him. An article could be classified
in more than one category; one that deals with both calculus and
geometry could show both a QAG and a QAC category.  Also, a person who
wants to be able to contribute through classifying articles should  have
the option to choose only those items which are unextended when he's
looking for work.

Ib my previous post I mentioned code "AAA" for unclassified, but there
are also other codes that could serve Wikipedia's own special purposes.

Eclecticology


body:
On lun, 2003-02-17 at 13:59, Brion Vibber wrote:
> On lun, 2003-02-17 at 11:33, Tomasz Wegrzanowski wrote:
> > Brion: have you replaced binaries in /apache/htdocs*/w/math/ directories
> >     with new versions ?

Okay, I've updated the binaries and cleared the math tables all around.
Let me know if there are any further problems...

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20030217/2bfc105d/attachment.pgp>


from_name: Karl Eichwalder

body:
Magnus Manske <magnus.manske at epost.de> writes:

> Cons:
> 1. Not much of a help...

Yes, that's it.  It does not help at all (we already have much to many
lists).  Better encourage people to write overview articles! ;-)

Better searching features are missing.  Wildcards and logical
expressions (and/or) would be nice things to have to (okay, one can use
google, but google is always some time behind

> 3. Quite complex to edit (e.g., "<category type='person'
>    occupation='biologist' birth_month='5' birth_day='24'
>    birth_year='1874' birth_place='London' death_month=.....>")

On those issues you can read the documentation on the TEI DTD (Text
Encoding Initiative - http://www.tei-c.org).

And how categorize artists?

--
ke at suse.de (work) / keichwa at gmx.net (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)


body:
Something is wrong with contents of math table on Wikipedias.
On Polish and French math_html is empty, and math_mathml usually
contains what was supposed to go to math_html but without first
character.

On Polish Wikipedia all new formulas are rendered to PNGs now
because of that.

No such problem on test Wikipedia.

Maybe it's problem with incomplete upgrade ?

Brion: have you replaced binaries in /apache/htdocs*/w/math/ directories
    with new versions ?


body:
On Mon, Feb 17, 2003 at 08:33:14PM +0100, Tomasz Wegrzanowski wrote:
> Something is wrong with contents of math table on Wikipedias.
> On Polish and French math_html is empty, and math_mathml usually
> contains what was supposed to go to math_html but without first
> character.
>
> On Polish Wikipedia all new formulas are rendered to PNGs now
> because of that.
>
> No such problem on test Wikipedia.
>
> Maybe it's problem with incomplete upgrade ?
>
> Brion: have you replaced binaries in /apache/htdocs*/w/math/ directories
>     with new versions ?

And if it will fix the problem, please clean all math tables on all
affected Wikis so that they can be refilled with correct values,
and grant rights on them for SQL query user (for some reason it doesn't have
such rights now).


from_name: Brion Vibber

subject: [Wikipedia-l] The pipe trick (ceci ne soit pas une pipe)

body:
As those in the know, er, know, on Wikipedia there's a preprocessor
syntax trick known as the 'pipe trick' which strips parentheticals,
usually disambiguators, from the display of a link:

  [[kingdom (biology)|]]
      turns into:
  [[kingdom (biology)|kingdom]]

so that it shows in the text as simply "kingdom", which is usually what
you want.

It's a nice trick, but there are two things wrong with this system:

First, since the replacement is done at save time instead of at display
time, newbies (who learn the finer points of wiki syntax primarily by
looking at how existing articles are written) can't learn the trick
without hearing about it or poring through the documentation. The tilde
signature system has the same problem; we have to tell newbies about it.

Second, and more importantly, *it's backwards.*

The overwhelming majority of the time we link to a page whose title has
a parenthetical in it, we want to hide the parenthetical and let the
main word stand alone. I'd be very hard pressed to think of a
counter-example that isn't a demonstration of the pipe trick or a
discussion about how to phrase a disambiguation.

Wouldn't it be more sensible if [[kingdom (biology)]] _automatically_
displayed as "kingdom", and in the much rarer cases we had to add a pipe
to force the long form?

After all, we don't need to add a special character to hide the
brackets! They're just part of the markup, telling the wiki parser that
it's dealing with a link. Parentheticals are essentially just more
markup, telling the parser that the link should point to one of several
otherwise ambiguously identified pages.

Thoughts, comments?

What about handling of namespaces and interwiki links? Currently they're
displayed be default, and the pipe trick strips them just like
parentheticals.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20030217/810921dd/attachment.pgp


from_name: Thomas Luft

subject: [Wikitech-l] Installing current CVS snapshot: writing articles doesn't work?

body:
Hi everyone,

I am quite new to Wikipedia and wanted to set up a testing server for
our student organisation using the PHP script. I know some PHP and
MySQL, but don't have experiance with a CVS.

To get a snapshot of the project I used the command "cvs -d
:pserver:anonymous at cvs.wikipedia.sourceforge.net:/cvsroot/wikipedia
checkout phpwiki/newcodebase" as stated here:
http://de.wikipedia.org/wiki/Wikipedia%3APhase_III_Software (at the
bottom of the page).

After uploading everything on the server and adjusting LocalSettings.php
I copied all the files of the maintenance dir to the others and ran
createdb.php. Everything seemed to work fine and the tables were
installed. I tried to edit the Startpage and got the following error
message:

"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:

     INSERT INTO cur
(cur_namespace,cur_title,cur_text,cur_comment,cur_user,cur_timestamp,cur_minor_edit,cur_counter,cur_restrictions,cur_user_text,cur_is_redirect,cur_is_new,cur_random,inverse_timestamp)
VALUES (0,'Hauptseite', 'test', '', '0', '20030217212253', 0, 0, '',
'192.168.68.1', 0, 1, RAND(), '79969782787746')

from within function "Article::insertNewArticle". MySQL returned error
"1054: Unknown column 'cur_random' in 'field list'"."

After checking the tables I found out that the row cur_random does not
exist. I checked the buildtables.inc in the maintenance dir and found
out that there is no cur_random field set up during db creation.

Is it possible to download a kind of stable version of wikipedia via CVS?

Thanks for your help

Thomas
PS: The layout looks a little bit weird with Mozilla and I am unable to
access the top items (drop down menu, talk, log in), is that normal?


from_name: Krzysztof P. Jasiutowicz

body:
> > Brion Vibber wrote:
> > > I think in general using country codes is going to cause more confusion
> > > when linking using language codes, which are *not* always the same. But
> > > if you guys really want it sitting at that location, I at least see no
> > > reason to stop you.
> On Mon, Feb 17, 2003 at 03:25:44AM -0800, Jimmy Wales wrote:
> > I agree with Brion completely.  I see some good reasons not to do
> > this, but they aren't overwhelming.
> > Who owns the .pl domain name?  Do we have a firm assurance that it
> > will be transferred to the nonprofit at the appropriate time?
On 17-02-2003, Tomasz Wegrzanowski wrote thusly :
> Kpjas owns it. CCed to him,
I really do own it but I see this domain as a property of the community of
the Polish Wikipedia. In fact several people donated some money towards
buying this domain. I personally seem to be in favour of transferring it to
the nonprofit but the decision must be first agreed upon within the Polish
Wikipedia. Now it is too soon to tell even without the slightest idea what
the nonprofit is going to be. I think we will act the same as other
Wikipedias (De, NL, Fr, Be). We are the Europeans ;-)

Regards,
Kpjas.


from_name: Erik Moeller

subject: [Wikitech-l] Current Database Download

body:
> On lun, 2003-02-17 at 04:59, Fred Bauder wrote:
>> The database as a whole produces a mirror, but if the point is to use the
>> software to present information in a different way, it would be nice to
>> start with a minimum and then add whichever articles you wanted to use from
>> wikipedia, but only those.

> As a reminder, you may only use these pages as a base for another wiki
> if it, too, will be under GFDL license.

This is not correct. It is only the particular pages (and material added
to them) that must be under the FDL.

Regards,

Erik


subject: [Wikitech-l] Compressing the old table

body:
The storage of old article revisions on Wikipedia is taking a few gigs
now, and getting larger.

Occasional alterations made to the old table's structure require a
duplicate temporary table; the downside of Innodb's storage management
is that while its storage pool can grow automatically, it doesn't
shrink! This leaves us with a few gigs of wasted space on the hard drive
that aren't available for other resources -- log files, uploads, etc
which might be needed. Frankly, we're running a little tight right now.

As the table grows, the doubled space requirements of maintenance time
are similarly going to increase. And even if we switch back to a db
backend that allows reclaiming unused space, we need to keep that space
available for when it comes time to add a field or adjust the indexes.

We could store old revisions as binary blobs compressed with gzip
instead of raw text; this should reduce overall storage requirements by
well over 50%. Performance shouldn't be harmed significantly, as old
versions are loaded relatively rarely and saved only once each.

Pro:
* Saves disk space!
* Should reduce maintenance downtime on table alterations, with less
data to copy around.

Con:
* Old revision contents wouldn't be searchable with straight SQL queries
(LIKE etc).
* Slight speed degredation due to compression/decompression; makes the
code a little more complex.
* PHP needs to be recompiled with zlib support; we may have to make it
optional for third-party sites.
* The downloadable dumps may actually get bigger, depending on how
compressors interact.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20030217/2f056572/attachment.pgp>


subject:
[Wikitech-l] Installing current CVS snapshot: writing articles
 doesn't work?

body:
Brion Vibber wrote:
> I've updated buildTables.inc in CVS; please update and try it again.
> (Or, run patch-random-dateindex.sql over the existing database.)

Thanks, that helped a lot!

> There is no stable version. ;)  Everything's very much under
> development, so occasionally it doesn't quite work out of the box.
> Someday we'll release stable versions, but until then you gotta work
> with it a bit.

Well, doesn't matter as long as everyone is so fast with fixing bugs :-)

>>PS: The layout looks a little bit weird with Mozilla and I am unable to
>>access the top items (drop down menu, talk, log in), is that normal?
>
> Make sure the stylesheets are installed! Check $wgStyleSheetPath in
> LocalSettings.php and make sure the .css files from the 'stylesheets'
> subdirectory of the source are copied there.

Dooh, I missed that... But thanks that helped. Everything is working
fine now. Maybe you should update LocalSettings.php so that the setting
of $wgStyleSheetPath is set to the path you use to store the stylesheets
(currently "stylsheets"). Makes it more easy for newbies.

Cheers

Thomas
wiki at luto.de


subject: [Wikipedia-l] Fwd: Rumors of my death...

body:
The mailing list isn't cooperating with Lee's attempts to send to it, so
I'm forwarding his message here; it may or may not make it through on
its own in a few hours.   -- brion

-----Forwarded Message-----
-----
From: Lee Daniel Crocker <lee at piclab.com>
To: wikipedia-l at wikipedia.org
Subject: Rumors of my death...
User-Agent: Mutt/1.3.27i
X-URL: http://www.piclab.com/lee/

It's been a fun couple of months for me, involving spending long
hours at work printing year-end reports and making up for many hours
of productivity lost to my wikihabit, followed immediately by my
buying a house, which is also a big time and money sink.

Anyway, I'm all moved in now (well, at least the important things--
the kitchen and the network), so I hope to get back to contributing.
Finding the new mailing list was simple enough, and I subscribed
with my own address now so I won't have the Nupedia disk-limit
problem any more (my server has a nice 12 gig or so free--that
should handle at least a week or so of list traffic).

I'll have to take a few days to go over the archives as well, but
it looks like Brion and Jimbo and Mav and the gang are doing their
usual bang-up job of keeping the project on track.

--
Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC


subject: [WikiEN-l] Symbols

body:
For those of you who have the time (I don't, this week), there's a
(copyrighted) mini-encyclopedia about symbols at
    http://www.symbols.com/index/wordindex-a.html
containing about 2.500 entries on different symbols. Maybe we should
work through the lists there, covering the symbols in the appropriate
articles, with self-made images, of course :-)

Things like "*Aesculapii staff" are not covered in the wikipedia yet
AFAIK, and I think they should be.

Magnus
*


from_name: Youandme

subject: [Wikipedia-l] Creating categories through voting

body:
I will describe my idea of creating categories through voting
in points (still a kind of draft):
// implementation notes are marked as here

Vote for category link on every page can lead
to Add keywords to the article you edit
// only one extra box needed

Software will count keywords as votes for particular categories.
// only one table for categories is needed
//   cat_id, cat_name, cat_votes
// keywords can have mulptiple words like "physical anthropology"
//   so some separator is needed

Keywords added by person who done some edit are weighted higher
e.g. like 5 'viewers votes'.
// this extra box can appear under editing pane like
// the description box appears

It is not obligatory to add any keyword in this case.

At the top of the article all categories can be presented
in the order of descending number of votes (let's say top 10).

If you disagree with the fact of a given article being in some category
or so high in the hierarchy preceed a keyword with minus sign.

Everybody (and especially admins) can view the whole list of categories
that a given article was assigned to (the number of votes are presented as well).
// maybe Special:Assignedto page?

Admins can remove real rubbish links to categories (including vandalism).
// delete link on said Special:Assignedto page (or a series of check-boxes)

Removed links are logged on a special page - that way everyone can check
if some admin overuses his rights.

=== Sifter extension ===

Another voting system could be implemented for "certified"
users who can vote for quality. This could incorporate "lighter" idea
of sifter into Wikipedia.

This won't have influence on editing capabilities of anyone.

Sister voting system, third one, could be implemented
for "certified" users who will vote for their category scheme.

Everyone can select either first or the second category scheme
or both when viewing article. As well, anyone can select quality
note to be rendered on the page.

----

Open problems:
- Will people like it?
- How filter RecentChanges with so many categories?
- What if a vandal, insane user, etc edits just to promote an article
  in a given category? How to decrease voting counters?
- Should we stick to stif tree-like structures?
  (Inclusion of one category into another can be done through...
  voting on Category:Foobar_category page that describes
  this particular category)

Regards,
  Youandme

----------------------------------------------------------
Think fast! This message will self-forget in 15 minutes ;)


subject: [Wikitech-l] Creating categories through voting


references:
<3E50DB6F.2020001@epost.de> <shsmum6b2c.fsf@tux.gnu.franken.de>
	<3E516CCD.7040703@telus.net>

body:
Ray Saintonge <saintonge at telus.net> writes:

> I took a look at it.  The complexity seems over the top for some of the
> more technophobic people we get here.

Yes, it's complex, but very mature.

> Some of the markups may even be in conflict with Wiki ways.

One could add namespaces to solve this issue.  Okay, that's even more
complexity ;)

> Besides that it's not clear that it accomplishes the task of
> developing a useful kind of indexing for our purposes.

Yes, that's the question.  Since I don't have that much experience with
the wikipedia I don't want to judge.

OTOH, I'd like basing a more specialized wiki on the TEI DTD -- just as
a proof of concept.  Does anybody know about such a wiki software?  In
other words: I'm interested in a wiki implemented as a conforming SGML
or XML application (for my own research purposes, not as a replacement
for wikipedia).

--
ke at suse.de (work) / keichwa at gmx.net (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)


body:
Brion Vibber <brion at pobox.com> writes:

> Wouldn't it be more sensible if [[kingdom (biology)]] _automatically_
> displayed as "kingdom", and in the much rarer cases we had to add a pipe
> to force the long form?

I'm inclined to say "no".  We use the current behavior when we write a
disambiguation page (translated from the German Wikipedia):

'''Marburg'''
#city in Hesse, Germany: [[Marburg (Lahn)]]
#city in Steiermark, Austria: [[Marburg (Drau)]]

(Thus far, both these article do not exist ;) ]

The less tricks, the better.  That's also the XML philosophy.

--
ke at suse.de (work) / keichwa at gmx.net (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)


from_name: Jimmy Wales

subject: [WikiEN-l] River names Oder/Odra and Neisse/Nysa

in_reply_to: <HFKI1WEKEPL3VC8JFRNWR4XQND0JG61.3e525c26@mt>; from mt@mirko-thiessen.de on Tue, Feb 18, 2003 at 05:15:34PM +0100

body:
Mirko Thiessen wrote:
> I'd like to ask the community, which name is used more often by
> native English speakers.

Searching only English pages for
"Oder River" -- 2,970
"Odra River" -- 1,730
Oder River -- 35,000
Odra River --  3,940

"Neisse River" --   415
"Nysa River"   --    38
Neisse River -- 1,600
Nysa River   -- 1,920

On the other hand, [[user:Space Cadet]] on User_talk:Taw has written:

>Or, why don't we just wait a couple more months until the "official
>English name" changes to the original "ODRA" and everybody's happy?
>Let's look into the future!"

I'm not sure what this means, exactly, since there is no such thing as
"official" English, but I assume it means something, and whatever it
does mean, is probably an important factor.

What do dictionaries say?  What does Britannica do?  Encarta?
U.S. government sources?  British and Australian government sources?

--Jimbo


subject: [Wikitech-l] Compressing the old table

body:
> The storage of old article revisions on Wikipedia is taking a few gigs
> now, and getting larger.

About how much are we talking here? Space is cheap.

> We could store old revisions as binary blobs compressed with gzip
> instead of raw text

If we do this, we should not do this on the last n revisions, so that
recent changes are still quickly available for diffs. I suggest n=5.

But yes, I was afraid we would be running into this problem sooner or
later when I first realized that we were, in fact, storing every version.
Some 30k articles are edited dozens of times in edit wars. We could, of
course, also use diffs+snapshots every x revisions.

I'm also thinking of a good way to implement my "merge subsequent edits by
one user" proposal to drastically reduce the number of edits.

Regards,

Erik


from_name: Jason Richey

subject: [Wikitech-l] Compressing the old table

in_reply_to: <1045548145.16923.279.camel@rdaneel.vibber.org>; from brion@pobox.com on Mon, Feb 17, 2003 at 10:02:25PM -0800

body:
This should be less of an issue when we separate the webserving and
the database serving...

Jason

Brion Vibber wrote:

> The storage of old article revisions on Wikipedia is taking a few gigs
> now, and getting larger.
>
> Occasional alterations made to the old table's structure require a
> duplicate temporary table; the downside of Innodb's storage management
> is that while its storage pool can grow automatically, it doesn't
> shrink! This leaves us with a few gigs of wasted space on the hard drive
> that aren't available for other resources -- log files, uploads, etc
> which might be needed. Frankly, we're running a little tight right now.
>
> As the table grows, the doubled space requirements of maintenance time
> are similarly going to increase. And even if we switch back to a db
> backend that allows reclaiming unused space, we need to keep that space
> available for when it comes time to add a field or adjust the indexes.
>
>
> We could store old revisions as binary blobs compressed with gzip
> instead of raw text; this should reduce overall storage requirements by
> well over 50%. Performance shouldn't be harmed significantly, as old
> versions are loaded relatively rarely and saved only once each.
>
> Pro:
> * Saves disk space!
> * Should reduce maintenance downtime on table alterations, with less
> data to copy around.
>
> Con:
> * Old revision contents wouldn't be searchable with straight SQL queries
> (LIKE etc).
> * Slight speed degredation due to compression/decompression; makes the
> code a little more complex.
> * PHP needs to be recompiled with zlib support; we may have to make it
> optional for third-party sites.
> * The downloadable dumps may actually get bigger, depending on how
> compressors interact.
>
> -- brion vibber (brion @ pobox.com)

--
"Jason C. Richey" <jasonr at bomis.com>


from_name: Zoe

body:
Definitely Oder and Neisser.  I never even heard of Odra and Nysa.
Zoe
 Mirko Thiessen <mt at mirko-thiessen.de> wrote:Hello all,

there is a dispute in several articles, whether the Oder/Odra river should be called by its
German or its Polish name. The same for the Neisse/Nysa river and the Oder-Neisse
line/Odra-Nysa line. I'd like to ask the community, which name is used more often by
native English speakers. There are some annoying accusations in this dispute (see
[[User talk:Taw|Taw's talk page]] for more details), so I would like to let the majority
decide and end the seesaw changes on the relating pages.

Mirko.

--
Mirko Thiessen
http://www.mirko-thiessen.de

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

---------------------------------
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030218/8915a0e9/attachment.htm


from_name: Tobin Richard

subject: [Wikitech-l] wikipedia setup issue.

body:
I've setup localsettings.php and createdb.php to use the correct
database but I continue recieving the following message.

"Parse error: parse error, unexpected T_VARIABLE in
/home/tobin/public_html/LocalSettings.php on line 10
Creating new tables. Could not select database
No Database Selected (tried non-p connect)

If this error persists after reloading and clearing your browser cache,
please notify the Wikipedia developers."

Server Information:
Operating System Linux
Kernel Version 2.4.7-10
Last Reboot  19days, 22:22min
Apache Version 1.3.27 (Unix)
Perl Version 5.006001
Perl Path /usr/bin/perl
Sendmail Path /usr/sbin/sendmail
Perl Modules Click to View
PHP Version 4.2.2
MySQL Version 3.23.54
cPanel Version 6.0.0-EDGE
cPanel Build 56
cPanel Theme cPanel X v1.4

Thanks in advance
Tobin Richard


subject:
[Wikipedia-l] Let Wikipedia mostly categorize itself (was Re:
 Categories, back to square one)

body:
Daniel Mayer wrote:

>Hm. I agree that #1 would be nearly useless and #3 is asking too much of mere
>mortals but #2 smells a lot like subpages. I remember one of the arguments
>against subages was that there are multiple ways to express the hierarchy of
>most subjects.
>
<snip>[[proteomics]] and [[Albert Einstein]] examples</snip>

The way my "#2" is supposed to work is like this:
* we put [[category:proteomics]] into, say, a [[tertiary protein
structure]] article
* we say (somewhere else) that the category "proteomics" is a child of
the category "biochemistry"
* likewise, it is a child of the category "genetics" (doubtful, though;-)
So, each category can have multiple parents, and we can assign multiple
categories to an article. Either all combinations would show on the
article page (we just need to make room for them...), or just
"proteomics", linking to [[category:proteomics]], which shows
* all articles in that category
* all its parent categories

>What would be much better is to allow a spider to follow links starting from
>the Main Page and automaticly classify articles based on what they link to
>and what links to them. The spider would check the classification of articles
>linked to and from the unclassified article in order to classify it.
>
We could start a classification with such a spider, but not for all
articles, I guess. Maybe to a level 2 or something. Our heavy
interlinking would assign articles to all kinds of categories otherwise.

>Biographies, for example, have a certain format (at least in en.wiki) whereby
>the birth and death dates are in parenthesis after the name on the first
>line. Most of them also state on the first line the country of origin of the
>person and their occupation(s). And many are listed on the list of
>biographies and lists of people pages and in the birth and death sections of
>year and day articles.
>
This would result in a lot of false positives, as well as false
negatives, which we'd have to clean up manually.

>All this can be used to classify the article so that the types of queries that
>you mention in #3 could be done. Another example is the use of the <math> tag
>for writing formula. So having that tag in an article would be /one/ thing
>that would be considered by the spider in determining its classification (but
>the spider wouldn't categorize the article under "mathematics" unless other
>articles linked to and from it are already categorized that way).
>
Again, false positives/negatives.

>And as time goes by we can make this categorization spider more and more
>sophisticated. But it will be rather crude at first so a human-powered
>feedback mechanism would have to be put into place to tweak the spider. The
>many lists that we already have can be a very useful way to prime the spider
>to quickly improve its accuracy.
>
All in all, I think we'd spend more time cleaning up after the spider
than doing it all manually in the first place. We could have a special
page with "hints", though. Say, an article is linked from at least two
articles that are categorized as "biochemistry". The special page could
then say "article [[xzy]] is likely to be in category 'bla'.", with a
button to assign that category to [[xzy]].

>In short, let the complex linking and standardized article formating already
>present in Wikipedia determine its own "weighted relationship" categorization
>with a minimal amount of human intervention. There is a goldmine of
>categorization information already in Wikipedia that hasn't been tapped yet
>(like in the BBC program Connections, Wikipedia could eventually be used to
>find odd but interesting connections between disparate subjects along with
>the more predictable relationships).
>
>Yeah, I know - I'm just dreaming. But it would be a very neat thing to have
>and it would greatly minimize the amount of work (and inconsistent guesswork)
>that humans would have to do.
>
IMHO wikipedia is *way* to informal to make such a spider with the
necessary accuracy. If we had <birthday> tags or something, it would be
a lot easier. But, we can do certain things half-automagically. For
example, on each year page, in the "Birth" and "Death" sections, the
very first link in each list item is most likely to be a person...

>But the above is probably already patented by somebody.... Software patents
>are evil!
>
>
Not unless Micro$oft patents the use of the *right* mouse button (Apple
only used one, AKA the left one!)

Magnus


from_name: Anthere

body:
--- Brion Vibber <brion at pobox.com> wrote:
> As those in the know, er, know, on Wikipedia there's
> a preprocessor
> syntax trick known as the 'pipe trick' which strips
> parentheticals,
> usually disambiguators, from the display of a link:
>
>   [[kingdom (biology)|]]
>       turns into:
>   [[kingdom (biology)|kingdom]]
>
> so that it shows in the text as simply "kingdom",
> which is usually what
> you want.
>
> It's a nice trick, but there are two things wrong
> with this system:
>
> First, since the replacement is done at save time
> instead of at display
> time, newbies (who learn the finer points of wiki
> syntax primarily by
> looking at how existing articles are written) can't
> learn the trick
> without hearing about it or poring through the
> documentation.

You know what ? I feel a newbie, I didnot know about
this trick :-)

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com


body:
Anthere wrote:
> You know what ? I feel a newbie, I didnot know about
> this trick :-)

Yeah, me too!

--Jimbo


from_name: Fred Bauder

body:
Remembering that we have no opinion ourselves and that the object is to
transmit information to our users who may use either name, we should use
both.

Fred

> From: Mirko Thiessen <mt at mirko-thiessen.de>
> Reply-To: wikien-l at wikipedia.org
> Date: Tue, 18 Feb 2003 17:15:34 +0100
> To: wikien-l at wikipedia.org
> Subject: [WikiEN-l] River names Oder/Odra and Neisse/Nysa
>
> Hello all,
>
>
> there is a dispute in several articles, whether the Oder/Odra river should be
> called by its
> German or its Polish name. The same for the Neisse/Nysa river and the
> Oder-Neisse
> line/Odra-Nysa line. I'd like to ask the community, which name is used more
> often by
> native English speakers. There are some annoying accusations in this dispute
> (see
> [[User talk:Taw|Taw's talk page]] for more details), so I would like to let
> the majority
> decide and end the seesaw changes on the relating pages.
>
>
> Mirko.
>
> --
> Mirko Thiessen
> http://www.mirko-thiessen.de
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikien-l


from_name: Poor, Edmund W

body:
Thanks, tough cat. I appreciate your concern both for the integrity
of the encyclopedia and for the inclusiveness of the community. We
want to keep bad _material_ out while encouraging new _contributors_
to come in and learn the ropes.

Uncle Ed

-----Original Message-----
From: Tucci [mailto:tucci528 at yahoo.com]
Sent: Sunday, February 16, 2003 3:04 PM
To: wikien-l at wikipedia.org
Subject: [WikiEN-l] empty album pages, years in MTV and KROQ, Baha
Men...

I just banned an anonymous user who had created many
of the track-listing only album pages, future-releases
on 2003 in music, plus list of years in KROQ, a
fact-free article on the Baha Men and, most recently,
list of years in MTV and related pages.  See User
talk:64.175.250.205 for the sordid details of the MTV
stuff, which was what made me finally do it.

I hesitated because he has entered true and relevant
information, it just takes me three times as long to
fix it than it took him to write it.  Plus, the Baha
Men thing scared me, because I would never have
bothered to check the facts if somebody hadn't pointed
out that the article said they formed in 1987 and 1988
-- a quick trip to allmusic shows they released their
debut in 1979, and that many of the other facts were
simply wrong as well.

Maybe the ban should be lifted in a day or two, as he
has at least discovered talk pages.  Anyway, I just
wanted to make a note here on the mailing list since
I'm normally opposed to banning users who have made
valuable edits in the past.

Tokerboy


body:
On mar, 2003-02-18 at 10:42, Anthere wrote:
> You know what ? I feel a newbie, I didnot know about
> this trick :-)

Don't feel bad -- *I* didn't know about it for six months!

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20030218/b95c8a7c/attachment.pgp


from_name: Daniel Mayer

subject: [Wikipedia-l] Re: The pipe trick (ceci ne soit pas une pipe)

body:
Brion Vibber wrote:
>....
>Wouldn't it be more sensible if [[kingdom (biology)]]

>_automatically_ displayed as "kingdom", and in the
>much rarer cases we had to add a pipe to force the
>long form?
>...

Yes that would be much more sensible and unless there
is an objection I say go ahead and implement it (with
the proper announcements to Wikipedia News on meta of
course).

>What about handling of namespaces and interwiki
>links? Currently they're displayed be default,
>and the pipe trick strips them just like
>parentheticals.

I rarely ever want to actually display any namespace
(including interwiki ones) other than the various talk
namespaces.  IMO all non-talk namespaces (wikipedia,
user, special and interwiki) should  not displayed by
default.

Question:

What about all the piped links that are already in
Wikipedia? Will all instances of [[kingdom (biology) |
kingdom]] that are in articles right now be converted
to [[kingdom (biology)]] but displayed as
kingdom? Or would  [[kingdom (biology)]]
automatically be converted to  [[kingdom (biology) |
kingdom]] in the wiki code upon save? Or would we keep
all cases of  [[kingdom (biology) | kingdom]] and
still support that syntax but also support [[kingdom
(biology)]] being displayed as just kingdom
without converting the wiki code to  [[kingdom
(biology) | kingdom]] at save?

What would also be nice is the extend the pipe trick
for comma titles. IMO to follow the logic of your
proposed change [[Auburn, California]] would
automatically become [[Auburn, California | Auburn]]
but that may brake many links that already intend to
display the whole link name. So just to make linking
easier for at least those in the know perhaps
[[Auburn, California | ]] could be displayed as just
Auburn but in the wiki code it could still be
[[Auburn, California | ]] so that newbies can figure
out the trick. Yeah I know this would be inconsistent
with the proposed change in how the pipe trick works
with parentheticals but it is still tedious to type
[[Auburn, California | Auburn]] all the time.

-- Daniel Mayer (aka mav)

WikiKarma
I added many events to [[February 10]] and updated all
the year and many of the other pages linked from that
page.)

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com


body:
On Tue, 18 Feb 2003, Karl Eichwalder wrote:
> Daniel Mayer <maveric149 at yahoo.com> writes:
> > What about all the piped links that are already in
> > Wikipedia?
>
> Of course, they must stay as are!  Look at
> http://de.wikipedia.org/wiki/Marburg and you will see what I mean.

Why? The 1% of cases where you _want_ to display the parenthetical can
simply use the long syntax.

>  No more tricks please or I'll start loosing confidence in the project
> as a whole.

You clearly have a different idea of what "tricks" constitute than I do,
or you'd be clamoring to get rid of the ugly tricks we're currently forced
to use on 99% of links to disambiguated page titles.

-- brion vibber (brion @ pobox.com)


from_name: Ray Saintonge

body:
Fred Bauder wrote:

>Remembering that we have no opinion ourselves and that the object is to
>transmit information to our users who may use either name, we should use
>both.
>
That doesn't solve the problem.  We still have to chose which has the
article and which has the redirect.

Eclecticology


body:
Jimmy Wales wrote:

>Mirko Thiessen wrote:
>
>>I'd like to ask the community, which name is used more often by
>>native English speakers.
>>
>
>On the other hand, [[user:Space Cadet]] on User_talk:Taw has written:
>
>>Or, why don't we just wait a couple more months until the "official
>>English name" changes to the original "ODRA" and everybody's happy?
>>Let's look into the future!"
>>
>I'm not sure what this means, exactly, since there is no such thing as
>"official" English, but I assume it means something, and whatever it
>does mean, is probably an important factor.
>
>What do dictionaries say?  What does Britannica do?  Encarta?
>U.S. government sources?  British and Australian government sources?
>
I looked at this last Nov. 6 and remarked at [[Talk:Oder]]

> Wikipedia is an English language encyclopedia. As such the names
> should be the English language names without regard to local political
> sensitivities. Here "Oder" is the correct conventional name in
> accordance with NIMA: http://www.nima.mil/gns/html/index.html
>
I hadn't looked at the other river then, and I now find that it uses
"Neisse" as the conventional name.

Space Cadet made a similar response in a slightly more expanded version
on that talk page.  It seems that in repeating himself he changed
"conventional" to "official".  His waiting for the "official" name to be
changed may be an exercise in wishful thinking.  The simple fact that
English is a Germanic rather than a Slavic language also favours the
affinity to Oder and Neisse.

Eclecticology


from_name: Jay Bowks

body:
One of the neat things about
reading all these messages is
the feeling I get that although
a newbie, I'm feeling pretty
confident about wiki-editing.
I feel a wiki attack coming on...
Ay ay ay!!!
Wiki'ing is wiki good.

But seriously, thanks for all
these neat tricks that keep
coming in my inbox. We've
made some progress on our
ia.wiki.com and it only keeps
getting better, thanks to you
all!
Jay B.

----- Original Message -----
From: "Brion Vibber" <brion at pobox.com>
To: "wikipedia-l" <wikipedia-l at wikipedia.org>
Sent: Tuesday, February 18, 2003 2:05 PM
Subject: Re: [Wikipedia-l] The pipe trick (ceci ne soit pas une pipe)


subject: [Wikitech-l] wikipedia setup issue.

body:
On Tue, 18 Feb 2003, Tobin Richard wrote:
> I've setup localsettings.php and createdb.php to use the correct
> database but I continue recieving the following message.
>
> "Parse error: parse error, unexpected T_VARIABLE in
> /home/tobin/public_html/LocalSettings.php on line 10
> Creating new tables. Could not select database
> No Database Selected (tried non-p connect)

Make sure the username & password settings are correct, and that you've
set up the user permissins on MySQL. Modify and run buildUsers.inc
appropriately.

-- brion vibber (brion @ pobox.com)


body:
LDC wrote:
>I should be subscribed now.
>....

Welcome back!

>....
>The syntax of a language intended for
>non-technical folks should be as simple
>and unsurprizing as possible.

I agree.

>If we can throw a bone to the old hands
>now and then to make their job easier too,
>that's fine--that's why I added the pipe
>trick in the first place.

An extension of the pipe trick to also work with comma
titles - perhaps. :)

>....

>What I /would/ support is changing the
>piped syntax so that it was interpreted
>at render time rather than save time; so
>that, for example, [[Mercury (planet) | ]]
>would remain in the page source code as is,
>rather than being expanded right away.

Hm. I think you have convinced me. It is not much
extra work at all to simply place a pipe after the
closing parens. And if this syntax is kept as is then
newbies are much more likely to discover this trick on
their own - in the same way as they quickly discover
that ''' placed before and after a term bolds the term
when it is displayed. Keep it simple.

--Daniel Mayer (aka mav)

WikiKarma:
Added a bunch of events to [[February 12]] and updated
all the year and many of the other articles linked
from that page.

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com