body:
norial wrote:
> I like to import wiki entries created with DokuWiki
> (http://wiki.splitbrain.org/wiki:dokuwiki) in the MediaWiki database.
> The data's are stored in UTF-8 text files. >Is a Converter already
> available?
> I think the easiest way could be an direct import into the mySQL
> database. So I need an small script that use the functions of MediaWiki
> like insertNewArticle. The script has to be insert the
> localsettings.php, connect to the database, login an admin and insert my
> text as a new page (text, summary, ...).

Take a look at maintenance/importUseModWiki.php for an example.

The 1.5 version I think now outputs an XML data stream for our importer
rather than poking directly into the database; if you use this technique
you'll help to future-proof your code.

The pages can then be imported with importDump.php (command-line) or
through Special:Import if the file isn't too big.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20051118/466cc9c5/attachment.pgp>


list: wikitech-l

source: pipermail-mbox

from_name: Brion Vibber

subject: [Wikitech-l] Wikimedia Servers and Organization

body:
J?rgen Herz wrote:
> But like all other clusters too, the load is very unequally
> distributed over the machines.
[snip]
> Where does this come from, or is this wanted? Wouldn't a more balanced
> load be better?

More balanced would likely be better. Spreading load evenly seems to be
really hard to get right; if you have advice based on experience I'm
sure we'd love to hear it.

> Other point: The Yahoo! Squids do virtually nothing between 18:00 and
> 0:00 (and machines besides yf1000-yf1004 to virtually nothing around
> the clock). How nice would it be make them helping out the other
> overloaded machines in Florida and Netherlands at least in these six
> hours.

What would they do during this time?

> 1. Squids at lopar idle all the time since dns has been moved of them.
> What where the problems with them and will they be back soon?

They're older, slower machines and can handle only a small fraction of
what we pump through the Amsterdam cluster, so not too sure about these.

> 2. Commons is very slow since the move from the prior "overloaded"
> server to the new one. Any explanation to satisfy a simple user?
> And what server is the new one?

It was already slow *before* that. The files were moved to a faster
internal server, but the web interface is still on a slow machine until
things get finalized. This means images are still slow to load (alas)
but don't bog down the primary wiki web servers as much when they poke
at the images.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20051118/e7915671/attachment.pgp>


list: wikien-l

from_name: Stephen Bain

subject:
[WikiEN-l] Tower of Babel - Voting to ignore MoS,
	NCs for language reasons.

body:
On 11/18/05, Tom Cadden <thomcadden at yahoo.ie> wrote:
>
>  For years the town of Kells in Ireland (the Meath one. There are two) was officially known as ''Ceananas M?r". NOBODY ever used that name. I lived there and it was an open joke that barely 0.001% of the population used the official name.

Was that the official name in English?

Some places have a number of official names, an official name in their
own language, and an official name in some other language.

--
Stephen Bain
stephen.bain at gmail.com


from_name: Sechan, Gabe

subject: [Wikitech-l] Parser caching

body:
Does the parser cache the results of pages after parsing them?  If so, is there a quick place I could turn it off for certain pages?  Such as pretending that they cache miss?  The parsing is messing up my read protections on pages-  the permissions are working perfectly on special pages like edit or history that try to access the page, but don't always protect the node itself unless I edit it after protecting it.

Gabe


subject: [WikiEN-l] Country naming

body:
I don't know if this got lost in the server, so I'll send it again.

In an attempt to resolve all this conflict, there's a new naming
convention proposal:

http://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_(countries)

Feel free to comment on the talk page.

--
Stephen Bain
stephen.bain at gmail.com


from_name: Fastfission

subject: [WikiEN-l] Wikipedia's provable anti-expertise bias

body:
What is the definition of "expert" we are working with here? Because
there are some forms of expertise which are compatible with our goals
and some which are not. I'm an expert of things which are wrong with
my house and need repairs, but that doesn't mean that this expertise
is worth a damn on here. Expertise in the modern sense usually denotes
some sort of specialized training or hands-on experience -- I'm not
sure that necessarily applies to people who claim expert status by
virtue of their having read a number of webcomics. I think this is at
the heart of the question of why obscure scientific principles don't
get nominated for deletion but obscure webcomics do.

(I'm not at all clued in to the webcomic debates and I don't
participate in AfD very regularly, so I'm not trying to make a
specific point, but just raise a general issue.)

(As an aside, it would be interesting to have a fairly comprehensive
discussion of what academic experts think of Wikipedia, in relation to
teaching as well as just generally. Maybe I could do something of this
nature for Wikimania, some sort of pseudo-sociological study...?
hmm...)

FF

On 11/15/05, David Gerard <dgerard at gmail.com> wrote:
> kosebamse wrote:
> >Alphax alphasigmax at gmail.com wrote at Tue Nov 15 12:15:00 UTC 2005:
>
> >>What worries me is that with our growing popularity, we're going to have
> >>more experts arriving on our doorstep, trying to write articles on their
> >>specialist areas, and leave in disgust when some 2-bit moron votes "d,
> >>nn. cruft".
>
> >As far as I can say, that has always been a serious problem. It's not a
> >matter of elitism. An expert who is used to discussing his views  with
> >well-informed people on an academic level will not enjoy the experience of
> >having to defend basic and established knowledge of his field against
> >schoolkids whose only expertise is with video games. I am offering no
> >opinion on the desirability of it, but the latter probably form a very
> >sizable fraction of our user base.
>
>
> The problem here is the degree of it. The assumption of bad faith that
> appears to be far too common on AFD has led to an expert being *driven
> off* Wikipedia by people who are not only proudly ignorant, but are
> doing their best to get anti-expert bias made policy and the way
> things work around here.
>
>
> - d.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


subject: [Wikitech-l] Parser caching

body:
Ok, I tried forsing ParserCache::get to pretend there's a cache miss on protected pages, and it seems to be working.  If anyone knows a reason this wouldn't work fully or that this is a bad idea (other than performance, which should be minor as less than 1% of pages are read restricted), please tell me.

Gabe

-----Original Message-----
From: wikitech-l-bounces at wikimedia.org [mailto:wikitech-l-bounces at wikimedia.org] On Behalf Of Sechan, Gabe
Sent: Friday, November 18, 2005 11:35 AM
To: wikitech-l at wikimedia.org
Subject: [Wikitech-l] Parser caching

Does the parser cache the results of pages after parsing them?  If so, is there a quick place I could turn it off for certain pages?  Such as pretending that they cache miss?  The parsing is messing up my read protections on pages-  the permissions are working perfectly on special pages like edit or history that try to access the page, but don't always protect the node itself unless I edit it after protecting it.

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


subject: [Wikitech-l] Parser caching

body:
Sechan, Gabe wrote:
> Does the parser cache the results of pages after parsing them?  If
> so, is there a quick place I could turn it off for certain pages?
> Such as pretending that they cache miss?  The parsing is messing up
> my read protections on pages-  the permissions are working perfectly
> on special pages like edit or history that try to access the page,
> but don't always protect the node itself unless I edit it after
> protecting it.

If this is causing a problem for you, your permissions scheme is
inherently flawed and is probably a huge security hole.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20051118/ffaa5652/attachment.pgp>


from_name: Ben Yates

subject: [WikiEN-l] Usability

body:
A lot of the supposed "stupid user" stories on rinkworks are really "stupid
techie" stories in which the customer/user makes a joke the technie doesn't
get, says something seemingly inane to make friendly smalltalk, etc.

Read http://rinkworks.com/stupid/ for a laugh and resign ourselves to
> the fact that no matter what we do, some people will NEVER "get it"?
>

--
Ben Yates
Wikipedia blog - http://wikip.blogspot.com


subject: [WikiEN-l] Wikipedia down

body:
It's a server-side issue. Keep trying; you'll get through eventually.

On 11/17/05, MacGyverMagic/Mgm <macgyvermagic at gmail.com> wrote:
>
> I can't reach IRC right now (I'm on the wrong machine), but can
> someone tell me if the Amsterdam servers are down or if it's just my
> computer playing causing my inability to reach Wikipedia?
>
> It happened at exactly the same articles I was looking at yesterday...
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

--
Ben Yates
Wikipedia blog - http://wikip.blogspot.com


subject: [Wikitech-l] Parser caching

body:
How so?  I'm honestly curious here.  My permissions are stored in page_restrictions.  Its just a simple group read/can't read thing (only groups in the field can read a page.  Unless the field is blank, in which case anyone can).  I put the restrictions checking in Revision::getText()  and Title::getText().  This is working for edit text, history text, etc.  The only exception is for the main node itself-  there it works only after I edit the page (so if I edit the page, then read it, it works.  If I just protect it without editing, it fails).  Putting in the fake cache miss seems to fix that bug.  What am I missing?

Gabe

-----Original Message-----
From: wikitech-l-bounces at wikimedia.org [mailto:wikitech-l-bounces at wikimedia.org] On Behalf Of Brion Vibber
Sent: Friday, November 18, 2005 12:07 PM
To: Wikimedia developers
Subject: Re: [Wikitech-l] Parser caching

Sechan, Gabe wrote:
> Does the parser cache the results of pages after parsing them?  If so,
> is there a quick place I could turn it off for certain pages?
> Such as pretending that they cache miss?  The parsing is messing up my
> read protections on pages-  the permissions are working perfectly on
> special pages like edit or history that try to access the page, but
> don't always protect the node itself unless I edit it after protecting
> it.

If this is causing a problem for you, your permissions scheme is inherently flawed and is probably a huge security hole.

-- brion vibber (brion @ pobox.com)


from_name: Derick Rethans

subject: [Wikitech-l] PHP 4.4.2RC1 Testing

body:
Hello!

You are receiving this email because your project has been selected to
take part in a new effort by the PHP QA Team to make sure that your
project still works with PHP versions to-be-released. With this we hope
to make sure that you are either aware of things that might break, or to
make sure we don't introduce any strange regressions. With this effort
we hope to build a better relation between the PHP Team and the major
projects.

If you do not want to receive these heads-up emails, please reply to me
personally and I will remove you from the list; but, we hope that you
want to actively help us making PHP a better and more stable tool.

The first release candidate of PHP 4.4.2 can be found at
http://downloads.php.net/derick/ . If everything goes well, we hope to
release PHP 4.4.2 next tuesday. If you find any issues, please contact
the PHP QA team at "php-qa at lists.php.net".

The main things that this release addresses are:
- problems with mod_rewrite and apache 2
- the key() and current() bug

Please test those cases extra carefully on as many platforms as
possible.

In case you think that other projects should also receive this kinds of
emails, please let me know privately, and I will add them to the list of
projects to contact.

regards,
Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org


list: wikipedia-l

from_name: steve v

subject: [Wikipedia-l] What do you think?

body:
Which one looks better?

http://en.wikipedia.org/wiki/State_terrorism
or
http://en.wikipedia.org/w/index.php?title=State_terrorism&oldid=28655976

SV

