subject: [Wikitech-l] Debugging suggestions?

body:
Thanks Brion, it turns out that I did have an extra newline after my
copy of EasyTimeline.php.  That did the trick.

Still, I'd be curious how y'all go about debugging your code.  Do you
really jus sprinkle printf's throughout?

thanks,
-Nick

Brion Vibber wrote:

> On Dec 5, 2004, at 11:23 AM, Nick Triantos wrote:
>
>> I've got a strange problem on my installation of mediawiki (an extra
>> blank line is emitted as the first line of all pages from my site).
>> This apparently breaks the RSS feeds.
>
>
> Usually this is because some extra whitespace has crept into one of
> the .php files.
>
> PHP scripts are actually embedded into a surrounding file (generally
> HTML), though in the case of 'biggish' apps like ours we've generally
> got a bunch of include files which are code only; everything goes
> inside <?php ... ?> tags. If there is a blank line at the start, or
> more than a single newline at the end, then the extra space will be
> output when the script is loaded. If this comes before output
> buffering is started that can prevent the output of HTTP headers from
> the script, or perhaps also damage gzip compression mode, etc.
>
> Check for extra whitespace around the <?php ... ?> tags, particularly
> in LocalSettings.php or other files you might have modified.
>
>> Interestingly, I made a second copy of the wiki software in which
>> I've been hacking in trying to debug this, and there, I see my shell
>> prompt as the first line of text.  So, something's pretty obviously
>> shelling out during init, but I've currently got no idea what is
>> doing that.
>
>
> Now that's just _weird_...
>
> -- brion vibber (brion @ pobox.com)
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Wikitech-l mailing list
>Wikitech-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


list: wikien-l

source: pipermail-mbox

from_name: Cool Hand Luke

subject: [WikiEN-l] 3RR - what exactly are "complex reverts"?

body:
I agree. Labeling it vandalism seems to give many users an excuse to
be drawn into revert wars. Unless it's simple vandalism (inserting
profanity, making the article ungrammatical, blanking it, patent
nonsense, ect), no one should violate the 3RR. Many folk have a much
broader definition of vandalism than simple vandalism, and if apprised
of this they should be blocked like other violators. Besides, it
doesn't accomplish anything and impedes resolution.

> No reverting isn't vandalism. VIP is busy enough just dealing with
> straightfowards George Busher is a wanker type vandalism.
>
> Theresa
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


list: wikitech-l

from_name: Brion Vibber

subject: [Wikitech-l] page deletion

body:
On Dec 5, 2004, at 3:36 PM, Evan Prodromou wrote:
> On Sat, 2004-04-12 at 08:59 -0800, Brion Vibber wrote:
>> The chief reason to be deleting something (as opposed to redirecting
>> it
>> to a more appropriate article or replacing it with a better one) is
>> that it includes copyrighted material that we don't have permission to
>> distribute. This necessitates not being able to have _just anybody_
>> come along and view or undelete it.
>
> Technically, it's probably not that kosher even to make the works
> available to admins.

They're "available" only in the same way that you can scrounge things
out of the trash bin before it's emptied.

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


list: foundation-l

from_name: Jonathan Fors

subject: [Foundation-l] Wikidoc

body:
Hello, fellow Wikimedians!

Since this is my first post to this mailing list, please let me
introduce myself. My name is Jonathan Fors and I am chairman for the
V?ster?s LUG, located 100 km west of Stockholm, Sweden. I am a full-time
Linux user and an occasional Wikipedia contributor, and I am a big fan
of Wikis in general.

In our LUG, which has existed for little less than a year, we have
started an ambitious Wiki project using Mediawiki. Its purpose is not
only to collect information about, but also to be a complete Swedish
Free Software documentation resource. We have and are translating
HOWTOs, manpages, tips and write documentation about all files and
directories of the *NIX system. Basically, it aims to be a complete
guide to GNU/Linux, *BSD and Free Software.

Now, the last week, some of our contributors have told us that they feel
like duplicating the Wikipedia project, something that I cannot fully
agree to. Wikipedia is encyclopedic and documentation isn't, meaning
that it not really fits there. I know about Wikibooks, but the whole
concept of a "single place for GNU/Linux and Free Software
documentation" would be a little far off. But not to cooperate with the
Wikimedia foundation would be to waste a big resource of knowledge and
knowledgeable people. So therefore, I have an idea.

There are, as far as I can see, a few subprojects under the Wikimedia
umbrella. Wikipedia, Wiktionary and Wikibooks are a few examples. They
contain different types of, often non-encyclopedic information that
don't fall under the same category as Wikipedia. The project most
similar to our Wiki is probably Wikibooks, which contains, guess what,
books! Well, not only books, but manuals in general. This is although
not ideal for the users that our Wiki aims to serve with information.

So here is the idea, feel free to flame or comment about it. I propose a
new subproject, perhaps called "Wikidoc", that documents 1. GNU/Linux
(including all distributions) 2. The various flavours of Free operating
systems 3. Free software in general (including those running on Windows,
web-based CM systems and so on).
Information (the sort you could find in an encyclopedia) goes to
Wikipedia and is linked from Wikidoc. Longer, in-depth books are linked
from Wikibooks, and source code and historical Usenet announcements
could be linked from wikisource. Wikimedia has IMHO a good opportunity
to create a Wiki for Free software, and much of the infrastructure is
already present.

Okay, I bet you have some things to crack down onto this on.
First, why do this under Wikimedia when there is wiki.linuxquestions.org
and the BerliOS Wiki that does the "same thing"?
Well, this thing would not be able to use the Wikimedia projects very
well. The great resources would effectively not be usable and also, the
user base is much smaller than Wikipedia's.

What has this got to do with Wikimedia at all?
In my opinion, the Free Software documentation would be something that
would attract a lot of new users, in a lot of languages. The reason we
started our Swedish project was that we felt that there was very little
high-quality documentation for GNU/Linux written in Swedish, and the
little that was was very scattered across the Internet. This was the
situation for the Swedish GNU/Linux movement back then, something that
now has changed with the advent of a few GNU/Linux-oriented Wikis.

I hope to receive feedback on this idea, and in the meantime you can
visit the Wiki at http://vlug.linux.se/wiki (Swedish)

Yours Sincerely,
Jonathan Fors
Chairman, V?ster?s Linux User Group
http://vlug.linux.se/


list: wikimedia-l

subject: [Foundation-l] Wikidoc


from_name: Tucci

subject: [WikiEN-l] original research

body:
--- Charles Matthews <charles.r.matthews at ntlworld.com>
wrote:

> Stan Shebs wrote
>
> > [...]  but I
> > can see WP *creating* a demand for new original
> research, to
> > answer questions that have come up.
>
> I don't think 'original research' should cover
> original scholarship.  That's
> a stretch.
>
> Charles

I'm not sure I understand this distinction, so let me
give an example.  In the field of music, there are a
number of genres that use very simple, stark and
emotional lyrics about poverty and bad luck, use
sparse, acoustic accompaniment, and are
played/invented by a group of poor people, often an
ethnic or religious minority.  The most famous example
is the blues.  Many music publications will compare a
genre like Brazilian samba or Greek rembetika to the
blues because it shares these traits -- these
comparisons occur in a wide variety of publications,
and it seems to be generally accepted that these
similarities are notable, despite there being no
historical relationship between the genres.  To the
best of my knowledge, no one has ever specifically
studied or documented this phenomenon; it's existence
is purely limited to a reference here and there in an
article on some other subject.

I put a list of such genres on the [[list of genres of
the blues]], along with an explanation (the list is
separated from the styles with a historical
relationship to the blues).  Would this count as
original research?  I didn't create a new observation,
but put other peoples' observations together in a new
way.

Just in case you're interested, here's a quote which
is fairly direct.  Ironically, it doesn't mention the
blues and does note the similarity of being from urban
port cities, which wouldn't apply to the blues.

:Thus, if we take together the Fado of Lisbon, the
Tango of Buenos-Aires and the Rembetika of Athens, we
will note firstly that all of them emerged a little
before or after the middle of the 19th century in poor
districts of the big port cities of the nascent
industry, attracting people from the country or from
abroad, and who were confined to a marginal existence.
And if we look for other parallels in the development
of these urban popular cultures, we will find them
again: first, their obscure and repressed beginnings,
then their discovery and appropriation by elements of
the higher social classes, later their acceptance and
admission by the establishment (often after their
success outside of the native land) before ending as a
subject of tourist explorations.

__________________________________
Do you Yahoo!?
All your favorites on one personal page ? Try My Yahoo!
http://my.yahoo.com


from_name: Dori

subject: [Foundation-l] Short Domain Name

body:
On Sun, 5 Dec 2004 18:11:33 -0500, Hunter Peress <hunterp at gmail.com> wrote:
> A generic (eg non country-specific) top level domain that is short (on
> the order of 2 - 3) letters would be ideal. sourceforge.net has sf.net

Sourceforge doesn't have to deal with brand though.

>
> The two most ideal domains are wp.net and wp.org

What about all the different languages: wp.de, wp.ja, etc, are they
available? If not it will lead to more abuse.

>
> whois says that wp.org is owned by telepathy.com, a us based internet
> focused group that does not seem to be greedy.

No matter who it is, if it's taken it will be a pain.

>
> A well placed email by a wikipedia official asking for release would
> be a good thing.
>
> Please keep the list aprised of your activity regarding short domain name search

It's already a pain to keep track of the domains that are owned (not
to mention expensive). This would make it a lot worse.

--
[[en:User:Dori]]


subject: [Foundation-l] Short Domain Name


list: wiktionary-l

from_name: Ian Monroe

subject: [Wiktionary-l] Re: [en] A Modest Proposal for Pretend Words

body:
I've started a dicussion on the beer parlor regarding how to implement
the new policy.

On Fri, 3 Dec 2004 04:01:37 -0600, Ian Monroe <ian.monroe at gmail.com> wrote:
> Proposal:
> I propose we change policy on en.Wiktionary user-created words
> (so-called "protologisms") to exclude them entirely.


subject: [Foundation-l] Short Domain Name

body:
On Sun, 5 Dec 2004 18:40:07 -0500, Hunter Peress <hunterp at gmail.com> wrote:
> >What about all the different languages: wp.de, wp.ja, etc, are they
> >available? If not it will lead to more abuse.
>
> ? en.wp.org  de.wp.org    zwinger.wp.org  download.wp.org mail.wp.org
>
> this is the point of having a non-country-specific  generic tld
>
>
> im not asking for wp.us... im asking for ONE of  wp.org wp.net wp.info wp.coop

