from_name: Jeffrey V. Merkey

body:
Rob Church wrote:

>On 26/02/07, Jeff V. Merkey <jmerkey at wolfmountaingroup.com> wrote:
>
>
>>I will try this. Will RebuildImages.php correct the wrong entries
>>already in the database or do I need to blow out the database and start
>>over?
>>
>>
>
>It *should* do, if not using the --missing option.
>
>Could you also let us know what the output of the command is when
>executed from the command line, e.g. "file -bi something.png" ?
>
>
>Rob Church
>
>

Image located here:

http://chr.wikigadugi.org/wiki/%E1%8E%BE%E1%8F%8D%E1%8E%A9%E1%8F%AF%E1%8E%A2:Alabama_counties_map.png

also try:

http://chr.wikigadugi.org/wiki/Alabama

I ran the command and the output follows. Note from the entry at the URL
above the image was tagged text/plain. I have 1.8.2 installations also
on the site and they render png correctly. 1.9.3 has this problem.

output from file -bi:

[root at gadugi en]#
[root at gadugi en]#
[root at gadugi en]#
[root at gadugi en]# file -bi
/wikidump/upload/wikipedia/en/d/d0/Alabama_counties_map.png
image/png
[root at gadugi en]#
[root at gadugi en]#
[root at gadugi en]#

Jeff

>_______________________________________________
>Wikitech-l mailing list
>Wikitech-l at lists.wikimedia.org
>http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>


list: wikien-l

source: pipermail-mbox

from_name: T P

subject: [WikiEN-l] Scott McCloud on Wikipedia

body:
On 2/27/07, John Lee <johnleemk at gmail.com> wrote:
>
> So you are saying that if a field is completely forgotten or outmoded,
> even
> if we have the secondary sources to back us up and our encyclopaedia is
> not
> on paper, we should not be including articles on that field? I'd like some
> concrete examples - but then again, these are all hypotheticals since
> nobody's ever written an encyclopaedia and published it in realtime. Then
> again, could you perhaps point to some topics fifteen years old which you
> think would not be worthy of inclusion in an encyclopaedia today, but
> would
> have been included in Wikipedia by experts at the peak of the topics'
> fame?

I think our reliance on secondary sources does help a lot.

On the other hand, a lot of pop culture is ephemeral.  Minor entertainers
and video games come to mind.  Do we need an article on Michael Richards'
racist tirade?  Britney Spears in rehab?  Do we really want articles on the
latest Paris fashions, each year and every year?

I suppose such information has a certain historical value, but it doesn't
fit in with my conception of what an encyclopedia should cover.

Adam


from_name: geni

subject: [WikiEN-l] Scott McCloud on Wikipedia

body:
On 2/27/07, John Lee <johnleemk at gmail.com> wrote:
> I think some perspective is necessary. Common sense isn't necessarily the
> same amongst different people, but I think there are some elements that tend
> to be the same. Common sense is the ability to know your limitations, to
> respect other people's opinions, and to deal with different opinions in a
> peaceful manner.

This is not consistent with what has been common sense for most of
human history. Generally killing people with different opinions
(heretics foreigners) has been more popular.

> And I've always favoured getting serious about desysoping people. Adminship
> is no big deal, and taking it away shouldn't be that big a deal either.

Knocking out even 10 of the hyperactives would lead to serious
problems unless you can find replacements (and if you can could you do
so now? The backlogs are getting anoying again).

--
geni


list: foundation-l

subject:
[Foundation-l] [GFDL Tools for Foundation XML Dumps] gfdl-wikititle
 released under GPLv3