__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com


from_name: David Gerard

subject:
[WikiEN-l] Fwd: Mediation on Pronunciation Paragraph Of
	"Bangladesh" page & Un-Ethical behaviour of SysOp

body:
Tariq originally sent this to the list binary-encoded; I asked that it
be put back through again in plain text.

- d.

---------- Forwarded message ----------
From: TariqAsh <tariqash at gmail.com>
Date: Nov 18, 2005 1:12 PM
Subject: Mediation on Pronunciation Paragraph Of "Bangladesh" page &
Un-Ethical behaviour of SysOp
To: wikien-l-owner at wikipedia.org

Hi David, I have been trying to keep a very necessary paragraph on
pronunciation of the word "Bangladesh" on [[Bangladesh]] page and also
another similar pronunciation para on the word "Bangla" in the
[[Bengali Language]] page . But paragraphs were often deleted and page
was often reverted back by sysop "Ragib" & sysop "Idleguy" and lastly
by sysop "Dmcdevit" . These three sysops worked as a team and did 3RR
by themselves . This paragraph is very important, because it can
remove confusion and reduce harassment on Bangladeshi people . Wrong
pronunciation of "Bangladesh" leads to an incorrect meaning . The
sound of "a" in "Bang" & "la" should be pronounced like the sound of
"a" in the word "Lava", for correct pronunciation . Which most
non-native speakers don't do, even some Bangladeshis, when they are
talking with non-native speakers . I'm looking forward to solve this
issue . Please start a mediation process to solve this problem . Many
thanks . I've already expressed and exchanged opinion about this issue
with "Ragib" in [[Bengali Language]] and [[Bangladesh]] discussion
page and also in our own Talk/discussion page . Please see those .
Admin/SysOp "Dmcdevit" performed many unethical steps outside of the
Wikipedia Policy . "Dmcdevit", "Ragib" and "Idleguy" deleted, reverted
even my improved version of that paragraph, again and again . Please
look into it . I'm looking for OnWiki (Public) type of mediation to
re-include this paragraph and an warning be issued for these SysOps,
or, revocation of their privilege which they have mis-used . Many
thanks for solving the problem related to post in my own page.
- Tarikash
IP:69.237.236.7


list: foundation-l

from_name: James D. Forrester

subject: [Foundation-l] .eu domains soon

body:
Jan Kulveit wrote:

> I'm not sure about the status of Wikimedia trademarks, but
> guess at least Wikipedia a Wikimedia are suitable. IMO
> "we" should apply at least for wikipedia.eu and wikimedia.eu.

Yes, certainly to those two. And Wikinews, I think (quite high-profile).

> Because of trademark issues and eu regulations concernig
> who can apply for .eu, I'm affraid it will be a bit
> complicated. I hope someone from the foundation can take care
> of it.

I would imagine that Wikimedia France would probably be best-placed to
take this on.

Yours,
--
James D. Forrester
Wikimedia : [[W:en:User:Jdforrester|James F.]]
E-Mail    : james at jdforrester.org
IM (MSN)  : jamesdforrester at hotmail.com


list: wikimedia-l

subject: [Foundation-l] .eu domains soon


from_name: Robert Scott Horning

subject:
[Foundation-l] Cleaning up Wikibooks (was Re: Incubator Wiki
	for	New Wikimedia Projects)

body:
Alfio Puglisi wrote:

>On 11/17/05, Sam Korn <smoddy at gmail.com> wrote:
>
>
>>On 11/17/05, Alfio Puglisi <alfio.puglisi at gmail.com> wrote:
>>
>>
>>>Why not simply moving them to some other place instead of outright
>>>deleting? This is a waste.
>>>
>>>
>>Some other place such as...
>>
>>
>
>Well, I don't know, but since they are being deleted because of a
>policy that, I understand, is stil debated, it shouldn't be difficult
>to find some temporary storage.
>
>Alfio
>
>
My big beef about this issue is that the decision was completely
arbitrary, and that some of the books that Jimbo wants to remove were in
some ways compatable with Wikibooks policy before his change.

Also, I preceive a conflict of interest here between Wikicities and
Wikimedia projects, where at least the impression that Jimbo is trying
to increase content on Wikicities at the expense of Wikibooks,
particularly with the Jokebook.  I understand that he wants to keep a
more educational mission to the project, and that is fine.  The lack of
details about why he is trying to remove these books is also difficult
to make future judgements on similar kinds of book projects on Wikibooks
as well.

--
Robert Scott Horning


from_name: Magnus Manske

subject: [Wikitech-l] DokuWiki -> MediaWiki Converter

body:
norial wrote:

> Hello
>
> sorry, English is the common language for this ng. ignore my previous
> posting.
> I like to import wiki entries created with DokuWiki
> (http://wiki.splitbrain.org/wiki:dokuwiki) in the MediaWiki database.
> The data's are stored in UTF-8 text files. >Is a Converter already
> available?
> I think the easiest way could be an direct import into the mySQL
> database. So I need an small script that use the functions of
> MediaWiki like insertNewArticle. The script has to be insert the
> localsettings.php, connect to the database, login an admin and insert
> my text as a new page (text, summary, ...).

You *do* realize that DokuWiki uses a rather different wiki syntax then
MediaWiki?

Magnus


from_name: Jan Kulveit

subject: [Foundation-l] .eu domains soon

body:
Hi,

the 1st sunrise period for .eu domain registration is going
to begin soon - 7 December 2005
only domain names which are registred EU community/national
trademarks will be registered.

I'm not sure about the status of Wikimedia trademarks, but
guess at least Wikipedia a Wikimedia are suitable. IMO
"we" should apply at least for wikipedia.eu and wikimedia.eu.

Because of trademark issues and eu regulations concernig
who can apply for .eu, I'm affraid it will be a bit
complicated. I hope someone from the foundation can take care
of it.

(If the process is allready going, sorry :-)

Jan Kulveit ([[USEr:Wikimol]])


subject: [Foundation-l] .eu domains soon


from_name: Ben Garney

subject: [Wikitech-l] Parser caching

body:
Sechan, Gabe wrote:
> How so?  I'm honestly curious here.
Me, too, it sounds like all that's happening is it's taking a cache
flush for the "this page protected" message to show up instead of the
regular content. In fact, for my project I've just turned off
client-side caching for the moment, since its been a significant source
of problems. I'll no doubt have to revisit that as more people start
using my site. :)

Regards,
Ben Garney
Torque Technologies Director


from_name: Tom Cadden

subject:
[WikiEN-l] need to work out clear policies on MANDATORY and
	OPTIONAL rules on WP

body:
Sam Korn <smoddy at gmail.com> wrote:

Setting aside sarcasm, it appears you still can't grasp that *anyone*
might disagree with you.

 No. I expect professionalism not amateurishness. This is meant to be an encyclop?dia, not a colouring book.

The day Wikipedia puts policy above community is the day I leave.

 The day when Wikipedia decides that it is simply a place for people to chat on talk pages and is not a professionally run encyclop?dia is the day when most people will leave. You don't seem to have noticed but a lot of people on Wikipedia do kind of think things like accuracy, standards, NPOV and verifiability matter more than treating the site as some sort of fancy-coloured chat room.

---------------------------------
Yahoo! Messenger  NEW - crystal clear PC to PC calling worldwide with voicemail


subject: [Wikitech-l] Parser caching

body:
Sechan, Gabe wrote:
> How so?  I'm honestly curious here.  My permissions are stored in
> page_restrictions.  Its just a simple group read/can't read thing
> (only groups in the field can read a page.  Unless the field is
> blank, in which case anyone can).  I put the restrictions checking in
> Revision::getText()  and Title::getText().

Be very careful; this will prevent all internal functions from loading
text properly, and could result in permanent data corruption on internal
maintenance processes (compression/uncompression for instance, backup
data dumps, perhaps future upgrades).

More generally about the parser cache; if you add per-user changes that
affect rendering you need to take this into account in the parser cache
option hash. See User.php.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20051118/4768f296/attachment.pgp>


subject:
[WikiEN-l] need to work out clear policies on
	MANDATORYandOPTIONAL rules on WP

body:
Sam Korn <smoddy at gmail.com> wrote:

Get this: Wikipedia is no less respectable for using the French name
than for using the English one.
 If its agreed code of rules says to follow one set of criteria, and hundreds of thousands of articles are written following it, and some choose to abandon the agreed standards and 'do their own thing' different to the rest of the pages, then Wikipedia's credibility as a sourcebook will plummet. The language is irrelevant. The only thing relevant is whether the terminology used is what readers would use. It has been unambiguously proven that in that one case the French name is rarely used except in one continent, and for hundreds of millions of readers is never used and unknown. Showing contempt for them by saying 'we're going to use the site to push one name because the government tells us to, irrespective of your needs' does not help WP's credibility. And as WP gets bigger and more famous, its need for credibility is central. If its credibility suffers through lack of professionalism then WP will soon find that its media coverage will turn from positive and negative, and everyone's
 hard work in trying to make a real as opposed to joke encylop?dia will have been in vain.

---------------------------------
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.


from_name: Ray Saintonge

body:
Robert Scott Horning wrote:

> Ray Saintonge wrote:
>
>> Anthony DiPierro wrote:
>>
>>> 1) Wikibooks is for textbooks, and this should be narrowly construed
>>> to mean classical textbooks, not to include any learning resources
>>> such as encyclopedias.
>>
>>
>> I tend to interpret the role of Wikibooks very broadly, certainly to
>> go beyond the idea of the classical textbook.  In some ways the
>> classical textbook is antithetical to good education because it tends
>> to mould its users into the same series of learning experiences.  A
>> single Wikibook should begin with a subject that can be included in
>> Wikipedia but which requires expansion into a book that in theory
>> could be published as a stand alone entity.  The Cookbook was a good
>> example of this.  There was a great debate at one time about the
>> inclusion of recipes in Wikipedia.  Some were accepted as proper to
>> Wikipedia, but the bulk ended up in Wikibooks where NPOV could also
>> be approached with a more relaxed interpretation.
>>
>> Ec
>
>
> A huge issue that has recently erupted on Wikibooks is resulting from
> a thread started by of all people Jimbo in the Staff Lounge:
>
> "In the next 24 to 48 hours, I will delete a variety of pages from
> Wikibooks which are a clear and simple violation of our charter.
> Jokebook <http://en.wikibooks.org/wiki/Jokebook>, Getting a date
> <http://en.wikibooks.org/wiki/Getting_a_date>, Naturism
> <http://en.wikibooks.org/w/index.php?title=Naturism&action=edit> are
> all not textbooks and need to be moved to another site. There may be
> more.--Jimbo Wales <http://en.wikibooks.org/wiki/User:Jimbo_Wales>
> 17:27, 13 November 2005 (UTC)"
>
> While I may agree with him in regards to those particular Wikibooks,
> this has resulted in a huge examination of the overall philosophy of
> Wikibooks and what should and should not be there.  In particular,
> Jimbo also changed the wording of an official policy from:
>
> "As a general rule, any book you might expect to find in the
> non-fiction section of your local library or bookshop is acceptable."
>
> to become instead:
>
> "As a general rule, most books you might expect to find in the
> non-fiction section of your local library or bookshop are not
> acceptable. This is for textbooks."
>
> This is Jimbo's website, so I guess he can make arbitrary changes like
> this whenever he wants to.  Still, as a Wikibook admin I am scratching
> my head to understand the full impact of this official policy change.
> In particular, it means that non-textbooks like the Cookbook may have
> to go, at least if we have a consistant textbook-only policy.  A large
> number of items are also being trans-wikied from Wikipedia to
> Wikibooks, so it is important as well to Wikpedia users to understand
> what the implications of this policy change is going to be.  And this
> is a policy change, as much as Jimbo wants to hide from that fact.
>
> There is a general tolerance of new content that goes onto Wikibooks,
> in part because it is a smaller project and we are trying to attract
> and keep contributors even if they add content that perhaps should be
> there. Writing a book is harder, and in some ways much harder than
> even an encyclopedia entry.  Driving away new contributors just
> because they do something against policy is especially harmful.
> Jimbo's comment that followed was especially harsh:
>
> "I'm happy to give more time, but these books are already candidates
> for speedy deletion. The point is that, to give on example which was
> thankfully already deleted, a racist white-power book is not a
> textbook, never will be a textbook, and should have been deleted on
> site and the creator banned for vandalism on site. --Jimbo Wales
> <http://en.wikibooks.org/wiki/User:Jimbo_Wales> 21:03, 13 November
> 2005 (UTC)"
>
> The user that added this white power book has otherwise done Wikibooks
> quite a bit of good, and banning him would only make an enemy rather
> than a useful contributor.  I prefer to follow the model of trying to
> mentor and encourage proper behavior where possible, and this user was
> not showing signs of traditional vandalism, nor would I want to drive
> this user to go in that direction.  We did delete the white-power book
> after a surprisingly short period of time on the Wikibooks VfD page.
>
> I think this issue needs to be brought to the attention of the larger
> Wikimedia community, and to be aware that there is a huge struggle
> going on to try an interpret Jimbo's actions here.

Without commenting on the applicability to the specified books,  this
policy change is bizarre and out of character.  (Still I do note that
there seems to be no attempt to get rid of [[Wikipedia:Bad Jokes and
Other Deleted Nonsense]].)  My primary activity has been on an other
project, so I have not kept up to date on all the policy discussions,
but I do remember the original establishment of Wikibooks, and the split
off of Wikisource.  The intent and purpose of Wikibooks was  seen  in
very broad terms; any kind of non-fiction book that you might find in a
library or bookstore represents a fair assessment of the broadest
mandates.  (Including the word "local" might even be too restrictive
unless it allows for comparable facilities on a university campus.)
Exceptions to that should be clearly described.  Insisting on a strict
interpretation of "textbook" suggests that we are clear about the
meaning of that word, but are we really so clear?  "Textbook" may imply
some kind of attempt at standardization, but about what subjects?  We
don't need to limit ourselves to books about traditional school
curriculum subjects; a textbook about how to play some videogame is
still a textbook.  From my perspective a cookbook IS a textbook.  The
concept of "no original research probably needs to be interpreted more
flexibly than in Wikipedia.  It would certainly be appropriate to use it
to prevent the development of entirely new wacko theories, but
developing subject continuity or filling the gaps between chapters may
often require original research.

If a handful of books are determined to be offensive that may be ample
reason for deleting those books; those books should not become straw men
to justify policies that have nothing to do with what makes them
offensive.  To be sure there have been a few recent discussions on the
mailing list about Wikibooks, but none of it has been particularly
alarming.  The Wikijunior and Wikiversity discussions seemed relatively
normal.  "How to Get a Girl," has been mentioned, but that was a fairly
focussed discussion about one book.  There have been other discussions
about other projects where the persuasiveness of an elephant's foot
would have been far more welcome.

In many respects you ar right when you say that Jimbo can make arbitrary
changes whenever and wherever he wants on a site that belongs.  (The
legal niceties about a person's relationship with a registered
non-profit society that he founded are well beyond the scope of these
comments.)  Much of what has been built up over what is now nearly five
years has been built on trust and on support for a fundamental idea.
People who have contributed enormous amounts of time, and more recently
money, have contributed to an idea and a vision rather than a person.
They have been able to put aside staggeringly different political
philosophies for the sake of something in which they all believe.
Creators who intervene in the societies thay have created often do so at
a price; it can even mean that people begin not to believe in God anymore.

Ec


subject: [Wikitech-l] Parser caching

body:
-----Original Message-----
From: wikitech-l-bounces at wikimedia.org [mailto:wikitech-l-bounces at wikimedia.org] On Behalf Of Brion Vibber
Sent: Friday, November 18, 2005 2:26 PM
To: Wikimedia developers
Subject: Re: [Wikitech-l] Parser caching

Sechan, Gabe wrote:
> How so?  I'm honestly curious here.  My permissions are stored in
> page_restrictions.  Its just a simple group read/can't read thing
> (only groups in the field can read a page.  Unless the field is blank,
> in which case anyone can).  I put the restrictions checking in
> Revision::getText()  and Title::getText().

Be very careful; this will prevent all internal functions from loading text properly, and could result in permanent data corruption on internal maintenance processes (compression/uncompression for instance, backup data dumps, perhaps future upgrades).

More generally about the parser cache; if you add per-user changes that affect rendering you need to take this into account in the parser cache option hash. See User.php.

-- brion vibber (brion @ pobox.com)

Good catch, I didn't think of backup.  I'll add in an exception to the checking so that internal functions bypass it.  Since these would be done via an admin or the command line, excepting those 2 cases ought to work (admins need full vision anyway).

Gabe


body:
Where sites allowed, all the usage measured was focused on the last five years. In newspaper usage, some US newspaper usage was measured as in what they used in 2005. Individual documents from the State Department were picked that dated from the last three years. (Many were from the last six months.) One European newspaper's usage was reviewed from 1st May 2005 to 1st November 2005. In fact some evidence (not included in the calculated) suggests that usage of Cote d'Ivoire peeked around 18 months after the government demand that it alone be used. News agencies probably tried to use it, found their readers rejected the usage, and returned to the usage their readers understood.

 New names are introduced all the time. Their impact usually follows one of a set of routes:

 * immediate adoption
 * slow adoption over time
 * immediate rush to adopt, followed by a quick abandonment
 * equilibrium between old and new versions.
 * failure of a new term to take off and its eventual dropping.

 Most usage when examined suggests that Cote d'Ivoire seems to have been either 3 or 5, depending on the source. Even the Economist, which championed its usage primarily because its largest market is among the business community who might be investing or interested in investing in the state, and so who in the magazine's eyes needed to use the government-preferred name, has started to return to Ivory Coast. Even the US State Department in the last two years has returned to using Ivory Coast in all but the most formal diplomatic discourses. Speeches by among others the Secretary of State, which are aimed at the media  and so at the public, use Ivory Coast predominantly. Cote d'Ivoire's usage is largely restricted to private inter-state and Letter of Credence usage.

Stan Shebs <shebs at apple.com> wrote: Tom Cadden wrote:

>
> It is one of the clearest open and shut cases imaginable. Put in ordinary language, the ordinary English speaker on the planet uses Ivory Coast not Cote d'Ivoire. Those that use the latter are aware of the former. Those that use the former are rarely aware of the latter. Under MoS criteria the only place the article can be placed at is Ivory Coast. But as the vote shows, most users aren't using MoS criteria but deciding on personal whims such as 'I like it', 'that's what I hear', 'it is what will become popular', and the even more POV 'we should help encourage its usage'. None of that fits the criteria of the MoS and means that that one article is in a different location to 99% of other such articles on WP, which follow most common usage, not personal agendas.
>
Stating your case more forcefully doesn't qualify as evidence. Since
you don't describe your sources of information, it's impossible to tell
whether you are talking about current usage or past usage - use of old
documents will by definition skew results to an old name, and we would
then be required to still use "Zaire", "Upper Volta", etc until the pile
of new documents outweighed the pile of old ones.

Stan

_______________________________________________
WikiEN-l mailing list
WikiEN-l at Wikipedia.org
To unsubscribe from this mailing list, visit:
http://mail.wikipedia.org/mailman/listinfo/wikien-l

---------------------------------
Yahoo! Messenger  NEW - crystal clear PC to PC calling worldwide with voicemail


from_name: norial

subject: [Wikitech-l] Re: DokuWiki -> MediaWiki Converter

body:
Hello

Magnus Manske schrieb am 18.11.2005 13:48:
> norial wrote:
>
> You *do* realize that DokuWiki uses a rather different wiki syntax then
> MediaWiki?

Yes of curse. This will be part of the Converter and could be solved
easily because my files don't contain complex formatting elements.

regards
  andreas


body:
As far as I can tell, the sources of information are users of the
English language, of course.

 That's what the MoS requires.

 Well, excepting encyclopedias, since for
some reason encyclopedias don't count.

 US Enclop?dias follow different MoS rules to WP which are based on their need to sell product in target markets in the country in question. We don't have to base our conduct on someone else's MoS, nor do we need to take business strategy into account in naming. And as we are not American we do not have to reflect American attitudes on the issue.

 Or people who, in their
professional life, deal with the names of countries, since they're
diplomats and diplomats call countries by the name they ask people to
use, which shouldn't count.

 Diplomatic usage is not the standard the MoS sets. That is most common uage. Even diplomats would not claim that their professional uage is aimed at communication with the mass market but that their own grouping. If one followed diplomatic usage then EVERY SINGLE COUNTRY ARTICLE on wikipedia would have to be renamed.

 Or the Economist, because, well, they're
the Economist and a bit funny in the head.

 No. Their target is not mass usage but business usage.

 Or anyone who also speaks
French.

 They are irrelevant under the MoS.

 Or anything produced by the US Government.

 This encyclop?dia is not American, must less owned by the US government.

 Or, indeed,
regional sources.

 Wikipedia is not a regional source a worldwide one. Worldwide usage is what is required to be followed under the MoS.

 Or English-speaking Ivorians.

 English readers around the world, not just English speaking Ivorians, read Wikipedia.

  Or the United Nations.

 Uses diplomatic language.

Or any result from a google search, because they're horribly
unreliable except when they get the right answer.

 Complete garbage. Google searches have proved themselves unreliable on thousands of pages. Targeted samples of independent worldwide, English-speaking communication sources provide more accurate answers.

 Or any "myths" about
what people may use.

 The standard is professional statistical analysis, not 'well I only use 'x' so obviously I am typical of the rest of the world.'

So, basically, any major source except the ones which use Cote
d'Ivoire, since we've just proven they don't count, use Ivory Coast.

 Not so. Independent factual sources, reviewed statistically, are used to set standards. There was no way of knowing what they would prove until they were analysed.