Yes, but they'd be needed to maintain brand

--
[[en:User:Dori]]


subject: [Foundation-l] Short Domain Name


from_name: Hunter Peress

subject: [Foundation-l] Short Domain Name

body:
A generic (eg non country-specific) top level domain that is short (on
the order of 2 - 3) letters would be ideal. sourceforge.net has sf.net

The two most ideal domains are wp.net and wp.org

whois says that wp.org is owned by telepathy.com, a us based internet
focused group that does not seem to be greedy.

A well placed email by a wikipedia official asking for release would
be a good thing.

Please keep the list aprised of your activity regarding short domain name search


subject: [Foundation-l] Short Domain Name


from_name: Evan Prodromou

subject: [Wikitech-l] Re: New Security model to work on REL1.4

body:
On Sat, 2004-04-12 at 02:59 +0100, Ashar Voultoiz wrote:

> HTMLForm.php need to be enhanced a lot as well. The best thing would be
> to reuse a PEAR extension but I am not sure we want to rely on PEAR for
> MediaWiki.

I realize that I just got into a big squabble about this earlier in the
week, but... why not?

Are we worried that PEAR is going away sometime soon? Is the
package-management overhead too costly? PEAR extensions are all licensed
under OSI-approve Open Source licenses and if needed could be
distributed with MediaWiki.

When to use or not to use available libraries is a case-by-case
question. Including a super-huge library to get a tiny sliver of its
functionality is wasteful, but more often than not general-purpose
libraries end up being a good bet.

~ESP

--
Evan Prodromou <evan at wikitravel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20041205/85e510ea/attachment.pgp>


subject: [Wikitech-l] page deletion

body:
On Sat, 2004-04-12 at 08:59 -0800, Brion Vibber wrote:

> The chief reason to be deleting something (as opposed to redirecting it
> to a more appropriate article or replacing it with a better one) is
> that it includes copyrighted material that we don't have permission to
> distribute. This necessitates not being able to have _just anybody_
> come along and view or undelete it.

Technically, it's probably not that kosher even to make the works
available to admins.

~ESP

--
Evan Prodromou <evan at wikitravel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20041205/bb62a604/attachment.pgp>


subject: [Foundation-l] Re:Short Domain Name

body:
>What about all the different languages: wp.de, wp.ja, etc, are they
>available? If not it will lead to more abuse.

? en.wp.org  de.wp.org    zwinger.wp.org  download.wp.org mail.wp.org

this is the point of having a non-country-specific  generic tld

im not asking for wp.us... im asking for wp.org wp.net wp.info wp.coop

http://en.wikipedia.org/wiki/GTLD


subject: [Foundation-l] Re:Short Domain Name


subject: [Foundation-l] Short Domain Name

body:
>What about all the different languages: wp.de, wp.ja, etc, are they
>available? If not it will lead to more abuse.

? en.wp.org  de.wp.org    zwinger.wp.org  download.wp.org mail.wp.org

this is the point of having a non-country-specific  generic tld

im not asking for wp.us... im asking for ONE of  wp.org wp.net wp.info wp.coop

http://en.wikipedia.org/wiki/GTLD


subject: [Foundation-l] Short Domain Name


subject: [Wikitech-l] page deletion

body:
On Sun, 2004-05-12 at 15:43 -0800, Brion Vibber wrote:

> > Technically, it's probably not that kosher even to make the works
> > available to admins.
>
> They're "available" only in the same way that you can scrounge things
> out of the trash bin before it's emptied.

I realize this is kind of complicated, but: if admins and Wikimedia had
some more formal relationship, keeping around archived versions would be
roughly equivalent to having employees in a company handle books that
couldn't legally be published. They're not being "published" -- they're
just archived until the company can figure out what to do with them.

But I think it would be hard to argue that admins have that tight a
relationship with the Foundation, and that it's qualitatively different
from the relationship non-admins have.

~ESP

--
Evan Prodromou <evan at wikitravel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20041205/1e5111ef/attachment.pgp>


from_name: Trevor Caira

subject: [WikiEN-l] New notice for common sense Wikipedians.

body:
 I have created a new template for Wikipedians to display on their user
pages to display they are content with the GFDL and don't feel the need to
jump on the multi-licensing bandwagon:

 You can get to it by typing {{NoMultiLicense}}.

You can see it here:
http://en.wikipedia.org/wiki/Template:NoMultiLicense

--Ashdurbat


from_name: Kate Turner

subject: [Wikitech-l] page deletion

body:
On Sun, 5 Dec 2004 20:28:21 +0100, Frank v Waveren
<fvw.wikipediaml at var.cx> wrote:
> On Sat, Dec 04, 2004 at 08:59:58AM -0800, Brion Vibber wrote:
> > The chief reason to be deleting something (as opposed to redirecting it
> > to a more appropriate article or replacing it with a better one) is
> > that it includes copyrighted material that we don't have permission to
> > distribute. This necessitates not being able to have _just anybody_
> > come along and view or undelete it.
> This is a problem, however my proposed system is in no way different
> than it currently is for existing articles/pages: If I paste
> copyrighted material into an article, it'll just get reverted, and
> only removed if the copyright holder complains

It was already proposed to allow non-sysops to see deleted articles [1].
There wasn't a consensus in favour of it.  If you only want this to apply to
sysops, there doesn't seem to be much difference to how it is.

Kate.

[1] http://en.wikipedia.org/wiki/Wikipedia:Viewing_deleted_articles


from_name: Frank v Waveren

subject: [Wikitech-l] page deletion

body:
On Sat, Dec 04, 2004 at 08:59:58AM -0800, Brion Vibber wrote:
> Please see existing discussion on this topic:
>
> http://en.wikipedia.org/wiki/User:ShaneKing/vfd_proposal
> http://meta.wikimedia.org/wiki/Deletion_management_redesign
Yup, I've seen, but neither are even close to what I'm suggesting. And
they both add needless complexity imho.

> The chief reason to be deleting something (as opposed to redirecting it
> to a more appropriate article or replacing it with a better one) is
> that it includes copyrighted material that we don't have permission to
> distribute. This necessitates not being able to have _just anybody_
> come along and view or undelete it.
This is a problem, however my proposed system is in no way different
than it currently is for existing articles/pages: If I paste
copyrighted material into an article, it'll just get reverted, and
only removed if the copyright holder complains (That's how it's done
at Wikimedia anyway; I don't care too much about other people running
mediawiki for this proposal), which currently needs a devel I think.
If that's going to be a problem we'll need to change how we handle it
in valid articles with copyrighted material in them anyway, so we
might as well use the same mechanism for "virtual deletions" as we use
for them.

Anyway, I intend to preempt all these obvious comments in a proper
proposal if it turns out to be technically viable. I'm posting to
wikitech-l to find out if there are _technical_ problems to the setup.
After that we can fight out the legal, philosophical,
interface-practical and what have you stuff on wikipedia or meta.

So, again: Does anybody foresee any major technical problems with
this?

--
Frank v Waveren                                      Fingerprint: BDD7 D61E
fvw@[var.cx|stack.nl] ICQ#10074100                      5D39 CF05 4BFC F57A
Public key: hkp://wwwkeys.pgp.net/468D62C8              FA00 7D51 468D 62C8


from_name: Erik Moeller

subject: [Foundation-l] Wikidoc

body:
Jonathan-
> Now, the last week, some of our contributors have told us that they feel
> like duplicating the Wikipedia project, something that I cannot fully
> agree to. Wikipedia is encyclopedic and documentation isn't, meaning
> that it not really fits there. I know about Wikibooks, but the whole
> concept of a "single place for GNU/Linux and Free Software
> documentation" would be a little far off.

I'm not sure I can follow you here. I initiated openfacts.berlios.de for
this purpose a while ago, but it never really took off, and I did not put
much further effort into it. Today I think that this kind of work should
take place on Wikibooks. You can create a portal page specifically for
open source documentation, and we'd be glad to set up some convenient
redirect there like opensource.wikibooks.org.

Of course there are drawbacks: Recent changes will include changes to all
books; linking specifically within the context of the open source section
will require specifying some kind of namespace or pseudo-namespace, etc.
But I believe that the right answer to these problems is to gradually
improve the software to better deal with these issues, e.g. by filtering
recent changes by namespace, and making certain namespaces "closed", so
that any link you create within them points to pages in the same
namespace.

In other words, I'd rather you outline the needs you think must be met
before Wikibooks can become a useful open source portal, than starting a
separate project.

Regards,

Erik


subject: [Foundation-l] Wikidoc


list: textbook-l

from_name: Marius Scurtescu

subject: [Textbook-l] web reference books

body:
Hi,

Even though I know about Wikipedia for a while only recently I started
to look more closely to this project. I was thinking how to start a
free online reference for Web related technologies (HTML, JavaScript,
CSS, ...) using a Wiki.

Wikibooks looks like an excellent candidate for this project and I
would like to ask your opinion.

I was thinking to start with an HTML reference where each tag is
described on one page and where everyone one can contribute. The
reference should contain lots of examples and cookbook style recipes.
It should highlight differences between browser. It should focus on
the standard but should also specify all browser specific features.

Once the HTML reference is started at least two other related
reference manuals should be created: JavaScript and CSS. These three
manuals  probably will make lots of references to each other.

Also, corresponding Cookbooks should be created, either as part of
these reference manuals or as stand alone books.

Ideal features that do not seem to be supported by Wikibooks:
- syntax coloring for code examples
- sample HTML files that can be tested as one reads the reference
- live testing of code
- page templates so a whole book has a consistent layout

I would appreciate any comments or suggestions on this matter.

Thanks,
Marius


subject: [Wikitech-l] Commons gone beta

body:
commons.wikipedia.org is now running on REL1_4. Overall it's looking
pretty good, but there may yet be surprises. Large categories full of
images present a bit of a difficulty, as least with the thumbnails not
all rendered yet...

We'll expand the beta onto the other Wikimedia wikis over the next week
or so.

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


from_name: sfk

subject: [Wikitech-l] Eval extension to action=raw and to export xml

body:
For collecting (and giving back later on!) information from Wikipedia (or other
MediaWikis) we are interested in structured data from a
http://meta.wikimedia.org/wiki/Machine-friendly_wiki_interface.

