subject: [Wikipedia-l] A quick thought about 1.0

body:
On Friday, December 19, 2003, at 04:26  PM, Peter Jaros wrote:

> On Friday, December 19, 2003, at 01:30  AM, Arvind Narayanan wrote:
>
>> For me there's a huge difference. My latency on wikipedia
>> is usually between 5 and 10 seconds. OTOH I have high bandwidth.
>> So I would greatly prefer to download a huge article at once.
>
> Same here.  At least.  But for bigger articles, it's longer.

That was really unclear.  'Same here' should refer to the latency, not
the opinion.  Sorry about that.

Peter

---
Funding for this program comes from Borders without Doctors: The
Bookstore Chain That Sounds Like a Charity.
		--Harry Shearer, Le Show


list: wikipedia-l

source: pipermail-mbox

from_name: Peter Jaros

subject: [Wikipedia-l] Monolithic articles vs parents and daughters

body:
On Friday, December 19, 2003, at 01:57  PM, Daniel Mayer wrote:

> I just want to clarify my statement that it is best to divide topics
> into
> digestible bits. I think this should only be considered for most
> articles
> once they reach the 20 KB (minus markup) size and the resulting
> daughter
> articles are not stubs. Although some articles demand a larger size
> just to
> summarize all the main points and clearly link to daughters that have
> move
> detail on each of those points.

I'll agree with that, and amend my previous opinion to do so (for all
of you keeping score at home).

Sometimes it's appropriate to have a long article, sometimes not.  I
think it's foolish to set a definite size limit as a 'rule', but as a
rule of thumb I agree.

I don't like the idea of daughter articles, though.  Sounds too much
like another word for subpage to me.  If it doesn't work out of
context, it should be a subpage, or, if we don't want subpages, we
should include it in the main article.  Personally, I'd rather use
subpages in this case, but the consensus seems to be against me.

Peter

---
Funding for this program comes from Borders without Doctors: The
Bookstore Chain That Sounds Like a Charity.
		--Harry Shearer, Le Show


from_name: Erik Moeller

body:
Daniel-
> I just want to clarify my statement that it is best to divide topics into
> digestible bits. I think this should only be considered for most articles
> once they reach the 20 KB (minus markup) size and the resulting daughter
> articles are not stubs. Although some articles demand a larger size just to
> summarize all the main points and clearly link to daughters that have move
> detail on each of those points.

I agree with you, except for the 20K ;-). I hope we can formulate a
standard policy for this.

Regards,

Erik


list: wikien-l

from_name: Docpetersn at aol.com

subject: [WikiEN-l] Wikipedia is a great work

body:
Ladies and Gentlemen,
                   I write to applaud your public-spiritedness. Wikipedia is
a great idea. How are you funded?  How can I help?

Andrew R.Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20031219/219a98eb/attachment.htm


from_name: Jussi-Ville Heiskanen

subject: [Wikipedia-l] A quick thought about 1.0

body:
On Fri, 2003-12-19 at 17:11, The Cunctator wrote:

    > From: Erik Moeller on Friday, December 19, 2003 5:01 AM
    > To: wikipedia-l at Wikimedia.org
    > Subject: Re: [Wikipedia-l] A quick thought about 1.0
    >
    > Erik-
    > > That should be "aestehtic", btw.
    >
    > Ugh, "aesthetic" of course. There's got to be some natural law that
    when
    > pointing out spelling errors in other people's messages, you will
    > inevitably make at least one yourself.
    >
    It is a recognized phenomenon...not sure if it's been given a name.

Typoietic conservation law? (just a suggestion)

--
Jussi-Ville Heiskanen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20031219/bdeedb40/attachment.htm


list: wikitech-l

from_name: zocky

subject: [Wikitech-l] Please disregard previous message from me

body: It is old and has been dealt with.


subject: [Wikitech-l] Edit conflicts on section editing

body:
If we treated section' s path as its ID, we could get rid of most conflicts
when editing sections.

''Disclaimer: this should work fairly well for two users in conflict. I'm
not sure how scalable it is or needs to be.''

Construct paths from heading texts, separated by #. Where needed, add
dissambig characters. Use the path to identify sections when editing.

Provide users with an option to either edit the section with it subsections
(so the smallest needed part is edited when restructuring) or just the text
of the section (to edit even less when appropriate).

So, users U1 and U2 are concurrently editing section S1 and S2 and then U1
saves the page with his version of S1. U2 tries to save the page with his
edit of S2, but gets an edit conflict. What's to be done?

1) If S1 and S2 are same, show diff and let U2 handle it.

2 ) If S1 and S2 are disjunct (i.e. one is not included in the other), there
is no conflict. Overwrite S2 with U2's version and save.

3) If S1 and S2 are not disjunct, we call the larger one (S) and the smaller
one (s). Check if (s) exists in the newest version of (S).

3.1) If (s) doesn't exist, present U2 with the diff page for (S).

3.2) If  (s) exists, and U1 changed its contents, present  U2 with the diff.

3.3) If (s) exists, and the user who edited (S) did not change its contents,
replace it with the version of the user who edited (s) (this is quite
automagical, so if conservative,  present U2 with the diff)

3.4) When U2 finally saves the page, record the version as an edit of (S) to
ensure correct behaviour.

Additional tuning may be needed:
Maybe show separate diff for (s) and show source of (s) in the version where
it was directly chosen for editing .

What happens when U1 changed the title of the section, (or ordering of
sections with the same names) but left the contents alone? Should we bother
to check for it? Maybe keep CRC's of section contents?  (They can be kept in
the source- filter them out on display and edit, calculate new and store on
save)

~~~~ zocky


from_name: Jimmy Wales

subject:
[Wikitech-l] [ken@dobruskin.com: Forbidden access to wikipedia
	server]

body:
Ken,  I'm forwarding your inquiry to wikitech-l.

----- Forwarded message from Ken Dobruskin <ken at dobruskin.com> -----

From: Ken Dobruskin <ken at dobruskin.com>
Date: Fri, 19 Dec 2003 12:00:02 +0100 (CET)
To: Jimbo Wales <jwales at bomis.com>
Subject: Forbidden access to wikipedia server

Greetings!

After reading the Wikipedia GFDL and policy on robots, I thought I'd try an experiment, absolutely in line with said policies.

However when I tried to access the site from my server it failed with a 403.

User-agent: Python-urllib/1.15
IP address: 216.28.158.40

Sorry if I should be asking this to the mailing list, but I did see a word about access issues to be addressed to a site admin.

Would appreciate your advice.

Best 'net regards,

Ken

----- End forwarded message -----


subject: [Wikipedia-l] Shirt / Wikipedia-Logo

body:
Kurt Jansson wrote:
> Would it be okay for the foundation to get some money through cafepress?
> If the answer is yes this would also be true for the Amazon partnership
> program, right?

It's o.k. with me on both of those, but Amazon in particular is much
hated in the free software community, so I haven't ever followed up on
it.  I don't think anyone has any objection to CafePress, not that I
know of.

--Jimbo


subject: [Wikitech-l] Wikipedia : MediaWiki

body:
zocky wrote:
> A) MediaWiki is a general purpose wiki infrastructure, which also runs
> Wikipedia. Developers of MediaWiki should concentrate on making the best
> possible software and editors of Wikipedia should take advantage of new
> features as they're provided.
>
> B) MediaWiki is support infrastructure for Wikipedia. Editors of Wikipedia
> should decide what kind of behaviour and which features Wikipedia needs and
> developers of MediaWiki should implement them.

I'm primarily supportive of (B).  I have no problems with MediaWiki
being accessible for other users, because if it is, then we'll attract
more developer talent, which is a good thing.  But I think our primary
focus ought to be support of the encyclopedia project.

--Jimbo


from_name: Brion Vibber

body:
> ----- Forwarded message from Ken Dobruskin -----
>
> However when I tried to access the site from my server it failed with
> a 403.
>
> User-agent: Python-urllib/1.15

Along with dozens of whole-site-downloaders and known mail-harvester
bots, Wget, Python-urllib, and libwww-perl are blocked by default,
sorry.

Please give your bot a real user-agent string that can be
_individually_ blocked if your bot accidentally goes mad (hey, it
happens).

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


subject: [Wikipedia-l] A quick thought about 1.0

body:
Peter Jaros wrote:
> >OK, let's make this quick:
> >What we need is a non-editable subset of wikipedia, correct?
>
> Hold up.  Do we?  Is this to be a paper or electronic encyclopedia?  Or
> both?  Or am I talking about two different proposals?  It seems a shame
> to me to freeze and de-wikify entries if not for the sole purpose of
> inscribing it on a medium that can't be edited (ie., paper).  I would
> much prefer a tagging system which allows us to mark entries as
> complete.  Note that 'complete' is not the same as 'finished'.  No
> entry should ever be finished.  But some entries have achieved
> completion, where the need only adjustment; think opposite of stub.
> Furthermore, these entries rarely devolve from their complete status,
> though if they did for some reason the tag could be quickly removed
> (or, preferably, the entry re-completed :) ).

You said a lot in this paragraph, but as far as I can tell I agree
with you on some crucial points.

1.  "freezing" is bad terminology, because it implies some inability
for people to continue editing the article,

2. instead, "tagging" particular versions as "good enough" is what we
want.  I like the "good enough" terminology rather than either
"complete" or "finished".  Basically a "good enough" article is one
which someone could print on paper and distribute in a bookstore
without feeling too stupid.

-----

Imagine this scenario -- a publisher says to the Wikimedia Foundation,
"We are prepared to distribute your encyclopedia worldwide in
bookstores for 1/10th the price of a new Britannica, and pay royalties
to the foundation to pay for new servers and whatnot, all you have to
do is send us a complete extract of articles that are good enough."

We'd like to be able to do that, without having to laboriously go over
the database _one last time_, because we'd like to already have
flagged some 60,000-100,000 "good enough" articles.

Let's say an article is flagged "good enough".  Then it gets edited.
That edit should, in some cases, not automatically result in the new
version also being tagged "good enough", because it might be an act of
vandalism that takes place just moments before I run the 'extract'
command to send the files to the printer.

On the other hand, if an article is "good enough" and some edits come
in that make it better, obviously we want it to be easy to update so
that the newer version is the "good enough" version.

--Jimbo


subject: [Wikitech-l] Wikipedia : MediaWiki

body:
On Dec 20, 2003, at 05:30, zocky wrote:
> A) MediaWiki is a general purpose wiki infrastructure, which also runs
> Wikipedia. Developers of MediaWiki should concentrate on making the
> best
> possible software and editors of Wikipedia should take advantage of new
> features as they're provided.
>
> B) MediaWiki is support infrastructure for Wikipedia. Editors of
> Wikipedia
> should decide what kind of behaviour and which features Wikipedia
> needs and
> developers of MediaWiki should implement them.

C) MediaWiki's primary user is Wikipedia and most of the developers are
Wikipedians. We do want to be easy to setup and use generally, but most
of us are going to be working on what we think would be good for
Wikipedia. As volunteers in our spare time, none of us are bound to
implement behaviors and features that other people think would be nice,
whether on Wikipedia or not.