body:
I have open sourced a simple "C" based utility under GPLv3 which will
convert Wikimedia Foundation XML Wikipedia Dumps into a format
which allows easy compliance with the GFDL for off-Wikipedia wikis.
This utility allows the XML dumps to be parsed and [[en:<Article
Title>]] or
[http://en.wikipedia.org/wiki/<ArticleTitle>] tags to be inserted into
the dump at the end of articles.  Dumps converted with this
tool point back into the source Wikipedia artcles and edit history when
imported into MediaWiki.

The tools allows tags which use interwiki_sql links as well as simple
URL addresses.   This code is provided to the Wikipedia Community
and other consumers of Wikipedia content with an easy way to insert GFDL
compliant tags into master XML dumps and import them.

The source code, binaries, and makefile are available at:

ftp://www.wikigadugi.org/wiki/xml/gfdl-wikititle.tar.gz

Enjoy.

Jeff


list: wikimedia-l


list: wikitech-l

subject:
[Wikitech-l] [GFDL Tools for Foundation XML Dumps] gfdl-wikititle
 released under GPLv3


subject: [WikiEN-l] Scott McCloud on Wikipedia

body:
On 2/27/07, Delirium <delirium at hackish.org> wrote:
>
> I don't see why we would look foolish for having good historical
> coverage.  If a field was *ever* of enough note to have multiple
> reliable sources we can cite, then we ought to cover it, and that will
> still be true 15 and 150 years from now.  The solution to imbalanced
> coverage between present-day and older stuff is not to reduce our
> generally thorough coverage of present-day stuff, but to greatly improve
> our much sparser coverage of anything older than 50 years.  Was there
> some field of study that was briefly popular in 1830 but faded to
> insignificance by 1845?  If anyone's written anything reliable about it
> that we can cite, then I'd like to be able to read an article on the
> subject.

That's a valid point.  I am concerned, however, that people will write stuff
in the heat of the moment and not go back and revise with the benefit of
hindsight.

Adam


subject: [WikiEN-l] Scott McCloud on Wikipedia

body:
On 2/27/07, Marc Riddell <michaeldavid86 at comcast.net> wrote:
> on 2/26/07 10:24 PM, geni at geniice at gmail.com wrote:
>
> > Knocking out even 10 of the hyperactives would lead to serious
> > problems unless you can find replacements (and if you can could you do
> > so now? The backlogs are getting anoying again).
>
>
> Are you saying that the quantity of the product is more important than the
> quality of the people? If so, that type of thinking is what has seriously
> contributed to the cancer in the culture.

I'm saying that if you want a situation where the maintenance side
continues to remain in any way shape or form under control you cannot
afford to follow any course that would result in the loss of the
hyperactive admins.

This is simply a description of the current sitution.

--
geni


subject: [WikiEN-l] Scott McCloud on Wikipedia

body:
On 2/27/07, John Lee <johnleemk at gmail.com> wrote:
>
> Also, remember the great thing about Wikipedia is that information can
> both
> be put in and taken out at the click of a mouse. If (let's say) this
> information some day truly becomes an embarassment to WP, we can delete it
> -
> and at the same time, the articles would have served their purpose
> throughout their lifetime, by being a resource for the readers of an era
> where the information was considered relevant and appropriate for an
> encyclopaedia or other general reference tertiary source.

This does stretch my notion of what an encyclopedia should be -- the idea
that we can include information that we later decide to take out.  But then,
I was the one who said we shouldn't limit Wikipedia to norms established by
traditional encyclopedias, so I'll yield the point.

Adam


subject: [WikiEN-l] Scott McCloud on Wikipedia

body:
On 2/27/07, Rich Holton <richholton at gmail.com> wrote:
> geni wrote:
> > On 2/27/07, Marc Riddell <michaeldavid86 at comcast.net> wrote:
> >> on 2/26/07 10:24 PM, geni at geniice at gmail.com wrote:
> >>
> >>> Knocking out even 10 of the hyperactives would lead to serious
> >>> problems unless you can find replacements (and if you can could you do
> >>> so now? The backlogs are getting anoying again).
> >>
> >> Are you saying that the quantity of the product is more important than the
> >> quality of the people? If so, that type of thinking is what has seriously
> >> contributed to the cancer in the culture.
> >
> > I'm saying that if you want a situation where the maintenance side
> > continues to remain in any way shape or form under control you cannot
> > afford to follow any course that would result in the loss of the
> > hyperactive admins.
> >
> > This is simply a description of the current sitution.
> >
>
> How may "hyper-active" admins are there?

100 maybe 150 closer to 100. About 45 admins carry out 50% of our deletions

http://en.wikipedia.org/wiki/User:Dragons_flight/deleterlist

> And if I'm following things
> corrects (and maybe I'm not), it seems that you're assuming that these
> hyperactives are likely candidates for losing their admin status. Am I
> right about that?
>

Probably. The less active you are the harder it is to upset people.

--
geni


from_name: Delirium

subject: [WikiEN-l] Scott McCloud on Wikipedia

body:
T P wrote:
> On 2/26/07, Michael Snow <wikipedia at earthlink.net> wrote:
>
>> fifteen years in the future, we should already be covering, right now,
>> the building blocks that field will ultimately study. For example,
>> there's a bit of a push these days for Hip hop studies to gain
>> recognition as an interdisciplinary academic field. Argue if you like
>> about its legitimacy - I'm sure Citizendium would reject it; I observe
>> that no Wikipedia article exists yet. But if you can imagine what
>> Wikipedia would have looked like in 1992, I can assure you that it would
>> have included detailed articles on Public Enemy and N.W.A, and the
>> articles we have might look better for it today.
>>
>
>
> If you can predict which fields will become significant in fifteen years, as
> opposed to which will become forgotten and make Wikipedia look foolish, you
> can make a lot of money.
>

I don't see why we would look foolish for having good historical
coverage.  If a field was *ever* of enough note to have multiple
reliable sources we can cite, then we ought to cover it, and that will
still be true 15 and 150 years from now.  The solution to imbalanced
coverage between present-day and older stuff is not to reduce our
generally thorough coverage of present-day stuff, but to greatly improve
our much sparser coverage of anything older than 50 years.  Was there
some field of study that was briefly popular in 1830 but faded to
insignificance by 1845?  If anyone's written anything reliable about it
that we can cite, then I'd like to be able to read an article on the
subject.

-Mark


subject: [WikiEN-l] JuryBot (was: Scott McCloud on Wikipedia)

body:
Michael Noda wrote:
> On 2/27/07, Rich Holton <richholton at gmail.com> wrote:
>
>> FWIW, I think that decreasing the average workload of the "hyperactives"
>> should be a major priority. The quality of their work will improve, the
>> number of fatigue-related problems will decrease, and there may be less
>> hesitation in de-sysopping one of them.
>>
>
> I wholeheartedly agree.  One thing that jumps out from the list of
> deleters that geni posted
> (<http://en.wikipedia.org/wiki/User:Dragons_flight/deleterlist> if you
> missed it) is that about a third of the 840 admins listed have not
> made a single deletion in the last 500,000.  Hardly an example of
> leveraging of the long tail!
>

Part of the problem from my perspective is figuring out what to do in
some of these tasks.  I typically do this "janitorial" work in
bursts---I'll do a bunch of recent-changes patrolling for three weeks,
because I'm in the mood for it, or clear out copyright violations for a
day, then I won't do anything for two months.  When I come back to one
of these tasks after an absence, it takes concerted effort to navigate
the web of rules and templates and informal policies.  Even simple stuff
like, "so what's the current policy on warning/blocking vandals, and
which of the 100+ user warning templates should I use?".  It tends to
lead to me doing a small subset of things I feel confident in my
familiarity with (new-article and recent-changes patrolling, mainly, and
some prod-clearing), and avoiding anything else.  To be fair, some parts
of our "process" do have concise documentation on the relevant page with
nicely laid out bold text saying something like "If you're just
wondering how to do [x], do these steps: 1, 2, 3, 4", and in those cases
it's easier to get into them.

On the topic of bots but with a slightly different intent, some
automation of drudgery would help make this work more appealing. Nobody
likes to do work that is super-repetitive and requires no human
judgment.  Clearing out the batches of images tagged "orphan fair use"
is annoying and I usually avoid doing it, because at least 50% of them
are trivially mistagged due to not being orphaned (perhaps they were
when tagged, but they aren't now), and so I end up spending most of my
time just deleting the template and pasting in a "not orphaned" edit
summary.  A bot could do that for me, letting me as the human look only
at the *actually* orphaned fair-use images to decide whether to delete
them or not.  There are a bunch of other examples.  Incidentally, two
nice examples of automation are the bots clearing WP:AIV, and the bot
that goes around adding Template:SharedIPEDU to talk pages of IPs from
universities and school districts.

-Mark


subject: [WikiEN-l] Scott McCloud on Wikipedia

body:
T P wrote:
> On 2/27/07, Delirium <delirium at hackish.org> wrote:
>
>> I don't see why we would look foolish for having good historical
>> coverage.  If a field was *ever* of enough note to have multiple
>> reliable sources we can cite, then we ought to cover it, and that will
>> still be true 15 and 150 years from now.  The solution to imbalanced
>> coverage between present-day and older stuff is not to reduce our
>> generally thorough coverage of present-day stuff, but to greatly improve
>> our much sparser coverage of anything older than 50 years.  Was there
>> some field of study that was briefly popular in 1830 but faded to
>> insignificance by 1845?  If anyone's written anything reliable about it
>> that we can cite, then I'd like to be able to read an article on the
>> subject.
>>
>
>
> That's a valid point.  I am concerned, however, that people will write stuff
> in the heat of the moment and not go back and revise with the benefit of
> hindsight.
>

Yeah, I think that's worth watching out for.  This is an issue even on
topics that are *definitely* notable.  For recent events, we use a lot
of news articles as sources, since they're the only thing available.  As
an event gets less recent, we should start rewriting the articles to use
reliable secondary sources written by historians and analysts, who are
better equipped to filter and contextualize the news articles for us.
Our article on World War II, for example, is based on books by
historians, not on the original newspaper accounts.  Our article on the
recent war in Somalia, meanwhile, necessarily relies exclusively on
original newspaper accounts.  I would hope that in 5 or 10 years' time,
when secondary sources on it become available, it will have been
rewritten so it no longer does.

IMO, this is part of the gray area of "original research".  Is writing
an article on the war in Somalia directly from news reports original
historical research?  It depends partly on how the article is
written---the more synthesis of narratives and analysis of the overall
situation, the more it's treading into research territory.  Once
secondary sources do appear, it's important to try to get away from that
gray area as much as possible and reduce our use of the contemporary
news sources.  So I can see your view that it would be better to just
wait until the sources exist before writing an article at all.  That
would certainly be sounder, but I think our articles on recent topics
provide an important enough service that it's worth muddling through the
gray areas anyway, so long as they do eventually get returned to.

-Mark


from_name: teun spaans

subject: [Foundation-l] RfC: Draft licensing policy resolution

body:
I like several elements in this approach.

First, such a "no free image" template is a very clear invitation for people
to donate one.

Second, if the board would express a clearer view that fair use is not what
we aim for, that in itzelf is a clear signal.

A gradual approach would be more acceptible on the english wiki than an all
out attack on all fair use images. For example, there could be a move where
person photos would be allowed first, and dealing with other categories such
as historical events later.

i wish you health and happiness,
teun spaans

On 2/26/07, Erik Moeller <erik at wikimedia.org> wrote:
>
> On 2/21/07, Brianna Laugher <brianna.laugher at gmail.com> wrote:
> > Does this implu that the Board ultimately does discourage the use of
> > such EDPs? At the moment the Board seems quite neutral on them, or
> > even encouraging them to be adopted. I know I am not the only person
> > who would like to see the Board *discourage* the adoption of EDPs, and
> > even indicate a very slow movement towards banning them. And yes I
> > know that gets enWP all huffy... but there are people there who
> > dislike fair use too.
>
> I think the recent example of the English Wikipedia using a "No free
> image" template is exactly the direction we should go:
>
> http://en.wikipedia.org/wiki/David_Mamet
>
> (Incidentally, a very similar system is used by the IMDB, except of
> course they do not care if their images are freely licensed.)
>
> I am willing to support a licensing policy that is more strict than
> the current draft, i.e., which explicitly rules out the use of EDPs
> for purposes such as portrait photos, and limits them essentially to:
> - media about significant historical events
> - "identifying media" such as logos, jingles, etc.
> - excerpts of contemporary copyrighted works (low quality versions of
> comic book characters, album covers, music samples, screenshots etc.)
>
> I think we need to also have a vague "reasonable expectation" clause
> in the resolution that clarifies that, if we can reasonably _expect_
> that a free work will be made available, then a non-free one shouldn't
> be used. This allows us to, over time, shift out more of the above
> (especially the historical stuff, which I think we can definitely get
> under free licenses in the not too distant future).
>
> On the other hand, as long as copyrighted works are dominant in the
> information society, EDPs are the main method by which we can
> illustrate and excerpt contemporary cultural works. I do think this is
> a significant part of the mission of the WMF, and that we should make
> use of the few exemptions to copyright law that there are in order to
> do it.
>
> Characters from contemporary films or cartoons, for example, are not
> going to become "free content" anytime soon. Even if we could
> "liberate" them, this would hardly be our first priority. Those that
> scoff at Pokemon or Star Wars screenshots should acknowledge that, if
> we were to ban any such material from being illustrated, it would also
> exclude the great masters of film, music and painting from most of the
> 20th century. We should not even try to discriminate here between that
> which is "worthy" and that which is not; if the work is notable enough
> to be described in an encyclopedia, it is notable enough to be
> illustrated.
>
> Moreover, experience has shown that trying to ban non-free content
> completely tends to only lead to workarounds which are even worse
> (e.g. people photographing 3D toys of a cartoon character, carefully
> cropping out all the background, and proudly proclaiming that they now
> have created a "free work"; logos being flatly claimed to not be
> "copyrightable", etc.). So while I think we should promote free
> culture as much as possible, and while I can support a licensing
> policy which allows us a gradual shift towards that goal, I don't
> expect it to be fully achievable unless there are radical changes in
> copyright law throughout the world.
>
> --
> Peace & Love,
> Erik
>
> DISCLAIMER: This message does not represent an official position of
> the Wikimedia Foundation or its Board of Trustees.
>
> "An old, rigid civilization is reluctantly dying. Something new, open,
> free and exciting is waking up." -- Ming the Mechanic
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l
>


body:
What I forgot to say: I also like the practical realization that for some
categories free content is indeed something we can not reasonably expect. We
dont even put our own logo under a free license, we can not expect other to
license their logo as free.

On 2/26/07, Erik Moeller <erik at wikimedia.org> wrote:
>
> On 2/21/07, Brianna Laugher <brianna.laugher at gmail.com> wrote:
> > Does this implu that the Board ultimately does discourage the use of
> > such EDPs? At the moment the Board seems quite neutral on them, or
> > even encouraging them to be adopted. I know I am not the only person
> > who would like to see the Board *discourage* the adoption of EDPs, and
> > even indicate a very slow movement towards banning them. And yes I
> > know that gets enWP all huffy... but there are people there who
> > dislike fair use too.
>
> I think the recent example of the English Wikipedia using a "No free
> image" template is exactly the direction we should go:
>
> http://en.wikipedia.org/wiki/David_Mamet
>
> (Incidentally, a very similar system is used by the IMDB, except of
> course they do not care if their images are freely licensed.)
>
> I am willing to support a licensing policy that is more strict than
> the current draft, i.e., which explicitly rules out the use of EDPs
> for purposes such as portrait photos, and limits them essentially to:
> - media about significant historical events
> - "identifying media" such as logos, jingles, etc.
> - excerpts of contemporary copyrighted works (low quality versions of
> comic book characters, album covers, music samples, screenshots etc.)
>
> I think we need to also have a vague "reasonable expectation" clause
> in the resolution that clarifies that, if we can reasonably _expect_
> that a free work will be made available, then a non-free one shouldn't
> be used. This allows us to, over time, shift out more of the above
> (especially the historical stuff, which I think we can definitely get
> under free licenses in the not too distant future).
>
> On the other hand, as long as copyrighted works are dominant in the
> information society, EDPs are the main method by which we can
> illustrate and excerpt contemporary cultural works. I do think this is
> a significant part of the mission of the WMF, and that we should make
> use of the few exemptions to copyright law that there are in order to
> do it.
>
> Characters from contemporary films or cartoons, for example, are not
> going to become "free content" anytime soon. Even if we could
> "liberate" them, this would hardly be our first priority. Those that
> scoff at Pokemon or Star Wars screenshots should acknowledge that, if
> we were to ban any such material from being illustrated, it would also
> exclude the great masters of film, music and painting from most of the
> 20th century. We should not even try to discriminate here between that
> which is "worthy" and that which is not; if the work is notable enough
> to be described in an encyclopedia, it is notable enough to be
> illustrated.
>
> Moreover, experience has shown that trying to ban non-free content
> completely tends to only lead to workarounds which are even worse
> (e.g. people photographing 3D toys of a cartoon character, carefully
> cropping out all the background, and proudly proclaiming that they now
> have created a "free work"; logos being flatly claimed to not be
> "copyrightable", etc.). So while I think we should promote free
> culture as much as possible, and while I can support a licensing
> policy which allows us a gradual shift towards that goal, I don't
> expect it to be fully achievable unless there are radical changes in
> copyright law throughout the world.
>
> --
> Peace & Love,
> Erik
>
> DISCLAIMER: This message does not represent an official position of
> the Wikimedia Foundation or its Board of Trustees.
>
> "An old, rigid civilization is reluctantly dying. Something new, open,
> free and exciting is waking up." -- Ming the Mechanic
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l
>


from_name: christoph.huesler at css.ch

subject: [Wikitech-l] Antwort: Re:  Meta tags for keywords

body:
Roman wrote:

> Thanks for the hint about extending the Parser. What I don't
> understand yet how I can replace the existing parser without
> touching the files that come with MediaWiki. I try to get this in as
> extension without modifying files...
>
> Roman

AFAIK this is not (yet) possible.


from_name: Jim Wilson

subject: [Wikitech-l] Antwort: Re: Meta tags for keywords

body:
Roman,

I had a similar problem when I was trying to figure out how to add <link>
tags to for RSS and Atom feed based on the presence of custom tags.  Here's
the source in case you're the kind of person who wants to dive right in:

http://jimbojw.com/wiki/index.php?title=WikiArticleFeeds

Read on for my take on what you want to do and how you might go about being
successful at it...

What you want to do /is possible/ using existing hooks, but it requires
multiple hooking methods working in concert.  This is because anything that
happens as the result of a tag extension executing (other than providing
output) expires after the page is rendered.

Since all Parser output is cached, when the Parser runs its parse() method,
this typically only happens once per edit.  In other words, this means that
your tag extension will not be re-run for every page view.

The meta tags exist outside the Parser - pulled into the Skin by the
OutputPage as you noted.  As it turns out, there is a hook in OutputPage
that you can use to affect the Meta tags just before they are rendered out
to the browser: 'OutputPageBeforeHTML'.

This hook runs on every page view, except when Squid caching is used.  In
your case this probably wouldn't make a difference anyway though since the
meta tags will be the same as long as the page content hasn't changed -
which would purge the squid cache anyway.

The difficulty lies in passing information from the custom tag (which the
Parser will only run once per edit) into the meta tags (which must be done
on each page view to be effective).  This can be achieved by hiding data
from the Parser.  To do this, you can have your tag extension output an HTML
comment with the data tucked away inside.

Here's an outline of what you could do:

1) Hook into the parser creating your extension tag

2) Have your tag interpret the internals of the tag, or attributes to the
tag, as a meta keyword (or list of keywords) to be injected into the page
header later.

3) Encode the incoming data as base64 to make it look like regular text.
Then wrap this in an HTML comment with flags to indicate the beginning and
end.  Something like this:
$encodedComment = '<!--
@METAKEYWORDS@'.base64_encode($input).'@METAKEYWORDS@ -->';

4) Output the wrapped, encoded comment tag.  The Parser will faithfully push
this into the page contents.