A request like <url>Foo?action=raw and <url>Special:Export (for XML) do a good
job. The problem is, that for *categories* this "action=raw" returns the wiki
tags. But what we would need is its *evaluated content*, i.e. the list of
articles, not the command which generates them.

How about an extension 'evaluated' like say
http://de.wikipedia.org/wiki/Kategorie:Ort_in_der_Schweiz?action=raw&evaluated
which does not return the Wiki tags ("[[Kategorie:Ort in Europa|Schweiz]]...")
but the list as it is presented in the default HTML page.

The same would apply to the Special:Export-Page, where obviously this would be
an option.


list: wikipedia-l

from_name: kelvSYC

subject: [Wikipedia-l] All Wikipedia wants for Christmas is...

body:
It's Christmas time, the time to give gifts to your significant other.
Now, being Wikipedians, Wikipedia is pretty much a significant other in
some ways.  So, what gift(s) do you wish Wikipedia could have this
holiday season?  Anything and everything is fair game - wish for
anything you want.

For example, I wish Wikipedia could have for Christmas...

... an automated VFD tabulator
... RSS/Atom syndication for watchlists
... en in UTF-8
... a print version of "Bad Jokes and Other Deleted Nonsense"
... category redirects

(these do not represent my personal views, but just a way to get the
ball rolling)

Of course, there is that other question, what gifts can you give to
Wikipedia this holiday season?  Me, I'd like to contribute to the
following:

* [[Churchill Bowl]]
* Any Wikipedia policy on episode lists of TV series


from_name: Christopher Mahan

subject: [Foundation-l] Policies expanding out of control

body:
--- Dori <slowpoke at gmail.com> wrote:

> I am really concerned that the number and extent of policies on en
> Wikipedia is getting seriously out of hand.
[Snip]

> Obviously Wikipedia is a lot bigger than it used to be,
> but I think the medicine might turn into a new disease.

Amen.

=====
Chris Mahan
818.943.1850 cell
chris_mahan at yahoo.com
chris.mahan at gmail.com
http://www.christophermahan.com/

__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail


from_name: Scott Nelson

subject: [Foundation-l] Short Domain Name

body:
On Dec 5.2004, at 15:11, Hunter Peress wrote:

> sourceforge.net has sf.net

That's fascinating; I actually didn't know that.

I'll try to remember that the next time I type
http://www.sourceforge.net/

> The two most ideal domains are wp.net and wp.org

Why would we want to associate wikipedia with WordPerfect? They've got
nothing to do with each other :)
--
Skot Nelson
skot at penguinstorm.com


subject: [Foundation-l] Short Domain Name


from_name: Andre Engels

subject: [Wikipedia-l] Proposed new language for Wikipedia

body:
First, "gem" is a generic code for Germanic languages, it is thus not
a code to use for a specific language. IF we are going to include this
language, you'll have to find another code for it. My proposal would
be de-pn, but I'll gladly give my opinion for a better one.

Having said that, it would be good if we could get some indication
showing that you are not the only one interested in setting up a
Wikipedia in Pennsylvania German. Perhaps you could look for other
interested people on the English village pump?

Andre Engels

On Sun, 5 Dec 2004 11:54:40 -0800 (PST), Josh Campfield
<gobigblue0405 at yahoo.com> wrote:
> I am fluent in Pennsylvania German and I'd like to do a WIkipedia in it. Pennsylvania German (or Pennsylvania Dutch, High German, or many other names) is spoken by up to 100,000 people in the USA and Canada, mainly in the states of Pennsylvania, Ohio, Indiana, and Iowa, and around the city of Kitchener, Ontario. It is a blend of many German dialects but mostly unintelligible to someone who speaks "regular" German (Deutsch). I am a native of the area and, while I'm not a native speaker, I have taught myself the language.
>
> Language Codes:
> ISO 639-2: gem
> SIL: pdc
>
> Thank you!
> Joshua Campfield
> Womelsdorf, PA, USA
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>


from_name: Ævar Arnfjörð Bjarmason

subject: [WikiEN-l] Fair use icons in templates

body:
I don't think it counts as fair use to use something that is designed
as an icon for an operating system on every computer stub on
wikipedia, referring to the template "Compu-stub" which uses
Image:Mycomp.PNG which is taken from the Windows XP operating system.


subject: [Wikitech-l] page deletion

body:
On Sun, Dec 05, 2004 at 08:00:57PM +0000, Kate Turner wrote:
> It was already proposed to allow non-sysops to see deleted articles [1].
> There wasn't a consensus in favour of it.  If you only want this to apply to
> sysops, there doesn't seem to be much difference to how it is.
Yup, I caught that, and though admittedly it doesn't bode well for my
hopes of achieving support, this does get us a lot more (imho) than
being able to view deleted pages, in fact I'd see it as a worthwhile
plan even if you see having deleted pages viewable as a drawback.

The big thing is not being able to view pages after deletion, but
having deletion be "just another edit", and the same for undeletion.
That way they can be handled by the same mechanisms as any other edit,
mechanisms which though they may not be perfect are a lot less
problematic than those surrounding deletion in its current form.

--
Frank v Waveren                                      Fingerprint: BDD7 D61E
fvw@[var.cx|stack.nl] ICQ#10074100                      5D39 CF05 4BFC F57A
Public key: hkp://wwwkeys.pgp.net/468D62C8              FA00 7D51 468D 62C8


from_name: Peter Danenberg

subject: [Wikipedia-l] Wikipedian gender ratio

body:
> Why is Wikipedia so repellant to women?

     I'd  say Wikipedia is not so much repellant to women as
it is seductive to men.

--
Peter Danenberg                                           .
wikisophia.org                                           ..:


from_name: Anthere

body:
>Just so that the discussion gains more interlingual dimension..

Just so that the discussion gains more dimension as well :-)

I have recently faced the issue of decisions being taken by poll versus by vote.
This is really confusing to me.

Some editors think that the difference between a poll and a vote is that the second is binding, while the first rather lead to a guideline, a recommandation.  Usually, the first one does not have a deadline, and rather reflect the general opinion of the community at a given point. The second one has a starting date and an ending date, and once it is binding, infringing it may drive you in problems.

While this is true most of the time, the distinction between vote and poll as binding and non binding is not always true.

Another interpretation is that the vote is something where those voting are the ones deciding (the result of the vote generate the decision). This is more of a direct democracy.

While in the case of a poll, the results of the poll are just a general indication of a community opinion, helping another smaller group to decide instead of the community. The decision might go against the community opinion, though this is unfrequent. This is more an indirect democracy. A recent example might be the wikinews poll.

I increasingly observe confusion between these two words, poll and vote. Difficulty to define what is supposed to be a binding policy and what is a guideline. And agressivity when an action is done after a poll, which some interpret as being not as valuable and acceptable as a vote.

More and more people are not accepting simple polls to evaluate community opinion as acceptable method for decision making. And complaints or accusation of power abuse which occur over and over and over finally result in making good old heavy and boring voting sessions for every single tiny decisions.

This is ridiculous.

---------------------------------
Do you Yahoo!?
 Yahoo! Mail - Helps protect you from nasty viruses.


subject: [Foundation-l] Wikinews in many languages

body:
>Hi,>now that we're about to move demo.wikinews.org to en.wikinews.org, we have  >to think about a procedure for setting up other language domains. If any  >decision on this matter has already been made by the Board, please let me  >know.

Not that I know.
I would like that we three have time to discuss this before decisions are taken please.

>It should be noted that on two of the language voting pages, no majority  >was reached on starting the project. These are French and Chinese. Others  >had very small participation.>In the original proposal, I suggested that Wikinews can be set up in any  >accepted Wikimedia project language where there is at least one interested  >participant, and that 4 more regulars are required for the language to be  >recognized as "official", and for the firsts sysops to be created.

I do think that "not recognising something official" even though it exists is nice
but totally irrealistic. As soon as wikinews exists, then we could always try to pretend it only
is "okay" in one language, but not okay or not part of wikimedia in another language, that would be
just ink on paper. For editors and mostly for readers, it will be there.

So, instead of pretending it is not recognised, we could 1) have a temporary adress of the type fr.demo.wikinews.org
and 2) have a temporary logo rather than the official and 3) put a warning on top of it.

I would like to ask the Board if this procedure is acceptable.If it is not, one possible >alternative would be to immediately set up  language domains for any language where there >are more than 10 votes on  the respective voting page on Meta, and more than 50% in favor. >This would  currently mean Japanese and German. The vote could be re-opened, and kept  >open permanently.

I am opposed to this. There is little sense to set up a language just based on editors in this language supporting the global project. What should lead the creation of a language subdomain is presence of editors, not support at a global poll. If some people are interested, let's open the domain, if not, we do not need to let an empty wiki prey of vandals.

I also think that the vote was meant to be global, not to decide which language would be created versus which languages would not be.

---------------------------------
Do you Yahoo!?
 The all-new My Yahoo! ? Get yours free!


subject: [Wikipedia-l] New languages and oral resources

body:
Anthere wrote:

>On the net, I found "Tumbuka is a Bantu language spoken in Zambia, Malawi & Tanzania.  There are a total of nearly 700,000 speakers in Malawi, where it is spoken primarily in the northern part of the country.  Within Zambia, about 450,000 speakers are located mostly on the eastern side of the country.  The balance of the nearly 2,000,000 total speakers are in Tanzania. "
>
>
Well, Wikipedia is not an oral source, so the relevant figure is readers
rather than speakers.  As far as I can tell from google, there are very
few readers of Tumbuka, because it is not taught in any schools in the
region---even those who speak Tumbuka at home read and write in a
different language.  That makes the usefulness of a Tumbuka Wikipedia as
an information source potentially limited.  Not that we shouldn't have
it, but it's not going to suddenly bring a wealth of information to
millions of people, because very few people can read the language.

-Mark

You are absolutely correct Mark, it probably wont make a huge difference :-) At least now.

But possibly in the future, wikipedia (and in this case wiktionary) can also become an oral resource with sound recording.

What it could make a huge difference with is little by little helping african people become active on the net, appropriating it through websites such as ours, also improving english articles on these cultures and countries (or any other languages they speak in their country). Tiny bits can make huge waves on day :-)

That would be far than enough for me to support it.