Case closed!
It has been for weeks. The evidence from sources worldwide is so conclusive as to be overwhelming. Worldwide, most common usage is Ivory Coast by a mile. Cote d'Ivoire is restricted to narrow target markets in regional areas and is not worldwide and much of the world it is not used at all.

---------------------------------
Yahoo! Messenger  NEW - crystal clear PC to PC calling worldwide with voicemail


from_name: Jack Lynch

subject:
[WikiEN-l] Re: Arbitration Committee members granted checkuser
	tool

body:
It is not a social handicap to prefer logic and order to the
judgements and "common sense" of others. Wikipedia has little or no
concensus, particularly when it comes to policy. Perhaps on obscure
article talk pages concensus occurs, but when it comes to policy the
few determine the fate of the many. Wikipedia's command structure is
an oligarchy, w little in common w a society of friends meeting.

Jack (Sam Spade)

On 11/18/05, Matt Brown <morven at gmail.com> wrote:
> On 11/17/05, Jack Lynch <jack.i.lynch at gmail.com> wrote:
> > Thats not an ideal admin. My ideal admin has no experience being an
> > admin on wikipedia, and need not be an editor. Instead, he would be
> > someone paid to follow and enforce rules, not make them up as goes
> > along.
>
> It strikes me, Jack, that you would prefer that because you have
> problems dealing with rules involving common sense and judgment and
> can only deal with rules that you can, by logic, determine whether you
> are doing a permitted thing.
>
> I don't think Wikipedia should change to accomodate such a social
> handicap, which is what this is.
>
> -Matt
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Milos Rancic

subject: [Wikipedia-l] Wiki about every person in the world

body:
As I saw some time ago, one Wikipedian has such project. Is there a
wiki with that purpose (Wikicity or some other)?


from_name: Gregory Maxwell

subject: [Wikitech-l] Extending Wikipedia with Java-based technology?

body:
On 11/18/05, Max Voelkel <max at xam.de> wrote:
> Dear Wikipedia-Wizards,
>   we are a group of four researchers building an extension for
>   Wikipedia, called the "Semantic Wikipedia", which is technically a
>   MediaWiki extension.
>   As a short summary, it allows users to type links, which yields to
>   the creation of semantic metadata (page name, link type, link
>   target). In a similar fashion we allow for the annotation of
>   attributes. If this project will be deployed on Wikipedia, a huge
>   amount of machine-processable data could be generated. We will
>   provide an RDF export per page and a SPARQL-query endpoint for the
>   whole Semantic Wikipedia (SPARQL is like SQL, but more adapted to
>   the data model of RDF, a building block of the semantic web).
>
>   Currently, we have two problems and would be glad if you help us:
>
>   1.
>   The tool stack in the semantic web community is mainly built on
>   Java. For C, there is only on "triple store" (which is needed for
>   efficient RDF storage & querying). The only candiadate we have,
>   "3store" is not very mature - but many Java stores are. Especially
>   the open-source system "Sesame" (openrdf.org) would be our choice
>   for implementation. But, as far as I understand Wikipedia, Java is
>   not open source enough, as there is no open source implementation of
>   Java itself? Is this true or just a rumor?

Look at [[GCJ]] on enwiki.  There are free implementations but they
are not good enough for all applications.

Perhaps I'm hopeless out of touch with the times, but why can't this
information be stored in a normal SQL database. I'm sure a parser
could be written to rewrite SPARQL queries into efficiently executing
SQL queries.

On my on and off again analysis copy of Wikipedia I use the hstore
module in PGsql to store name=value pairs for every revision.  If you
were only talking about storing metadata for the current versions
articles it would likely be quite efficent to carry a relation which
contains source,type,dest tuples for each of your links.  Even MySQL
could do a pretty good job for this.

>   2.
>   Syntax. We had to extend the syntax slightly to enable annotations
>   of links and data values. Currently we settled down to use
>
>     [[link type::link target|optional alternate label]]
>
>     Sample, on page "London":  ... is in [[located in::England]] ...
>     Renders as:    ... is in England ....  (England = Linked)
>
>   for relations, and for attributes.
>
>     [[attribute type:=data value with unit|optional alternate label]]
>
>     Sample, on page "London": ... rains on [[rain:=234 days/year]] ....
>     Renders as  .... rains on 234 days/year  (nothing linked)
>
>   For a full explanation of whay and what we try to do,
>   you can also have a look at a paper, which we wrote for a
>   conference:
>   http://www.aifb.uni-karlsruhe.de/Publikationen/showPublikation_english?publ_id=1055

There would appear to be some potential conversion with namespaces. It
might be advisable to use a character which could currently not appear
in an internal link.
It might also be advisable to not make them look like internal links.
We've already overloaded [[]] quite a bit with things which are not
quite the same as internal links conceptually, or syntactically
(categories, images).

Can semantic links carry an additional attribute beyond their type, i.e.
on [[Bill Clinton]] [[us presidential succession::George W.
Bush:=next]] or would it have to be  [[next us president::George W.
Bush]]

If it's just the latter case, then all it is is a typed directed graph
and there are a wealth of fast algorithms available for searching and
storing the relationships.


subject: [Wikipedia-l] Village pump inside of Navigation bar

body:
When I was trying to find what languages use small letter at the
beginning of language name, I found that it is very hard to find
village pump on bigger Wikipedias.

On Serbian Wikipedia, we put village pump as the second link inside of
navigation bar and I think that it should be implemented on all
Wikipedias. (Not necessary to be the second, but inside of navigation
bar.)

What do others think?


from_name: Delirium

subject:
[WikiEN-l] Tower of Babel - Voting to ignore MoS, NCs for language
	reasons.

body:
Peter Mackay wrote:

>I'm having difficulty with the notion that the name "Ivory Coast" could
>possibly be described as "widely used" or "widely known".
>
>With a straight face, that is.
>
>
Well, there are over 2,200 results on google news for "Ivory Coast".  It
may not be widely discussed in bar conversations, but anyone who's been
reading the news has seen it come up quite a bit in the past few years.

I suspect next someone is going to argue that it's amateurish to have an
article on "France" when the country's real name is "R?publique fran?aise".

-Mark


from_name: Brandon Cordy

subject:
[WikiEN-l] Re: Wikipedia's provable anti-expertise bias (was How
	didthis happen (comixpedia??))

body:
I don't think you understand. Obvious lapses of general common snese, like a
seperate article on, say, Ashlee Simpson or someone's cover of "Joy to the
World" can be listed on AfD all it wants to, but the teenybopper fan club is
gonna gang up and have it kept.

On 11/18/05, Sean Barrett <sean at epoptic.org> wrote:
>
> > AfD is flawed, because if you suggest cutting any of this stuff
> > down, merging, or whatever, little Wikipedia cliques pop up and
> > prevent anything from being done.
>
> Those annoying people who insist on pointing out that there is no
> consensus for deletion rampages sure are killjoys, aren't they?
> Gosh darn them to heck!
>
> --
> Sean Barrett | A positive attitude may not solve all
> sean at epoptic.org | your problems, but it will annoy enough
> | people to make it worth the effort.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


body:
I saw it and I think that there is a lot of sense to make a wiki.

>From time to time people add an article about her/his relative,
girl/boy/friend etc. Today someone added it on Serbian Wikipedia...

I think that wiki about every person is good idea because it can be
very good material for sociology as well as a number of persons would
not be forgotten.

As well as I am imaginning in this moment how can be arranged it via
MediaWiki possibilities :)

On 11/18/05, Fred Bauder <fredbaud at ctelco.net> wrote:
> Google Base has taken the project up, although not in the wiki
> format, see
>
> http://base.google.com/base/processstep1offerunauth
>
> Fred
>
> On Nov 18, 2005, at 7:27 AM, Milos Rancic wrote:
>
> > As I saw some time ago, one Wikipedian has such project. Is there a
> > wiki with that purpose (Wikicity or some other)?
> > _______________________________________________
> > 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: Sam Korn

body:
On 11/18/05, Tom Cadden <thomcadden at yahoo.ie> wrote:
> Setting aside sarcasm, it appears you still can't grasp that *anyone*
> might disagree with you.
>
>  No. I expect professionalism not amateurishness. This is meant to be an encyclop?dia, not a colouring book.

Hang on, are you trying to say that C?te d'Ivoire looks
*amateurish*???  I would hardly describe Britannica, World Book, the
US government, and such organisations as amateurish.  This isn't an
argument for C?te d'Ivoire, by the way, just saying how ridiculous
your point is.

The truth is that this part of Wikipedia policy is written in a way
that makes looking amateurish highly likely.

> The day Wikipedia puts policy above community is the day I leave.
>
>  The day when Wikipedia decides that it is simply a place for people to chat on talk pages and is not a professionally run encyclop?dia is the day when most people will leave. You don't seem to have noticed but a lot of people on Wikipedia do kind of think things like accuracy, standards, NPOV and verifiability matter more than treating the site as some sort of fancy-coloured chat room.

That's a strawman.  I never attacked NPOV or any of the other tenets
you mentioned.

NPOV is vital to the community.  Verifiability is intrinsic to NPOV.
No-one would say that accuracy isn't a good thing.  But naming
conventions?  *Naming conventions*?  Are we really going to say that a
naming convention is more important than the community?

Come off it.

--
Sam


from_name: charles matthews

body:
Fastfission wrote

>As an aside, it would be interesting to have a fairly comprehensive
discussion of what academic experts think of Wikipedia, in relation to
teaching as well as just generally.

They're going to think it's patchy, aren't they?

Most academics are remarkably poor at popularization.  They write as
experts, for experts.  Any technical slip will catch their eye, before all
the work going into access and presentation.

Most non-user academics are going to miss the point about hypertext.  An
area of WP with good navigation can get you in an hour what might cost a
week of a well-appointed library.  But only academics who actually remember
the mazy, hazy grad student days  of bombardment by things about which one
should already know will rate that aspect.

Most popularizing academics will find the tone of WP rather subdued.  (This
is a good thing.  We have no need to do boosterism. )

Charles


body:
On 11/18/05, Anthony DiPierro <wikilegal at inbox.org> wrote:
> On 11/18/05, Milos Rancic <millosh at mutualaid.org> wrote:
> > I saw it and I think that there is a lot of sense to make a wiki.
> >
> We already have a wiki, though, Wikipedia.  It'd be better to just add
> articles about people there.

Wikipedia's policy is not to have an article about every human. (I
would like that Wikipedia becomes the place for ALL human knowledge,
but AFAIK it seems that people don't think that it should be.)


subject:
[WikiEN-l] Re: Wikipedia's provable anti-expertise bias (was
	Howdidthis happen (comixpedia??))

body:
Sean Barrett wrote