5) Hook 'OutputPageBeforeHTML', and in the implementing function, use a
regular expression to search for your encoded comment tags in the provided
$text param.

6a) If you find any matches, and want to delete all existing keywords
(meaning you only want those that the user specifies), then you can call
something like this:

$out->mKeywords = array();

Note: I'm not completely sure this will work though since I don't know with
certainty where mKeywords gets populated in the first place.  If it happens
after the call to addParserOutput( ), then you may be out of luck.

6b) For each encoded comment found, add it to the OutputPage's keywords like
this:

$out->addKeyword(base64_decode($encodedText));

That's about it.  Good luck!

-- Jim

On 2/27/07, christoph.huesler at css.ch <christoph.huesler at css.ch> wrote:
>
> Roman wrote:
>
> > Thanks for the hint about extending the Parser. What I don't
> > understand yet how I can replace the existing parser without
> > touching the files that come with MediaWiki. I try to get this in as
> > extension without modifying files...
> >
> > Roman
>
> AFAIK this is not (yet) possible.
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


subject:
[Wikitech-l] Antwort: Introduction + 7zip dump format better for
	random	access

body:
Hi

How about using another algorithm that does this already?

-- chris

> [...]
> The problem is that 7zip was never optimized to work quickly on
> extracting one given file out of hundreds of thousands, or millions.
> Right now, the Indonesian wikipedia (60MB 7zipped) takes about 15
> seconds for a page on my two-year old iBook, whereas the Chinese one
> (250MB 7zipped) takes about 150 seconds for a page. I haven't dared
> try any of the bigger ones, like the German (1,5GB) or the English
> (four files a 1,5GB)... My first thought was if it was possible to
> modify the open-source 7zip to generate an index of which block the
> different files where, which would then make the actual extraction a
> lot faster. The problem is that I suck at C, and I have been looking
> for people to help me, even offering a small bounty to the developer.
> (If anyone here would help me, that would be MUCH appreciated! I
> personally think it would be quite easy, given the sourcecode that
> exists, but I don't know for sure).


list: wikipedia-l

subject:
[Wikipedia-l] Expert: Wikipedia Won't Go Away,
 So Learn How to Use It

body:
Thanks for pointing out the link.  A few of her comments are good, but
some of them are downright strange.

Frederick Noronha wrote:
> Matei recommends Wikipedia be used as a search engine that acts as a
> springboard to other resources and that it never be cited as a primary
> source of information. But before starting an Internet search, Matei
> urges users to consult with a professional who can help focus their
> research topic. After narrowing the topic, those in an academic
> environment should then search for more literature on major article
> databases from institutional organizations, such as ProQuest or
> LexisNexis.
>
> "Many of the papers found on these databases are reviewed by highly
> qualified individuals and institutions," Matei says. "They are not
> just very powerful and accessible search engines, they are also
> excellent filters of information that can be easily sorted by topics,
> subjects and time."
>
> After a broader Internet search, Matei says the Wikipedia page can be
> used to help clarify some specific questions or terms that the initial
> research process has not been able to resolve.

This seems strangely self-contradictory, although to be fair that might
be the fault of the article writer instead of Ms. Matei's. It certainly
isn't how I, or anyone else I know, uses or would recommend using
Wikipedia. You resort to a paid professional *after* Wikipedia, not
*before*.  Wikipedia is particularly good as a first glance, giving you
search terms you might not have heard of, pointeres to other related
topics, and in good articles an overview of the subject.  And I'd argue
that unless people know what they're doing, a search of LexisNexis or
ProQuest (or Google Scholar) is likely to be much worse than browsing
the Wikipedia article as a first resource.  A good Wikipedia article
puts all these sources in context, and so is infinitely better than the
raw listing of sources as a first reference.  These databases are giant
archives of primary sources, *not* generally reviewed, interrelated, or
usefully commented upon.  Honestly this part, especially with its focus
on paid professionals and pay-access archives, strikes me as a bit of
turf defense.

The suggestions further down about how to spot potentially questionable
Wikipedia articles are good ones, though.

-Mark


list: commons-l

from_name: Gregory Maxwell

subject: [Commons-l] Mayflower: Wikimedia Commons media search

body:
On 2/27/07, David Gerard <dgerard at gmail.com> wrote:
> On 13/02/07, Tangotango <tangotango at wikignome.net> wrote:
>
> > I've uploaded my Wikimedia Commons image/media search tool, dubbed
> > "Mayflower",  to the toolserver; it's available at http://
> > tools.wikimedia.de/~tangotango/mayflower/.
> > Any comments and/or suggestions would be most welcome.
>
> Interesting!
>
> I just did a search on "Canon camera". Um. Well, there are a few
> pictures of Canon cameras and lenses there. Mostly shots taken *with*
> a Canon camera. And one pic of [[:en:David Cameron]] ...

The search would be well equipped to handle this if only we didn't use
categories in a rather brain dead manner.

In your "Canon camera" search most of the results just have the words
"canon" and "camera" in random spots in the description text.

The search you want is:

http://tools.wikimedia.de/~tangotango/mayflower/search.php?q=Canon&ic=Canon_cameras&ec=&ft=any&sc=gt&sv=&ds=&t=n&z=15&a=1

But because of the obsession with sub-categorization on commons the
endless number of sub-categories means you miss most of the results.
:(

If we used categories well, you could depend on there being a category
"cameras" and a category "canon products" on the pictures you want.
Mayflower will gladly search for the intersection of these two
taggings.

I'm sure someone will suggest having the search walk the category
hierarchy, but not only is this computationally expensive, it will
result in an incorrect result: [[Category:Photos_taken_with_Canon]] is
a child of [[Canon_cameras]], and I wouldn't be surprised to find that
some of the "Taken with Canon foo5" are children of "Canon foo5".

I don't think that Photos_taken_with_Canon as a child of Canon_cameras
is actually an unreasonable situation when you think of the category
tree as a structure designed to help humans find categories. ... Nor
do I think that using the category tree as an exclusive human aid is a
problem since due to their being too many semantic link types, the
drift will always make such simple relationships error prone.

If we ever want it to be as easy to find images on commons as it is on
commercial stock photography sites like Getty, we need to stop
pretending that all categories are best used as tools for manual
browsing.


body:
Actually, in retrospect there's a simpler solution:

1) Have users enter keyword data in  tags with class="keyword" like
this:

    Cool Stuff

2) Hook OutputPageBeforeHTML (as before) to use a regular expression to
parse out these strings and push the contents into $out via addKeyword().

3) Add a CSS rule to hide spans of class keyword (to MediaWiki:Common.css):

    span.keyword { display: none; }

Much simpler, and doesn't require a parser hook or any base64 encoding.