---------------------------------
Do you Yahoo!?
 Yahoo! Mail - Find what you need with new enhanced search. Learn more.


body:
Just so that the discussion gains more interlingual dimension..

I recently find a similar tendency at Japanese Wikipedia. Some of the
policies that I feel difficult include the kind of policies that define
people's qualifications:

*Who can vote at Request for Deletion
*Whose inappropriate comments could be removed at Request for Administratorship
*Who can remove inappropriate comments at Request for Administratorship
*Who can make a request at Request for Blocking
*Who can conclude a discussion on an item on Request for Deletion
*Who can conclude a discussion on an item on Request for Administratorship

These policies were formed in reactions to IPs and new accounts disturbing
the process by making irrelevant comments, illegitimate requests, disputable
conclusions, etc. We do not know those IP edits and new accounts are real innocent
newbies who were simply bold, or some troublemakers disguising as a newbie.

I was thinking what alternatives were available:

1)No rule, & give matters on the discretions of bold volunteers,
who may or may not exercise fair judgment.

2)No substantive rule, but give matters to designated trusted volunteers
who we can expect would act in good faith and common sense.

3)Simplify those rules but still let them exist.

I don't have an answer except that 1) is probably not as good as 2) and 3)..
I had a chance to chat with other Japanese Wikipedians on this, and some of
them who were pushing/leading to formulate the rules seem to recognize that
those rules create some problems by solving one.

Tomos

----- Original Message -----
From: Fred Bauder <fredbaud at ctelco.net>
To: foundation-l at wikimedia.org
Sent: Sun, 05 Dec 2004 06:16:54 -0700
Subject: Re: [Foundation-l] Policies expanding out of control

>Here's a question for you then. Do you want the Arbitration Committee to use
>"common sense" or follow established policies. (fyi, the Committee is
>somewhat split on this point)
>
>Fred
>


from_name: Nick Pisarro

subject: [Wikitech-l] Compiler Errors on phase3 head branch

body:
Hi,

Sorry to trouble you here...

I can't seem to get into bugzilla.wikipedia.org. It doesn't like my
password and I'm not getting E-Mail from it. So, I'm posting my real
problems here after syncing to the phase3 head branch. Could I trouble
someone to post if for me or perhaps fix the problem(s)?

---------------

I am getting PHP errors when I try to open the Special:Newimages page.
They are:

[Mon Dec  6 04:31:31 2004] [error] PHP Notice:  Undefined variable:
wgHashedUploadDirectory in /Library/MediaWiki/includes/Image.php on line
561

>	function getFullPath( $fromSharedRepository = false )
>	{
>		global $wgUploadDirectory, $wgSharedUploadDirectory;
>
>		$dir      = $fromSharedRepository ? $wgSharedUploadDirectory :
>		                                    $wgUploadDirectory;
>		$ishashed = $fromSharedRepository ? $wgHashedSharedUploadDirectory :
>		                                    $wgHashedUploadDirectory;
>		$name     = $this->name;
>		$fullpath = $dir . wfGetHashPath($name) . $name;
>		return $fullpath;
>	}

'$wgHashedUploadDirectory' is not defined with a "global" statement.

[Mon Dec  6 04:31:31 2004] [error] PHP Fatal error:  Call to a member
function on a non-object in /Library/MediaWiki/includes/Image.php on line
115

	function newFromTitle( $nt )
	{
		$img = new Image( $nt->getDBKey() );  # line 115.
		$img->title = $nt;
		return $img;
	}

implies that $nt is not an object.

Another problem on the 1.5 branch is that it doesn't seem to be
recognizing Sysops. My administrator IDs are not getting any special
privileges and I am not seeing any administrator or beaurcrates when I try
to list them with the User List special page.

Upgrading from a v1.3.8 db seemed to gone off without an error.

MediaWiki: 1.5alpha
PHP: 4.3.4 (apache)
MySQL: 4.0.13

What is the proper protocol when reporting bleeding edge source problems,
like these?

Nick Pisarro


from_name: Brion Vibber

subject: [Wikitech-l] Re: Commons gone beta

body:
On Dec 6, 2004, at 1:01 AM, Andreas Hoerstemeier wrote:
> Is it intentionally that the image descirption pages don't show the
> picture anymore? IIRC there was some talk to show downscaled pictures
> there, especially in the case the image is very high resolution. I can
> see the "Download full scale version" link, but no scaled down
> version...

Should be fixed now. (Accounts without the max image size option set
were not handled right)

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


body:
On Dec 6, 2004, at 3:03 AM, Nick Pisarro wrote:
> [Mon Dec  6 04:31:31 2004] [error] PHP Notice:  Undefined variable:
> wgHashedUploadDirectory in /Library/MediaWiki/includes/Image.php on
> line
> 561

I fixed this a couple days ago, but apparently forgot to check it in.
It's checked in.

> [Mon Dec  6 04:31:31 2004] [error] PHP Fatal error:  Call to a member
> function on a non-object in /Library/MediaWiki/includes/Image.php on
> line
> 115

You'll have to trace the source of the parameter for that. Add an
if(!is_object($nt)) { wfDebugDieBacktrace(); } or such.

> Another problem on the 1.5 branch is that it doesn't seem to be
> recognizing Sysops.

Check in user_groups that your "sysop" is in the sysop group.

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


from_name: Ashar Voultoiz

subject: [Foundation-l] Re: Short Domain Name

body:
Hunter Peress wrote:
> A generic (eg non country-specific) top level domain that is short
> (on the order of 2 - 3) letters would be ideal. sourceforge.net has
> sf.net
>
> The two most ideal domains are wp.net and wp.org
>
> whois says that wp.org is owned by telepathy.com, a us based internet
>  focused group that does not seem to be greedy.
>
> A well placed email by a wikipedia official asking for release would
> be a good thing.
>
> Please keep the list aprised of your activity regarding short domain
> name search

Hello,

The problem is that even if we got wp.org we will want to get other wp
entries in info. fr. uk.  ... That will just double the cost of domain
registration.

We should just stick with wikipedia.org. , don't let registrars make
more money than what is really needed.

cheers,

--
Ashar Voultoiz - WP++++
http://en.wikipedia.org/wiki/User:Hashar
Servers in trouble ? noc (at) wikimedia (dot) org
"This signature is a virus. Copy me in yours to spread it."


subject: [Foundation-l] Re: Short Domain Name


from_name: David Gerard

subject: [WikiEN-l] original research

body:
Charles Matthews (charles.r.matthews at ntlworld.com) [041206 06:48]:
> Stan Shebs wrote

> > [...]  but I
> > can see WP *creating* a demand for new original research, to
> > answer questions that have come up.

> I don't think 'original research' should cover original scholarship.  That's
> a stretch.

I don't think it is. Wikipedia is not somewhere people writing on a subject
should be coming to new conclusions.

- d.


from_name: Charles Matthews

subject: [WikiEN-l] original research

body:
David Gerard wrote

> >Charles Matthews  wrote
> > I don't think 'original research' should cover original scholarship.
That's
> > a stretch.

> I don't think it is. Wikipedia is not somewhere people writing on a
subject
> should be coming to new conclusions.

Take [[apple pie]], which cites an original source.  WP doesn't need to
police whether the conclusions drawn are safely derivative or not.  (That's
apple sauce - sorry.)  Any  more than if I wander around Cambridge and see
something encyclopedic, I need first to check that it's in a guidebook.

That being said, 'secondary source' is a  good enough definition to go into
a WP mission statement, such as 'master secondary source on the Web'.

Charles


subject: [WikiEN-l] original research

body:
Tucci wrote

> I'm not sure I understand this distinction, [...]

The [[scholarship]] article is not bad.   I like the definition elsewhere at
[[rigour]] - wrote it myself - as 'quality control of information'; but I
can see that others might find it narrow.  Anyway, on a narrow definition ,I
can't see the problem with Wikipedians checking facts and being critical
about source material.  Five minutes of googling shows that you need all
that.

Charles


subject: [Wikitech-l] Commons gone beta

body:
On Sun, 5 Dec 2004 21:59:29 -0800, Brion Vibber <brion at pobox.com> wrote:
> commons.wikipedia.org is now running on REL1_4. Overall it's looking
> pretty good, but there may yet be surprises. Large categories full of
> images present a bit of a difficulty, as least with the thumbnails not
> all rendered yet...
>
> We'll expand the beta onto the other Wikimedia wikis over the next week
> or so.

Looks good, one thing that does not work anymore however is
html/javascript in MediaWiki messages, will there be a possibility to
gain that functionality in some other way, for example to get the
special character toolbar in use on MediaWiki:Copyrightwarning on en.
is. it. de. and others?

> -- brion vibber (brion @ pobox.com)
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
>
>


subject: [Wikipedia-l] Re: All Wikipedia wants for Christmas is...

body:
Hello,

kelvSYC wrote:
<snip>
> For example, I wish Wikipedia could have for Christmas...
>
> ... an automated VFD tabulator
Maybe an extension can be made to add a "request for deletion" tab in
the interface that will then take care of creating the entry for you.
That will surely be an interesting enhancement to VfD.

> ... RSS/Atom syndication for watchlists
That one can probably be made easily but on wikipedia I think watchlist
overload the database servers so we don't really want to have rss
aggregator to request watchlists every 10 minutes ;o)

> ... en in UTF-8
That one probably need a long maintenance window with en locked for some
days.

> ... a print version of "Bad Jokes and Other Deleted Nonsense"

> ... category redirects
That one should ship with 1.4 although there is still a minor bug with
it when you redirect from a category to another namespace (list of
category is shown).
See http://bugzilla.wikipedia.org/show_bug.cgi?id=710

<snip>

--
Ashar Voultoiz - WP++++
http://en.wikipedia.org/wiki/User:Hashar
Servers in trouble ? noc (at) wikimedia (dot) org
"This signature is a virus. Copy me in yours to spread it."


from_name: Andreas Hoerstemeier

subject: [Wikitech-l] Re: Commons gone beta

body:
Brion Vibber wrote:
> commons.wikipedia.org is now running on REL1_4. Overall it's looking
> pretty good, but there may yet be surprises. Large categories full of
> images present a bit of a difficulty, as least with the thumbnails not
> all rendered yet...
Is it intentionally that the image descirption pages don't show the
picture anymore? IIRC there was some talk to show downscaled pictures
there, especially in the case the image is very high resolution. I can
see the "Download full scale version" link, but no scaled down version...