Others' opinions may vary of course; Evan runs Wikitravel for instance
and may have different particular interests.

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


from_name: Daniel Mayer

subject: [Wikitech-l] Wikipedia : MediaWiki

body:
Jimbo wrote:
>I'm primarily supportive of (B).  I have no problems with
>MediaWiki being accessible for other users, because if it is,
>then we'll attract more developer talent, which is a good
>thing.  But I think our primary focus ought to be support
>of the encyclopedia project.

So I guess the needs of Wiktionary, Wikiquote, Wikibooks, and Wikisource (not
to mention Wikitravel) are secondary then? MediaWiki should serve /all/ of
Wikimedia and also our friends over at Wikitravel. However by doing so it
will become a general use wiki that can be used for many non-Wikimedia
projects.

But please lets stop supporting Wikipedia-centracism/chauvinism and work
toward making MediaWiki maximally useful to all Wikimedia projects.

-- Daniel Mayer (aka mav)


body:
zocky-
> Construct paths from heading texts, separated by #. Where needed, add
> dissambig characters. Use the path to identify sections when editing.

What do you mean? Headers are already translated to anchors. Try
http://en.wikipedia.org/wiki/Biology#Evolution_and_biology

If there are two or more headers of the same name, the duplicates will be
numbered.

> Provide users with an option to either edit the section with it subsections
> (so the smallest needed part is edited when restructuring) or just the text
> of the section (to edit even less when appropriate).

Yeah, that's been on my to do list for some time.

> So, users U1 and U2 are concurrently editing section S1 and S2 and then U1
> saves the page with his version of S1. U2 tries to save the page with his
> edit of S2, but gets an edit conflict. What's to be done?

...
It's better to use a generic merge mechanism that is applicable to all
edits, not just section edits. Then you just treat section edits like
regular ones -- use the text constructed from the pre-conflict revision
with inserted section as basis for the merge.

Regards,

Erik


subject: [Wikipedia-l] Shirt / Wikipedia-Logo

body:
Kurt Jansson wrote:
>Erik opened an account at cafepress.com a while ago:
>http://www.cafeshops.com/wikipedia

That's really cool! I didn't know this existed.

>Maybe he can update it to the new logo without much work.

Yes, definitely.

>Would it be okay for the foundation to get some money
>through cafepress?

I don't see why not. We would just have to charge more for each item so that
the leftover money can go to the foundation.

>If the answer is yes this would also be true for the Amazon
>partnership program, right

Uh oh - the 'A word'. There are a whole bunch of free software and/or
anti-corporate zealots around here who hate Amazon and will always hate
Amazon because they are a big bad corporation who uses software and business
practice patents. Sadly that means we cannot partner with them unless we want
to alienate many in the Wikimedia community and even risk mass defections and
forks.

-- Daniel Mayer (aka mav)


from_name: Anthere

subject: [Wikipedia-l] Re: Monolithic articles vs parents and daughters

body:
Daniel Mayer a ?crit:
> I just want to clarify my statement that it is best to divide topics into
> digestible bits. I think this should only be considered for most articles
> once they reach the 20 KB (minus markup) size and the resulting daughter
> articles are not stubs. Although some articles demand a larger size just to
> summarize all the main points and clearly link to daughters that have move
> detail on each of those points.

I think I have the same opinion than yours as regards this issue Mav, as
I explained here :
http://en2.wikipedia.org/wiki/User_talk:The_Cunctator/Agglomeration

This is very much what I try to do with these "portal" pages I work on.

Only but...I put the limit much higher, around 30 kb size, essentially
for technical reasons. That is where I draw the line. But even though I
choose to separate part of the article, I always leave an introduction
in the main article. Just a link is not informative enough.


from_name: Evan Prodromou

subject: [Wikitech-l] Wikipedia : MediaWiki

body:
>>>>> "JW" == Jimmy Wales <jwales at bomis.com> writes:

    Zocky> A) MediaWiki is a general purpose wiki infrastructure, [...]

    Zocky> B) MediaWiki is support infrastructure for Wikipedia. [...]

    JW> I'm primarily supportive of (B).  I have no problems with
    JW> MediaWiki being accessible for other users, because if it is,
    JW> then we'll attract more developer talent, which is a good
    JW> thing.

So, actually, this may come as a surprise, but I support B), too. I
don't think we'd be using MediaWiki for Wikitravel if it was a more
general-purpose Wiki engine. What's good for making an
encyclopedia turns out to be good for making a travel guide. That's
why we picked MediaWiki in the first place.

That said, I think some level of generalization (say, extracting
config stuff into LocalSettings.php, extracting strings into
LanguageXX.php) has made MediaWiki into a better piece of software --
even if it were run _only_ for English-language Wikipedia, ever.

I don't do admin on larousse or pliny, but I'm pretty sure it's easier
to tweak a single message in LanguageXX.php than to do a
search-and-replace for some string in umpteen source files. And
turning off expensive functionality under high load seems to have been
valuable, too. So, some of the features of MediaWiki that are for
generalization actually help English-language Wikipedia proper, too.

I also think it makes new Wikimedia projects (other-language
Wikipedias, new projects) relatively low-cost in terms of time and
effort to start up. That's probly a good thing.

>From a selfish standpoint, I'd _prefer_ to have new features or
designs in MediaWiki be _at_least_ configurable to be turned off. But
in the worst-case scenario we could maintain custom local patches. Not
optimal, but possible.

Anyways, here's my point: if there's something that's right for
Wikipedia, and you're worried it might not be right for downstream
projects, well... Go for it. We'll cope. But! if it's not right for
us, it _might_ not be right for Wikipedia or other Wikimedia
projects. So it's a good thing to think through.

~ESP

--
Evan Prodromou <evan at wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide


subject: [Wikitech-l] Wikipedia : MediaWiki

body:
Just out of curiosity, what is the current thinking among developers? Is it
more:

A) MediaWiki is a general purpose wiki infrastructure, which also runs
Wikipedia. Developers of MediaWiki should concentrate on making the best
possible software and editors of Wikipedia should take advantage of new
features as they're provided.

B) MediaWiki is support infrastructure for Wikipedia. Editors of Wikipedia
should decide what kind of behaviour and which features Wikipedia needs and
developers of MediaWiki should implement them.

~~~~ zocky


subject: [Wikipedia-l] A quick thought about 1.0

body:
On Saturday, December 20, 2003, at 09:12  AM, Jimmy Wales wrote:

> Peter Jaros wrote:
>>> OK, let's make this quick:
>>> What we need is a non-editable subset of wikipedia, correct?
>>
>> Hold up.  Do we?  Is this to be a paper or electronic encyclopedia?
>> Or
>> both?  Or am I talking about two different proposals?  It seems a
>> shame
>> to me to freeze and de-wikify entries if not for the sole purpose of
>> inscribing it on a medium that can't be edited (ie., paper).  I would
>> much prefer a tagging system which allows us to mark entries as
>> complete.  Note that 'complete' is not the same as 'finished'.  No
>> entry should ever be finished.  But some entries have achieved
>> completion, where the need only adjustment; think opposite of stub.
>> Furthermore, these entries rarely devolve from their complete status,
>> though if they did for some reason the tag could be quickly removed
>> (or, preferably, the entry re-completed :) ).
>
> 2. instead, "tagging" particular versions as "good enough" is what we
> want.  I like the "good enough" terminology rather than either
> "complete" or "finished".  Basically a "good enough" article is one
> which someone could print on paper and distribute in a bookstore
> without feeling too stupid.

I like the term 'good enough'.  It's definitely better than my
'complete' (why I basically tried to redefine 'slightly' to become it's
own antonym) and I like its connotations better than those of
'sufficient'.  'Good enough' is reminiscent of 'zarro boogs'.

>
> -----
>
> Imagine this scenario -- a publisher says to the Wikimedia Foundation,
> "We are prepared to distribute your encyclopedia worldwide in
> bookstores for 1/10th the price of a new Britannica, and pay royalties
> to the foundation to pay for new servers and whatnot, all you have to
> do is send us a complete extract of articles that are good enough."
>
> We'd like to be able to do that, without having to laboriously go over
> the database _one last time_, because we'd like to already have
> flagged some 60,000-100,000 "good enough" articles.

Exactly

> Let's say an article is flagged "good enough".  Then it gets edited.
> That edit should, in some cases, not automatically result in the new
> version also being tagged "good enough", because it might be an act of
> vandalism that takes place just moments before I run the 'extract'
> command to send the files to the printer.

This is a sticky point.  I'm divided between your point above and this
question:  If any edit removes the tag to protect against vandalism,
will we ever have enough articles tagged?  Also, who is tagging the
articles?  Can't a vandal tag?  Or is it safe enough to limit it to
registered users?

Peter

---
Funding for this program comes from Borders without Doctors: The
Bookstore Chain That Sounds Like a Charity.
		--Harry Shearer, Le Show


subject: [Wikitech-l] Wikipedia with more than one language

in_reply_to:
<bs1ltj$rji$1@sea.gmane.org> (Markus Baumeister's message of
	"Sat, 20 Dec 2003 15:22:51 +0100")

body:
>>>>> "MB" == Markus Baumeister <markus at spampit.retsiemuab.de> writes:

    MB> Is this correct or is there a way to have two languages with
    MB> only one database and one copy of the mediawiki code?

Two answers to this: yes and no.

The yes answer is trivial: just add articles to a database in more
than one language. For two articles that cover the same topic, you can
just make links between them, like this:

          Some Topic

          This is the text in English. Blah blah blah.

          See also: [[Schomme Topische|Ditte Artikel inn Deutsch]]

(Pardon my mockdeutsch, but you get the picture). You can even get
interlanguage links to work, by mapping prefixes back onto the same
wiki, like this (in table interwiki):

      iw_prefix         iw_url                               iw_local
      ---------------------------------------------------------------
      en                http://www.example.com/wiki/$1       1
      de                http://www.example.com/wiki/$1       1

Then [[de:Schomme Topische]] will just put a link up in the "Other
languages" area, pointing to the [[Schomme Topische]] page.

The problem here is that you'd get name clashes for articles that
would and should have the same title in both English and German. One
ugly way around it is to do some kind of fake namespacing for all
articles, like "English:Dave Barry" and "Deutsch:Dave Barry", but
that'd get kind of cumbersome. You might be able to get around this
using tricky values of iw_url in interwiki.

As for somehow automatically making links from English pages always go
to other English pages (that is, [[Dave Barry]] in English [[Miami]]
always would go to the English [[Dave Barry]]), well... no.

There are some problems on the list of RFEs on SourceForge that would
probly be best solved by having one database and one images dir, but I
think it's going to be a while before this ever happens. It'd be a
massive change and the payoff is too low.

~ESP

--
Evan Prodromou <evan at wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide


from_name: Minoru Mochizuki

subject:
[WikiEN-l] Error in your explanation about Plaza Accord and
	Japanese Yen to US Dollar exchange rate

body:
Your explanation that Japanese yen "depreciated" against US dollar
after the Plaza Accord is an error.  It was "appreciated," in other
words, the value of Jppanese yen increased against US dollar.