On 2/27/07, Jim Wilson <wilson.jim.r at gmail.com> wrote:
>
> Roman,
>
> I had a similar problem when I was trying to figure out how to add <link>
> tags to for RSS and Atom feed based on the presence of custom tags.  Here's
> the source in case you're the kind of person who wants to dive right in:
>
> http://jimbojw.com/wiki/index.php?title=WikiArticleFeeds
>
> Read on for my take on what you want to do and how you might go about
> being successful at it...
>
> What you want to do /is possible/ using existing hooks, but it requires
> multiple hooking methods working in concert.  This is because anything that
> happens as the result of a tag extension executing (other than providing
> output) expires after the page is rendered.
>
> Since all Parser output is cached, when the Parser runs its parse()
> method, this typically only happens once per edit.  In other words, this
> means that your tag extension will not be re-run for every page view.
>
> The meta tags exist outside the Parser - pulled into the Skin by the
> OutputPage as you noted.  As it turns out, there is a hook in OutputPage
> that you can use to affect the Meta tags just before they are rendered out
> to the browser: 'OutputPageBeforeHTML'.
>
> This hook runs on every page view, except when Squid caching is used.  In
> your case this probably wouldn't make a difference anyway though since the
> meta tags will be the same as long as the page content hasn't changed -
> which would purge the squid cache anyway.
>
> The difficulty lies in passing information from the custom tag (which the
> Parser will only run once per edit) into the meta tags (which must be done
> on each page view to be effective).  This can be achieved by hiding data
> from the Parser.  To do this, you can have your tag extension output an HTML
> comment with the data tucked away inside.
>
> Here's an outline of what you could do:
>
> 1) Hook into the parser creating your extension tag
>
> 2) Have your tag interpret the internals of the tag, or attributes to the
> tag, as a meta keyword (or list of keywords) to be injected into the page
> header later.
>
> 3) Encode the incoming data as base64 to make it look like regular text.
> Then wrap this in an HTML comment with flags to indicate the beginning and
> end.  Something like this:
> $encodedComment = '';
>
> 4) Output the wrapped, encoded comment tag.  The Parser will faithfully
> push this into the page contents.
>
> 5) Hook 'OutputPageBeforeHTML', and in the implementing function, use a
> regular expression to search for your encoded comment tags in the provided
> $text param.
>
> 6a) If you find any matches, and want to delete all existing keywords
> (meaning you only want those that the user specifies), then you can call
> something like this:
>
> $out->mKeywords = array();
>
> Note: I'm not completely sure this will work though since I don't know
> with certainty where mKeywords gets populated in the first place.  If it
> happens after the call to addParserOutput( ), then you may be out of luck.
>
> 6b) For each encoded comment found, add it to the OutputPage's keywords
> like this:
>
> $out->addKeyword(base64_decode($encodedText));
>
> That's about it.  Good luck!
>
> -- Jim
>
> On 2/27/07, christoph.huesler at css.ch <christoph.huesler at css.ch> wrote:
> >
> > Roman wrote:
> >
> > > Thanks for the hint about extending the Parser. What I don't
> > > understand yet how I can replace the existing parser without
> > > touching the files that come with MediaWiki. I try to get this in as
> > > extension without modifying files...
> > >
> > > Roman
> >
> > AFAIK this is not (yet) possible.
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l at lists.wikimedia.org
> > http://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
>


from_name: David Gerard

subject: [WikiEN-l] Presentation to readers

body:
On 27/02/07, geni <geniice at gmail.com> wrote:

> Things like {{notability}} whatever the tags are for cats needed and
> total lack of citations tags can go on the talk page but ah it didn't
> catch on last time so I assume there is some oposition somewhere or
> that people don't really care about the problem.

Total lack of references should be noted on the article itself. It's
useful to the reader to know.

"Notability" warnings are part of the ongoing AFD conflict. I predict
that putting them on talk will be seen as an attempt to encourage
deletion by stealth.

- d.


body:
On 2/27/07, David Gerard <dgerard at gmail.com> wrote:
> On 27/02/07, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>
> > If we ever want it to be as easy to find images on commons as it is on
> > commercial stock photography sites like Getty, we need to stop
> > pretending that all categories are best used as tools for manual
> > browsing.
>
>
> If categories in MediaWiki can be turned into tags, and you can then
> do interesting tag queries (and you can be sure the system will be
> tested to its limit the moment it's possible), then quite a lot of the
> problems with categories on Commons go away without breaking the
> current category system on other wikis. Are the efforts to this end
> progressing at all?

You can do them right now with Mayflower. This is no accident. :)  ..
Mayflower supports giving you an intersection and then subtracting
other categories from that intersection. More complex operations are
easily possible, but I think that what we have is the most useful
starting point.

For our purposes I don't see that using mayflower to get started on
this is bad... it's easier and less risky to do development outside of
MediaWiki proper, and Mayflower is free software running on our
hardware, and written by a community member. So it's not like relying
on Google.

The next step will be to raise awareness. Once more people know about
this there will be less opposition to using categories as tags.


from_name: Rob Church

subject: [Wikitech-l] rebuildImage.php MIME detection error 1.9.3

body:
On 26/02/07, Jeff V. Merkey <jmerkey at wolfmountaingroup.com> wrote:
> I will try this. Will RebuildImages.php correct the wrong entries
> already in the database or do I need to blow out the database and start
> over?

It *should* do, if not using the --missing option.

Could you also let us know what the output of the command is when
executed from the command line, e.g. "file -bi something.png" ?

Rob Church


body:
On 2/27/07, David Gerard <dgerard at gmail.com> wrote:
> > The next step will be to raise awareness. Once more people know about
> > this there will be less opposition to using categories as tags.

> If Mayflower was put on en:wp, would the toolserver melt?

Probably, but that is being fixed.


body:
I'm an academic, sort of, or future academic if you prefer (PhD student
in Comp. Sci., in the U.S.).

To be clear, I find LexisNexis, JSTOR, and other archives very valuable,
and I use them frequently.  But there are a lot of pitfalls, especially
if you don't already know something about the subject you're searching
for.  I certainly wouldn't recommend "search the databases" as a good
first step for an undergraduate trying to learn about a subject.
Wikipedia is sometimes (when the article isn't bad) a better first
resource, and textbooks and other encyclopedias (especially
subject-specific encyclopedias) are also good options.  Then once
someone has learned a little bit about the subject, they know how to
decide which original journal articles or news articles to search for
and read, and how to interpret them in appropriate context.

I actually thought that's what this article was saying, from the
beginning part, but when it gets further towards the end of the article
it starts saying that the databases should be the first resource, with
Wikipedia used later to look up specific information---and that seems
exactly backwards.

-Mark

Frederick "FN" Noronha wrote:
> Mark, very interesting comments. Just out of curiosity -- are you an
> information scientist, librarian, academic, or none of the above? :-)
> FN
>
> PS: I don't mean to be poking fun. Just curious to know how different
> segments would see this issue. BTW, I'm a journalist, in India (Goa).
>
> On 27/02/07, Delirium <delirium at hackish.org> wrote:
>
>> This seems strangely self-contradictory, although to be fair that might
>> be the fault of the article writer instead of Ms. Matei's. It certainly
>> isn't how I, or anyone else I know, uses or would recommend using
>> Wikipedia. You resort to a paid professional *after* Wikipedia, not
>> *before*.  Wikipedia is particularly good as a first glance, giving you
>> search terms you might not have heard of, pointeres to other related
>> topics, and in good articles an overview of the subject.  And I'd argue
>> that unless people know what they're doing, a search of LexisNexis or
>> ProQuest (or Google Scholar) is likely to be much worse than browsing
>> the Wikipedia article as a first resource.  A good Wikipedia article
>> puts all these sources in context, and so is infinitely better than the
>> raw listing of sources as a first reference.  These databases are giant
>> archives of primary sources, *not* generally reviewed, interrelated, or
>> usefully commented upon.  Honestly this part, especially with its focus
>> on paid professionals and pay-access archives, strikes me as a bit of
>> turf defense.
>>
>> The suggestions further down about how to spot potentially questionable
>> Wikipedia articles are good ones, though.
>>


from_name: Ben McIlwain

subject: [Wikitech-l] Captcha changes

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

Brion Vibber wrote:
> I've fixed up the image-based captcha to read from subdirectories, which
> should put less load on the file server.
>
> Also I've gone ahead and enabled it for all wikis, partly in response to
> concerns that there's some possibly machine-based mass registration
> going on which might be malicious.
>
> If there's problems, let us know.

Has the CAPTCHA since been disabled, and why?  We're no longer seeing it
in use on any wikis while trying to make anonymous edits.

_______________________________________________
Wikitech-l mailing list
Wikitech-l at lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/wikitech-l

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)

iD8DBQFF5DjjvCEYTv+mBWcRAkjkAJ9o8uXivqcPrHTnwP8WWgx4PhgxGQCfV6pH
o4cIp/6jVB8mYR8xpBj6HaI=
=rXdN
-----END PGP SIGNATURE-----


from_name: Stan Shebs

subject: [Wikipedia-l] [Foundation-l] a new free image!

body:
David Gerard wrote:
> On 27/02/07, Marco Chiesa <chiesa.marco at gmail.com> wrote:
>
>
>> If I remember I even saw a picture doubly licensed as GFDL + CC-BY-NC-SA
>> (on en.wiki), which I recognised as pure genius. I wonder if such a
>> double licensing would be allowed on commons :)
>>
>
>
> If it is, then I may have a decent chance of getting a Metric Shitload
> of good video content for us under dual GFDL and CC-by-nc-nd ...
>
It believe it should be OK - we only care that a picture has *a* free
license, we're not trying to control all possible licenses for it. But
beware, the non-free CCs have templates that put them in "delete me"
categories, so you might want an alternate template or just boilerplate
text, so triggerhappy admins :-) don't blast the image before noticing
its dual license.

It *is* a clever idea to use GFDL to discourage casual commercial use...

Stan


from_name: Lane, Ryan

subject: [Wikitech-l] using /etc/passwd for authentication

body:
> Is there a way to allow account creation only for users
> already present  in /etc/passwd ?
>
> Thanks a lot if anyone has an idea.
> Holger

Take a look here:

http://meta.wikimedia.org/wiki/PwAuthPlugin

V/r,

Ryan Lane


from_name: Peter

subject:
[Wikitech-l] Introduction + 7zip dump format better for random
	access