[[User:Ahoerstemeier]]


from_name: Jimmy (Jimbo) Wales

subject: [Foundation-l] sep11.wikipedia.org

body:
I support this concept, and will host it for free wherever the major
participants prefer.

Erik Moeller wrote:

> sep11.wikipedia.org is a spam magnet, and not really an appropriate
> project of its own:
> * not educational: outside our mission
> * not a community: scope too narrow
> * not verifiable
> * no NPOV
> * improperly located: sep11.wikipedia.org suggests association with
> Wikipedia - it even uses a Wikipedia logo
>
> We're apparently so embarrassed by it that we hide it from most of our
> "Sister Projects" lists.
>
> Well, I won't be too negative - there are some valuable memories there
> that deserve to be preserved, and volunteers have kept it in presentable
> shape.
>
> So here's my offer:
>
> With Board authorization, I would go over these pages, and transform them
> into a static website. This could be located at some URL which has yet to
> be decided, maybe 911memories.org or something like that. I would prefer a
> location that is not directly associated with Wikimedia, though it could
> be labeled a Wikimedia publication.
>
> Wikipeople has been brought up as a potential assimilation project, but
> that strikes me as too vague, and there's no real thrust behind it, and
> I'm not sure Wikipeople is a good idea in the first place, so the static
> version seems like the best way forward for now. We would of course
> preserve and make available the wiki database in case we ever want to
> integrate it into something else.
>
> Another option would be to host it at Jimbo's free wiki hosting service,
> Wikicities.com. That would disassociate it from Wikimedia while still
> allowing interested people to work on it.
>
> Thoughts?
>
> Regards,
>
> Erik
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>

--
"La n?fle est un fruit." - first words of 50,000th article on fr.wikipedia.org


subject: [Foundation-l] sep11.wikipedia.org


subject: [WikiEN-l] Original research

body:
Delirium wrote:
> Well, I'd expand the ban on "original research" slightly further than
> just that.  An article that makes no new low-level claims, but
> nonethless synthesizes work in a non-standard way, is effectively
> original research that I think we ought not to publish.  This comes up
> most often in history, where there is a tendency by some Wikipedians to
> produce novel narratives and historical interpretations with citation to
> primary sources to back up their interpretation of events.  Even if
> their citations are accurate, Wikipedia's poorly equipped to judge
> whether their particular synthesis of the available information is a
> reasonable one.

I agree completely.

I think in part this is just a symptom of an unfortunate tendency of
disrespect for history as a professional discipline.  Some who
completely understand why Wikipedia ought not create novel theories of
physics by citing the results of experiments and so on and
synthesizing them into something new, may fail to see how the same
thing applies to history.

--Jimbo


body:
Can you fix the font so it's not so tiny? Can you fix the font so you
don't fix the font size?

here I go top-posting again...

--- Trevor Caira <trevor.caira at gmail.com> wrote:

>  I have created a new template for Wikipedians to display on their
> user
> pages to display they are content with the GFDL and don't feel the
> need to
> jump on the multi-licensing bandwagon:

=====
Chris Mahan
818.943.1850 cell
chris_mahan at yahoo.com
chris.mahan at gmail.com
http://www.christophermahan.com/

__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail


subject: [Wikipedia-l] Re: Problem in the Yiddish Wikipedia

body:
On Wed, 1 Dec 2004 21:08:30 -0700, Mark Williamson <node.ue at gmail.com> wrote:
> Right, if I wrote an article on en: that said "a popular singer", it
> would be expanded? Am I supposed to believe that? If I made articles
> like that on en.wikipedia, I'd probably be asked to stop, and perhaps
> even banned.

Not so. On en: the article would get {{substub}} slapped upon it, be
extended to "Britney Spears is a popular singer." and then just left
hanging around because anyone proposing its deletion would get
insulted and told that he is just too lazy to extend it. Now if you
had said de: or nl:, you might have a point, they don't like that kind
of 'article', but on en: there is no way to ged rid of it unless you
are an admin and sneak it away. And on da: it would after the
extension not even be among the shortest pages.

Andre Engels


body:
* A search system that is always on and has all articles (something's
terribly wrong at WikiCommons's search)
* A working maintenance page
* Working or more often updated special pages

> ... en in UTF-8

Hey, we at nl: go first! One year ago it was already promised that it
would happen "next weekend or maybe the one after." It still hasn't,
whereas de: DID get it in the meantime.

Andre Engels


from_name: Mark Richards

body:
I didn't know that there was anyone who was actively
proposing the gfdl as a good thing rather than just
something with such inertia that it was difficult to
change.
Mark

--- Trevor Caira <trevor.caira at gmail.com> wrote:

>  I have created a new template for Wikipedians to
> display on their user
> pages to display they are content with the GFDL and
> don't feel the need to
> jump on the multi-licensing bandwagon:
>
>  You can get to it by typing {{NoMultiLicense}}.
>
> You can see it here:
> http://en.wikipedia.org/wiki/Template:NoMultiLicense
>
> --Ashdurbat
>
>
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


from_name: Evan Prodromou

subject: [Wikitech-l] Skins in MediaWiki 1.5

body:
This is a MediaWiki code design discussion; people uninterested in
MediaWiki's guts can safely ignore it.

So, I think one of the big questions third-party admins have is how to
skin MediaWiki. Right now, it requires writing some PHP code. I'd like
to float some suggestions for how we can make our skin architecture a
bit easier for everyone.

In MediaWiki 1.5, I think we should re-focus our Skin classes
specifically on *HTML generation*. I think we should keep the name
"Skin", just because it's hard not to, but I think we should steer away
from using server-side PHP code to do layout design.

Instead of having skin classes for them, I think we should use alternate
CSS stylesheets to provide the "look-and-feel" differences -- Monobook,
Nostalgia, Standard, and Cologne Blue, as well as future look-and-feels.
Hopefully, if we can make this transition, we can open up the process of
skinning MediaWiki to people with more CSS/(X)HTML experience than PHP
chops, and get more/better-looking/easier-to-use skins. Admins who want
to have "branded" styles for their sites could do so with CSS.

To support browsers that can't handle CSS styling (I think lynx is the
only one in wide usage that is in this category, but there may be
others), we should provide another HTML generation class on the server
to make very simple, style-free HTML.

Extensions -- hopefully third-party extensions -- could provide HTML
generation from PHP template systems like PHPTal, Smarty, etc. *I*
wouldn't use them, but for folks who are really into these templating
system, there'd be an option. There may also be call for a skin subclass
to generate table-based layout for HTML 3.0-era browsers.

Lastly, I think we should push most of the business logic of skins up to
the root class. By this I mean stuff like: figuring out whether or not
to show admin function links, or links that should only be shown for
articles, or links that should only be shown for logged-in users, or
whatever.

Historically this has been replicated in each skin class, but in recent
versions there's been some consolidation. It would be great to finish
this process and get all this code into one spot in the root skin class.
I think the PHPTal/SkinTemplate mechanism -- one function per logical
"menu" (nav urls, personal urls, etc.) returning an array of arrays,
each one representing a link -- is the best system here.

Attached is a rough class diagram to illustrate these ideas. To
summarize:

      * Abstract class "Skin" provides a framework and supports business
        logic for determining which links are shown, etc.
      * SkinBasic gives rock-bottom, dead-simple HTML.
      * SkinTemplate is the most-used, default HTML generator. It allows
        an alternation between multiple CSS stylesheets, and generates
        the kind of high-quality HTML (or XHTML if the browser is
        capable) to make CSS-styling simple and useful.
      * SkinPHPTal and SkinSmarty are third-party HTML-generation
        classes that use those templating systems. There could be other
        such classes; they're only on the diagram to illustrate that we
        want skins to be able to handle this kind of subclassing.

Now, we're awful close to something like this already; I think the
SkinTemplate class in 1.4, with some changes for handling multiple
alternate CSS stylesheets, is a really good "default" class. Although
it's not a requirement, the other HTML generators could use the same
stylesheets as long as they generate similar HTML.

The main drawbacks with this kind of system are:

     1. We won't have pixel-identical versions of Nostalgia, Standard,
        and Cologne Blue. I don't think this is a huge problem.
     2. Folk wisdom that "Nostalgia makes HTML that can be read in lynx"
        would become untrue.
     3. We have a couple of classes that vary by the user's preferences
        (SkinBasic versus SkinTemplate), and a couple that vary by the
        sysadmin's preferences (SkinTemplate vs. PHPTal, Smarty, ...).
     4. It's not clear how to allow different stylesheets. There's a
        good way here: http://www.alistapart.com/articles/alternate/

I realize we're in a release cycle and 1.5-timeframe discussions are
somewhat distracting, but I've been thinking about this and figured it
was worth discussing while I still had it in my brain.

~ESP

--
Evan Prodromou <evan at wikitravel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20041206/ac5202e0/attachment.pgp>


subject: [Wikitech-l] Re: Skins in MediaWiki 1.5

body:
On Mon, 2004-06-12 at 11:58 -0500, Evan Prodromou wrote:

> Attached is a rough class diagram to illustrate these ideas.

Famous last words. Diagram attached to this document, or found here:

	http://bad.dynu.ca/~evan/skins.png

	http://bad.dynu.ca/~evan/skins.svg

~ESP

--
Evan Prodromou <evan at wikitravel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20041206/e6dd6c56/attachment.pgp>


from_name: Phil Sandifer

body:
I have to say, I'm sorry to see this template's existence. The failure
of various free licenses to "talk" to one another is rapidly becoming
one of the biggest barriers to the creation of free content, and with
the rapid ascent of Creative Commons, frankly, Wikipedia is looking a
little crusty in its model. It's very hard to utilize bits of Wikipedia
in creative works, because the GFDL kinda sucks for that. I'd have a
tough time applying the GFDL to a visual work. (How would I link back?)

Until a better solution comes along (I'm hoping very much that the new
version of the GFDL that they're working on will have some provision
about other free licenses) multi-licensing seems to me a necessary
evil. In particular, the no sign over the CC image feels in poor taste
to me.

-Snowspinner

On Dec 5, 2004, at 6:42 PM, Trevor Caira wrote:

>  I have created a new template for Wikipedians to display on their user
> pages to display they are content with the GFDL and don't feel the
> need to
> jump on the multi-licensing bandwagon:
>
>  You can get to it by typing {{NoMultiLicense}}.
>
> You can see it here:
> http://en.wikipedia.org/wiki/Template:NoMultiLicense
>
> --Ashdurbat
>
>
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Nick Triantos