>> AfD is flawed, because if you suggest cutting any of this stuff
>> down, merging, or whatever, little Wikipedia cliques pop up and
>> prevent anything from being done.
>
> Those annoying people who insist on pointing out that there is no
> consensus for deletion rampages sure are killjoys, aren't they?
> Gosh darn them to heck!

I'm sure there is plenty that ought to be merged, though.  Pending that, the
important thing is that Star Trek pages (for example) get categorised
properly.

Charles


body:
Ray Saintonge wrote:

> If a handful of books are determined to be offensive that may be ample
> reason for deleting those books; those books should not become straw
> men to justify policies that have nothing to do with what makes them
> offensive.  To be sure there have been a few recent discussions on the
> mailing list about Wikibooks, but none of it has been particularly
> alarming.  The Wikijunior and Wikiversity discussions seemed
> relatively normal.  "How to Get a Girl," has been mentioned, but that
> was a fairly focussed discussion about one book.  There have been
> other discussions about other projects where the persuasiveness of an
> elephant's foot would have been far more welcome.
>
> In many respects you ar right when you say that Jimbo can make
> arbitrary changes whenever and wherever he wants on a site that
> belongs.  (The legal niceties about a person's relationship with a
> registered non-profit society that he founded are well beyond the
> scope of these comments.)  Much of what has been built up over what is
> now nearly five years has been built on trust and on support for a
> fundamental idea.  People who have contributed enormous amounts of
> time, and more recently money, have contributed to an idea and a
> vision rather than a person.  They have been able to put aside
> staggeringly different political philosophies for the sake of
> something in which they all believe.  Creators who intervene in the
> societies thay have created often do so at a price; it can even mean
> that people begin not to believe in God anymore.
>
> Ec

The big deal right now is that if we follow this general policy to its
ultimate conclusion, about half of the current content on Wikibooks
needs to be removed somehow.  Of particular note is the Computer Gaming
Guides bookshelf, which are not precisely textbooks but are an
interesting sub-community on Wikibooks.

I mention the Cookbook because I fail to see how that differs in a
substantial way from the Jokebook.  Both have very similar internal
organization and both have had some controvercial sections added from
time to time (the current being [[b:Cookbook:Human]], about how to cook
human flesh).  Both of these Wikibooks have a very substantial edit
history, including edits by just about every admin past and current and
many users.  Neither has been subject to any sort of VfD discussion
until this week, and that is prompted only by Jimbo.  The only
difference I see is that Jimbo likes the Cookbook and hates the
Jokebook.  How do you make policy based off of that idea?

The other issue is that the only place to move these Wikibooks is to put
them onto Wikicities, as there is no other logical Wikimedia project to
move them to.  I know Jimbo has a lot on his plate, and trying to deal
with the internal politics of a minor project like Wikibooks is not
something he is prepared to deal with in a substantial way.  Still, I
want everybody on this mailing list to know the turmoil that has
resulted from these actions.  Most recently I'm getting into an edit war
of deletion/undeletion with another admin over these books that Jimbo
has declared off limits.  It is going to get worse before it gets better.

--
Robert Scott Horning


from_name: Tels

subject: [Wikitech-l] Extensions that return non-wikitext

body:
-----BEGIN PGP SIGNED MESSAGE-----

Moin,

On Friday 18 November 2005 01:17, Brion Vibber wrote:
> Tels wrote:
> > my graph extension (see http://bloodgate.com/perl/graph) returns
> > either HTML, or SVG. However, mediawiki treats the returned text as
> > wikitext, e.g. it parses it, attempts transform it into HTML and the
> > sanitizes it.
>
> That would be very unusual if true; extensions' HTML output is
> reinserted into final output in a very late stage of parsing, at
> blocklevels iirc.
>
> Avoid extra whitespace and blank lines in your output.

Well, what is it - inserted late (and thus unmodified) or modified and
then inserted?

In 1.5.x lines with white space in front are turned into <pre>, and empty
lines result in paragraphs - and both of these transformations shouldn't
be nec. when the extension outputs HTML.

This smells like some bug - could you point me to the place in the code
where the result of the extension output is worked into the normal
output?

Best wishes,

Tels

- --
 Signed on Fri Nov 18 17:58:41 2005 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 This email violates U.S. patent #6,775,781 <http://tinyurl.com/3khqm>:

   sudo rm -fR *

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQEUAwUBQ34IxHcLPEOTuEwVAQGjvAf1HIyka85g96hQKICj+isolgAiERsQ6+Kp
5gNhSlN2Bj+I7fagG4VDY/fcYpDQlKli/t2nEB9lrxlrNfb/CrG/jHewNjFGLCpJ
0ZJcM6lMWl5i9x/dAmu15QJIBS3nReXmRRI+g8eWEyXg4oo/6F7tUQfqYgLa5VcO
ugLIED49C6fjBKWRXrRgo2/99QW4IC8SLNqKW9qGnTR85R4OE8rjJX2hWJeksTDe
isPxrw4DB6LI0agn343D+KvRmJWM3GX/SVRRkDDLLRWLu4ckxKocSQWQyjHI0Wzc
Tu2yNq26PFXYtpcEK2zbB2Kj98/EPoa0lxGPdpsCVeaGVhNm2jBm
=G7GO
-----END PGP SIGNATURE-----


from_name: Mark Gallagher

subject: [WikiEN-l] Arb elections poll

body:
G'day Jack,

> I am before the current ArbCom, and while I felt comfortable w every
> other ArbCom we have had, Jimbo's recent appointees make me feel
> unsafe, and dubious of justice, despite the overwhelming evidence
> against my accuser. Something must be done, the status quo cannot
> continue. No justice, no peace.

"No justice, no peace."?  Is that a threat?  It's a very odd thing to
say, one way or the other, methinks.

--
Mark Gallagher
"What?  I can't hear you, I've got a banana on my head!"
- Danger Mouse

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.3/174 - Release Date: 17/11/2005


from_name: Bryan Derksen

body:
charles matthews wrote:

> Sean Barrett wrote
>
>>> AfD is flawed, because if you suggest cutting any of this stuff
>>> down, merging, or whatever, little Wikipedia cliques pop up and
>>> prevent anything from being done.
>>
>>
>> Those annoying people who insist on pointing out that there is no
>> consensus for deletion rampages sure are killjoys, aren't they?
>> Gosh darn them to heck!
>
>
> I'm sure there is plenty that ought to be merged, though.  Pending
> that, the important thing is that Star Trek pages (for example) get
> categorised properly.

AfD has nothing to do with merging, though, except that it's often
recommended as part of a keep vote for something to do with the article
after its AfD listing is finished. Anyone can merge an article any time
without going to AfD to get "permission" about it. I've merged plenty of
articles myself that way.


body:
Tels wrote:
> Moin,
>
> On Friday 18 November 2005 01:17, Brion Vibber wrote:
> >> Tels wrote:
> >>> my graph extension (see http://bloodgate.com/perl/graph) returns
> >>> either HTML, or SVG. However, mediawiki treats the returned text as
> >>> wikitext, e.g. it parses it, attempts transform it into HTML and the
> >>> sanitizes it.
> >> That would be very unusual if true; extensions' HTML output is
> >> reinserted into final output in a very late stage of parsing, at
> >> blocklevels iirc.
> >>
> >> Avoid extra whitespace and blank lines in your output.
>
> Well, what is it - inserted late (and thus unmodified) or modified and
> then inserted?
>
> In 1.5.x lines with white space in front are turned into <pre>, and empty
> lines result in paragraphs - and both of these transformations shouldn't
> be nec. when the extension outputs HTML.
>
> This smells like some bug - could you point me to the place in the code
> where the result of the extension output is worked into the normal
> output?
>
> Best wishes,
>
> Tels
>
Stupid guess, but what if you wrap your HTML in <nowiki> tags as a
temporary measure?

MAgnus_______________________________________________
Wikitech-l mailing list
Wikitech-l at wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/wikitech-l


subject:
[WikiEN-l] Tower of Babel - Voting to ignore MoS, NCs for	language
	reasons.

body:
Alphax (Wikipedia email) wrote:

>So in the interests of addressing systematic bias, I say we leave it the
>hell alone. If they want to be called "C?te d'Ivoire", that's where the
>article should be. End of discussion. MOS be damned; it's the spirit of
>the rules that counts.
>
>
So if in some fit of English-rules nationalism the United States were to
decree that "United States of America" is the name of the country in all
languages, would the French article be moved to
http://fr.wikipedia.org/wiki/United_States_of_America?

I submit that it would and should not be.

-Mark


from_name: Kelly Martin

subject:
[WikiEN-l] Tower of Babel - Voting to ignore MoS,
	NCs for language reasons.

body:
On 11/18/05, Andrew Gray <shimgray at gmail.com> wrote:
> (There are some weird stylistic quirks, by the standards of en:,
> around - de: has asterisks and daggers on dates, say - no reason
> naming conventions won't differ according to local taste as well.)

Yeah, I've found some badly translated de: biographies on en: that
have the daggers still in them. :)

Kelly


from_name: Timwi

subject: [Wikitech-l] Re: <link> elements for interlanguage link information

body:
> I think it'd be useful for most multilingual MediaWiki installations
> that use interlanguage links to have such hidden <link> elements.

Speaking of which - this reminds me of an idea I had a while ago and I
was wondering if anyone would be interested to hear this. Currently many
Wikipedia pages in Google search results are redirects (for example,
Google for "nonogram" and look at the seventh search result). I was
wondering if there is a <link> element one could use to say that another
URL is the "real" page? Then the page returned for a redirect's URL
would tell search engines the URL of the page it's redirecting to.

Timwi


from_name: Robert Scott Horning

body:
Delirium wrote:

> Robert Scott Horning wrote:
>
>> The big deal right now is that if we follow this general policy to
>> its ultimate conclusion, about half of the current content on
>> Wikibooks needs to be removed somehow.  Of particular note is the
>> Computer Gaming Guides bookshelf, which are not precisely textbooks
>> but are an interesting sub-community on Wikibooks.
>
>
> Since I'm peripherally involved with a Game Studies PhD program (not
> my field, but I work with people who are in it), I thought I would
> point out that what constitutes a "textbook" is not very narrowly
> defined.
>
> Who decided Wikibooks was for textbooks anyway?  This was never the
> intent.
>
> -Mark

Jimbo.  It is hard to tell him no, he is wrong, especially when he was
so specific on the topic.

--
Robert Scott Horning


body:
> Would be good if articles on the different projects were
> translations. Most of the time, although they are about the same
> subject, the articles are differents.

Not all inter-wiki links link to an article that is about the same
subject. They sometimes link to a more general topic. My pet peeve
example is the German Wikipedians insisting that [[en:Vulcan (Star
Trek)]], [[en:Romulan]], [[en:Ferengi]] etc. don't deserve German
equivalents, so they *all* link to [[de:V?lker im Star-Trek-Universum]],
which of course contains less than half of the information, but instead
a huge patronising banner warning not to be so stupid as to think these
fictitious things could have anything to do with the real world, much
less that they could be welcome on Wikipedia.

Timwi


from_name: Max Voelkel

body:
Dear Wikipedia-Wizards,

  we are a group of four researchers building an extension for
  Wikipedia, called the "Semantic Wikipedia", which is technically a
  MediaWiki extension.

  The project is described here:
  http://meta.wikimedia.org/wiki/Semantic_MediaWiki

  can be used as a demo here:
  http://wiki.ontoworld.org

  As a short summary, it allows users to type links, which yields to
  the creation of semantic metadata (page name, link type, link
  target). In a similar fashion we allow for the annotation of
  attributes. If this project will be deployed on Wikipedia, a huge
  amount of machine-processable data could be generated. We will
  provide an RDF export per page and a SPARQL-query endpoint for the
  whole Semantic Wikipedia (SPARQL is like SQL, but more adapted to
  the data model of RDF, a building block of the semantic web).

  Currently, we have two problems and would be glad if you help us:

  1.
  The tool stack in the semantic web community is mainly built on
  Java. For C, there is only on "triple store" (which is needed for
  efficient RDF storage & querying). The only candiadate we have,
  "3store" is not very mature - but many Java stores are. Especially
  the open-source system "Sesame" (openrdf.org) would be our choice
  for implementation. But, as far as I understand Wikipedia, Java is
  not open source enough, as there is no open source implementation of
  Java itself? Is this true or just a rumor?

  2.
  Syntax. We had to extend the syntax slightly to enable annotations
  of links and data values. Currently we settled down to use

    [[link type::link target|optional alternate label]]

    Sample, on page "London":  ... is in [[located in::England]] ...
    Renders as:    ... is in England ....  (England = Linked)

  for relations, and for attributes.

    [[attribute type:=data value with unit|optional alternate label]]

    Sample, on page "London": ... rains on [[rain:=234 days/year]] ....
    Renders as  .... rains on 234 days/year  (nothing linked)

  For a full explanation of whay and what we try to do,
  you can also have a look at a paper, which we wrote for a
  conference:
  http://www.aifb.uni-karlsruhe.de/Publikationen/showPublikation_english?publ_id=1055

  BTW: I promised Jimmy (in San Diego) to explain him, what the semantic web
  is. I still work on that :-)

  Thanks a lot in advance,