body:
if I'm not mistaken the 7z format has no index at the start of the file with
pointers to where all files start, just use plain old zip files, they are
larger in size but they are great for picking out only 1 file.

Cheers,
Peter.

On 2/27/07, Stian Haklev <shaklev at gmail.com> wrote:
>
> Dear all,
>
> I thought I'd introduce myself first. I've been using Wikipedia for
> about four years, mostly the English one (user houshuang), but also
> occasionally the Norwegian (I am Norwegian), the Chinese, and lately
> the Indonesian (I currently live in Jakarta). I am also very
> interested in Wikipedia from a social and technological perspective.
>
> Lately I've been working a lot on a way to use Wikipedia HTML dump
> files offline. I posted about this a while ago, the current version
> can be downloaded from http://houshuang.org/blog . I am working on one
> with a few improvements. It's working quite well right now (I have
> about 8 small language wikis on my HD, and all the interlingua links
> work, etc). THe idea is that it works without unzipping the files
> first, you just place them in the right directory, and given that you
> have 7zip and Ruby, it should just work (serving files to localhost).
> I will make a better installer, a tiny graphical UI etc later, so that
> I can put it on a CD with a given language file, and it will just work
> with one click, on Mac, Windows, Linux.
>
> The problem is that 7zip was never optimized to work quickly on
> extracting one given file out of hundreds of thousands, or millions.
> Right now, the Indonesian wikipedia (60MB 7zipped) takes about 15
> seconds for a page on my two-year old iBook, whereas the Chinese one
> (250MB 7zipped) takes about 150 seconds for a page. I haven't dared
> try any of the bigger ones, like the German (1,5GB) or the English
> (four files a 1,5GB)... My first thought was if it was possible to
> modify the open-source 7zip to generate an index of which block the
> different files where, which would then make the actual extraction a
> lot faster. The problem is that I suck at C, and I have been looking
> for people to help me, even offering a small bounty to the developer.
> (If anyone here would help me, that would be MUCH appreciated! I
> personally think it would be quite easy, given the sourcecode that
> exists, but I don't know for sure).
>
> The developer himself suggested packing the Wikipedia dump file with
> something like this
> 7z a -mx -ms=32M -m0d=32M archive *
>
> which would make it more modular, and much faster to access. However,
> I really don't want to repack all the dumpfiles (I cannot imagine the
> time it would take to rezip the 1,5GB big file) and I don't have the
> capacity to host them - my intention has all the time been for my
> program to work out of the box with the Wikipedia dump files... So I
> am writing here, since I don't know how else to contact the dump file
> developers... is there any way they would consider using these options
> for making the dump files, or if not, what are the reasons (maybe the
> files would get slightly bigger, but I think the benefit would far
> outweigh the disadvantage!).
>
> Anyway, any help or guidance or ideas would be much appreciated. And
> feel free to play around with my program. It's very unfinished (and I
> have a better version which I will publish soon), but it's already
> quite functional, and has saved me through several long boring
> meetings in fancy hotels with too expensive wifi :)
>
> Thank you very much, and please let me know if there are other mailing
> lists - Wikipedia discussion pages which would be more appropriate for
> this question.
>
> Stian in Jakarta
>
> --
> Stian Haklev - University of Toronto
> http://houshuang.org/blog - Random Stuff that Matters
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


from_name: Gwern Branwen

subject: [WikiEN-l] Scott McCloud on Wikipedia

body:
geni <geniice at gmail.com> writes:

t> On 2/27/07, Gwern Branwen <gwern0 at gmail.com> wrote:
>> I would argue that hyper-active admins are more likely to have
a short admin
>> career (whether that be because of desysopping or just
leaving), and further
>> that the likelihood is greater than proportional to their
   edits.
>
> Not exactly whuile the burn out rate is high (2-3 of the top ten
  on
> that list I posted are gone) most are not that new.

Perhaps. Without a longer-term comparison, we might be seeing a
[[survivorship bias]] there. And I think a 30% burn out rate is
fairly high - I don't think the burnout rate of the full cohort of
1,132 admins is so high.

>> My ideal situation would be that admins would be very active
initially so
>> they can learn the ropes,
>
> You can't inforce this

No, not really. It's just what would be a better way of doing
things.

>>and that they would then settle down to an
>> activity level more characteristic of the long tail, where they
are not so
>> much admins but editors with admin powers who regularly (but
   not
>> excessively) help out the current batch of very active new
admins and once
>> in a while clear out backlogs.
>
> There are not enough new admins. Throw in the rate of rule shift
  and
> you have a problem with the older admins.
>
> The long tail isn't doing enough with the result that the head
  has to.
>
> --
> geni

--
Gwern
Inquiring minds want to know.


from_name: Holger Witsch

body:
Hi all,
I'm new on this forum. please bear with me.

I am running a mediawiki (1.6.9 because I would like to put my fingers
into updating php in a server where I am not an admin).

Now this is a wiki which will be looked at by a lot of people in my
company, but only edited by about 15 programmers, who all have an
account on that server.

Is there a way to allow account creation only for users already present
 in /etc/passwd ?

Thanks a lot if anyone has an idea.
Holger


from_name: Jeff V. Merkey

subject: [Foundation-l] [Wikitech-l] mwdumper does not work

body:
Hi Rob,

I completed running mwdumper with the following command last night.  It
took several hours to complete.   I aborted the previous
importDump.php in order to run this test for you.  The wiki they were
run against was en.wikigadugi.org.  The database name is
endb.

[root at gadugi archive]#
[root at gadugi archive]#
[root at gadugi archive]#
[root at gadugi archive]#
[root at gadugi archive]# java -jar mwdumper.jar --format=sql:1.5
/wikidump/dump/enwiki-GFDL-20070206-pages-articles.xml | mysql -u root
-p endb
Enter password:
[root at gadugi archive]#
[root at gadugi archive]#
[root at gadugi archive]#
[root at gadugi archive]#

The mwdumper ran to completion through almost 4 million articles then
exited.  I then applied the command you had specified.  Same result,
mwdumper does not work as was previously reported on other blogs.  I am
running Fedora Core 5 on wikigadugi.  Configuration has already
been provided in previous posts.  Here is the output from applying the
UPDATE command via mysql.

[root at gadugi /]#
[root at gadugi /]# mysql -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 30734 to server version: 5.0.18

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> use endb
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> UPDATE page SET page_touched = 20070226080700
    -> ;
Query OK, 61932 rows affected (2.72 sec)
Rows matched: 61932  Changed: 61932  Warnings: 0

mysql>
mysql>
mysql>

The server is at http://en.wikigadugi.org and as you can see if you
visit the site, mwdumper fails to update any of the articles to the
database (other than filling the mysql Innodb file with a lot of wasted
space).

:-)

Jeff


body:
On 13/02/07, Tangotango <tangotango at wikignome.net> wrote:

> I've uploaded my Wikimedia Commons image/media search tool, dubbed
> "Mayflower",  to the toolserver; it's available at http://
> tools.wikimedia.de/~tangotango/mayflower/.
> Any comments and/or suggestions would be most welcome.

Interesting!

I just did a search on "Canon camera". Um. Well, there are a few
pictures of Canon cameras and lenses there. Mostly shots taken *with*
a Canon camera. And one pic of [[:en:David Cameron]] ...

- d.


from_name: William Pietri

subject: [WikiEN-l] Zero information is preferred to misleading or false

body:
lawrence harms wrote:
> In the reference "Old Catholic Church"  there are listings of Old Catholic Churches in the United States.  There is a Old Catholic Church called "The American Catholic Church in the United States"  This Old Catholic Church is not listed with the rest of the listings.  If you wish, you may want to view there website ACCUS.US
>

This has now been fixed by User:Kf4bdy.

William

--
William Pietri <william at scissor.com>
http://en.wikipedia.org/wiki/User:William_Pietri


subject: [Wikitech-l] [Fwd: Re:  mwdumper does not work]

body:
Wrong list.  Sorry.

Jeff


subject: [Wikitech-l] mwdumper does not work

body:
Sorry, I fat fingered the email address and posted to the wrong list.
Here's the results of my testing.

Hi Rob,

I completed running mwdumper with the following command last night.  It
took several hours to complete.   I aborted the previous
importDump.php in order to run this test for you.  The wiki they were
run against was en.wikigadugi.org.  The database name is
endb.

[root at gadugi archive]#
[root at gadugi archive]#
[root at gadugi archive]#
[root at gadugi archive]#
[root at gadugi archive]# java -jar mwdumper.jar --format=sql:1.5
/wikidump/dump/enwiki-GFDL-20070206-pages-articles.xml | mysql -u root
-p endb
Enter password:
[root at gadugi archive]#
[root at gadugi archive]#
[root at gadugi archive]#
[root at gadugi archive]#

The mwdumper ran to completion through almost 4 million articles then
exited.  I then applied the command you had specified.  Same result,
mwdumper does not work as was previously reported on other blogs.  I am
running Fedora Core 5 on wikigadugi.  Configuration has already
been provided in previous posts.  Here is the output from applying the
UPDATE command via mysql.
[root at gadugi /]#
[root at gadugi /]# mysql -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 30734 to server version: 5.0.18

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> use endb
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> UPDATE page SET page_touched = 20070226080700
   -> ;
Query OK, 61932 rows affected (2.72 sec)
Rows matched: 61932  Changed: 61932  Warnings: 0

mysql>
mysql>
mysql>

The server is at http://en.wikigadugi.org and as you can see if you
visit the site, mwdumper fails to update any of the articles to the
database (other than filling the mysql Innodb file with a lot of wasted
space).

:-)

Jeff


from_name: John Lee

subject: [WikiEN-l] Scott McCloud on Wikipedia

body:
On 2/27/07, T P <t0m0p0 at gmail.com> wrote:
>
> That depends on what we want Wikipedia to be.  If we want it to be the
> elaborated union of all existing encyclopedias, no matter how specialized,
> fine.  But what we want Wikipedia to be is not to be decided strictly
> based
> on the opinions of experts.  Citizendium is --> that way.
>
> I think people are jumping to conclusions about my point.  My point is not
> that webcomics should not be included.  My point is that Scout McCloud's
> evaluation of notability should not carry more weight than the consensus
> of
> the people writing Wikipedia.  If he wants to change Wikipedia he's
> welcome
> to join us in writing it.
>
> Adam