subject: [Wikitech-l] RSS feeds for individual watchlists?

body:
Is anyone working on adding an RSS feed to the Special:Watchlist page?

Presumably, most of the code could be shared / copied from
Special:Recentchanges.  I might try to implement this if no one else is
working on this.

thanks,
-Nick


list: commons-l

from_name: Yann Forget

subject: [Commons-l] Re: [Wikitech-l] Commons gone beta

body:
Hi,

Le Monday 6 December 2004 06:59, Brion Vibber a ?crit :
> commons.wikipedia.org is now running on REL1_4. Overall it's looking
> pretty good, but there may yet be surprises. Large categories full of
> images present a bit of a difficulty, as least with the thumbnails not
> all rendered yet...

I noticed that some translations and customization are needed.
The head message in French on
http://commons.wikimedia.org/wiki/Special:Recentchanges
French translation of "Special Pages"
http://commons.wikimedia.org/wiki/Special:Specialpages

Where is the place to translate this ?

BTW, the favicon disappeared and the Special:Allmessages gives a error message
when the language interface is not in English, cf.
http://commons.wikimedia.org/wiki/Special:Allmessages
"Your current interface language fr is not supported by Special:AllMessages at
this site."

> -- brion vibber (brion @ pobox.com)

Thanks,
Yann
--
http://www.non-violence.org/ | Site collaboratif sur la non-violence
http://www.forget-me.net/ | Alternatives sur le Net
http://fr.wikipedia.org/ | Encyclop?die libre
http://www.forget-me.net/pro/ | Formations et services Linux


subject: [Wikitech-l] Commons gone beta


subject: [Foundation-l] Re: Commons gone beta

body:
Hi,

Le Monday 6 December 2004 06:59, Brion Vibber a ?crit :
> commons.wikipedia.org is now running on REL1_4. Overall it's looking
> pretty good, but there may yet be surprises. Large categories full of
> images present a bit of a difficulty, as least with the thumbnails not
> all rendered yet...

Great! That's very much appreciated by non English users who can now choose
the language interface.

> We'll expand the beta onto the other Wikimedia wikis over the next week
> or so.

May I?suggest to put REL1.4 on Wikisource first as many users requested a
localized language interface there.

> -- brion vibber (brion @ pobox.com)

Thanks a lot, Brion.
Yann
--
http://www.non-violence.org/ | Site collaboratif sur la non-violence
http://www.forget-me.net/ | Alternatives sur le Net
http://fr.wikipedia.org/ | Encyclop?die libre
http://www.forget-me.net/pro/ | Formations et services Linux


subject: [Foundation-l] Re: Commons gone beta


subject: [Wikitech-l] Re: Commons gone beta


from_name: Delirium

subject: [Wikipedia-l] Wikipedian gender ratio

body:
David Gerard wrote:

>Tim Starling (t.starling at physics.unimelb.edu.au) [041206 19:14]:
>
>
>
>>The 13.6% figure agrees neatly with the 3:22 ratio observed in London.
>>Why is Wikipedia so repellant to women? I couldn't begin to speculate.
>>Any ideas?
>>
>>
>
>
>Repellent to women or more attractive to men?
>
>
I'd say it's this one.  Especially in its earlier days, Wikipedia was
jump-started by people who weren't necessarily originally interested in
writing an encyclopedia, but found it a fascinating technological
experiment.  Since there are *far* more men in computer-related fields
than women, cool new technological ideas like wikis tend to attract far
more interest from men than women.

Of course, it's now more about the encyclopedia than the technology, but
there's still a lot of interaction between the two (it helps immensely
if you're comfortable with the idea of markup, and more if you have a
vague idea of what a parser is and how it works), such that someone
completely non-technical (like my parents) just finds the whole thing a
little bit alien.

On a more speculative note, on occasion researchers suggest that men
tend to be more interested in enlightenment-style "knowledge for
knowledge's sake", while women tend to be more interested in applied
fields (at least in CS and math, which is where I've read the
research).  Wikipedia definitely has interesting social and applied
aspects, but the joy of building a compendium of human knowledge is very
much an enlightenment-style project, so that might attract a
disproportionate number of men.

And actually, I think that while gender is the easiest imbalance to
measure, we don't draw a uniform sample of men either---there are
specific sorts of men who are much more interested in a project like
this than others (there were some suggestions earlier that autism, for
example, is very over-represented among Wikipedians as compared to the
general population).

-Mark


subject: [WikiEN-l] original research

body:
Charles Matthews wrote:

>Take [[apple pie]], which cites an original source.  WP doesn't need to
>police whether the conclusions drawn are safely derivative or not.  (That's
>apple sauce - sorry.)  Any  more than if I wander around Cambridge and see
>something encyclopedic, I need first to check that it's in a guidebook.
>
>
Yeah, this is somewhat of a tricky issue.  My personal barometer is that
if I'm documenting facts with a minimum of interpretation, then all I
need is some reference for the facts.  But if I'm making an
interpretation, I try to confine it to interpretations that have been
made before, rather than trying to synthesize primary sources myself.

In a few cases, like [[industrial music]], there's no authoritative
scholarship in the field (indeed, very little scholarship at all), so
some amount of original research contentiously creeps in, but there's
still an attempt to document "prevailing opinion", as far as information
on it can be found, and trying as much as possible to avoid making novel
musicological arguments and categorizations.

-Mark


subject: [Wikitech-l] Skins in MediaWiki 1.5

body:
On Dec 6, 2004, at 8:58 AM, Evan Prodromou wrote:
> So, I think one of the big questions third-party admins have is how to
> skin MediaWiki. Right now, it requires writing some PHP code.

To concretize this, here's the PHP code for a new skin which will use
MonoBook's HTML skeleton and replace the styles:

require_once( 'MonoBook.php' );
class SkinSuperCool extends SkinMonoBook {
	function initPage( &$out ) {
		parent::initPage( $out );
		$this->skinname  = 'supercool';
		$this->stylename = 'supercool';
	}
}

Now, perhaps we could get rid of even that, but it's most of the way
there. What actually needs to be different?

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


body:
I'm confused, wouldn't that Special:Watchlist page be generated based on
the logged-in user? In other words, if I RSS subscribe to that page from
my PC, I'd just see my own watchlist, right?

confused,
-Nick

Rowan Collins wrote:

>On Mon, 06 Dec 2004 13:57:59 -0800, Nick Triantos <nick at triantos.com> wrote:
>
>
>>Is anyone working on adding an RSS feed to the Special:Watchlist page?
>>
>>Presumably, most of the code could be shared / copied from
>>Special:Recentchanges.  I might try to implement this if no one else is
>>working on this.
>>
>>
>
>I think the problem which no-one has got around to solving is how to
>keep the information private: currently, users cannot view each
>other's watchlists, and although this isn't a big deal, I believe some
>are unwilling to give up this privacy. Of course, the simplest answer
>is simply to have RSS feeds disabled by default, and warn users that
>by activating the feed, they are essentially "opting out" of this
>privacy. Otherwise, some kind of magic authentication key needs to be
>invented; or something.
>
>
>


from_name: Petr Kadlec

subject: [Wikitech-l] Commons gone beta

body:
> I noticed that some translations and customization are needed.

I am sorry to bring it up again, but the Czech translation in CVS
(i.e. and everywhere else except cs: Wikipedia) is _terrible_ (not to
mention incomplete).

Someone with proper rights, *PLEASE*, update LanguageCs.php with
either http://meta.wikimedia.org/wiki/LanguageCs.php , or messages
exported from cs:MediaWiki: namespace, which (both) are complete and
correct (although there are some issues with Wikipedia-centric
messages that should be fixed in MediaWiki distribution per se).

Best regards,
[[ cs:User:Mormegil | Petr Kadlec ]]


from_name: Johannes Schindelin

subject: [Wikitech-l] Re: Patch: Lilypond support for MediaWiki

body:
Hi,

On Fri Dec 3 17:01:05 UTC 2004, Evan Prodromou wrote:

> Can you clump it all up into a single extension module? By, say, adding
> a new tag?

Thank you for this hint. As I was developping on 1.2.6, I was not aware of
this wonderful new feature.

Attached is the gzip'ed file which you just have to drop in the
extensions/ directory. I tested it, and it works Just Fine(tm).

Please CC me in your replies, as I am off-list.

Ciao,
Dscho


body:
On Dec 6, 2004, at 3:15 PM, Nick Triantos wrote:
> I'm confused, wouldn't that Special:Watchlist page be generated based
> on the logged-in user? In other words, if I RSS subscribe to that page
> from my PC, I'd just see my own watchlist, right?

If you read RSS directly in your browser, perhaps. But that won't help
you in your standalone RSS feed reader application (which might be an
aggregator serving out your favorite feeds via HTTP).