Kind regards,

  Max V?lkel
--
Dipl.-Inform. Max V?lkel
University of Karlsruhe, AIFB, Knowledge Management Group
mvo at aifb.uni-karlsruhe.de   +49 721 608-4754   www.xam.de


body:
-----BEGIN PGP SIGNED MESSAGE-----

Moin,

On Friday 18 November 2005 18:44, Magnus Manske wrote:
> Tels wrote:
> > Moin,
> >
> > On Friday 18 November 2005 01:17, Brion Vibber wrote:
> > >> Tels wrote:
> > >>> my graph extension (see http://bloodgate.com/perl/graph) returns
> > >>> either HTML, or SVG. However, mediawiki treats the returned text
> > >>> as wikitext, e.g. it parses it, attempts transform it into HTML
> > >>> and the sanitizes it.
> > >>
> > >> That would be very unusual if true; extensions' HTML output is
> > >> reinserted into final output in a very late stage of parsing, at
> > >> blocklevels iirc.
> > >>
> > >> Avoid extra whitespace and blank lines in your output.
> >
> > Well, what is it - inserted late (and thus unmodified) or modified
> > and then inserted?
> >
> > In 1.5.x lines with white space in front are turned into <pre>, and
> > empty lines result in paragraphs - and both of these transformations
> > shouldn't be nec. when the extension outputs HTML.
> >
> > This smells like some bug - could you point me to the place in the
> > code where the result of the extension output is worked into the
> > normal output?
> >
> > Best wishes,
> >
> > Tels
>
> Stupid guess, but what if you wrap your HTML in <nowiki> tags as a
> temporary measure?

I'll try this - but it would be the same kind of "hack" that I employ now
- - I just strip empty lines and leading whitespace from the HTML before
returning it to mediawiki. I'll try to look into the mediawiki source and
see if something obvious jumps at me.

The <svg> issue is still unsolved though - SVG outpout gets mangled so
that it no longer works and the browser (like firefox 1.5) does not
recognize it as valid SVG. (And external SVG files create a lot of
problems with caching, filesystem etc). I haven't found a workaround for
SVG yet, but your <nowiki> trick might actually help here :)

Thanx a lot,,

Tels

- --
 Signed on Fri Nov 18 19:34:35 2005 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Time flies like an arrow; fruit flies like a banana." -- Groucho Marx

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQ34fbncLPEOTuEwVAQFO6wf+NCknjs5hBckKGtEj8Oro0Yk4ohD4Ejmq
LGBfKWuC610sdKBu/2mtMxVn6QOLDfthnmG8rlWJTununa5l7xbtQljwpwHxBbwF
Cv8EC9KLRkKR6vOu+eBM/XV/gJQaFeIOyrWaR1frTDN9rYoDWwIwPbXq4xVlTObz
lnWwAo75IKG50C5E4G2V9gR3ipB/Q4/SS7bhM7JB1NyoIAjoWZQhyBJLeXE16n55
EVBlHdLO8o//YNOnmolGBTu7SXW6dUZFo6SvM4b0T25PdnTV4E4cdM6taUC2fBNj
2qZZhPPOTmbb4kLlcHUzPEvV5thq8P+0hPecNkcIr9g2Jab4tHtmdA==
=1Vvb
-----END PGP SIGNATURE-----


from_name: FxParlant

subject: [Wikitech-l] Re: links in template headache

body:
Solved by a hack:

In Parser::replaceFreeExternalLinks(), about line 1125:

Changed:
$bits = preg_split( '/(\b(?:'.$wgUrlProtocols.'))/S', $text, -1,
PREG_SPLIT_DELIM_CAPTURE );

Into:
$bits = preg_split( '/(\b(?:xx'.$wgUrlProtocols.'))/S', $text, -1,
PREG_SPLIT_DELIM_CAPTURE );

Just added "xx" to break the search for protocols.

Added to a limitation of the Sanitizer::Removehtmltags to work only for
talk pages, I got what I wanted ... until I discover other bugs in this
tuning.

Thanks for your help in this linkification problem.

Fran?ois

FxParlant wrote:
> Thanks Brion for reminding me that
> http://foo is replace into a link
>
> But, Sorry for asking again. Is there a proper way to have this kind of
> link in a template to work (Mediawiki 1.5.0)
>
>  src="http://rcm-fr.amazon.fr/e/cm?t=httpwwwfxpa03-21&o=8&p=8&l=as1&asins={{{1}}}&queryEncoding=utf-8&_encoding=UTF-8&queryCharset=utf-8&charset=UTF-8&fc1=000000&=1&lc1=0000ff&bc1=000000&lt1=_blank&IS2=1&bg1=ffffff&f=ifr"
> style="width:120px;height:240px;float:left;" scrolling="no"
> marginwidth="0" marginheight="0" frameborder="0">
>
>
> In mw1.3, I hacked a bit the regexp in Parser.php so that anything
> beginning with an '=' was left out of attributes replacement.
>
> Here (mw1.5.0), I tried the simple  surrounding, but with
> no success.
>
> I'm really not sure there is a way to write this in wiki language, but
> if someone knows...
>
> Thanks for any solution
>
> Fran?ois


from_name: Pavol Cupka

subject: [Wikitech-l] RC rss feed problems

body:
Hello techs :)

I would like to ask about a specific bug that prevents showing the
diff for new pages in the RC rss feed. Can someone please look at it
and tell me someting about it.

http://bugzilla.wikimedia.org/show_bug.cgi?id=3996

Thank you in advance
--
Palica
http://sk.wikipedia.org/User:Palica
Nezabudni si vzia? svoje Wikam?ny. / Don't forget to take your
Wikamins today. - Palica
http://sk.wikipedia.org - slobodn? encyklop?dia, ktor? m??e ka?d?
upravova? - AJ TY


from_name: Peter Mackay

body:
> -----Original Message-----
> From: wikien-l-bounces at Wikipedia.org
> [mailto:wikien-l-bounces at Wikipedia.org] On Behalf Of Tom Cadden

> You still don't get it. The only issue is 'is a name widely
> used in English?' Those names are now widely used. If Ivory
> Coast was ever to become widely known to English users as
> Cote d'Ivoire rather than Ivory Coast...

I'm having difficulty with the notion that the name "Ivory Coast" could
possibly be described as "widely used" or "widely known".

With a straight face, that is.

Peter (Skyring)


subject:
[Foundation-l] Cleaning up Wikibooks (was Re: Incubator Wiki
	for	New Wikimedia Projects)

body:
Robert Scott Horning wrote:

> The big deal right now is that if we follow this general policy to its
> ultimate conclusion, about half of the current content on Wikibooks
> needs to be removed somehow.  Of particular note is the Computer
> Gaming Guides bookshelf, which are not precisely textbooks but are an
> interesting sub-community on Wikibooks.

Since I'm peripherally involved with a Game Studies PhD program (not my
field, but I work with people who are in it), I thought I would point
out that what constitutes a "textbook" is not very narrowly defined.

Who decided Wikibooks was for textbooks anyway?  This was never the intent.

-Mark


from_name: Walter Vermeir

subject: [Wikipedia-l] Re: Village pump inside of Navigation bar

body:
Milos Rancic schreef:

> What do others think?

That you can use the normal interwiki-language links to find the
"Village pump" of a other wiki.

--
Ook een artikeltje schrijven? WikipediaNL, de vrije GNU/FDL encyclopedie
http://www.wikipedia.be


body:
Robert Scott Horning wrote:

>> Who decided Wikibooks was for textbooks anyway?  This was never the
>> intent.
>
>
> Jimbo.  It is hard to tell him no, he is wrong, especially when he was
> so specific on the topic.

Well, since the Cookbook is one of the oldest Wikibooks, I don't think
anyone can honestly claim to be surprised that Wikibooks has things
other than textbooks.  The "Wikibooks:About" page has even for *years*
said: "Wikibooks is a collection of open content textbooks, manuals, and
other texts".

Chopping off "manuals, and other texts" and making it textbooks-only
would be quite a radical change, and I see no compelling reason to do so.

-Mark


from_name: James D. Forrester

subject: [WikiEN-l] Re: [Wikipedia-l] What do you think?

body:
steve v wrote:
> Which one looks better?
>
> http://en.wikipedia.org/wiki/State_terrorism
> or
> http://en.wikipedia.org/w/index.php?title=State_terrorism&oldid=28655976

IMO, the former. However, I'm pretty sure this is an English-Wikipedia
matter, so I've set follow-ups to there.

Yours,
--
James D. Forrester
Wikimedia : [[W:en:User:Jdforrester|James F.]]
E-Mail    : james at jdforrester.org
IM (MSN)  : jamesdforrester at hotmail.com


subject: [Wikipedia-l] What do you think?