I think something's been missed in the rush here. First of all, many of us
(including myself, a longtime member of the Association of Deletionist
Wikipedians - not that it means anything) have always thought that Wikipedia
exists as an encyclopaedia. Not a general encyclopaedia, not a specific
encyclopaedia, an encyclopaedia. If you can find published sources about
something, then it's in. There's not really a much better way to solve the
problem of deciding what's in and what's out, except through the question of
notability.

Now, regarding notability, I think it's become a bit outmoded. Notability as
a concept stems from the VfD days when we could not find valid reasons to
delete an article, but the community agreed that it was not suitable for WP.
Nowadays, almost any article that deserves to be deleted can be deleted
without resort to notability. Typically, the article is unverifiable,
innately biased, or whatever.

I think one of the worst things that has happened WRT deletion is the
codification of notability - ironically as an attempt to make something
subjective objective because inclusionists kept demanding that we have
objective criteria for deletion. Notability is a placeholder concept for
common sense. The trouble is, as WP scaled up, we got a lot more
contributors without enough common sense to think about what they're doing,
and so we decided to codify notability instead of either getting rid of it
as outmoded, or finding some other way to keep common sense around for those
who can use their noggins.

I really can't see the argument against including something that a
specialist encyclopaedia (which is often a tertiary source) has an article
about, unless the encyclopaedia itself is a primary source on the subject.
Sure, a lot of the crap is trivial - I couldn't care less about some vintage
postage stamp of which only half a dozen were ever made, or about some
ridiculous Pokemon character. But if they're verifiable, they're in. The
only question is whether we can keep enough common sense about ourselves,
and get our editors to write these articles as they should be written,
instead of dribbling over them like crazed fans (as happens so often with
fiction-related articles).

As for the question of experts, I think this notion that WP is completely
egalitarian is totally fictitious. From day one, some Wikipedians have been
considered more qualified and worthy of having their opinions heard than
others. WP is not a vote, and not all WPians have equal standing. This is
just how it has always been, because if everyone is equal, if everyone has
the same voice, then we are effectively an anarchy - which, contrary to what
some might think, is not what WP is. We have some hierarchical structure -
it's just very loose because often we don't need to rely on it.

When it comes to borderline issues, though, I think there has to be some
external force acting on people to ensure we don't go overboard. This goes
for whether we are having a content dispute, edit war, or yes, a borderline
AfD. Until now, the only people whose voices have counted more have
generally been Wikipedians. But I see no reason to exclude experts
completely either from having a voice in how things go.

The demand that experts participate in WP is, I think, a little excessive.
Many of these people don't have the time to participate, or don't think of
it as a fruitful use of their time. That's not a reason to ignore them,
however. The voices of experts should be given a little gravity, instead of
completely ignored. In the past, we have deferred to the interests of people
with a vested interest in the outcome of things, even when they have not
said a word - Brian Peppers comes to mind. Here, someone without a vested
interest - an objective observer - is commenting on an article, and yet we
choose to ignore him. I don't see the logic in that.

If an article truly does not belong on Wikipedia, there are usually much
better arguments to be made than "delete, nn". One problem I can think of
with webcomics is verifiability - how many of them have been written about
in a secondary source? There shouldn't be a need to apply notability except
in the real borderline cases which a policy/guideline has never encountered
before (i.e. the real outliers). Notability should always be a last, not a
first resort, and experts ought to be given weight. We shouldn't blindly
accept anything they say, but neither should we reject them out of hand
simply because of this false notion that WP is egalitarian and that you need
to be a Wikipedian to have a say in what goes on here.

Johnleemk


subject: [WikiEN-l] Scott McCloud on Wikipedia

body:
On 2/27/07, T P <t0m0p0 at gmail.com> wrote:
>
> On 2/26/07, Marc Riddell <michaeldavid86 at comcast.net> wrote:
> >
> > > On Feb 26, 2007, at 8:40 PM, T P wrote:
> > >> I noted elsewhere that, as a volunteeer effort, Wikipedia is
> primarily
> > >> written to satisfiy the needs of the writers.
> > >
> > > and
> > >
> > >> Practically speaking, what matters is the opinions of the people
> > >> working on
> > >> Wikipedia, because you sure as hell aren't going to "fix" Wikipedia
> > >> just
> > >> because outsiders think it's broken.
> >
> > on 2/26/07 8:44 PM, Phil Sandifer at Snowspinner at gmail.com wrote:
> > >
> > > There's not much to say here. Both of these statements are, I think,
> > > 100% wrong. They are the polar opposite of how Wikipedia should work.
>
>
>
>
> > They represent the exact instinct that causes many of the problems
>
> > I've been describing here. I think it is vital that we do everything
> > > we can to resist these attitudes on every conceivable level.
>
>
> I think you need to distinguish between the way Wikipedia works and the
> way
> you think it should work.  My comments relate to the former.  Yours relate
> to the latter.
>
> If you can think of a way to make a volunteer organization like Wikipedia
> work the way you think it should work, more power to you.
>
> Adam

Correction: that's the way *AfD* works. You note that WP exists to serve the
writers, but most (if not all) of those commenting on certain nominations
may have never written on the topic concerned. That's not to say they should
be ignored, because WP works by consensus, but if the people who know most
about a field are writing about something, or saying that something deserves
an article, then generally shouldn't it be included, unless it fails certain
guidelines/policies, e.g. verifiability?

Johnleemk


body:
> Using display: none to enforce semantics is bad.  It will then show up
> for many cell phone users, old screen readers, Lynx, etc.

I concur.  Even modern feed aggregators will ignore CSS (even inline
style="" directives).

> The comment was probably a better idea, although unfortunately still
rather hacky.

Yeah it's hacky - I can't argue with that - but it's the only way I know of
to deal with all three of the following:

1) HTML comments found in wikitext are stripped (we get around this by using
an extension tag)
2) Whitespaces in extension output are converted to <br> and <p> tags (we
get around this by putting it in an HTML comment)
3) Malicious users could prematurely end the comment by putting "-->" in the
keyword text followed by <script> or any other HTML markup (we avoid this by
base64 encoding all input and only decoding it during the meta parsing
step).

If there's a better way to achieve this, I'm open to suggestions.  I've been
using this technique on extensions I've been developing since I haven't yet
found a better way.  But seriously, if there /is/ a cleaner way to do this
I'd love to know about it :)

On 2/27/07, Simetrical <Simetrical+wikilist at gmail.com> wrote:
>
> On 2/27/07, Jim Wilson <wilson.jim.r at gmail.com> wrote:
> > 3) Add a CSS rule to hide spans of class keyword (to MediaWiki:
> Common.css):
> >
> >     span.keyword { display: none; }
>
> Using display: none to enforce semantics is bad.  It will then show up
> for many cell phone users, old screen readers, Lynx, etc.  The comment
> was probably a better idea, although unfortunately still rather hacky.
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


subject: [WikiEN-l] Scott McCloud on Wikipedia

body:
On 2/27/07, Marc Riddell <michaeldavid86 at comcast.net> wrote:
>
> on 2/25/07 10:29 PM, John Lee at johnleemk at gmail.com wrote:
>
> > Okay, instead of bickering over whether there is a problem with the
> status
> > quo, let's assume there is a problem. What should we do to solve this
> > problem? I haven't seen many ideas about what ought to be done to
> resolve
> > the ostensible issues.
> >
> > I'm not saying there isn't a problem, nor am I saying it's impossible to
> > solve it. However, I think it's important to recognise that you can't
> expect
> > perfection from an innately imperfect project. When you have something
> on
> > the scale of Wikipedia, involving so many mortals, the errors multiply
> by
> > each other pretty quickly, and add up to some massive problems. We need
> to
> > solve them, and the status quo is what we came up with. It's clunky, it
> > sucks, but it's better than nothing.
> >
> > The problem, as I see it, is that there's just far too little common
> sense.
> > Defining common sense is of course an ordeal I am not about to delve
> into,
> > but the point of our policies and guidelines is to enforce a semblance
> of
> > common sense on people lacking it. ??????
> >
> > Johnleemk
>
> Common sense or common purpose? What common sense needs to be applied to
> accomplish this common purpose?
>
> I see a great deal of the problem being many persons with many different
> agendas and purposes for being in WP itself. If a degree of common sense
> is
> needed to accomplish the common goal of ?A? then all persons must be
> trying
> to accomplish ?A?. If others are there to accomplish ?B?, their ?common
> sense? will be applied and measured differently.
>
> Solutions? That is going to take some creative, collaborative thinking
> with
> all participants working toward the same common goal. But first, there
> must
> be an agreement about what the problem - and its cause - really is.
>
> There seems to be a great deal of resistance to the idea that many of the
> problems within WP involve the very culture itself. This speaks to me of a
> great deal of denial on the part of the Community Members.
>
> Denial is saying ?anything but that?. To admit that the ?that? is the
> problem, might mean having to confront, and possibly get rid of, the
> ?that?.
> If a chemical dependent admits that the chemical is the ?that? that is
> killing them, they might have to give up that ?that?.  ?Anything but
> that!?
>
>
> Marc Riddell

It's a question of whether we want a "big tent" of people with different but
similar purposes working together to achieve a result that approximates what
all of them desire, or whether we want a smaller but more dedicated group to
achieving a particular common purpose. I have always been torn between the
two, but I am of the opinion that it wouldn't hurt to turn Wikipedia more to
the latter direction. At times, there's been a great deal of
misunderstanding about what exactly Wikipedia is. It's not an attempt to use
a democracy or anarchy to organise information. It's not an attempt to prove
that a decentralised approach to organising information works. It's not an
attempt to make information egalitarian by being anti-expert. It's not a
social networking site. It's an encyclopaedia, and everything about
Wikipedia, directly or indirectly, should be related to the purpose of
writing an encyclopaedia.

Regarding the issue of culture, I'm not sure if that was meant to directly
rebutt anything I said, because I implied that the problem is one of
culture. We've turned to more red tape and more policy in order to
approximate the common sensibility that was shared in earlier days. The
inclusionist and deletionist debates were in full swing around 2004, but you
didn't see complaints about "rouge admins" or things like that, because
people had the common sense to respect each other, to accept different
viewpoints, to understand their limitations. That culture is gone.