You say on http://en.wikipedia.org/wiki/Plaza_Accord:
The Plaza Accord was an agrrement signed on September 22, 1985 to make the Japanese yen cheaper.

In 1985, 1 US dollar was exchanged for 216 yen according to the table on the same page.  But the relative value of yen kept rising (appreciated, in other words) mainly because of the Plaza Accord until it reached 132 yen to a dollar in1988 according to said table.  If the intent of the Accord was to cheapen yen as you say, it obviously failed to achieve the objective completely.  Actually, the intent was to raise the value of yen against US dollar.

Yen has been going up steadly with some ups and downs here and there against US dollar since 1985, and it is now 108 yen to a US dollar, or a great appreciation, not depreciation.  Yen's value increased more than three times since 1945 when it was fixed at 360 yen to a dollar in 1945.

Now, everyone is concerned abou Chinese currency which is artificially suppressed for the benefit of Chinese export, by fixing it to US dollar.  People are saying that now is the time for the second Plaza Accord to free up the exchange ratio of Chinese currency against US dollar.

Minoru Mochizuki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20031220/cf3d8f09/attachment.htm


from_name: Markus Baumeister

body:
Hello,

I'm currently playing around with wikipedia to get a version with German and
English entries running on my zaurus. As far as I currently understand the
code, having entries from two languages would require two mysql-databases,
two http-directories on the server, and cross-references between these wikis
on the "en" and "de" prefix within the interwiki database table.

Is this correct or is there a way to have two languages with only one
database and one copy of the mediawiki code?

BTW, http://wikipedia.sourceforge.net/ still names mediawiki-20031118.tar.gz
as most recent version, which got me wondering over the speed of
rebuildlinks.php ;-)

Kind regards
	Markus


subject: [Wikitech-l] Wikipedia : MediaWiki

body:
Daniel-
> But please lets stop supporting Wikipedia-centracism/chauvinism and work
> toward making MediaWiki maximally useful to all Wikimedia projects.

MediaWiki is not really within Jimbo's realm of control. It's an open
source project like any other, and the authority rests with the
developers, some of whom have little or nothing to do with Wikipedia at
all. This might change if Jimbo directly pays Brion has lead developer of
MediaWiki.

Of course Jimbo might decree against activating certain features for
Wikipedia or any other project. In practice, even that decision will
probably be made by Brion. ;-) All of us love Wikipedia so there's
unlikely to be a major disparity of opinion.

But in spite of Jimbo's benevolent dictator position, the reality is that
all our working relationships are voluntary arrangements that can be
easily broken up and replaced if necessary. As a libertarian, I think
Jimbo likes it that way.

I also agree that we should not be too Wikipedia-centric. Wikibooks in
particular may well reach similar orders of magnitude as Wikipedia, so
might Wikisource with a good policy. It is simply good planning to keep
the software universal.

Regards,

Erik


from_name: tarquin

subject: [Wikitech-l] oelig on fr:

body:
We still seem to be having to write œ in article text and links.
Is the letter ? (oe digraph) working properly on fr: yet? If not, will
it work at some time in the future?
(I will write up answers to this in the fr: FAQ! :)

A further problem is that the system does not know that Œ is the
upper case of &oelig.
For example, [[œil (typographie)]] shows as an empty link, even
though the page [[Œil (typographie)]] exists.
Could this second problem be fixed at least?
**


body:
Some projects, like Wikibooks and Wikisource (not to mention Meta), don't have
major naming conflict problems. But it would help a great deal if it were
possible for users to set their preferred interface language in their
preferences and for language category tags to set the interface language as
well  (so anons visiting a page with a French language tag will have their
interface switch to French; &lang=fr in the URL would trigger the same thing
as well).

-- mav


from_name: Agon S. Buchholz

subject: [Wikitech-l] Wikipedia : MediaWiki

body:
Daniel Mayer wrote:

> So I guess the needs of Wiktionary, Wikiquote, Wikibooks, and
> Wikisource (not to mention Wikitravel) are secondary then?

As I understood Jimbo and Brion, the priority is Wikipedia, *more or
less* including the affiliated Wikimedia projects. Really *secondary*
are third party projects, mirroring the Wikipedia or using the MediaWiki
software for other tasks. I think, the message was, that MediaWiki is
not supposed to become a second TikiWiki Groupware- Content- Management-
Calendaring- And- Whatever- One- Stop- Catch-All solution.

> But please lets stop supporting Wikipedia-centracism/chauvinism and
> work toward making MediaWiki maximally useful to all Wikimedia
> projects.

That's simply the way Open Source works. It's developer-centric, not
user-centric; coders are rulers, because they can code; because they
aren't paid, they are coding what they like to use for themselves; if
they would be paid, maybe some project manager could give them tasks to
code, but they aren't. In lucky cases, the interests of developers and
users come together, but usually developers won't code stuff for users
they don't need for themselves. People who want to have problems solved
have to become coders, or just take what the developers give away. If
there *are* developers using other WikiMedia projects, they *will*
enhance it; if there aren't, features needed for other WikiMedia
projects will *maybe*  implemented sometime if a developers feels like
doing so. Features needed by third party users will most probably be
never implemented by the core developers. It's simply a matter of
priorities.

Regards, -asb


subject: [Wikipedia-l] Wikimedia Memorial

body:
The name discussion over the Wikimorial project proposal was blocking real
progress on implementing the idea. I've therefore suggested the name
"Wikimedia Memorial" be used as the new working title of the expanded-focus
Sep11wiki and for that database to be moved to
http://memorial.wikimedia.org/. The as-yet-non-existant Wikimedia Memorial
community can revisit the naming issue at some (much) later date.

Please comment here:
http://meta.wikipedia.org/wiki/Talk:Wikimorial#Name_discussion

Full proposal:
http://meta.wikipedia.org/wiki/Wikimorial

-- Daniel Mayer (aka mav)


from_name: Walter Vermeir

subject: [Wikitech-l] Multi-Wikipedia search does not work

body:
http://pliny.wikipedia.org/tools/wikisearch.php

Multi-Wikipedia search does not work.

It gives the error;

Searching in the Deutsch wiki...

Warning: file(http://de.wikipedia.org/w/wiki.phtml?search=linux): failed
to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in
/usr/local/apache/htdocs/pliny/tools/wikisearch.php on line 227

Warning: implode(): Bad arguments. in
/usr/local/apache/htdocs/pliny/tools/wikisearch.php on line 227

--
Contact: walter AT wikipedia DOT be
Let your computer do something possibly usefull today
Join SETI and team Wikipedia.
http://setiathome.ssl.berkeley.edu/stats/team/team_172338.html


body:
On Dec 20, 2003, at 10:59, Walter Vermeir wrote:

> http://pliny.wikipedia.org/tools/wikisearch.php
>
> Multi-Wikipedia search does not work.

Right, it should have been disabled for quite a long time. .... Okay,
it now admits up front that it doesn't work.

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


from_name: Rob Hooft

body:
> From: Ken Dobruskin <ken at dobruskin.com>
> Date: Fri, 19 Dec 2003 12:00:02 +0100 (CET)
> To: Jimbo Wales <jwales at bomis.com>
> Subject: Forbidden access to wikipedia server
>
> Greetings!
>
> After reading the Wikipedia GFDL and policy on robots, I thought I'd try an experiment, absolutely in line with said policies.
>
> However when I tried to access the site from my server it failed with a 403.
>
> User-agent: Python-urllib/1.15
> IP address: 216.28.158.40
>
> Sorry if I should be asking this to the mailing list, but I did see a word about access issues to be addressed to a site admin.

Ken,

You're welcome to join the pywikipediabot project on sourceforge. You
may be able to use quite some code that has already been written.

Rob

--
Rob W.W. Hooft  ||  rob at hooft.net  ||  http://www.hooft.net/people/rob/


from_name: Tomasz Wegrzanowski

subject: [Wikitech-l] Wikipedia : MediaWiki

body:
On Sat, Dec 20, 2003 at 02:30:17PM +0100, zocky wrote:
> Just out of curiosity, what is the current thinking among developers? Is it
> more:
>
> A) MediaWiki is a general purpose wiki infrastructure, which also runs
> Wikipedia. Developers of MediaWiki should concentrate on making the best
> possible software and editors of Wikipedia should take advantage of new
> features as they're provided.
>
> B) MediaWiki is support infrastructure for Wikipedia. Editors of Wikipedia
> should decide what kind of behaviour and which features Wikipedia needs and
> developers of MediaWiki should implement them.

B, definitely


from_name: Timwi

subject: [Wikitech-l] Re: WikiTeX (for Chem formulas!)

references:
<brcvaq$6lt$1@sea.gmane.org>
	<8zijJLUSpVB@erik_moeller>	<brdo3f$b0l$1@sea.gmane.org>
	<20031215203416.GD8576@mitdasein.com>	<20031215185157.GA3111@tavaiah>
	<brl5fc$dov$1@sea.gmane.org>
	<20031216162354.GA14338@wroclaw.taw.pl.eu.org>

body:
Tomasz Wegrzanowski wrote:

> On Mon, Dec 15, 2003 at 08:27:21PM +0000, Timwi wrote:
>
>>Interesting that you should say that, with "<" having similarly many if
>>not more meanings already.
>>
>>It doesn't have to be "[", but personally I'm rather strongly opposed to
>>mimicking HTML/XML when it's not actually HTML or XML.
>
> `<' has only one use - starting/closing named tags. And adding more
> tags is consistent with it. It's also trivial to parse.

Those tags, however, have many meanings. Some are "real" HTML (like
<table>, which fortunately we managed to introduce a Wiki syntax for),
some are "mixed" (like <pre>) and some are "bogus" (like <math>).

'<' has additionally the meaning of <.

> Why are you opposed to using '<' this way ? I'm personally rather strongly
> in favour, so I wonder what are your reasons. Is it because you think
> people may confuse Wiki markup with XML (I don't think such confusion is
> likely to happen), or because you don't like <foo></foo> tags in general ?

I've pretty much laid out my reasons already ((1) "math" is
anglocentric, (2) Wiki markup and XML should not be confused, and (3)
{{{ blah }}} is always easier to type than <math> blah </math>, and not
any more difficult to parse)...

... but I think I've made more of a fuss of it than I really intended. I
don't actually care as much as I'm making it sound in this thread. Since
there hasn't been any noticeable support of my proposal, I guess I'll
retreat now.

Timwi


subject: [Wikitech-l] Re: Edit conflicts on section editing

in_reply_to:
<bs2js9$4tb$1@sea.gmane.org> (timwi@gmx.net's message of "Sat,
	20 Dec 2003 22:52:51 +0000")

body:
>>>>> "T" == Timwi  <timwi at gmx.net> writes:

    T> It may be best to come up with some sort of system to uniquely
    T> identify a section. Maybe they should be identified by their
    T> title (which will only change if it itself is edited, but not
    T> when other sections are edited).

So, I had another idea, which is hard to implement, has limited scope,
and would probably corrupt a lot of data before it got tested out.

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

Thought I'd throw it out there.

~ESP

--
Evan Prodromou <evan at wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide


subject: [Wikitech-l] Re: Proposed table restructuring

body:
user_Jamesday wrote:

> LJ blobs (images and audio) are now on a NetApp box filesystem, completely apart from their user database cluster machines.

I didn't realise that this was a filesystem. It was constantly referred
to as a "NetApp" and I had no idea what it was, so I assumed it was some
sort of database or cache.

I also thought that functionally it was really just a cache, and I
thought the actual canonical data was still in the LJ database. Thanks
for clearing up that they are actually moving stuff out of the database.

But then again, the way LiveJournal handles userpics (or blobs in
general) makes backing up a consistent state easier for two reasons: (1)
The same blob ID is never used for different blobs. (2) The same blob,
for as long as it exists, is always found under the same ID.

Thus, all they need to do to back everything up is to back up the
database, and then the NetApp. Then you might have blobs in the NetApp
that aren't referenced in the database, but that's not nearly as bad as
having blobs referenced in the database that do not exist in the NetApp.

So, then, I guess Wikipedia could do that too.

Timwi


body:
Erik Moeller wrote:

> It's better to use a generic merge mechanism that is applicable to all
> edits, not just section edits. Then you just treat section edits like
> regular ones -- use the text constructed from the pre-conflict revision
> with inserted section as basis for the merge.

Section edits require special attention, though. Currently in section
editing, sections are identified solely by their number. If a user adds
a section, all subsequent sections now have different numbers. Then if
you get an edit conflict, and your generic merge mechanism tries to
replace the old section with the new version, it will replace the wrong one.

It may be best to come up with some sort of system to uniquely identify
a section. Maybe they should be identified by their title (which will
only change if it itself is edited, but not when other sections are edited).

Greetings,
Timwi


subject: [Wikitech-l] Re: oelig on fr:

body:
tarquin wrote:

> We still seem to be having to write œ in article text and links.
> Is the letter ? (oe digraph) working properly on fr: yet? If not, will
> it work at some time in the future?

<meta http-equiv="Content-type" content="text/html; charset=iso-8859-1">

The fr Wikipedia appears to be using the iso-8859-1 character set
currently. This character set does not include the oelig character.

The Windows-1252 character set (and, of course, UTF-8 also) contains the
character, and it is largely compatible with ISO-8859-1. However, I bet
someone is going to tell you that there exist hardly-used broken ancient
browsers that can't handle it and this is why they continue to use
ISO-8859-1.

The problem here is that these "hardly-used broken ancient browsers" can
corrupt whole pages (by removing all the oeligs, for example).
Therefore, whenever someone contributes with such a browser, you will
either have to fix all the oeligs (too much work) or forego their
contribution (a pity).

> A further problem is that the system does not know that Œ is the
> upper case of &oelig.
> For example, [[œil (typographie)]] shows as an empty link, even
> though the page [[Œil (typographie)]] exists.
> Could this second problem be fixed at least?

This would be trivial with UTF-8, but since that can't be used ...

Greetings,
Timwi


subject: [WikiEN-l] Redirects

body:
Hi.

Is there an established policy on the English Wikipedia as to what sort
of Redirects should or should not exist?

I used to maintain the point of view that having redirects all over the
place (as long as they always go to the intended article) can never do
any harm, and in fact they keep the pages accessible under old links
(i.e. deleting them would break links elsewhere on the Internet).

However, I remember having an argument about this on the German
Wikipedia mailinglist a few months back, and it seemed that their
prevailing view was that redirects should only exist in places where a
paper encyclopedia would have an item saying "see: XYZ", lest they
clutter up the "All articles" Special page.

What is the view of the English Wikipedia in this regard? Currently
there seem to be a lot of redirects that seem redundant, but as I said,
my view on this is that they do not do any harm.

As an example, should the following page be deleted or kept?

http://en.wikipedia.org/w/wiki.phtml?title=Sozialdemokratischen_Partei_Deutschlands&redirect=no

because the actual German name of the party is "Sozialdemokratische
Partei Deutschlands", not "Sozialdemokratischen" - that is an inflected
form (genitive or dative).

Or how about wrong spellings, should these be kept? e.g.
http://en2.wikipedia.org/w/wiki.phtml?title=Condoleeza_Rice&redirect=no
http://en2.wikipedia.org/w/wiki.phtml?title=Condolezza_Rice&redirect=no

And what about ancient subpages, e.g.
http://en.wikipedia.org/w/wiki.phtml?title=Star_Trek/BElanna_Torres&redirect=no

Thanks,
Timwi


from_name: Angela

subject: [WikiEN-l] Redirects

body:
Timwi wrote:
> Is there an established policy on the English
> Wikipedia as to what sort
> of Redirects should or should not exist?

See
*http://en2.wikipedia.org/wiki/Wikipedia:Redirect
*http://en2.wikipedia.org/wiki/Wikipedia:Redirects_for_deletion#When_should_we_delete_a_redirect?
*http://en2.wikipedia.org/wiki/Wikipedia_talk:Deletion_policy/redirects
*http://en2.wikipedia.org/wiki/Wikipedia_talk:Deletion_policy/redirects/Archive1
*http://en2.wikipedia.org/wiki/Talk:AKFD/redirect

Basically, broken links are bad but sometimes a
redirect is worse than broken link.

Sozialdemokratischen Partei Deutschlands is also a
redirect on the German Wikipedia, so I'd see no reason
to delete it.

Angela.

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html


subject: [WikiEN-l] Confusing message

body:
Hi,

first of all, thanks to Angela for her reply to my previous question.

So, as I carried on browsing around for information, I came across this:
http://en2.wikipedia.org/wiki/Wikipedia:Defective_redirects

It says on that page:
	"Please don't try to fix these by hand.
	 -- Tim Starling 00:09, Dec 9, 2003 (UTC)"

What does that mean? Are they going to be fixed by some sort of
automated bot? If so, why is that list even there? I'm confused.

Thanks,
Timwi


subject: [WikiEN-l] Confusing message

body:
Timwi wrote:
> I came across this:
http://en2.wikipedia.org/wiki/Wikipedia:Defective_redirects
>...
> I'm confused.

Answered on the talk page already:
http://en2.wikipedia.org/wiki/Wikipedia_talk:Defective_redirects

That's often a better place to go before the mailing
list.

Regards,

Angela.

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html


from_name: Allan Crossman

subject: [WikiEN-l] Somebody call an arbiter/mediator/whatever :-)

body:
Hello...

While this may sound trivial, I'm fed up with User:12.144.5.2, who
insists on using his own idiosyncratic punctuation, even knowing it's
wrong, and even knowing that it's causing other people work to fix.

This is very irritating, especially since he's doing it deliberately
(as opposed to, for example, people for whom English is a second
language getting grammar wrong).

What can be done?

--
Allan Crossman - http://dogma.pwp.blueyonder.co.uk
PGP keys - 0x06C4BCCA (new) || 0xCEC9FAE1 (compatible)


subject: [WikiEN-l] Re: Confusing message

body:
Angela wrote:

> Timwi wrote:
>
>> I came across this:
>> http://en2.wikipedia.org/wiki/Wikipedia:Defective_redirects
>
> Answered on the talk page already:
> http://en2.wikipedia.org/wiki/Wikipedia_talk:Defective_redirects

Geez, I feel like I'm wasting everybody's time with my two questions
today that I could have found the answers to so easily. I'm sorry! :)

But thanks a lot for your patient help, Angela :))

Greetings,
Timwi


subject: [Wikitech-l] Re: Proposal for deadlinks

body:
Jeroenvrp wrote:

> Please visit http://meta.wikipedia.org/wiki/Proposal_for_dead_links .

Edited ruthlessly. ;-)

Timwi


body:
Evan Prodromou wrote:

> So, I had another idea, which is hard to implement, has limited scope,
> and would probably corrupt a lot of data before it got tested out.
>
>     http://meta.wikipedia.org/wiki/Edits_as_patches

Heh. I'm not sure I understand what you mean by "it has limited scope",
but it's certainly worth considering.

Timwi


from_name: Jeroenvrp

subject: [Wikitech-l] Proposal for deadlinks

body:
Hi,

Please visit http://meta.wikipedia.org/wiki/Proposal_for_dead_links .

Cheers,

Jeroenvrp


from_name: Lars Aronsson

subject: [Wikitech-l] Re: oelig on fr:

body:
Timwi wrote:
> The fr Wikipedia appears to be using the iso-8859-1 character set
> currently. This character set does not include the oelig character.

When the ISO 8859-1 standard was defined in the late 1980s, the French
committee member refused to include oelig since this was "a ligature
and not a letter".  To reach consensus, oelig was taken out and the
multiplication (hex 0xd7) and division (hex 0xf7) signs were
introduced instead.  Therefore, it is only just that the French should
be punished by always having to use ISO 8859-1, even long after
everybody else have switched to Unicode.

As you can see, the code positions are assigned very systematically,
but this pattern is clearly broken by the mult and div symbols:

  0xd1  N-tilde     0xf1  n-tilde
  0xd2  O-grave     0xf2  o-grave
  0xd3  O-acute     0xf3  o-acute
  0xd4  O-circum    0xf4  o-circum
  0xd5  O-tilde     0xf5  o-tilde
  0xd6  O-dieresis  0xf6  o-dieresis
  0xd7  mult        0xf7  div
  0xd8  O-slash     0xf8  o-slash
  0xd9  U-grave     0xf9  u-grave
  0xda  U-acute     0xfa  u-acute

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik - http://aronsson.se/


body:
Timwi wrote:
> But then again, the way LiveJournal handles userpics (or blobs in
> general) makes backing up a consistent state easier for two reasons: (1)
> The same blob ID is never used for different blobs. (2) The same blob,
> for as long as it exists, is always found under the same ID.

Yes, this is the way I would have designed it too.  However, NetApps
are quite expensive NFS file servers, and they are soooo 1999.  :-)

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik - http://aronsson.se/


from_name: Thomas R. Koll

subject: [Wikitech-l] Minor Edits

body:
Good morning,

At wikide-l the idea came up to merge minor edits which are done by a
single user within, let's say 15 minutes.
It would be a good way to save some space in the gigantic cur-table.

ciao, tom
--
http://www.tomk32.de - just a geek trying to change the world
   -.-       http://de.wikipedia.org/wiki/Benutzer:TomK32
   /|>	           http://tomk32.bookcrossing.com
   / \                 http://tinyurl.com/u6de


from_name: Erik Moeller

subject: [Wikitech-l] Minor Edits

body:
Thomas-
> Good morning,

> At wikide-l the idea came up to merge minor edits which are done by a
> single user within, let's say 15 minutes.
> It would be a good way to save some space in the gigantic cur-table.

See previous discussion in wikitech-l:
http://marc.theaimsgroup.com/?l=wikitech-l&m=104444835503339&w=2

Regards,

Erik


from_name: Daniel Mayer

subject: [Wikitech-l] Stats weirdness

body:
Erik wrote:
>The stats job failed halfway through on the en: 'old'
>SQl dump. This happened before, since huge en: has
>been split into 2 files. Second part probably
>corrupt/incomplete.

Yikes! Do you mean to say that the script completely starts over for every
update? Would it not be better for the script to know the last time and place
in the 'old' dump it did its last update and only compute the data that has
been added since that update?

-- Daniel Mayer (aka mav)


subject: [WikiEN-l] Redirects

body:
Hephaestos wrote:
>I don't think redirects should show up at all on the
>"All articles" page, if they do perhaps it should be fixed.

Yeah we should be consistant with our defintions as well and only list
'articles' per our automatic definition of what an article is: Over 0 bytes
in the main/content page/article namespace with at least one internal link
and without #REDIRECT in the text.

But I think an "All pages" function would be a useful thing to have in
addition to the "All articles" function.

-- Daniel Mayer (aka mav)


from_name: John Robinson

subject: [WikiEN-l] Redirects

body:
 >lest they clutter up the "All articles" Special page.

I don't think redirects should show up at all on the "All articles"
page, if they do perhaps it should be fixed.

-Hephaestos


from_name: delirium at rufus.d2g.com

subject: [WikiEN-l] Redirects

body:
> I used to maintain the point of view that having redirects all over the
> place (as long as they always go to the intended article) can never do
> any harm, and in fact they keep the pages accessible under old links
> (i.e. deleting them would break links elsewhere on the Internet).

I think some sort of technological solution (hopefully a light-weight one)
is needed to fix that problem.  There seem to be two main types of
redirects:

1. Titles under which one might reasonably expect to find an article in an
encyclopedia, but which redirect elsewhere because there are multiple
legitimate names for the same concept.  An example is [[United States]]
vs. [[United States of America]]: both are legitimate names, but obviously
the article should only be at one or the other.  Same with scientific vs.
common names of many organisms, and so on.

2. Titles that should not exist in an encyclopedia, either because they
are misspellings, just kind of ridiculous, simple variations of
capitalization, or something else, but which might conceivably be searched
for.  This also includes old names, like the former subpage naming
mechanism.

Clearly these two types of redirects serve useful, but different purposes.
 We might want those in 1. to show up in allpages with a "See [blah]", but
perhaps we wouldn't want those in 2. to do so.

Would it be possible to implement some sort of mechanism whereby a
redirect can be flagged as merely a convenience or technological measure,
not a legitimate alternate article title?

Of course, this may lead to some argument over what is legitimate, but I
think there are a great deal of obvious cases of not legitimate names that
this could take care of (like all the former subpages, misspellings, or
variations on capitalization).

-Mark


from_name: Evan Prodromou

subject: [Wikitech-l] Talk: and subpages

body:
Is [[User talk:Evan/Somesubpage]] a subpage of [[User talk:Evan]], or
the talk page for [[User:Evan/Somesubpage]]?

~ESP

--
Evan Prodromou <evan at wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide


subject: [Wikitech-l] Re: Multi-Wikipedia search does not work

body:
Brion Vibber wrote:

> On Dec 20, 2003, at 10:59, Walter Vermeir wrote:
>
>> http://pliny.wikipedia.org/tools/wikisearch.php
>>
>> Multi-Wikipedia search does not work.
>
>
> Right, it should have been disabled for quite a long time. .... Okay, it
> now admits up front that it doesn't work.
>
> -- brion vibber (brion @ pobox.com)

So it will not come back soon? A Multi-Wikipedia search can be usefull.

--
Contact: walter AT wikipedia DOT be
Join SETI and team Wikipedia.
http://setiathome.ssl.berkeley.edu/stats/team/team_172338.html


from_name: Brion Vibber

subject: [Wikitech-l] Stats weirdness

body:
On Dec 21, 2003, at 10:24, <epzachte at chello.nl> wrote:

> The stats job failed halfway through on the en: 'old' SQl dump.
> This happened before, since huge en: has been split into 2 files.
> Second part probably corrupt/incomplete.

===== WikiCounts /  6:12 Sunday, December 21, 2003 / Wikipedia: EN =====

Read sql dump file
'/home/wikipedia/backups/public/en/cur_table.sql.bz2' (150.2 Mb)
Extract names and timestamps.
Data read (Mb):

06:12 - 10
06:13 - 20 30 40 50 60 70 80 90 100 110
06:14 - 120 130 140 150 160 170 180 190 200 210 220
06:15 - 230 240 250 260 270 280 290 300 310 320
06:16 - 330 340 350 360 370 380 390 400 410 420 430 440
06:17 - 450 460 470 480 490 500 510 520 530 540 550 560 570
06:18 - 580 590 600 610
Read sql dump file
'/home/wikipedia/backups/public/en/old_table.sql.bz2' (2665.3 Mb)
Extract names and timestamps.
Data read (Mb):
10 20 30 40 50 60 70
06:19 - 80 90 100 110 120 130 140 150 160 170 180

Parsing SQL files took 6 min, 59 sec.

That's rather mysterious.

Re-running with the new version, let's see what happens...

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


subject: [Wikitech-l] Stats weirdness

body:
On Dec 21, 2003, at 18:07, Brion Vibber wrote:
> That's rather mysterious.
>
> Re-running with the new version, let's see what happens...

Dies at the same point. Erik, would it be possible to add some error
checks that would explain why it stopped at that point? I'm not sure I
fancy looking through 10 megabytes of text looking for 'something that
might make the script stop.' :)

(Note that the dump is not split into two parts. It's just one big
bzip2 file, but it's dying only 180-some megabytes into the
_uncompressed_ data.)

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


subject: [Wikitech-l] Stats weirdness

body:
Ok, tried to manually decompress the file, and bzip2 is crapping out at
191025000 bytes with a 'data integrity error'.

How... encouraging.

I'll run another backup.

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


from_name: Yann Forget

subject:
[Wikipedia-l] Re: Press release : Logo putsch on the
	FrenchWikipedia !

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

Hi Adam,

Le Thursday 11 December 2003 17:58, Adam Bishop a ?crit :
> I'm Canadian, and I try to work on the French wikipedia sometimes.
> Malhereusement, le fran?ais n'est pas ma langue maternelle.  However, I'm
> not sure it would help to have French-Canadians there, especially as the
> French-Canadians on the English wikipedia can barely work together (with
> themselves and with English-Canadians like me) on Quebec-related articles.

You are very welcome to work on the French language wikipedia.
Now the great majority of contributors are from France, but we need more
contributions from other people.

> Adam Bishop

Cordialement,
Yann Forget

- --
http://www.non-violence.org/ | Site collaboratif sur la non-violence
http://www.forget-me.net/ | Alternatives sur le Net
http://fr.wikipedia.org/ | Encyclop?die libre
http://www.forget-me.net/pro/ | Formations et services Linux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/5eGgm4KYjQo0y9oRAr7iAKCSh8e6u5Oio8VG3xDmxqp6J2QLZACfZtrA
kDX9lgcUmstaxaAW+GlSwKI=
=NED5
-----END PGP SIGNATURE-----


from_name: epzachte at chello.nl

subject: [Wikitech-l] Stats weirdness

body:
The stats job failed halfway through on the en: 'old' SQl dump.
This happened before, since huge en: has been split into 2 files.
Second part probably corrupt/incomplete.

Brion,
if you rerun, did you receive my mail about new version of perl files,
as usual at http://members.chello.nl/epzachte/Wikipedia/Statistics/Perl.zip

A minor fixes + Catalan version
B new js file (fixes bar heights for small Wp's, rounding happened before scaling)
C please add codes for new phase 3 Wp's

Erik Zachte


subject: [Wikipedia-l] Shirt / Wikipedia-Logo

body:
Kurt Jansson wrote:
>I mean, would it be a problem with our non-profit status?

It would not be any more illegal than a church (a non-profit) having a bake
sale and using those funds to help support an on-site day care. Selling
shirts and mugs is a valid way for non-profits to perform fundraising.

>....
>And of course we aren't limited to Amazon, I think every big
>online book shop has an affiliate program. We could join all of
>them or at least pick one or two which have sympathies in the
>community (in Germany this would be lob.de, I think).

I agree and also think that it would  be great to join every affiliate program
that we possibly can and ignore any that requires an exclusive relationship
(but still provide a link to them anyway since that is useful to readers).
Maybe if we did that then the Amazon haters wouldn't be too grumpy.

-- Daniel Mayer (aka mav)


subject: [Wikipedia-l] A quick thought about 1.0

body:
Delirium wrote:
>A belated comment: I'd still like to make sure there's *some*
>standards for Wikipedia.  It would be unfortunate if it turned
>into "1.0 is the 'real' encyclopedia, so 'wikipedia raw' is an
>anything-goes dumping ground".

Agreed. However I think our standards for the 'raw' version of Wikipedia
should in fact be better than than the current standards are. This in fact
should happen naturally once a stable version is set-up; most long-time
contributors will want to make their articles good enough for inclusion in
the stable version. That should enhance the quality of pretty much
everything.

I also strongly support the idea that there should not be any artificial size
limits on the number of topics to include in the stable version (but it could
be divided into encyclopedias covering different subject areas - such as an
encyclopedia of mathematics or even of the Tolkien Universe). Of course a
paper version would require size limits but our on-line version of stable
should not.

The paper version would simply be a subset of stable that is reformulated for
the constraints of paper (article size will have to reduced for many topics,
long tables will have to redone or cut out, and hyperlinks will have to be
converted into something that will work on paper).

To help with the article size issue in the paper version, all Wikipedia stable
content should, IMO, be in a type of news style (where lead paragraphs would
be what one would expect to find for an entry in a concise encyclopedia and
the less relevant material is placed at the end of articles or relegated to
daughter articles). That would make it easier to cut out the less relevant
material. see: http://en.wikipedia.org/wiki/News_style and
http://en2.wikipedia.org/wiki/Wikipedia:News_style

A CD version, for the foreseeable future, can and should be the entire stable
version. We may need to either restrict the number of topics covered in the
future or move to a multiple CD and/or DVD media. Or we could simply divide
the stable version into different specialized encyclopedias (including a
general one and a concise one). Category tagging would make this possible.

-- Daniel Mayer (aka mav)


from_name: Arvind Narayanan

subject: [Wikitech-l] Stats weirdness

body:
Hi,

On the en stats page http://download.wikimedia.org/wikistats/EN/ChartsWikipediaEN.htm,
the current rate of article creation (under " Articles - New articles per day ")
is almost 2000 per day. That doesn't sound right. (60000 new articles per month?)
I think its a tenth of that. Some others also sound fishy: mean edits per
article is nearly 1 ?!

Arvind
--
Its all GNU to me


from_name: Ashar Voultoiz

subject: [Wikitech-l] Re: oelig on fr:

body:
On Sat, 20 Dec 2003 23:11:10 +0000, Timwi wrote:

> tarquin wrote:
<snip>
>> A further problem is that the system does not know that Œ is the
>> upper case of &oelig.
>> For example, [[œil (typographie)]] shows as an empty link, even
>> though the page [[Œil (typographie)]] exists.
>> Could this second problem be fixed at least?
>
> This would be trivial with UTF-8, but since that can't be used ...
>
> Greetings,
> Timwi

Hello,

Why can't we switch fr: to UTF-8 ?  :0)

--
Ashar Voultoiz
http://fr.wikipedia.org/Utilisateur:Hashar
do not send mail to listme at listme.dsbl.org


from_name: Delirium

subject: [Wikipedia-l] A quick thought about 1.0

body:
Jimmy Wales wrote:

>The idea is that Wikipedia can be *more* expansive once we have a 1.0
>"certification" process to keep people happy.  No one can argue "that
>doesn't belong in an encyclopedia" after that, because the simple
>response is "well, it may not belong in 1.0, but it's o.k. for
>wikipedia raw".
>
>
A belated comment: I'd still like to make sure there's *some* standards
for Wikipedia.  It would be unfortunate if it turned into "1.0 is the
'real' encyclopedia, so 'wikipedia raw' is an anything-goes dumping ground".

-Mark


subject: [Wikitech-l] Talk: and subpages

body:
Evan-
> Is [[User talk:Evan/Somesubpage]] a subpage of [[User talk:Evan]], or
> the talk page for [[User:Evan/Somesubpage]]?

Both.


subject: [Wikitech-l] Stats weirdness

body:
On Dec 21, 2003, at 18:38, <epzachte at chello.nl> wrote:
> 1 when the regexp completes it should have reached nearly end of file.
> 2 when the number of records read is less than on previous run clearly
> something is wrong

(Unless there's been a lot of deletions maybe. :)

When reading from bzip2 compressed files it's coming down a pipe; there
should be some way to detect abnormal termination (non-zero return code
from bzip2).

> Is there any way I can make the script alert you and me when something
> went wrong, like sendmail ?

Hmm, I suppose. My experience with auto e-mail error systems is that
they tend to send much too much data. Maybe best to write to an error
log, then the backup/stats job can notify if there's something in it?

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


from_name: Tomasz Wegrzanowski

subject: [Wikitech-l] Re: oelig on fr:

references:
<3FE48B26.7030303@planetunreal.com> <bs2kuk$6v4$1@sea.gmane.org>
	<1wd1wrtnsgzqj$.1wmw3zx5y7ve5$.dlg@40tude.net>

body:
On Sun, Dec 21, 2003 at 08:44:03PM +0100, Ashar Voultoiz wrote:
> On Sat, 20 Dec 2003 23:11:10 +0000, Timwi wrote:
>
> > tarquin wrote:
> <snip>
> >> A further problem is that the system does not know that Œ is the
> >> upper case of &oelig.
> >> For example, [[œil (typographie)]] shows as an empty link, even
> >> though the page [[Œil (typographie)]] exists.
> >> Could this second problem be fixed at least?
> >
> > This would be trivial with UTF-8, but since that can't be used ...
>
> Why can't we switch fr: to UTF-8 ?  :0)

That's a good question - you (= French Wikipedians) can switch and should switch.
It has been delayed for too long already.


subject: [Wikitech-l] Stats weirdness

body:
Daniel wrote:
> Do you mean to say that the script completely starts over for every
update?

I have considered incremental counts, of course, but given the occasional algorithm updates in the counting scripts, the possibilty that database structure changes and last but not least the fact that actions need to be synchronized between Brion and me, which works well most of the time, but sometimes some confusion/delay creeps in, I decided to play it safe.

Erik Zachte


subject: [Wikipedia-l] Reboots coming

body:
The servers will be rebooted in a couple hours, circa 12:00 UTC, to
install new operating system kernels. These include routine security
upgrades, and hopefully the updated 64-bit kernel will help with the
database server's Mysterious Occasional Data Corruption problems.

This will probably mean downtime of 30 minutes to an hour; if some of
the machines fail to come back up it could take longer, but hopefully
not.

Those of you in Europe -- take a long lunch. :)

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20031222/03e233fa/attachment.pgp


subject: [Wikitech-l] Reboots coming

body:
The servers will be rebooted in a couple hours, circa 12:00 UTC, to
install new operating system kernels. These include routine security
upgrades, and hopefully the updated 64-bit kernel will help with the
database server's Mysterious Occasional Data Corruption problems.

This will probably mean downtime of 30 minutes to an hour; if some of
the machines fail to come back up it could take longer, but hopefully
not.

Those of you in Europe -- take a long lunch. :)

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


from_name: Kurt Jansson

subject: [Wikipedia-l] Shirt / Wikipedia-Logo

body:
Mav wrote:
> Kurt Jansson wrote:
> >Would it be okay for the foundation to get some money
> >through cafepress?
>
> I don't see why not. We would just have to charge more for each item so
> that the leftover money can go to the foundation.

I mean, would it be a problem with our non-profit status?

> >If the answer is yes this would also be true for the Amazon
> >partnership program, right
>
> Uh oh - the 'A word'. There are a whole bunch of free software and/or
> anti-corporate zealots around here who hate Amazon and will always hate
> Amazon because they are a big bad corporation who uses software and
> business practice patents. Sadly that means we cannot partner with them
> unless we want to alienate many in the Wikimedia community and even risk
> mass defections and forks.

Why do we link to them then? I think it's stupid to provide a link to
Amazon, but not to take the money.
(Of course we shouldn't advertise for Amazon. The only difference would be
that the URL gets a bit longer.)

And of course we aren't limited to Amazon, I think every big online book
shop has an affiliate program. We could join all of them or at least pick one or
two which have sympathies in the community (in Germany this would be lob.de,
I think).

Kurt

--
+++ GMX - die erste Adresse f?r Mail, Message, More +++
Neu: Preissenkung f?r MMS und FreeMMS! http://www.gmx.net


from_name: Jimmy Wales

subject: [Wikipedia-l] Shirt / Wikipedia-Logo

body:
Kurt Jansson wrote:
> > I don't see why not. We would just have to charge more for each item so
> > that the leftover money can go to the foundation.
>
> I mean, would it be a problem with our non-profit status?

No, it would not.  Unrelated business income, if we have any, is
potentially taxable, that's all.

> Why do we link to them then? I think it's stupid to provide a link
> to Amazon, but not to take the money.

It's sort of a compromise, but yes, a very strange one.  :-)

My own view is that it is unlikely that the Amazon link would bring in
very much money anyway.  It's incidental revenue at best.  If I'm
right, then there's no reason to have a big discussion and fight over
something that wouldn't matter much anyway.

I estimate, by the way, that if we accepted google adwords ads, we
could bring in $20,000-$40,000 per month right now.  So if we want to
have a big fight, we should fight about that.  :-)

--Jimbo


subject: [Wikitech-l] Stats weirdness

body:
This would mean either that the input is incomplete/corrupt or that my regular expression is not as sound as it seems (it has parsed millions of records so far without falling over, but -like Popper told us- seeing millions of black ravens only is no proof that no white raven will ever be found).

In any case I think I will add some extra checks.

1 when the regexp completes it should have reached nearly end of file.
2 when the number of records read is less than on previous run clearly something is wrong

Is there any way I can make the script alert you and me when something went wrong, like sendmail ?

Erik Zachte

>
> van: Brion Vibber <brion at pobox.com>
> datum: 2003/12/22 ma AM 03:07:57 CET
> aan: Wikimedia developers <wikitech-l at Wikipedia.org>,
> 	epzachte at chello.nl
> onderwerp: Re: [Wikitech-l] Stats weirdness
>
> On Dec 21, 2003, at 10:24, <epzachte at chello.nl> wrote:
>
> > The stats job failed halfway through on the en: 'old' SQl dump.
> > This happened before, since huge en: has been split into 2 files.
> > Second part probably corrupt/incomplete.
>
> ===== WikiCounts /  6:12 Sunday, December 21, 2003 / Wikipedia: EN =====
>
>
> Read sql dump file
> '/home/wikipedia/backups/public/en/cur_table.sql.bz2' (150.2 Mb)
> Extract names and timestamps.
> Data read (Mb):
>
> 06:12 - 10
> 06:13 - 20 30 40 50 60 70 80 90 100 110
> 06:14 - 120 130 140 150 160 170 180 190 200 210 220
> 06:15 - 230 240 250 260 270 280 290 300 310 320
> 06:16 - 330 340 350 360 370 380 390 400 410 420 430 440
> 06:17 - 450 460 470 480 490 500 510 520 530 540 550 560 570
> 06:18 - 580 590 600 610
> Read sql dump file
> '/home/wikipedia/backups/public/en/old_table.sql.bz2' (2665.3 Mb)
> Extract names and timestamps.
> Data read (Mb):
> 10 20 30 40 50 60 70
> 06:19 - 80 90 100 110 120 130 140 150 160 170 180
>
> Parsing SQL files took 6 min, 59 sec.
>
> That's rather mysterious.
>
> Re-running with the new version, let's see what happens...
>
> -- brion vibber (brion @ pobox.com)
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20031222/a7a67dd6/attachment.pgp>


from_name: tarquin

subject: [WikiEN-l] Redirects

body:
delirium at rufus.d2g.com wrote:

>>I used to maintain the point of view that having redirects all over the
>>place (as long as they always go to the intended article) can never do
>>any harm, and in fact they keep the pages accessible under old links
>>(i.e. deleting them would break links elsewhere on the Internet).
>>
>>
>
>Would it be possible to implement some sort of mechanism whereby a
>redirect can be flagged as merely a convenience or technological measure,
>not a legitimate alternate article title?
>
>
A *very long time ago* I suggested we implement sysnonyms of the
REDIRECT keyword, that would indicate the type:
#MISSPELLING
#DEPRECATED for subpages, etc
and plain old #REDIRECT would correspond to a "see also" entry.


subject: [Wikitech-l] Wikipedia : MediaWiki

body:
--- Brion Vibber <brion at pobox.com> wrote:
> On Dec 20, 2003, at 08:41, Daniel Mayer wrote:
> > So I guess the needs of Wiktionary, Wikiquote,
> > Wikibooks, and Wikisource (not to mention
> > Wikitravel) are secondary then?
>
> Yes, they are. They're smaller, less popular
> projects, and "the needs  of the many outweigh the
> needs of the few".

And minority rights mean next to nothing then? Should
their needs be put permanently on the back burner just
because they are have fewer hits? What about the very
small Wikipedias that get close to no traffic - is
setting more of them up really more important than
internationalizing Wiktionary in German and French?
Some Wikipedias have set up internal dictionaries due
to the wait.

I would love to help but I can't access the server yet
(I know this is on your very long ToDo list that every
body adds to so I haven't bothered you much about it).
Don't get me wrong - I deeply appreciate the work you
do and firmly believe that without you Wikipedia and
the other Wikimedia projects would be in sad shape due
to nearly constant server and software problems.

> That doesn't mean they're _irrelevant_, and I'd
> appreciate an apology  for the "chauvinism" comment.

It wasn't directed at you it was directed at the
Wikipedia-specific direction of the code and Jimbo's
apparent approval of that (the code part is not your
fault - or anyone's fault really - it is just the way
things developed).

All I want is for us to move in the direction of
making MediaWiki more usable for all Wikimedia
projects (something we /have/ been doing) - Jimbo's
first comment wasn't in that direction so I challenged
it since what Jimbo says is often seen as policy. But
if you were offended then I apologize. I most
certainly did not want to cause you any grief.

-- Daniel Mayer (aka mav)

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


list: textbook-l

from_name: Karl Wick

subject: [Textbook-l] software

body:
Didn't someone say that http://open-education.org/ would
release some of their software this December in a way that
we could use it to compile pages for printing ?

Karl

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/


subject: [Wikitech-l] Wikipedia : MediaWiki

body:
Daniel Mayer wrote:
> Jimbo wrote:
> >I'm primarily supportive of (B).  I have no problems with
> >MediaWiki being accessible for other users, because if it is,
> >then we'll attract more developer talent, which is a good
> >thing.  But I think our primary focus ought to be support
> >of the encyclopedia project.

> So I guess the needs of Wiktionary, Wikiquote, Wikibooks, and
> Wikisource (not to mention Wikitravel) are secondary then? MediaWiki
> should serve /all/ of Wikimedia and also our friends over at
> Wikitravel.

Hmmm, well, I see your point.

--Jimbo


subject: [Wikitech-l] Wikipedia : MediaWiki

body:
Erik Moeller wrote:
> Daniel-
> > But please lets stop supporting Wikipedia-centracism/chauvinism and work
> > toward making MediaWiki maximally useful to all Wikimedia projects.
>
> MediaWiki is not really within Jimbo's realm of control.

That's absolutely true.  Very little really is, of course.  I just sit
and type, cheering for the team.

--Jimbo


from_name: magnus,manske

subject: [Wikitech-l] meta-tags

body:
People on the German wikipedia noticed that a mirror site of the German
wikipedia (wikipedia.t-st.de) has higher Google ratings than the "real"
one, which was attributed to their use of <meta keywords=""> tags.
(Supposedly, Google doesn't care about meta tags, but what do I know?)

I vaguely remember that (at least in Phase II) there were meta-keywords,
generated from the title of the article and all wiki-links. Also, it had
a meta "summary" tag from what the software thought was the first
paragraph of the article.

Could we turn that on again? Might cost some bandwidth, but if it really
gets us higher ratings, we should do this. Maybe for anonymous views
only, since logged-in users probably don't care for meta tags...

Magnus


from_name: The Cunctator

subject: [WikiEN-l] Redirects

body:
> -----Original Message-----
> From: wikien-l-bounces at Wikipedia.org [mailto:wikien-l-
> bounces at Wikipedia.org] On Behalf Of Andrew Lih
> Sent: Monday, December 22, 2003 9:25 AM
> To: 'English Wikipedia'
> Subject: RE: [WikiEN-l] Redirects
>
> Tarquin wrote
> >A *very long time ago* I suggested we implement sysnonyms of the
> >REDIRECT keyword, that would indicate the type:
> >#MISSPELLING
> >#DEPRECATED for subpages, etc
> >and plain old #REDIRECT would correspond to a "see also" entry.
>
> This is a great idea... Something that will help make sense of the
"keep
> all redirects" policy, which I've always had problems with.
>
Deprecated isn't a great idea; we want to restrict names to ones that
don't have meaning only within a Wikipedia context; they should have
meaning outside of Wikipedia. Such as

#REDIRECT (for alternate names of same topic)
#MISSPELLING (for misspellings)
#SUBTOPIC_OF (for redirects into broader topics, which I think is bad
practice but other people like)


subject: [Wikitech-l] Wikipedia : MediaWiki

body:
> From: Daniel Mayer on Monday, December 22, 2003 2:52 PM
>
> --- Brion Vibber <brion at pobox.com> wrote:
> > On Dec 20, 2003, at 08:41, Daniel Mayer wrote:
> > > So I guess the needs of Wiktionary, Wikiquote,
> > > Wikibooks, and Wikisource (not to mention
> > > Wikitravel) are secondary then?
> >
> > Yes, they are. They're smaller, less popular
> > projects, and "the needs  of the many outweigh the
> > needs of the few".
>
> And minority rights mean next to nothing then?

How does "secondary" become "next to nothing"?


from_name: Dave Caroline

subject: [Wikitech-l] meta-tags

body:
At 13:45 22/12/2003 +0100, you wrote:
>People on the German wikipedia noticed that a mirror site of the German
>wikipedia (wikipedia.t-st.de)

17 links

>  has higher Google ratings than the "real" one, which was attributed to
> their use of <meta keywords=""> tags. (Supposedly, Google doesn't care
> about meta tags, but what do I know?)
10500 links

>I vaguely remember that (at least in Phase II) there were meta-keywords,
>generated from the title of the article and all wiki-links. Also, it had a
>meta "summary" tag from what the software thought was the first paragraph
>of the article.
>
>Could we turn that on again? Might cost some bandwidth, but if it really
>gets us higher ratings, we should do this. Maybe for anonymous views only,
>since logged-in users probably don't care for meta tags...
>
>Magnus

Although google  rating is meant to be link based it may be taking the link
qty to be spamming and demoting the main wiki see spider food
www.spider-food.net. I know this happens with other search engines.

Dave Caroline

>_______________________________________________
>Wikitech-l mailing list
>Wikitech-l at Wikipedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikitech-l


from_name: Timwi

subject: [WikiEN-l] Re: Redirects

body:
tarquin wrote:

> A *very long time ago* I suggested we implement sysnonyms of the
> REDIRECT keyword, that would indicate the type:
> #MISSPELLING
> #DEPRECATED for subpages, etc
> and plain old #REDIRECT would correspond to a "see also" entry.

If you do do this, please deprecate #REDIRECT and use (say) #SEE
instead. Otherwise it will be very difficult to find redirects that have
not already been considered.

In other words, "#REDIRECT" should mean "redirect, but someone should
look at this and decide whether it's #SPELLING, #SUBTOPIC, or #SEE".
Especially the move function should use this (unless, of course, you
also extend that and let the mover choose).

I'm suggesting #SPELLING instead of #MISSPELLING so it can encompass
both misspellings and alternate spellings/capitalisations.

Timwi


from_name: Nikola Smolenski

subject: [WikiEN-l] Redirects

body:
On Monday 22 December 2003 21:34, The Cunctator wrote:
> > Tarquin wrote
> >
> > >A *very long time ago* I suggested we implement sysnonyms of the
> > >REDIRECT keyword, that would indicate the type:
> > >#MISSPELLING
> > >#DEPRECATED for subpages, etc
> > >and plain old #REDIRECT would correspond to a "see also" entry.
> >
> > This is a great idea... Something that will help make sense of the
>
> "keep
>
> > all redirects" policy, which I've always had problems with.
>
> Deprecated isn't a great idea; we want to restrict names to ones that
> don't have meaning only within a Wikipedia context; they should have
> meaning outside of Wikipedia. Such as
>
> #REDIRECT (for alternate names of same topic)
> #MISSPELLING (for misspellings)
> #SUBTOPIC_OF (for redirects into broader topics, which I think is bad
> practice but other people like)

Add there #ALTSPELLING for alternative spellings. But wouldn't something like
#REDIRECT [[Something]] (misspelling)
be just as effective without any changes to the software?


subject: [WikiEN-l] Redirects

body:
> From: Nikola Smolenski on Tuesday, December 23, 2003 12:59 AM
> On Monday 22 December 2003 21:34, The Cunctator wrote:
> > #REDIRECT (for alternate names of same topic)
> > #MISSPELLING (for misspellings)
> > #SUBTOPIC_OF (for redirects into broader topics, which I think is
bad
> > practice but other people like)
>
> Add there #ALTSPELLING for alternative spellings. But wouldn't
something
> like
> #REDIRECT [[Something]] (misspelling)
> be just as effective without any changes to the software?

Yup!


from_name: Jay Bowks

subject: [Wikipedia-l] Need admin access after change over to new software

body:
Thanks to Brion for the change over
to the new software for some of the
other languages.

I have one request, though, the login
for admin access is now different for
the new software. I would like to be
granted access once again... thanks.

w/ regards,
Jay B.
[[User:ILVI]]


from_name: Daniel Mayer

subject: [Wikipedia-l] Disclaimer notices and category systems

body:
Neil Harris wrote:
>At the moment, some articles have disclaimer
>notices added (in addition to the general
>disclaimer covering the whole encyclopedia,
>of course). The new MediaWiki namespace has
>recently improved things by allowing the text
>of article disclaimer notices to be standardised
>and updates automated.

I think these disclaimers are very ugly and make us
look unprofessional (most reference works don't start
their articles with disclaimers!). I also think they
are a bad idea since their absence implies that
somebody should be able to trust the content. It is
also self-referential and has links to a
Wikipedia-namespace page. Having too many of these
links adds an extra burden on third party users of our
content who would want to remove the
Wikipedia-specific references.

It is ''far'' better IMO just to have a link to
[[Wikipedia:Disclaimers]] at the bottom of every page.
In fact I think I'll go ahead and do that this
weekend.

That would get rid of the need to place these ugly
notices everywhere.

-- Daniel Mayer (aka mav)

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


subject: [Wikitech-l] en/en2 quick fixes

body:
Brion Vibber wrote:
> Just a note: on an overall basis, the traffic for the English wikipedia
> is about the same as all the others combined. If we could get the
> processor upgrade for larousse actually in place, well that would be
> great. Since that doesn't seem to be forthcoming, alternatively, we
> could move some of the languages to larousse and put English on pliny
> only.

Actually, Jason has a new machine built which I'm giving to Wikipedia.
It's apparently stable and all, and he offered to drive it down today,
but I figured he could wait a bit until he has other reasons to go
down (which he will, soon, since I've ordered some parts and a new
server for Bomis, etc.).

So within a week or two, Wikipedia will be getting a new server as a
Christmas gift from Bomis.  Not a mondo powerhouse, but perfectly
decent.

--Jimbo


subject: [Wikitech-l] Server situation

body:
larousse - single PIII/866
pliny - dual Athlon 2600+
new machine - dual Athlon 2600+
db server - dual opteron mega server

With this setup, we can have larousse act as the load balancer
frontend for the 2 webservers pliny and new, which can be mirror
images of each other.  This is much cleaner than any sort of dns-based
setup.

Also, in the short run, it will permit us to just put the intl-wikis
on the new machine and keep en on the existing machine, or something
similar, which should be a pretty reasonable way to load balance as
well while we work out the details of the other architecture.

The PIII/866 is *more* than powerful enough to do iptables load
balancing, if anyone is wondering about that.  I've done this before,
and you can handle a ton of traffic with not a lot of hardware,
because packet rewriting is easy.

And once we have this structure in place, one great thing is that it's
very scalable -- to increase capacity we just add extra webservers,
which can go into the mix seamlessly.

--Jimbo


subject: [Wikipedia-l] Shirt / Wikipedia-Logo

body:
Jimbo wrote:
>My own view is that it is unlikely that the
>Amazon link would bring in very much money anyway.
>It's incidental revenue at best.  If I'm right,
>then there's no reason to have a big discussion
>and fight over something that wouldn't matter much
>anyway.

It would not only be Amazon but /every/ similar
service we could enter agreements with. I'm pretty
sure that that would generate an not-insignificant
amount of money (maybe enough to pay your cost for
Wikimedia bandwidth).

>I estimate, by the way, that if we accepted
>google adwords ads, we could bring in $20,000-
>$40,000 per month right now.  So if we want to
>have a big fight, we should fight about that.  :-)

Wow! Google ad-words are those little text ads on the
right hand side of Google searches, right? Those seem
to be very well-suited to whatever I am searching for
and I in fact find them useful. However, we already
have had one fork over just the rumor of advertising
and some people have stated that they would leave the
project if we started to have ads. I'm far more
pragmatic and think that having something unobtrusive
(and in fact useful to readers!) like Google adwords
would be a great thing to have. But IMO, this should
only be shown to non-logged-in users. Why? Well those
people who are logged-in are much more likely
contribute to Wikimedia by adding content, while those
who don't log-in are most likely just to be readers.
They should contribute as well by being exposed to
unobtrusive (and in fact useful) adwords.

A mock-up of a Wikipedia article with adwords will be
needed. Then we should have a wide-ranging discussion
on the pros and cons of having them. When that is done
we should have a two-level vote: A Wikimedia-wide vote
on Meta about whether to allow /any/ Wikimedia wiki to
have adwords. If say 75% of Wikimedians vote to allow
adwords at all then there would be a per wiki vote on
the respective wikis on whether or not to have adwords
on their wiki (75% margin needed there as well).

Some problems; What are we going to do with all that
money? If we can't spend it, would that jeopardize our
nonprofit status? I think it would be a step backwards
for Wikimedia to become a for-profit organization.

Some possible ways to solve above problems; Hire
mostly part-time executives (with maybe a full-time
President) and programming staff and use the leftover
money to fund paper/CD publication and distribution
(heck maybe even buy ultra-cheap GNU/Linux boxes with
all Wikimedia content preloaded on them).

Just some thoughts.

-- Daniel Mayer (aka mav)

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


subject: [Wikitech-l] Server situation

body:
The Cunctator wrote:
> Are we going to be able to fix the en-en2 url situation? There's no
> reason that the public should see en2 urls.

Yes, that's one of my primary motivations in hurrying up and giving
another server now.

Wikimedia Foundation also has around $4,000 in the bank right now, so
in addition to this server, we can also talk about whether we want to
add a 3rd webserver sooner rather than later (my preference), or
whether it's more urgent to have a standalone mail/mailinglist/phpbb
site.

--Jimbo


from_name: Neil Harris

body:
Just a thought:

At the moment, some articles have disclaimer notices added (in addition
to the general disclaimer covering the whole encyclopedia, of course).
The new MediaWiki namespace has recently improved things by allowing the
text of article disclaimer notices to be standardised and updates
automated.

The process of adding these per-article notices could be made still
easier when the name-value pair infrastructure is added by allowing the
addition of  _automatic_ disclaimer messages based on article category
tags.  These texts could be sysop-editable, in just the same way as the
MediaWiki tags (or indeed might be implemented as MediaWiki tags).

-- Neil


subject: [Wikitech-l] Disclaimer notices and category systems


body:
> From: Daniel Mayer on Tuesday, December 23, 2003 1:19 PM
>
> It is ''far'' better IMO just to have a link to
> [[Wikipedia:Disclaimers]] at the bottom of every page.
> In fact I think I'll go ahead and do that this
> weekend.
>
> That would get rid of the need to place these ugly
> notices everywhere.
>
I agree. Information is dangerous and knowledge more so, but it's pretty
much what you get with an encyclopedia.

Maybe we should just put this disclaimer on the top of every page:

"When we say The Free Encyclopedia we really mean it."


from_name: Guillaume Blanchard

subject: [Wikitech-l] MediaWiki

body:
Hi all,
Can we use the current article name in a MediaWiki page ?
I'd like to be able to create a link like [[talk:<page_name>|talk page]].

Aoineko


subject: [Wikitech-l] Server situation

body:
Are we going to be able to fix the en-en2 url situation? There's no
reason that the public should see en2 urls.


from_name: Peter Jaros

subject: [WikiEN-l] Re: Redirects

body:
On Tuesday, December 23, 2003, at 01:46  AM, Timwi wrote:

> In other words, "#REDIRECT" should mean "redirect, but someone should
> look at this and decide whether it's #SPELLING, #SUBTOPIC, or #SEE".
> Especially the move function should use this (unless, of course, you
> also extend that and let the mover choose).

It would be nice, for some or all redirect directives, to put the
redirectee under the redirector in search results.  Consider the
following search result for "USA":

8. _USA_ (27 bytes)

I'd suggest this be displayed as:

8. USA
	see _United_States_ (X bytes)

Looks nice, feels nice, and it doesn't look like the article is only 27
bytes long.  This also opens the door (at least conceptually) for "see
also" links in the style of inter-language links.  Has this come up
before?

BTW, why is it so hard to find the article 'United States' by title?  A
search for ' "United States" ' doesn't bring it up...

Peter

---
Funding for this program comes from Borders without Doctors: The
Bookstore Chain That Sounds Like a Charity.
		--Harry Shearer, Le Show


from_name: Thomas R. Koll

subject: [Wikipedia-l] External link spam

body:
On Tue, Dec 23, 2003 at 08:36:49PM +0530, Arvind Narayanan wrote:
>
> Hi,
>
> Several times I have seen external link spammage: someone,
> typically not logged in, adds links to their product/homepage etc.
> in several articles vaguely related to it. With the growing
> popularity of both wikipedia and spamming, we can only expect
> external link spam to increase ;^)

On de: the user Akl generated a list of external links. 179 links is the
top-runner. I'm sure he gives you details on generating the list.

http://de.wikipedia.org/wiki/Benutzer:Akl/H%E4ufig_verlinkte_URLs

ciao, tom
--
http://www.tomk32.de - just a geek trying to change the world
   -.-       http://de.wikipedia.org/wiki/Benutzer:TomK32
   /|>	           http://tomk32.bookcrossing.com
   / \                 http://tinyurl.com/u6de


from_name: Imran Ghory

subject: [Wikipedia-l] External link spam

body:
On Tue, 23 Dec 2003, Arvind Narayanan wrote:

> I think merely being related to the subject of the article is
> not enough justification for having an external link, it has to
> enhance the reader's understanding of the subject etc. So if it
> doesn't meet that criterion I think I can remove external links.
> Any objection?

That's pretty close to what I do. Although I normally go on the criteria
that I let through a link if it is directly relevent to the article and
the site linked to provides either a unique source of information, is
authoritive, or provides information in a clear and concise manner
unavailable elsewhere.

Imran
--
http://bits.bris.ac.uk/imran


from_name: Arvind Narayanan

subject: [Wikipedia-l] External link spam

body:
Hi,

Several times I have seen external link spammage: someone,
typically not logged in, adds links to their product/homepage etc.
in several articles vaguely related to it. With the growing
popularity of both wikipedia and spamming, we can only expect
external link spam to increase ;^)

When I see such links in the body of an article, I just remove
the them (it is usually clear from the context whether it is
spam or if it is a relevant link that needs to be moved to the
external links section). But when they are in the external links
section I'm not sure what to do.

I think merely being related to the subject of the article is
not enough justification for having an external link, it has to
enhance the reader's understanding of the subject etc. So if it
doesn't meet that criterion I think I can remove external links.
Any objection?

Arvind
--
Its all GNU to me


from_name: Erik Zachte

subject: [Wikitech-l] Christmas gift

body:
> So within a week or two, Wikipedia will be getting a new server as a
> Christmas gift from Bomis.

Thanks Jimbo!

Erik Zachte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20031223/af604352/attachment.html>


from_name: Jimmy Wales

subject: [Wikitech-l] Server situation

body:
If you set the list options so that mail from unsubscribed people
is automatically rejected, then you'll see virtually no spam.  Or,
is there something else going on in this case?

Thomas R. Koll wrote:

> On Tue, Dec 23, 2003 at 11:17:09AM -0800, Jimmy Wales wrote:
> > Wikimedia Foundation also has around $4,000 in the bank right now, so
> > in addition to this server, we can also talk about whether we want to
> > add a 3rd webserver sooner rather than later (my preference), or
> > whether it's more urgent to have a standalone mail/mailinglist/phpbb
> > site.
>
> infode-l really needs a spam filter. I'm sure some other lists too.
>
> ciao, tom
> --
> http://www.tomk32.de - just a geek trying to change the world
>    -.-       http://de.wikipedia.org/wiki/Benutzer:TomK32
>    /|>	           http://tomk32.bookcrossing.com
>    / \                 http://tinyurl.com/u6de
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Chuck Smith

subject: [Wikipedia-l] what to do with the money?

body:
> Some problems; What are we going to do with all that
> money? If we can't spend it, would that jeopardize
> our
> nonprofit status? I think it would be a step
> backwards
> for Wikimedia to become a for-profit organization.

I think we should hire full-time editors especially
for the non-English Wikipedias.  The English Wikipedia
had a full-time Larry Sanger to help jump-start the
Wikipedia, but the other languages (to my knowledge)
never had such luxuries.  As I said before, I would
propose Brion Vibber (technical support, non-English
wikis) and Arno Lagrange (Esperanto Wikipedia editor)
as full-time employees.  Arno is now trying to start a
Wikipedia organization in France to be able to legally
work full-time for the Esperanto Wikipedia.

Also, I've never heard of having too much money as
being a problem.  I mean, we're a foundation!  Lots of
foundations have millions of dollars...  We could use
the money to hold Wikipedia seminars and conferences.
We could also use the money to finance other worthy
educational projects like other foundations do.
"Sponsored by Wikimedia"

Chuck

=====
We are the Esperanto speakers who say "Ni!"
http://www.esperantomobilo.org/

_________________________________________________________
Do You Yahoo!?
Informaci?n de Estados Unidos y Am?rica Latina, en Yahoo! Noticias.
Vis?tanos en http://noticias.espanol.yahoo.com


body:
Imran Ghory wrote:
> Something else we could do is use the money to obtain public domain books
> (e.g. biographical encyclopedias) that can be scanned/ocred and used for
> creating basic articles in areas which wikipedia currently lacks coverage.

What would something like that cost, anyway?  My guess is that if
someone wanted to do this, the cost would be close to zero anyway, am
I wrong?

--Jimbo


subject: [Wikitech-l] Server situation

body:
On Tue, Dec 23, 2003 at 11:17:09AM -0800, Jimmy Wales wrote:
> Wikimedia Foundation also has around $4,000 in the bank right now, so
> in addition to this server, we can also talk about whether we want to
> add a 3rd webserver sooner rather than later (my preference), or
> whether it's more urgent to have a standalone mail/mailinglist/phpbb
> site.

infode-l really needs a spam filter. I'm sure some other lists too.

ciao, tom
--
http://www.tomk32.de - just a geek trying to change the world
   -.-       http://de.wikipedia.org/wiki/Benutzer:TomK32
   /|>	           http://tomk32.bookcrossing.com
   / \                 http://tinyurl.com/u6de


from_name: tarquin

subject: [WikiEN-l] Redirects

body:
Nikola Smolenski wrote:

>
>
>Add there #ALTSPELLING for alternative spellings. But wouldn't something like
>#REDIRECT [[Something]] (misspelling)
>be just as effective without any changes to the software?
>
>
>
Yes.
One neat thing to come out of this would that we'd be able to check
misspelling redirects for links.