from_name: Any File

subject: [Foundation-l] Re: Cleaning up Wikibooks

body:
Robert Scott Horning wrote:
> Wikibooks and what should and should not be there.  In particular, Jimbo
> also changed the wording of an official policy from:
>
> "As a general rule, any book you might expect to find in the non-fiction
> section of your local library or bookshop is acceptable."
>
> to become instead:
>
> "As a general rule, most books you might expect to find in the
> non-fiction section of your local library or bookshop are not
> acceptable. This is for textbooks."
>

This definition is not only , in my opinion, not only cumbersome,
but also open a serious question: What is a textbook?

Just as an example why a cookbook is not a textbook? In many school
cookbook are used as a textbook. Morover they are used in some small
lecture course about cooking. What should be consider as a textbook?
Just what is normally used in American High school?

And should the subject only be limited to normal subject textbook are
written about?

For instance there exist a lot of book about chess (and many of them
not only dealt about chess, but are even organized in lesson). Anyway
I have never seen a textbook about chess (because chess is not taught
at school).

Thank you
AnyFile


from_name: Tony Sidaway

subject: [WikiEN-l] Arb elections poll

body:
I'm deeply suspicious of the election process.  This is a project to
produce an encyclopedia.  Let's just have an all-appointed arbitration
committee.  The election process is a millstone, we need to keep the
system lightweight and oriented to the purpose.


from_name: steve v

body:
--- MacGyverMagic/Mgm <macgyvermagic at gmail.com> wrote:

> The mergefrom is in the red box under "disputed"
> while the merge isn't disputed.

OK. What's the abstracted general idea superceding
both 'disputes' and 'suggested action' - 'Editorial
issues?' Whats the term to use?

> I wouldn't mind those templates being shrunk...

Great! Another support vote - and none too soon
either.

>...but the way it's done it
> is exceptionally confusing for newbies who don't
know what it's all about.

Im assuming that youre speaking for yourself, and
therefore I may infer that you are a newbie? If not,
then I cant simply accept your blanket statement as
any thing comparable to a 'poll targeted at newbies.'
For example.

Let's stick with the first until the creases
> are sorted out.

Lets not. Lets move in the general direction which we
all can agree on and sort the particulars along the
way. So what would be a better term?

SV

__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com


from_name: valdelli at bluemail.ch

body:
I'm in the similar point of view.

In addition in italian there is also an ambiguity: it could be a "manual"
or "handbook" or it could be a "perfect book" (???). which version is correct?