The reason I mentioned that we may have to resort to a software fix is
because I am very skeptical about the possibility of changing our culture.
It's not possible to do this without alienating a lot of longtime editors.
In the end, it's possible that we could massively purge WP of people who
don't share the common purpose of building an encyclopaedia, but it's highly
implausible. I believe we can survive without these people, because a lot of
edits are made by anonymous editors, but we will never drive them off,
because it's politically unacceptable to most Wikipedians, even those who do
share the common purpose of building an encyclopaedia.

Therefore, what has to be done is to find ways to limit the damage our
corroded culture can do. We've tried the policy route, and it's failed
abysmally. It's time to see if article and editor ratings, together with a
more refined approach to blocking, can ameliorate the problem.

Johnleemk


from_name: Phil Sandifer

subject: [WikiEN-l] What makes a good article?

body:
On Feb 27, 2007, at 5:19 AM, John Lee wrote:

>
> The trouble I have with the citation fetish is that it goes
> overboard. For
> example, let's say that I have two or three core sources for an
> article -
> webpages written by published and respected authors and experts in the
> field. Does it make sense to cite these pages for every little
> detail in the
> article, or does it make sense to collate them in one section
> titled as
> references? I would argue that it is the latter that matters, but
> the inline
> citation fetishists have succeeded in making the typical reading of
> our
> guidelines closer to the former. As Phil (I think) noted not too
> long ago,
> one article even has a footnote for the name of the article's
> subject! This
> only makes sense if the name is a disputable/unique detail (e.g.
> [[Jeff
> Ooi]] is always known as Jeff Ooi to most Malaysians, but his legal
> name is
> Ooi Chuan Aun, so it makes sense to provide a citation for the
> latter in the
> lead).

I think we need to distinguish among three tiers of information.

1) Needs a citation
2) Would be nice if it had a citation
3) Doesn't need a citation.

Remove all of #1 that lacks a citation. Leave #2 and #3 alone, adding
them if you have them handy. But it's non-essential.

-Phil


from_name: Jim Hu

subject: [Wikitech-l] Help w/Debugging and database functions

body:
I'm trying to use the database functions to connect to an external
database called wikibox_db using the following

			$dbr =& wfGetDB( DB_SLAVE );
			$dbr->debug(true);
			$dbr->selectDB('wikibox_db');
			$output .= "\n\nQuery:".$dbr->lastQuery()."<br>\n\n";

			$res = $dbr->select(
				'wikibox_db.box',
				'*'
			);

This gives the following error on the special page I'm working on:

A database query syntax error has occurred. This may indicate a bug
in the software. The last attempted database query was:
(SQL query hidden)
from within function "Database::select". MySQL returned error "1103:
Incorrect table name 'wikibox_db.box' (jim-hus-computer.local)".

Not surprisingly, it works if I query a table in the mediawiki
schema.  Two questions:
1) Anyone know how to do this?
2) How do I set the wiki to not hide the sql query from me?

Thanks!

Jim
=====================================
Jim Hu
Associate Professor
Dept. of Biochemistry and Biophysics
2128 TAMU
Texas A&M Univ.
College Station, TX 77843-2128
979-862-4054


body:
> Probably the "cleanest" way to do it would be to create a new database
> table for it, akin to categorylinks or other metadata tables, and
> query that on page render.  Whether in practice that's better than the
> hacky solution, I don't know.

Would it be unethical to utilize the objectcache table for this purpose?  In
other words, push in a new entry at page-render time, then look it up at
page-display time.  (If none is there at page-display time, then the script
assumes there's no meta data to use).

Just a thought.

On 2/27/07, Simetrical <Simetrical+wikilist at gmail.com> wrote:
>
> On 2/27/07, Jim Wilson <wilson.jim.r at gmail.com> wrote:
> > Yeah it's hacky - I can't argue with that - but it's the only way I know
> of
> > to deal with all three of the following:
> >
> > 1) HTML comments found in wikitext are stripped (we get around this by
> using
> > an extension tag)
> > 2) Whitespaces in extension output are converted to <br> and <p> tags
> (we
> > get around this by putting it in an HTML comment)
> > 3) Malicious users could prematurely end the comment by putting "-->" in
> the
> > keyword text followed by <script> or any other HTML markup (we avoid
> this by
> > base64 encoding all input and only decoding it during the meta parsing
> > step).
> >
> > If there's a better way to achieve this, I'm open to suggestions.  I've
> been
> > using this technique on extensions I've been developing since I haven't
> yet
> > found a better way.  But seriously, if there /is/ a cleaner way to do
> this
> > I'd love to know about it :)
>
> Probably the "cleanest" way to do it would be to create a new database
> table for it, akin to categorylinks or other metadata tables, and
> query that on page render.  Whether in practice that's better than the
> hacky solution, I don't know.
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


subject: [WikiEN-l] Presentation to readers

body:
On Feb 27, 2007, at 8:06 AM, Andrew Gray wrote:

>
> Hmm. I like it.
>
> "The Wikipedia community has identified issues with the quality of
> this article; [click here] to show more specific details or [see the
> talk page] for discussion regarding the issue"
>
> First link brings a dropdown as with the banners template; second
> takes you to talk. If you were particularly clever, "the quality"
> could be changed on the fly to reflect the specific tagging...

This is, of course, an even better idea. The only quibble I have is
that I dislike the use of "the Wikipedia community," which seems to
me to go too far in the other direction in establishing a split
between reader and editor.

Perhaps "It has come to our attention that this article may not be as
good as we'd like it to be. [click here] to see more specific
details..." and so on.

-Phil


subject: [WikiEN-l] Scott McCloud on Wikipedia

body:
On 2/27/07, Jeff Raymond <jeff.raymond at internationalhouseofbacon.com> wrote:
>
>
> Marc Riddell wrote:
>
> > I see a great deal of the problem being many persons with many different
> > agendas and purposes for being in WP itself. If a degree of common sense
> > is
> > needed to accomplish the common goal of ?A? then all persons must be
> > trying
> > to accomplish ?A?. If others are there to accomplish ?B?, their ?common
> > sense? will be applied and measured differently.
> >
> > Solutions? That is going to take some creative, collaborative thinking
> > with
> > all participants working toward the same common goal. But first, there
> > must
> > be an agreement about what the problem - and its cause - really is.
>
> Well, I think the first step is to stop thinking that common sense is
> universal.  Look at what happened over the weekend - common sense
> apparently told people that we did and didn't need an article on Daniel
> Brandt, and did and didn't need to discuss it.  Some people feel common
> sense is to simply do what you think is best (WP:IAR, which should be
> destroyed with heat seeking nuclear missiles after the way February has
> gone on this project), some people feel common sense is giving people the
> due process they crave.
>
> There's obviously no such thing as "common sense" here, so we need to get
> out of that frame of mind and come to a conclusion as to what's best - not
> what's favored by any specific group of people, not what the people who
> show up on a given afternoon believe, but what makes the most logical
> sense for the project to continue to succeed as opposed to looking like
> morons to outsiders.
>
> >
> > There seems to be a great deal of resistance to the idea that many of
> the
> > problems within WP involve the very culture itself. This speaks to me of
> a
> > great deal of denial on the part of the Community Members.
>
> Damn skippy.  You nailed it with this paragraph.
>
> >
> > Denial is saying ?anything but that?. To admit that the ?that? is the
> > problem, might mean having to confront, and possibly get rid of, the
> > ?that?.
> > If a chemical dependent admits that the chemical is the ?that? that is
> > killing them, they might have to give up that ?that?.  ?Anything but
> > that!?
>
> I mean, an easy short term fix has two steps:
>
> 1) Stop giving administrators carte blanche to do as they please when they
> please based on their version of common sense.
>
> 2) Remove the admin bit from the worst offenders, in which there are more
> than enough to cause major problems and further destroy a culture that's
> been rotting for a long time.
>
> This solves - in the short term - 90% of our problems, and gives us the
> opportunity to fix the problems, heal the wounds, put up the necessary
> boundaries, and start as fresh as possible.  We're in a good *position* -
> Citizendium, the most capable fork to challenge Wikipedia long-term, is
> not ready for prime time, or even cable access - but we're very close to
> teetering off the edge.  We can unbecome a top 15 website quicker than we
> became one, and that can be headed off at the pass by amputating the
> diseased aspects - users, administrators, policies, guidelines, and even
> articles.
>
> But I remain pessimistic.  Even now, after three weeks of consistent
> abuses from many administrative forces, the only time Jimbo feels the need
> to step in is due to a wheel war.  It tells me that the perspective on the
> top end is lacking regarding the problems this project is facing on the
> interior, which, while a legitimate perogative, is unfortunate for those
> of us who are/were doing the legwork to keep the articles coming and the
> cash flowing.  And the sickness will still remain.
>
> -Jeff

I think some perspective is necessary. Common sense isn't necessarily the
same amongst different people, but I think there are some elements that tend
to be the same. Common sense is the ability to know your limitations, to
respect other people's opinions, and to deal with different opinions in a
peaceful manner. Despite some of the worst and most turmoiled debates I can
imagine occurring in 2004, we didn't have a problem with "rouge admins" or
such other issues. It was because the overall culture then was one of common
sense. As we scaled up, many newer editors were not assimilated into this
culture, and thus people resorted to policy and red tape to solve things
instead.

I don't believe there's carte blanche for admins, nor that there ever has
been. Even though in the early days, admins could have been said to have a
sort of blank cheque, it was much like the powers the Queen theoretically
has - the blank cheque was hardly ever exercised except where truly
necessary, in the borderline outliers. Today's culture in newer admins,
however, is that the blank cheque exists to be used in any case. The
elements of common sense that once were a core part of our culture are gone.

The blank cheque is *very* useful for handling the outlying cases, and
that's why I've always maintained that it's necessary. The problem with
these reserve powers, however, is that they are so easily abused, despite
their necessity. More red tape only creates more loopholes through which
"rouge admins" can abuse their powers, so I would prefer a slightly more
structured hierarchy which permits, say, some people to oversee the exercise
of admin powers. At least we can reduce the possible points of failure,
without resorting to Jimbo.