An RSS news reader appears to the server as just another HTTP user
agent, but it won't know how to use our forms to log in or maintain the
login session cookies. Some (many?) readers can use HTTP
authentication, perhaps via the URL (eg
http://user:pass at example.com/feed.xml), but MediaWiki can't currently
authenticate you that way.

Alternately, a username could be passed as a query string parameter,
either along with a password/hash/token (potentially unsafe -- this
will appear in proxy and server logs in addition to going over the wire
raw) or after an explicit opt-in by the user to allow reading the
watchlist without authentication.

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


from_name: Mark Williamson

body:
My proposal would be gem-pdc, in accordance with for example roa-rup

On Mon, 6 Dec 2004 00:44:18 +0100, Andre Engels <andreengels at gmail.com> wrote:
> First, "gem" is a generic code for Germanic languages, it is thus not
> a code to use for a specific language. IF we are going to include this
> language, you'll have to find another code for it. My proposal would
> be de-pn, but I'll gladly give my opinion for a better one.
>
> Having said that, it would be good if we could get some indication
> showing that you are not the only one interested in setting up a
> Wikipedia in Pennsylvania German. Perhaps you could look for other
> interested people on the English village pump?
>
> Andre Engels
>
> On Sun, 5 Dec 2004 11:54:40 -0800 (PST), Josh Campfield
>
>
> <gobigblue0405 at yahoo.com> wrote:
> > I am fluent in Pennsylvania German and I'd like to do a WIkipedia in it. Pennsylvania German (or Pennsylvania Dutch, High German, or many other names) is spoken by up to 100,000 people in the USA and Canada, mainly in the states of Pennsylvania, Ohio, Indiana, and Iowa, and around the city of Kitchener, Ontario. It is a blend of many German dialects but mostly unintelligible to someone who speaks "regular" German (Deutsch). I am a native of the area and, while I'm not a native speaker, I have taught myself the language.
> >
> > Language Codes:
> > ISO 639-2: gem
> > SIL: pdc
> >
> > Thank you!
> > Joshua Campfield
> > Womelsdorf, PA, USA
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> > _______________________________________________
> > Wikipedia-l mailing list
> > Wikipedia-l at Wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
> >
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>


from_name: Rich Holton

subject: [Wikipedia-l] Bandwidth theft

body:
I have looked, and have not found any explicit
statement that bandwidth "theft" is "discouraged". It
seems like common sense to me, but what do I know?

A few weeks ago, Brian blocked a site that was
mirroring wikipedia by passing on each request to
Wikipedia live, and presenting the results (wrapped,
of course, with advertisements). That site was also
blatantly violating GFDL, so the block seemed obvious.

There is also a site that has been doing the same
thing, though with the appearance of GFDL compliance.
( See
http://meta.wikimedia.org/wiki/Non-compliant_site_coordination/
)

So, my question is, do we need such a statement
forbidding/discouraging/allowing/encouraging
band-width stealing? Perhaps more important, is it
safe to assume that such sites should be blocked? Do
we need some process to make sure it happens when
appropriate?

Finally, is this the right place to bring this up?

-Rich Holton (en.wikipedia:user:rholton)

__________________________________
Do you Yahoo!?
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250


subject: [Wikipedia-l] Report

body:
Hello all,

I am excited to announce that the Sicilian Wikipedia currently has 113
articles and is growing rapidly!

It actually started very recently, perhaps a week after an ISO 639
code was added for Sicilian, and initially there was only one major
contributor, Joe "Pippu" D'Angelo, who is actually the Chief Finance
Officer in the (Australian parliamentary) Department of the Senate.

However, as it began to pick up speed, it attracted new contributors
including Giuseppi Melfi, in Switzerland, from it.wikipedia, and
others who now contribute regularly.

http://scn.wikipedia.org/


from_name: Pawel 'Ausir' Dembowski

body:
> Not so. On en: the article would get {{substub}} slapped upon it, be
> extended to "Britney Spears is a popular singer." and then just left
> hanging around because anyone proposing its deletion would get
> insulted and told that he is just too lazy to extend it. Now if you
> had said de: or nl:, you might have a point, they don't like that kind
> of 'article', but on en: there is no way to ged rid of it unless you
> are an admin and sneak it away. And on da: it would after the
> extension not even be among the shortest pages.
> Andre Engels

On pl: it would also most probably be deleted right away.

--
Ausir


subject: [Wikipedia-l] Wikipedian gender ratio

body:
Delirium wrote:
> this than others (there were some suggestions earlier that autism, for
> example, is very over-represented among Wikipedians as compared to the
> general population).

I don't know about that, but based on my own casual observations at
wikipedia meetings, left-handedness is above average.  (The average is
10-13%, I think at wikipedia meetings it is closer to 20%.)

`However, because I am left-handed, and left-handed people tend to
notice each other, this could be a matter of cognitive bias.

--Jimbo


from_name: Jonah Bossewitch

subject: [Wikitech-l] Re: AW: Hooks and filters

body:
I am still very excited about this prospect but I haven't gotten any
feedback on the problem I was having with passing references through the
hook method.

http://mail.wikipedia.org/pipermail/wikitech-l/2004-December/026533.html

Once possible way to make it easier to make sure that the refs get
through (using php4 at least, I imagine that php5 will take care of some
of these issues), is to bundle up all the parametes within dictionaries,
thereby fixing the signature of all hook methods and avoiding the
get_func_args.  This would also make it easier to add more parameters to
  the hook methods in the future without breaking old hooks.  Besides,
when you start passing around longer lists of parameters, named
parameters are a bit easier to manage, since the order doesn't matter.

Beyond this suggestion, a friend of mine threw out the idea of
implementing this functionality using the interceptor pattern

something like this:
http://www.jroller.com/comments/deep?anchor=aop_fun_with_javascript

but that is probably more trouble than it is worth for now.

It looks like this hook infrastructure made it into 1.4, so there may
not be a chance for the parameter packaging modification, but I think it
might be worth the effort.

Any comments?

Jonah

Heli Retzek wrote:
> that is really a great and very useful plan !!
>
>
>>So, I'd like to set up a system of hooks and filters for MediaWiki. We
>
>
>
> HeliR


from_name: Anthere

subject: [Wikipedia-l] Wikipedian gender ratio

body:
Tim wrote "Why is Wikipedia so repellant to women? I
couldn't begin to speculate.
Any ideas?"

Might have a couple ones to give.
I do not think it is a question of repellance.

You may notice than the under representation is
particularly critical for a age over 30-35. You may
ask female wikipedians their age to check. Most are
below 35.
The next question would be "do you have kids ?".

Generally, most women over 30-35 do have kids.

Check on google "free time, housework, women, men" and
contemplate results. All studies I know show that at
least in european countries, men enjoy a significantly
higher leisure time compared to women, essentially due
to less time spend on housework chores and children
care. This is especially significant as most
participants to Wikipedia are educated people, which
often implies working people (when over 30)
Ask a working mother how she occupies her time in the
evening versus how a man occupy his time, and I think
it will enlighten you.

This other point is significant as well I think. When
you are an already overworked mom, and your family or
most friends realise the time you spend over
Wikipedia, their comment is at best "you are crazy",
and at worse, "you are damaging your family". This is
not the type of comment a man having a serious
associative activity will get.

When you answer that you also have a brain (and enjoy
using it) and have the desire to participate to "big"
things, not only family and job, as you feel teaching
kids, though a very nice activity is not satisfying
you enough as a participation to the grand scheme of
things, a woman will often get as an answer "but you
can't feel you are useless, look, you have a nice
husband and great kids who need you and love you, you
are very important to them".

Who would ever DARE saying to a man that he should not
feel useless as he has kids to take care of ? Who
would ever dare say a man he should focus on doing his
job well and nurturing his kids before ever thinking
of using his abilities for social activities ?

I feel and resent very much the heavy weight of some
well-thinking people who would perfectly agree women
are just as bright and able than men, but comment with
a touch of despise that it is really not a good idea
not to focus on what is *really* important, family and
job.

I also invite you to reflect on Mark comment

>On a more speculative note, on occasion researchers
suggest that men tend to be more interested in
enlightenment-style "knowledge for
knowledge's sake", while women tend to be more
interested in applied fields (at least in CS and math,
which is where I've read the research).  Wikipedia
definitely has interesting social and applied
aspects, but the joy of building a compendium of human
knowledge is very much an enlightenment-style project,
so that might attract a disproportionate number of
men.

There it is as well. Women like less knowledge for
knowledge sake, and more applied fields.

We mostly enjoy what we have the time and opportunity
to like Mark. Most women my age would love do more,
but they are currently running after job hours,
housechores, lice treatment, purchasing socks for the
kids, driving the kids to doctors, to friends
birthday, picking up presents for friends birthday,
cleaning up, cooking etc... This is very practical, it
has to be done. If not done, we see the deep serious
look of society considering this should first be done,
and done well, and fun or enlightement should come
after... when there is time for it.

__________________________________
Do you Yahoo!?
All your favorites on one personal page ? Try My Yahoo!
http://my.yahoo.com


from_name: Tim Starling

subject: [Wikipedia-l] Wikipedian gender ratio

body:
On viewing a photo from the Wikipedia meetup in London last Friday:

http://en.wikipedia.org/wiki/Image:WikiMeet_London_2004-12-03_23.09.jpg

...it struck me how skewed the gender ratio was -- 3 women and about 22
men at that meeting. I looked around for some statistics or discussion
to explain or at least confirm this phenomenon, but I all I found was
blogger Joi Ito remarking that after meeting a few people from the top
of the power structure, Wikipedia seemed to be remarkably gender-balanced.

That, I think, is a statistical anomaly, or perhaps an odd fact of
gender relations -- after all, those women were singled out and elected.

I pondered doing a proper survey, contacting people by email, but the I
realised that there was a less precise but far easier way to get this
information.

The "Viva Wikipedia" community on orkut.com contains 774 wikipedians,
wannabe wikipedians, and people interested in Wikipedia. Unlike on
Wikipedia, orkut members generally give their gender and relationship
status. I downloaded all 52 pages of the member listing and counted the
relevant keywords, which were conveniently given on the member listing
itself. 10 minutes later I had the following results:

"Viva Wikipedia" community membership statistics
Total: 774
                     Number              Ratio
Male                665                 85.9%
Female              105                 13.6%
Unspecified         4                   0.5%

Single              353                 45.6%
Married             101                 13.0%
Committed           158                 20.4%
Open marriage       6                   0.8%
Open relationship   11                  1.4%
Unspecified         145                 18.7%

It would have been nice to have some age and education statistics, but
that information wasn't given on the member listing. The relationship
statistics are roughly in line with Orkut's background demographics. The
background gender statistics on Orkut are:

Male:               1,433,169           48.1%
Female:             1,543,413           51.9%

These were determined using the search feature. The overall proportion
of female web surfers ranges from about 40% to 50% depending on country,
see http://www.itfacts.biz/index.php?id=P1554

The 13.6% figure agrees neatly with the 3:22 ratio observed in London.
Why is Wikipedia so repellant to women? I couldn't begin to speculate.
Any ideas?

-- Tim Starling


subject: [Wikipedia-l] Wikipedian gender ratio

body:
Similarly, it would seem the proportions of homosexual to heterosexual
Wikipedians (that is, those whose orientation is public) are very
different than those of society at large. There could be many reasons
for this - groups with higher education generally tend to have larger
numbers of "out" gays (for various reasons).

There are a few more groups which are over- or under-represented in
the Wikipedian population, for any number of reasons.

Mark


subject: [Wikipedia-l] Wikipedian gender ratio

body:
Indeed...

However, among all Wikipedians, there seem to be larger numbers of
people under 35 than of people over that age, since for example a
22-year-old woman in most Western countries is at least somewhat
likely to not have a family of her own yet, restrictions from
traditional gender roles may not be an adequate explanation in many
cases.

However, what you say definitely is true. I have invited my own mom a
number of times to contribute to Wikipedia. She does have a bit of
free time and is a technical writer by profession and very
intellectual, but I think the two factors you mentioned together make
her less interested or able to contribute to Wikipedia on a regular
basis. Of course I don't know if this is the same hesitation you might
encounter from many people about contributing to Wikipedia, or if it
is indeed as I suspect the factors you mentioned.

But I think in general, in the age range I mentioned above, reasons
would probably be mostly cultural - many girls here think it's not
"cool" to be smart and that you should be exactly like everybody else
if you want to be popular. Boys seem to think the same thing, but I
think the difference is that, culturally, girls are taught to place a
great deal of importance on acceptance by a group, while boys are
taught to place a great deal of importance on personal achievements.
Thus, schools which we have in the area for highly gifted children
have, with no exceptions, a large number of boys but a tiny number of
girls.

This is because for many girls who *do* enjoy intellectual pursuits
and find time for them, social life is still more important than
cognitive challenge, and for those girls who might enjoy intellectual
pursuits but hide it because they think that it will make them less
"popular" it is in the long run a negative effect.

Thus, more women will be involved with making careers, raising
families, and social life, while more men will be involved with making
careers, pursuit of intellectual stimulation, and in some cases social
life.

While the true objective of any Wikipedian should be to improve the
quality of Wikipedia, one major motivation for many is a love of
learning. I for one crave the intellectual stimulation provided by the
seemingly endless supply of facts provided by Wikipedia, and by the
fact that I can also access such supplies in many different languages.
I think that, in general, Western society works to foster a lifelong
love of learning more in men than in women, and despite the successes
of the feminist movement, Western society in general is still very
much built on the idea that women should stay home and take care of
kids, while men should earn a living or even that men should live only
to seek intellectual and physical stimulation.

Mark

On Mon, 6 Dec 2004 19:08:42 -0800 (PST), Anthere <anthere9 at yahoo.com> wrote:
> Tim wrote "Why is Wikipedia so repellant to women? I
> couldn't begin to speculate.
> Any ideas?"
>
> Might have a couple ones to give.
> I do not think it is a question of repellance.
>
> You may notice than the under representation is
> particularly critical for a age over 30-35. You may
> ask female wikipedians their age to check. Most are
> below 35.
> The next question would be "do you have kids ?".
>
> Generally, most women over 30-35 do have kids.
>
> Check on google "free time, housework, women, men" and
> contemplate results. All studies I know show that at
> least in european countries, men enjoy a significantly
> higher leisure time compared to women, essentially due
> to less time spend on housework chores and children
> care. This is especially significant as most
> participants to Wikipedia are educated people, which
> often implies working people (when over 30)
> Ask a working mother how she occupies her time in the
> evening versus how a man occupy his time, and I think
> it will enlighten you.
>
> This other point is significant as well I think. When
> you are an already overworked mom, and your family or
> most friends realise the time you spend over
> Wikipedia, their comment is at best "you are crazy",
> and at worse, "you are damaging your family". This is
> not the type of comment a man having a serious
> associative activity will get.
>
> When you answer that you also have a brain (and enjoy
> using it) and have the desire to participate to "big"
> things, not only family and job, as you feel teaching
> kids, though a very nice activity is not satisfying
> you enough as a participation to the grand scheme of
> things, a woman will often get as an answer "but you
> can't feel you are useless, look, you have a nice
> husband and great kids who need you and love you, you
> are very important to them".
>
> Who would ever DARE saying to a man that he should not
> feel useless as he has kids to take care of ? Who
> would ever dare say a man he should focus on doing his
> job well and nurturing his kids before ever thinking
> of using his abilities for social activities ?
>
> I feel and resent very much the heavy weight of some
> well-thinking people who would perfectly agree women
> are just as bright and able than men, but comment with
> a touch of despise that it is really not a good idea
> not to focus on what is *really* important, family and
> job.
>
> I also invite you to reflect on Mark comment
>
> >On a more speculative note, on occasion researchers
> suggest that men tend to be more interested in
> enlightenment-style "knowledge for
> knowledge's sake", while women tend to be more
> interested in applied fields (at least in CS and math,
> which is where I've read the research).  Wikipedia
> definitely has interesting social and applied
> aspects, but the joy of building a compendium of human
> knowledge is very much an enlightenment-style project,
> so that might attract a disproportionate number of
> men.
>
> There it is as well. Women like less knowledge for
> knowledge sake, and more applied fields.
>
> We mostly enjoy what we have the time and opportunity
> to like Mark. Most women my age would love do more,
> but they are currently running after job hours,
> housechores, lice treatment, purchasing socks for the
> kids, driving the kids to doctors, to friends
> birthday, picking up presents for friends birthday,
> cleaning up, cooking etc... This is very practical, it
> has to be done. If not done, we see the deep serious
> look of society considering this should first be done,
> and done well, and fun or enlightement should come
> after... when there is time for it.
>
> __________________________________
> Do you Yahoo!?
> All your favorites on one personal page ? Try My Yahoo!
> http://my.yahoo.com
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>


from_name: David Gerard

subject: [Wikipedia-l] Wikipedian gender ratio

body:
Tim Starling (t.starling at physics.unimelb.edu.au) [041206 19:14]:

> The 13.6% figure agrees neatly with the 3:22 ratio observed in London.
> Why is Wikipedia so repellant to women? I couldn't begin to speculate.
> Any ideas?

Repellent to women or more attractive to men?

- d.


from_name: Robin Shannon

body:
As to the argument in discussion, i do not have a fixed opinion one
way or the other; yes polices are suffering something similar to
[[feature blot]], but equally which policies are the non-essential
ones. I would also like to share an insight re: our polices, that i
had on the train home - Our core policies ([[Be bold]], assume good
faith, NPOV) are all "thou shalt"
rather than "thou shalt not" ie, rather than Jimbo sending Larry
Sanger down the mountian with 10 comandments; thou shalt NOT covert
thy neighours ox, thou shalt NOT J-walk, etc. they are thou shalt be
bold, etc

I am reasonably sure that this is very significant, though not quite
so sure why.

paz y amor,
[[User:The bellman]]

> > I am really concerned that the number and extent of policies on en
> > Wikipedia is getting seriously out of hand.
> [Snip]
>
> > Obviously Wikipedia is a lot bigger than it used to be,
> > but I think the medicine might turn into a new disease.
>
> Amen.

--
hit me: robin.shannon.id.au
jab me: saudade at jabber.zim.net.au

This work is licensed under the Creative Commons
Recombo Plus License. To view a copy of this license, visit
http://creativecommons.org/licenses/sampling+/1.0/


from_name: Peter Danenberg

subject: [Wikipedia-l] Re: Wikipedian gender ratio

body:
> Why? I don't know.

     Risking  tautology, thou understand'st nought Man; spa-
tial recognition goes hand-in-hand with our genius.

--
Peter Danenberg                                           .
wikisophia.org                                           ..:


from_name: Rowan Collins

body:
On Mon, 06 Dec 2004 13:57:59 -0800, Nick Triantos <nick at triantos.com> wrote:
> Is anyone working on adding an RSS feed to the Special:Watchlist page?
>
> Presumably, most of the code could be shared / copied from
> Special:Recentchanges.  I might try to implement this if no one else is
> working on this.

I think the problem which no-one has got around to solving is how to
keep the information private: currently, users cannot view each
other's watchlists, and although this isn't a big deal, I believe some
are unwilling to give up this privacy. Of course, the simplest answer
is simply to have RSS feeds disabled by default, and warn users that
by activating the feed, they are essentially "opting out" of this
privacy. Otherwise, some kind of magic authentication key needs to be
invented; or something.

--
Rowan Collins BSc
[IMSoP]


subject: [Wikitech-l] Back to funny characters in page names

body:
I've seen a few threads go by about not being able to use "funny"
characters in page names... Everything from non-US characters, to the
plus sign ( + ) and apostrophe ( ' ).

Is there a reason that the page titles aren't just stored in the
database in urlencode( )'d page titles?  When a search, etc. is
performed, we could just convert the string to its urlencode( )
equivalent, and do the same for [[ ]] type links.

I'll code this up on the 1.4 code base if no one objects, but I'm
guessing there's some good reason it hasn't been done before.

(It's pretty annoying to me that you can't name a page "C++")  :-)

thanks,
-Nick


from_name: Michael Snow

subject: [Foundation-l] Re: Short Domain Name

body:
Scott Nelson wrote:

>> The two most ideal domains are wp.net and wp.org
>
> Why would we want to associate wikipedia with WordPerfect? They've got
> nothing to do with each other :)

Similarly, I wonder why so many emails seem to be referring to the World
Monuments Fund. For those who share my interest in Wikipedia as a
trademark, I would suggest that one helpful way to protect its trademark
status is to practice actually using the word (properly, of course), and
*not* constantly acronymize it. The same applies to helping the world at
large learn that the nonprofit organization behind all of this is the
Wikimedia Foundation (not Wikipedia Foundation).

--Michael Snow


subject: [Foundation-l] Re: Short Domain Name


from_name: Brion Vibber

body:
On Dec 6, 2004, at 11:11 PM, Nick Triantos wrote:
> I've seen a few threads go by about not being able to use "funny"
> characters in page names... Everything from non-US characters, to the
> plus sign ( + ) and apostrophe ( ' ).
>
> Is there a reason that the page titles aren't just stored in the
> database in urlencode( )'d page titles?  When a search, etc. is
> performed, we could just convert the string to its urlencode( )
> equivalent, and do the same for [[ ]] type links.

The storage of titles in the database is *in no way at all* related to
limitations of what characters we allow in titles. Storing them in the
database urlencode()d would make absolutely no difference except to
complicate the code and bloat the database.

What characters we allow in titles is *only* related to the wiki link
syntax and HTML and URL encoding/decoding issues.

It's extremely helpful for titles to be idempotent for URL decoding;
data may be decoded multiple times for instance due to mod_rewrite
hell, and for historical reason we in some places allow URL-encoded
text to be used in wiki links themselves. Interwiki links at least let
%xx hex does pass through unmolested.

> (It's pretty annoying to me that you can't name a page "C++")  :-)

The + issue has to do with multiple encoding/decoding issues and
backwards-compatible links (in URL encoding, + represents a space).

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