In the second case what is handbook? A book like "Galateo" (http://it.wikipedia.org/wiki/Galateo_overo_de'_costumi)
is an handbook?

Ilario

>>
>> "As a general rule, most books you might expect to find in the
>> non-fiction section of your local library or bookshop are not
>> acceptable. This is for textbooks."
>>
>
>This definition is not only , in my opinion, not only cumbersome,
>but also open a serious question: What is a textbook?
>
>Just as an example why a cookbook is not a textbook? In many school
>cookbook are used as a textbook. Morover they are used in some small
>lecture course about cooking. What should be consider as a textbook?
>Just what is normally used in American High school?
>


from_name: Andrew Gray

body:
On 18/11/05, Delirium <delirium at hackish.org> wrote:

> So if in some fit of English-rules nationalism the United States were to
> decree that "United States of America" is the name of the country in all
> languages, would the French article be moved to
> http://fr.wikipedia.org/wiki/United_States_of_America?
>
> I submit that it would and should not be.

It's kind of moot; as I understand matters, naming conventions and
other matters of style are decided on a local level. If you want to go
and posit that question on fr., do feel free, but they'll probably
look at you a bit funny...

(There are some weird stylistic quirks, by the standards of en:,
around - de: has asterisks and daggers on dates, say - no reason
naming conventions won't differ according to local taste as well.)

--
- Andrew Gray
  andrew.gray at dunelm.org.uk


from_name: MacGyverMagic/Mgm

body:
The mergefrom is in the red box under "disputed" while the merge isn't disputed.
I wouldn't mind those templates being shrunk, but the way it's done it
is exceptionally confusing for newbies who don't know what it's all
about. Let's stick with the first until the creases are sorted out.

--Mgm

On 11/18/05, James D. Forrester <james at jdforrester.org> wrote:
> steve v wrote:
> > Which one looks better?
> >
> > http://en.wikipedia.org/wiki/State_terrorism
> > or
> > http://en.wikipedia.org/w/index.php?title=State_terrorism&oldid=28655976
>
> IMO, the former. However, I'm pretty sure this is an English-Wikipedia
> matter, so I've set follow-ups to there.
>
> Yours,
> --
> James D. Forrester
> Wikimedia : [[W:en:User:Jdforrester|James F.]]
> E-Mail    : james at jdforrester.org
> IM (MSN)  : jamesdforrester at hotmail.com
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


subject: [WikiEN-l] Arb elections poll

body:
Jimbo wouldn't have appointed them to the arbcom if he didn't believe
them to be trustworthy. If you believe he was mistaken, dig up the
evidence and appeal his decision.

--Mgm


from_name: Craig Schiller

subject:
[WikiEN-l] Re: need to work out clear policies on
	MANDATORYandOPTIONAL

body:
> They follow their own MoS. We follow ours. Ours is not business based but
> based exclusively on the most common name principle.

Well, not exclusively. There are quite a few subject areas where
Wikipedia quite explicitly spells out that something other than the
"most common name" is the naming convention in that particular case.

Television and radio stations in North America, for example, are
required by policy to be titled by their official W---, K---, C--- or
X---- callsigns, even though a strict application of "most common
name" would require that they be titled with things like "Fox 25",
"CTV Toronto" or "The Beat 94.5".

It's quite common to disambiguate people with the same first name and
last name by adding a middle name to the title even if that middle
name isn't in particularly common use. (And it would be impossible or
excessively confusing, in some cases, to use another point of
disambiguation -- frex, there's been more than one Canadian politician
named Angus Macdonald, so the typical dab format, "Angus Macdonald
(Canadian politician)", would *still* have to be a dab page.)

It's patently obvious that in general day-to-day use, Laura
Schlessinger and Phil McGraw are *vastly* more commonly referred to to
as "Dr. Laura" and "Dr. Phil" than by their full names, and yet their
articles are located at their full names.

We use Inuit rather than Eskimo, Church of Jesus Christ of Latter-Day
Saints rather than Mormon Church, on the stated grounds that "we need
to temper common usage when the commonly used term is unreasonably
misleading or commonly regarded as offensive".

And a very real case could be made that in day-to-day English
conversational usage, "Holland" is still technically a more common
name for the country than "the Netherlands", but for obvious reasons
nobody who valued their reputation as a Wikipedia editor would even
*think* of suggesting anything other than "the Netherlands" as that
article's title.

And on and so forth. Most common name is not an inviolable rule; it's
a *guideline*, and one which is already *not* regarded as the final
word in every single situation.

There are already a *lot* of circumstances in which other
considerations trump "most common name", so can we *please* stop
pretending that "C?te d'Ivoire" somehow represents some unprecedented
blasphemy against Wikipedia's Great Unbreakable Commandment?

Craig


from_name: Ævar Arnfjörð Bjarmason

body:
On 11/18/05, Max Voelkel <max at xam.de> wrote:
>   2.
>   Syntax. We had to extend the syntax slightly to enable annotations
>   of links and data values. Currently we settled down to use

The problem with your extending of the syntax is that it conflicts
with existing titles both in theory and in practice, pages with double
colons though rare do exist, for example the Code::Blocks article on
enwiki and numerous user pages on other wikis.

Having said that you could either break compatability with such titles
or use some of the characters currently not allowed in titles which
are:

* +
* <
* >
* [
* ]
* {
* |
* }

[] aren't practical since they already delimit the link (unless you
wanted horrors like [[located in[England]]), {} are already used for
templates and | would be ambiguous that leaves you with <> and +. and
[[location>England]] or [[location=>England]] doesn't look all that
bad.

>     [[attribute type:=data value with unit|optional alternate label]]
>
>     Sample, on page "London": ... rains on [[rain:=234 days/year]] ....
>     Renders as  .... rains on 234 days/year  (nothing linked)

Say I also wanted to link an assigned value, say make a link to [[234
days/year]] how would I do that? [[[[rain:=234 days/year]]]] doesn't
work.


from_name: Brian Haws

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

> "Tony Sidaway" wrote
>
> >The BBC uses it
>
> BBC World Service uses CI:
>
>
http://www.bbc.co.uk/cgi-bin/worldservice/psims/ScheduleSDT.cgi?Pg=Co&Co=CI%3aCote%20D%27Ivoire%3a0%2d45
>
> so that's enough half-truths for the moment.
>
> Charles
>
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

note the search term and the result of the search:

http://www.bbc.co.uk/cgi-bin/search/results.pl?q=COTE+D%27IVOIRE&x=31&y=13&recipe=all&tab=allbbc


from_name: Carbonite

body:
On 11/19/05, charles matthews <charles.r.matthews at ntlworld.com> wrote:
>
> "Tony Sidaway" wrote
>
> >The BBC uses it
>
> BBC World Service uses CI:
>
>
> http://www.bbc.co.uk/cgi-bin/worldservice/psims/ScheduleSDT.cgi?Pg=Co&Co=CI%3aCote%20D%27Ivoire%3a0%2d45
>
> so that's enough half-truths for the moment.

 It looks like the BBC also uses "Ivory Coast":
 http://news.bbc.co.uk/1/hi/world/africa/4448322.stm
http://news.bbc.co.uk/1/hi/world/africa/country_profiles/1043014.stm
http://www.bbc.co.uk/weather/world/country_guides/results.shtml?tt=TT005880
 Carbonite


from_name: charles matthews

subject: [WikiEN-l] Arb elections poll

body:
MacGyverMagic/Mgm wrote

>Jimbo wouldn't have appointed them to the arbcom if he didn't believe
them to be trustworthy.

Obviously.

>If you believe he was mistaken, dig up the
evidence and appeal his decision.

An invitation to sling mud is not in the best possible taste.  There are
some tensions around, since there are misgivings about the way ArbCom places
are going to be filled.  (I share few of those, as I've seen them
expressed.)  This is not, however, a great time (if there is one) for
negative campaigning of any sort.  Our past hustings have not been for the
thin-skinned, and ArbCom places need quality candidates.

Charles


from_name: Stephen Bain

body:
People following this discussion might be interested in this proposal
for a new naming convention:

[[Wikipedia:Naming conventions (countries)]]
http://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_%28countries%29

--
Stephen Bain
stephen.bain at gmail.com


from_name: Jack Lynch

subject: [WikiEN-l] Arb elections poll

body:
To who?

Jack (Sam Spade)

On 11/19/05, MacGyverMagic/Mgm <macgyvermagic at gmail.com> wrote:
> Jimbo wouldn't have appointed them to the arbcom if he didn't believe
> them to be trustworthy. If you believe he was mistaken, dig up the
> evidence and appeal his decision.
>
> --Mgm
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: stevertigo

body:
--- MacGyverMagic/Mgm <macgyvermagic at gmail.com> wrote: > While the red template looks great...   My gosh - thanks.  (blush - hope my lines indent properly BTW)  >...it doesn't help > explain to people > what's wrong with the article.   We do use our own language of shortcuts of sorts - NPOV,  POV, Merge, etc.  And while I think that we can get carried away with the  acronyms (I do it too - FLOABT, etc), I dont think that  Wikipedia readers are retards. Hence while its proper to be explanatory, its not proper to assume end user stupidity. People learn rather quickly that if they click on a link  - they can go to some place that explains the links. If  its done right, the explanation will be well written and even a few sentences may be enough to satisfy the need for info.  >I'm not a newbie, but > if we put tags on > an article we should make sure a casual reader as > well as newbie and > experienced editors understands what it means.  How do we do that? Even with the current
 templates,  I have no idea what the real issues of dispute are - nor  should I know these from the talk page. Granted each  link should link directly to a talk page section, but I was  lazy, and thought somebody might just restore the status  quo. They did shortly after - so whats the point of doing  anything at all?  At least we can agree that the status quo does not work: It does little more than explain in pedantic language the  general fact that theres some dispute going on, and then  (as Alphax agreed) just says "see the talk page." Not only  is it no more useful than the {{editag}} idea, its also an  excessive WP:Self ref on the article - hence its a blight, and  an obstacle to reading articles. I think this adds to the overall impression of Wikipedias "second rate" status.  > Having the word > "mergefrom" in a red box on top of an article really > isn't helpful.  > What problem is it trying to solve? Is it meant to > save the space the > templates take or don't you like how
 it is now?  Its meant to provide due notice of a dispute while limiting the disruption factor such notices. Its tidying up our messes - and yes, it dispenses with the illusion that such disriptions are somehow inherently helpful.   For those who claim that "well the excessive disruptiveness  of these templates motivate editors to fix the problem," Id like to see some support for that claim. I rather think that  people have just gotten used to them, and that some have  gotten in the habit of using these messages (and the  processes they represent) to keep an article in state of  perpetual disarray.  > Personally I can see nothing wrong with the current > templates, but if > it must change, just put the merge bit (and all > suggested actions) > above the "disputed" heading and only put disputed > stuff below it. >  > --Mgm  Mechanically, the Disputed: header is stuck as being a header.  You havent answered my question that you suggest a better term. Separate editags for general
 "disputes" and for "suggestions?"  Is that what you are suggesting?  SV

---------------------------------
 Yahoo! FareChase - Search multiple travel sites in one click.


body:
(RESENT) Still having a word wrap problem...

--- MacGyverMagic/Mgm <macgyvermagic at gmail.com> wrote:

> While the red template looks great...

My gosh - thanks.  (blush - hope my lines indent
properly BTW)

>...it doesn't help
> explain to people
> what's wrong with the article.   We do use our own
language of shortcuts of
sorts - NPOV,  POV, Merge, etc.  And while I think
that we can get carried away
with the  acronyms (I do it too - FLOABT, etc), I dont
think that  Wikipedia
readers are retards. Hence while its proper to be
explanatory, its not proper to
assume end user stupidity. People learn rather quickly
that if they click on a
link  - they can go to some place that explains the
links. If  its done right,
the explanation will be well written and even a few
sentences may be enough to
satisfy the need for info.

>I'm not a newbie, but
> if we put tags on
> an article we should make sure a casual reader as
> well as newbie and
> experienced editors understands what it means.

How do we do that? Even with the current templates,  I
have no idea what the
real issues of dispute are - nor  should I know these
from the talk page.
Granted each  link should link directly to a talk page
section, but I was  lazy,
and thought somebody might just restore the status
quo. They did shortly after
- so whats the point of doing  anything at all?  At
least we can agree that the
status quo does not work: It does little more than
explain in pedantic language
the  general fact that theres some dispute going on,
and then  (as Alphax
agreed) just says "see the talk page." Not only  is it
no more useful than the
{{editag}} idea, its also an  excessive WP:Self ref on
the article - hence its a
blight, and  an obstacle to reading articles. I think
this adds to the overall
impression of Wikipedias "second rate" status.

> Having the word
>"mergefrom" in a red box on top of an article really
> isn't helpful.
> What problem is it trying to solve? Is it meant to
> save the space the
> templates take or don't you like how it is now?

Its meant to provide due notice of a dispute while
limiting the disruption
factor such notices. Its tidying up our messes - and
yes, it dispenses with the
illusion that such disriptions are somehow inherently
helpful.   For those who
claim that "well the excessive disruptiveness  of
these templates motivate
editors to fix the problem," Id like to see some
support for that claim. I
rather think that  people have just gotten used to
them, and that some have
gotten in the habit of using these messages (and the
processes they represent)
to keep an article in state of  perpetual disarray.

> Personally I can see nothing wrong with the current
> templates, but if  it must change, just put the
merge bit
(and all > suggested actions)
> above the "disputed" heading and only put disputed
> stuff below it.
>  > --Mgm

Mechanically, the Disputed: header is stuck as being a
header.  You havent
answered my question that you suggest a better term.
Separate editags for
general "disputes" and for "suggestions?"  Is that
what you are suggesting?

SV

__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com


from_name: Puddl Duk

subject: [WikiEN-l] Wikipedia's provable anti-expertise bias

body:
>
> I just now returned from an 8 hour seminar wherein we were repeatedly
> informed that free, non-governmental information on the internet is
> dubious at best, and should be avoided for anything other than
> commercial or general knowledge queries. Instead, the online
> university  database was praised (it includes a subscription to
> britannica, btw ;)
>
> Jack (Sam Spade)
>

Get used to it. As long as we have no validation/review/vetting/rating
mechanism we will always be in various stages of dubiousness.


from_name: Bryan Derksen

body:
Sam Korn wrote:

>On 11/19/05, Bryan Derksen <bryan.derksen at shaw.ca> wrote:
>
>
>>AfD has nothing to do with merging, though, except that it's often
>>recommended as part of a keep vote for something to do with the article
>>after its AfD listing is finished. Anyone can merge an article any time
>>without going to AfD to get "permission" about it. I've merged plenty of
>>articles myself that way.
>>
>>
>
>The logical conclusion of this is that merge votes are actually votes
>to keep.  That is not true.
>
Isn't it? If an article gets one third "keep" votes, one third "merge"
votes, and one third "delete" votes, the article gets kept. Even if an
article gets 100% merge votes, it's still "kept" - the old title gets
turned into a redirect and the information that was there gets moved
into an existing article the redirect points to. And this isn't a
binding forever and ever result like "delete" is, either, so the
material could eventually get split back out and moved to the old title
again one day if it grows enough to warrant it. I myself can think of
two cases where I merged articles after an AfD, complaints arose from
people who didn't like the resulting merged article, so I split the
material back out again to the original location and that was that.

I see "merge" as a vote to keep accompanied by a recommendation for how
to clean up the kept article afterward.


from_name: Brion Vibber

subject: [Wikitech-l] Moodle, newgroups for Threading

body:
Uwe Brauer wrote:
>     - Would it be possible that instead of  providing a link to a
>       discussion  page,   provide a    link  to  a  corresponding
>       *newsgroup*. That is every   article page should   have its
>       newsgroup (or mailing list if that would be easier.)

I think having several million mailing lists or newsgroups would not be
very nice. :)

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20051119/84d49c44/attachment.pgp>


body:
While the red template looks great it doesn't help explain to people
what's wrong with the article. I'm not a newbie, but if we put tags on
an article we should make sure a casual reader as well as newbie and
experienced editors understands what it means. Having the word
"mergefrom" in a red box on top of an article really isn't helpful.

What problem is it trying to solve? Is it meant to save the space the
templates take or don't you like how it is now?

Personally I can see nothing wrong with the current templates, but if
it must change, just put the merge bit (and all suggested actions)
above the "disputed" heading and only put disputed stuff below it.

--Mgm

On 11/19/05, steve v <vertigosteve at yahoo.com> wrote:
> --- MacGyverMagic/Mgm <macgyvermagic at gmail.com> wrote:
>
> > The mergefrom is in the red box under "disputed"
> > while the merge isn't disputed.
>
> OK. What's the abstracted general idea superceding
> both 'disputes' and 'suggested action' - 'Editorial
> issues?' Whats the term to use?
>
> > I wouldn't mind those templates being shrunk...
>
> Great! Another support vote - and none too soon
> either.
>
> >...but the way it's done it
> > is exceptionally confusing for newbies who don't
> know what it's all about.
>
> Im assuming that youre speaking for yourself, and
> therefore I may infer that you are a newbie? If not,
> then I cant simply accept your blanket statement as
> any thing comparable to a 'poll targeted at newbies.'
> For example.
>
> Let's stick with the first until the creases
> > are sorted out.
>
> Lets not. Lets move in the general direction which we
> all can agree on and sort the particulars along the
> way. So what would be a better term?
>
> SV
>
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
> http://mail.yahoo.com
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Ilya N.

subject: [Wikipedia-l] Wiki about every person in the world

body:
Would you consider an article about plain old Ilyanep who hasn't ever done
anything very notable to be encyclopedic?

Or how about baby Gary who's 3 months old?

On 11/19/05, Anthony DiPierro <wikilegal at inbox.org> wrote:
>
> On 11/18/05, Milos Rancic <millosh at mutualaid.org> wrote:
> > Wikipedia's policy is not to have an article about every human.
>
> Oh, sorry, I've never seen this policy.
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>

--
~Ilya N.
http://w3stuff.com/ilya/ (My website; DarkLordFoxx Media)
http://en.wikipedia.org/wiki/User:Ilyanep (on Wikipedia)


subject: [Wikipedia-l] Village pump inside of Navigation bar

body:
I think that's a very good idea. At times, it's really hard for me to find
the village pump on other language wikipedias I'm not very familiar with
(such as Spanish or Russian) and wouldn't know the name of it.

On 11/18/05, Milos Rancic <millosh at mutualaid.org> wrote:
>
> When I was trying to find what languages use small letter at the
> beginning of language name, I found that it is very hard to find
> village pump on bigger Wikipedias.
>
> On Serbian Wikipedia, we put village pump as the second link inside of
> navigation bar and I think that it should be implemented on all
> Wikipedias. (Not necessary to be the second, but inside of navigation
> bar.)
>
> What do others think?
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>

--
~Ilya N.
http://w3stuff.com/ilya/ (My website; DarkLordFoxx Media)
http://en.wikipedia.org/wiki/User:Ilyanep (on Wikipedia)


from_name: Anthony DiPierro

body:
On 11/18/05, Milos Rancic <millosh at mutualaid.org> wrote:
> Wikipedia's policy is not to have an article about every human.

Oh, sorry, I've never seen this policy.