And I've always favoured getting serious about desysoping people. Adminship
is no big deal, and taking it away shouldn't be that big a deal either. The
problem is that the arbcom works too slowly, and so we constantly require
Jimbo to step in. That shouldn't be the case.

Johnleemk


subject: [Wikitech-l] Commons image archive

body:
On 2/27/07, Bryan Tong Minh <bryan.tongminh at gmail.com> wrote:
> Hello,
>
> As you might or might not know, the Commons Picture of the Year 2006
> [1] is running. We have also made an archive [2], which we want to be
> available as a zip download. This archive contains all Featured
> Pictures of 2006 and their licensing and description. This archive is
> 550 MB big. Would it be possible to have it hosted on
> download.wikimedia.org?

Hi.

I've turned your directory into a 500mb zip. I've made a torrent from
the zip.  We can host a tracker on toolserver.

In addition to the wikimedia bandwidth, I can provide about 10mbit/sec.

We frequently see people advocating BitTorrent for
download.wikimedia.org. I am not convinced that we get enough
transfers of a single dump to make it worth while. However, POTY will
probably get more traffic.. I think it would be a worthwhile
experiment.

Any objections?


from_name: Yury Tarasievich

subject: [Wikipedia-l] Translating the Five pillars

body: So, an online community with no real rules. You must be kidding guys.


from_name: Simetrical

subject: [Wikitech-l] Captcha changes

body:
On 2/27/07, Ben McIlwain <cydeweys at gmail.com> wrote:
> Has the CAPTCHA since been disabled, and why?  We're no longer seeing it
> in use on any wikis while trying to make anonymous edits.

The captcha was only universally enabled for registrations and
potentially spammy things like the addition of external links, not for
anonymous edits generally.


body:
On 2/27/07, Jim Wilson <wilson.jim.r at gmail.com> wrote:
> 3) Add a CSS rule to hide spans of class keyword (to MediaWiki:Common.css):
>
>     span.keyword { display: none; }

Using display: none to enforce semantics is bad.  It will then show up
for many cell phone users, old screen readers, Lynx, etc.  The comment
was probably a better idea, although unfortunately still rather hacky.


body:
On 27/02/07, Delirium <delirium at hackish.org> wrote:

>  When I come back to one
> of these tasks after an absence, it takes concerted effort to navigate
> the web of rules and templates and informal policies.  Even simple stuff
> like, "so what's the current policy on warning/blocking vandals, and
> which of the 100+ user warning templates should I use?".  It tends to
> lead to me doing a small subset of things I feel confident in my
> familiarity with (new-article and recent-changes patrolling, mainly, and
> some prod-clearing), and avoiding anything else.

Ah, yep.

> To be fair, some parts
> of our "process" do have concise documentation on the relevant page with
> nicely laid out bold text saying something like "If you're just
> wondering how to do [x], do these steps: 1, 2, 3, 4", and in those cases
> it's easier to get into them.

Rewrites for clarity are always a good idea, if you can form the
patchwork of special cases into something coherent without losing
hard-fought detail.

- d.


from_name: MacGyverMagic/Mgm

subject: [WikiEN-l] Presentation to readers

body:
One or two templates are rarely a problem. It gets ugly when an article has
3 or more problem templates stuck to it. Perhaps we can have some
non-obstrusive box like "ArticleHistory" to cut down on too many templates,
and somehow get that template to show what's wrong in a more concise manner?

Mgm

On 2/27/07, David Gerard <dgerard at gmail.com> wrote:
>
> On 27/02/07, geni <geniice at gmail.com> wrote:
>
> > Things like {{notability}} whatever the tags are for cats needed and
> > total lack of citations tags can go on the talk page but ah it didn't
> > catch on last time so I assume there is some oposition somewhere or
> > that people don't really care about the problem.
>
>
> Total lack of references should be noted on the article itself. It's
> useful to the reader to know.
>
> "Notability" warnings are part of the ongoing AFD conflict. I predict
> that putting them on talk will be seen as an attempt to encourage
> deletion by stealth.
>
>
> - d.
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>


subject: [Wikitech-l] RTL-lang messages in a multilingual wiki

body:
On 2/27/07, Brianna Laugher <brianna.laugher at gmail.com> wrote:
> Hello,
>
> Please compare
> http://commons.wikimedia.org/w/index.php?title=Special:Userlogin&uselang=he&type=signup
> to
> http://he.wikipedia.org/w/index.php?title=Special:Userlogin&uselang=he&type=signup
>
> On Commons, the messages appear RTL text direction which is correct,
> but on the left, which I imagine is as unnatural as right-aligning for
> English.

Monobook appears to use the content language to decide whether to make
the site as a whole right-to-left.  I'm not sure if this is correct
behavior.  Certainly the content direction should depend on the
content language, but I would think the overall page (and all
interface messages) should depend on the interface language.  Can
anyone think of why the whole page should be the same direction as the
content language and not the interface language?

> Should we (Commons) go and insert <span align="right"> around every /he message?
> Would this solve it?
> (Would this be a *good way* to solve it?)

That would probably not be a good solution at all, and it would only
partly work.  If you want to solve it on your side, rather than
waiting on software changes, ideally you should be able to do it via
CSS rules, although I'm not sure whether there's anything you can key
off of with a CSS rule to determine interface language at present.
(You may have to use JS to get the CSS rules to work, though, which is
a bad solution.)

I'm thinking we could add some more classes to the <body>:
interface-langcode, content-langcode, interface-dir, content-dir.
Then we could move all the RTL stuff into the main stylesheets, in
fact, rather than adding it conditionally as an extra stylesheet.


body:
On 2/27/07, Jim Wilson <wilson.jim.r at gmail.com> wrote:
> Yeah it's hacky - I can't argue with that - but it's the only way I know of
> to deal with all three of the following:
>
> 1) HTML comments found in wikitext are stripped (we get around this by using
> an extension tag)
> 2) Whitespaces in extension output are converted to <br> and <p> tags (we
> get around this by putting it in an HTML comment)
> 3) Malicious users could prematurely end the comment by putting "-->" in the
> keyword text followed by <script> or any other HTML markup (we avoid this by
> base64 encoding all input and only decoding it during the meta parsing
> step).
>
> If there's a better way to achieve this, I'm open to suggestions.  I've been
> using this technique on extensions I've been developing since I haven't yet
> found a better way.  But seriously, if there /is/ a cleaner way to do this
> I'd love to know about it :)

Probably the "cleanest" way to do it would be to create a new database
table for it, akin to categorylinks or other metadata tables, and
query that on page render.  Whether in practice that's better than the
hacky solution, I don't know.


from_name: Marc Riddell

subject: [WikiEN-l] Scott McCloud on Wikipedia

body:
on 2/26/07 9:57 PM, John Lee at johnleemk at gmail.com wrote:

> It's a question of whether we want a "big tent" of people with different but
> similar purposes working together to achieve a result that approximates what
> all of them desire, or whether we want a smaller but more dedicated group to
> achieving a particular common purpose. I have always been torn between the
> two, but I am of the opinion that it wouldn't hurt to turn Wikipedia more to
> the latter direction.

Terrific post, John.

I agree with how you are leaning. I don?t believe it matters how large the
group - although it would seem that a smaller one would be easier to
coordinate. But it does matter a great deal that this group have a common,
specific, and mutually agreed upon purpose or goal. In the case of
Wikipedia, I believe that goal should be to create and maintain a reliable,
unbiased encyclopedia of human knowledge.

At times, there's been a great deal of
> misunderstanding about what exactly Wikipedia is.

For the record, I differentiate between Wikipedia and the Wikipedia
Community. Wikipedia (the encyclopedia) is created and maintained by the
Community (the people). Wikipedia needs specific policies and guidelines to
govern its characteristics ? so should the Community. If there is
ambivalence or downright disagreement about either of these, you have
confusion ? actually, you have a mess.

It's not an attempt to use
> a democracy or anarchy to organise information. It's not an attempt to prove
> that a decentralised approach to organising information works. It's not an
> attempt to make information egalitarian by being anti-expert. It's not a
> social networking site. It's an encyclopaedia, and everything about
> Wikipedia, directly or indirectly, should be related to the purpose of
> writing an encyclopaedia.

Well put. And, yes, it is that simple.
>
> Regarding the issue of culture, I'm not sure if that was meant to directly
> rebutt anything I said, because I implied that the problem is one of
> culture.

No rebuttal was intended.

?people had the common sense to respect each other, to accept different
> viewpoints, to understand their limitations. That culture is gone.

I believe it has more to do with emotional makeup than common sense. And,
unfortunately, it appears I have come too late to the Community to have
experienced the culture you say was.

>
> The reason I mentioned that we may have to resort to a software fix is
> because I am very skeptical about the possibility of changing our culture.

But wouldn?t that be like replacing the electrical system of a car whose
engine is shot?

> It's not possible to do this without alienating a lot of longtime editors.
> In the end, it's possible that we could massively purge WP of people who
> don't share the common purpose of building an encyclopaedia, but it's highly
> implausible. I believe we can survive without these people, because a lot of
> edits are made by anonymous editors, but we will never drive them off,
> because it's politically unacceptable to most Wikipedians, even those who do
> share the common purpose of building an encyclopaedia.

If the persons (editors) agree to a common purpose and a set of common
cultural values, what could possibly be their argument to keep anyone who
doesn?t?
>
> Therefore, what has to be done is to find ways to limit the damage our
> corroded culture can do. We've tried the policy route, and it's failed
> abysmally. It's time to see if article and editor ratings, together with a
> more refined approach to blocking, can ameliorate the problem.
>
* John, I?m afraid it?s going to take more that mechanical fixes to halt the
corrosion. It is going to take everyone from the top down finally coming to
terms with the fact that there are flesh and blood, emotional, human beings
at the core of this project ? each bringing their own learning, life
experiences and day-to-day struggles into the mix. The larger culture we
come from, and have learned from, doesn?t handle this emotional aspect of
the human being very well. But, perhaps, with some work, the Wikipedia
culture can.

Marc Riddell

--

You can dream of a moment for years, and still somehow miss it when it
comes.  You?ve got to reach through the flames and take it - Or lose it
forever.