subject: [Commons-l] [Toolserver-l]  Stats on deletion

body:
> interiot wrote:
> Okay, do individuals' deletion totals need to be made opt-in then?

Not sure - I would have thought that is uncritical, but Paddy's comments
on Commons-l imply the opposite.

> If I have a question about whether specific feature is okay, who is the best person to ask?

I think it would be a very good idea to ask the Foundation to develop a
privacy guideline for MediaWiki and tool developers.

> Does a user's total number of edits count as "intelligence that is not relevant to Wikipedia activity"?

Since several wikis have policies requiring a minimum number of edits to
the main namespace, etc, it *is* relevant. OTOH, I'm a bit undecided if
it's really OK to expose this information without asking.

Ideally, new users would be presented with a text explaining what data
they expose when they contribute, and how this may be analyzed. This may
even be made a click-through part of the account creation process.

Also ideally, users would be able to state which types of analysis they
want to allow. Perhaps a simple scheme of "no statistics", "simple
statistics" and "detailed statistics" would be enough, with a default of
"simple". "Simple" statistics would basically be total counts (number of
edits, maybe per namespace, number of deletions, etc), "detailed" would
be "anything goes". A per-project policy could then require admins to at
least allow simple statistics, or something like that.

I'm not sure if this would be feasible and/or legally sound. I'm just
brainstorming here.

-- Daniel

PS: sorry for cross-posting again. I guess this discussion should be
moved to the foundation list or something.

--
Homepage: http://brightbyte.de


list: wikitech-l

source: pipermail-mbox

from_name: Jay R. Ashworth

subject: [Wikitech-l] Apple's Wiki Server brings WYSIWYG to wiki

body:
On Thu, Aug 10, 2006 at 07:08:20PM +0100, Christiaan Briggs wrote:
> On 10 Aug 2006, at 6:33 PM, Jay R. Ashworth wrote:
> > But again: the amount of wikitext markup syntax you have to carry
> > around in your head to use it approaches zero more closely than
> > anything else I've ever worked with.
>
> And what you think matters not one iota when it comes to other
> people's experiences.

Well, I dunno; I've made a reasonably comfortable living for the last
two decades exercising professional judgement about software design, so
I suspect my opinions are neither *merely* opinions, nor worthless.

>                       People are different from you and many of us
> think it's worth catering for those differences in order to broaden
> participation in Wikimedia projects.

Well, your original argument actually soudned like it was as much
concerned with catering to *non* WMF projects, to me, but as far as WMF
projects are concerned...

people will code what they will code, if it scratches their itch, and
brion and Tim will decide whether to roll it in, based on what
scratches *theirs*, and each of our opinions will be but one small
datapoint in that constellation...

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	The Internet: We paved paradise, and put up a snarking lot.


subject:
[Wikitech-l] Using a template to set some character formatting
	to several blocks of text

body:
On Thu, Aug 10, 2006 at 08:10:00PM +0200, Steve Bennett wrote:
> This all makes me think that templates trying to be "clean" by
> refusing to leave dangling tags is probably going beyond what they
> were designed for - straight text substitution.

The impression I acquired from following that thread was that yes,
that's what TPTB feel as well, though I don't speak for them, even if
paid to..

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	The Internet: We paved paradise, and put up a snarking lot.


from_name: Brion Vibber

subject:
[Wikitech-l] "What links here" doesn't update properly
	with	templates

body:
Steve Bennett wrote:
> On 8/10/06, Brion Vibber <brion at pobox.com> wrote:
>> It takes some time for the queue to run through and update all entries,
>> especially when the queue is already full from some widely-used template being
>> edited.
>>
>> Please learn patience. :)
>
> Oh, sorry, I wasn't complaining that the update wasn't happening fast
> enough, I simply thought that it wasn't happening at all. I'll check
> back tomorrow and see if it's updated then.

It wouldn't hurt for a little warning message on some of those special pages, I
suspect.

-- 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/20060810/ed276f53/attachment.pgp>


list: commons-l

from_name: Patrick-Emil Zörner

subject: [Commons-l] Stats on deletion

body:
--- Matt Brown <morven at gmail.com> schrieb:

> I find it most bizarre that you suddenly have an issue with this,
> and
> suggest - since it is unlikely to change - that you either accept it
> or leave the project, bluntly.

Thanks for reminding me of my right to leave.

Paddy

PS I wonder if more comments like the german law is stupid, pack your
bags and leave, bizzare,... follow. There has only been one person
that is answering to the topic and that is daniel.

___________________________________________________________
Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de


from_name: Steve Bennett

subject:
[Wikitech-l] "What links here" doesn't update properly with
	templates

body:
Is this a known issue? Take a look at "what links here" for this image:
http://en.wikipedia.org/wiki/Image:Chambord_pano.jpg

It claims to be "linked to" by 50 or more pages - most of them user
pages that have {{POTD}} on them. However, that template no longer
refers to the image.

As a test, I updated one of the user pages (just adding a space) and
the set of "what links here" updated, removing that entry.

Steve


from_name: Bill Clark

subject: [Wikitech-l] Categories

body:
Hi all,

I'm involved in a debate about the pseudoscience and pseudoscientists
categories, that seems to be at an impasse because of the differences
between categories and lists.

One side argues that these two categories are inherently problematic,
and that a list would be more appropriate because it allows for
annotation of entires and referencing of sources.

The other side insists that a list is not acceptible and that a
category is required, for reasons that don't seem particularly clear
to me but which they feel strongly about.

Clearly this problem isn't restricted to just those two categories.
There are several guidelines that deal with controversial categories,
and this debate seems to come up whenever there is a vaguely defined
or otherwise "sensitive" category.  A more general solution seems to
be in order.

Rather than continue the debate (which from the archives on the talk
page for the pseudoscience category I can see has been continuing on
and off for years) I thought it might be best to simply change how
categories work, so that they can support the features of lists that
are desired.  (Yes, I'm using "simply" in an ironic manner :)

I've tried looking through the mailing list archives and on meta to
see if this has been discussed before, but could not find anything
relevant.  Since there are many other problems with the category
implementation (big DB hit for category page loads, inability to cache
the results, etc.) I thought I should put together a comprehensive
list of features, bugs, suggestions, and so forth before I begin
development work.

I'd also like suggestions as to the best place to discuss this topic
on either WP or meta.

-Bill Clark


list: wikien-l

from_name: David Gerard

subject: [WikiEN-l] Challenge: explain NPOV in a sentence.

body:
On 10/08/06, The Cunctator <cunctator at gmail.com> wrote:

> I meant as WP is intended, not necessarily in practice. However,
> principles like citing sources and forbidding original research do
> point articles in the direction of verifiable information.
> The bias toward verifiable information may be weak, but it's there.

My laptop has a file containing the complete and neutral encyclopedia,
in all languages. It's called /dev/random. It takes a while to read
the whole thing, and some would complain about its standard of
usefulness.

- d.


list: foundation-l

from_name: Anthony

subject: [Foundation-l] board candidacies

references:
<ebfkoi$bup$1@sea.gmane.org> <ebflq6$fkg$1@sea.gmane.org>
	<71cd4dd90608101016y80834albe8cb906c2bc5c@mail.gmail.com>
	<453b6e50608101058p518c54dcg1a84b8efa8615c33@mail.gmail.com>

body:
On 8/10/06, Delphine M?nard <notafishz at gmail.com> wrote:
> I sincerely hope that the international and cross project community
> will get organized and vote on this election, so as to balance the
> natural weight of the English Wikipedia and make sure that the person
> elected on the board has the skills necessary to the position.Whether
> they are or not from the English Wikipedia is indeed, irrelevant.
>
If it's irrelevant, then why is it being brought up?

With only one seat up for grabs, I don't really think it matters what
project the board member winds up spending most of his or her time on.

As for whether or not they speak English, I frankly don't think it's
possible for someone who doesn't read and write English well to be an
effective board member - unless maybe they have the money to hire
their own personal translator.

Anthony


list: wikimedia-l

subject: [Foundation-l] board candidacies


subject: [Wikitech-l] Categories

body:
On 8/10/06, Sebastian Moleski <sebmol at gmail.com> wrote:

> I'm not aware of any such discussions but I can tell you that these two
> categories, and categories like it, are not a local problem. On German
> Wikipedia, we have these very same discussions over and over again without
> much of a resolution. If you find anything, let us know because we're
> looking for solutions too.

Well, my initial thought is to replace categories with something along
the lines of "edit-time updated lists", by which I mean that adding a
category tag to a page would update not just that page but also an
"index" page (for lack of a better term) that is essentially a cached
version of the category page.  This way, loading the index page
wouldn't incur any extra database hits, and the index page would be
designed such that annotations and references could be added.

Implementation-wise, the code would need to recognize presence of the
category tag and update the corresponding index page appropriately.
This would complicate page updates slightly, but not overly so.  In
order to allow for rearranging and annotating the index page itself,
code would need to be added that checked for the presence of a link
(on the index page) back to the article.

Alternately, the index page could be an entirely different kind of
structure than a regular wiki page, and the presence of links could be
checked by some more efficient mechanism.  This might needlessly
complicate the editing of index pages, however.

This would basically combine the features of a list with the features
of a category, and improve the load-time efficiency at the expense of
a slight decrease in edit-time efficiency (which I think would
probably be a big win overall).

These are just my initial thoughts and I'm certainly open to
suggestions or objections.

-Bill Clark


from_name: jkelly at fas.harvard.edu

subject: [WikiEN-l] Wikipedia and Wikinews? (was:A busy article!)

body:
  Hi,

Quoting Steve Bennett <stevagewp at gmail.com>:

> http://en.wikipedia.org/wiki/2006_transatlantic_aircraft_plot
> Close to 1000 modifications and 54 footnotes, in less than 24 hours.

  To what extent are we duplicating effort or competing with Wikinews here?  Are
we doing something substantially different?

                     Jkelly


subject: [Wikitech-l] Categories

body:
On 8/10/06, Simetrical <Simetrical+wikitech at gmail.com> wrote:
> This is basically bug 1775: http://bugs.wikimedia.org/show_bug.cgi?id=1775

Yes, exactly.  Thanks for finding that.

However, I think the suggestion about how to expand category tags is
necessarily the best way to go.  I think it would be easier to be able
to edit the improved category page (what I'm calling an index page)
directly, rather than complicating the tag structure itself.  On the
other hand, perhaps the ability to keep the information on the article
page rather than on a list-style page is precisely why category
proponents prefer categories to lists.  That's precisely the type of
question that I think needs to be discussed in a more general,
non-technical forum.

I'd also like to address the problem of load-time efficiency with any
change, since my understanding is that the current category
implementation puts quite a strain on the servers.

-Bill


subject: [Wikitech-l] Categories

body:
On 8/10/06, Bill Clark <wclarkxoom at gmail.com> wrote:

> However, I think the suggestion about how to expand category tags is
> necessarily the best way to go.

Sorry.. that should read "not necessarily the best way to go."

-Bill


from_name: Death Phoenix

subject: [WikiEN-l] MyWikiBiz

body:
On 8/9/06, Jimmy Wales <jwales at wikia.com> wrote:
>
> Dabljuh wrote:
> > On Wed, 09 Aug 2006 14:58:44 -0400
> > Jimmy Wales <jwales at wikia.com> wrote:
> >
> >
> >> (stuff)
> >>
> >
> > So what is the agreement?
> >
> He agreed not to edit Wikipedia articles when he is being paid to write
> by the subject of the article, and to help the companies he works with
> understand that it is probably not a great idea for them to edit their
> own articles as well.  He will write articles and post them on his own
> site, under the GNU FDL, and to ask trusted prominent and independent
> Wikipedians to add the articles, on their own independent judgments of
> the merits of the articles.
>

Hey Jimbo, can you confirm that you tried to unblock MyWikiBiz but had
problems with your browser, per [[User talk:MyWikiBiz]]?


from_name: Kirill Lokshin

body:
On 8/10/06, jkelly at fas.harvard.edu <jkelly at fas.harvard.edu> wrote:
>  To what extent are we duplicating effort or competing with Wikinews here?  Are
> we doing something substantially different?

We're citing everything to external sources, for one.  The WikiNews
policy of allowing "original reporting" basically makes their articles
unsuitable for direct copying to Wikipedia, which means that we have
to write our own if we think the topic deserves an encyclopedia entry
rather than merely a news report.

--
Kirill Lokshin


subject: [Wikitech-l] Categories

body:
On 8/10/06, Bill Clark <wclarkxoom at gmail.com> wrote:
> However, I think the suggestion about how to expand category tags is
> [not] necessarily the best way to go.

On second thought, doing it that way would require the fewest code
changes and I could probably get it written this weekend.  Then, the
additional improvements I had in mind could come later.

In order to truly replace lists, we'd eventually need to be able to
add these features:

1) Items that don't yet have articles can still be members.
2) Category page can be cached.
3) Arbitrary restructuring of the page.

..and probably more.

I'll look into adding functionality to category tags so that they can
take a possibly arbitrary number of key=value pairs, delimited by
pipes.

-Bill Clark


from_name: Raffi Kojian

subject: [Wikitech-l] Synchronize mediawiki articles with wikipedia feature

body:
Hi - I am running a reasonably large wikimedia site (a few thousand
pages) and have thought for a while about a certain desired feature I
have, which I suspect a number of other wikimedia sites might find
quite helpful.

Background:
Armeniapedia.org is for articles on anything and everything to do with
Armenians.  So, for example, it can have articles on anything from
Yerevan to George Bush.  Now the Yerevan article, in theory, should
not need to be any different than the one on Wikipedia, while the
George Bush article, should have only Armenia(n) specific information
that would not be fitting on Wikipedia.  Armeniapedia is also a good
home for say online cookbooks, texts, etc, etc.

The idea:
For articles like Yerevan, it would be nice to somehow synch my site
with Wikipedia.  If I could somehow specify that a certain article on
my site is a sister article to Wikipedia, then allow the article on my
site to automatically update itself on a timely basis (weekly or so),
plus whenever someone wants to edit they get automatically taken to
the wikipedia article's edit page, it would allow both sites to
benefit.

I'm sure other ways of implementing this would be possible, but the
basic idea I think (and hope you agree) is a good one.

Thanks for reading this...


from_name: Andrew Gray

subject: [WikiEN-l] Norman Technologies AfD

body:
On 10/08/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On 8/9/06, maru dubshinki <marudubshinki at gmail.com> wrote:
> > (Note that this screed is independent of any deal Jimmy and MyWikiBiz
> > may've come to).
> >
> > This is an absurd block. He was writing perfectly fine, well-written,
> > *referenced* articles and has so far as I know scrupulously followed
> > the notability guidelines; would to God that we had a thousand more
> > like him, and could ditch the bottom thousand editors.
> [snip]
>
> Are we so sure?
>
> How do we know that he doesn't use multiple accounts with the role
> account attached to his orgs name on good behavior?

For one thing, we've seen the account in *his* name. It's on good behaviour.

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


subject:
[WikiEN-l] Article bragging (was: Re: en: well on the way to
	... 2 million!)

body:
Heh, I was wondering if it could be bent into "FOCDOC" so you could
say "Oh, FOC the DOC"... (perhaps as a response to rtfm)

anyway...

Steve

On 8/10/06, maru dubshinki <marudubshinki at gmail.com> wrote:
> On 8/10/06, Alphax (Wikipedia email) <alphasigmax at gmail.com> wrote:
> > Would you rather it was FODOC? :)
> >
> > --
> > Alphax - http://en.wikipedia.org/wiki/User:Alphax
>
> I'd rather it was FDC, so that way it is a curse word - "FDC it!" "FDC
> you, man."
>
> ~maru
> _______________________________________________
> 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: Simetrical

body:
Jay, with all due respect, you're a programmer.  You're comfortable
with codes and so on.  You'd probably be fairly comfortable with HTML
too.  You're probably also comfortable with command lines.  Most
people are not.  It doesn't matter how simple you make it--many people
are going to be put off by markup of any kind.  I know many such
people: anything resembling codes makes them instantly uncomfortable.
"Screw them" is not a productive answer.

As for the problem at hand: quite simply, a WYSIWYG editor that
implements all of our wikisyntax is totally impossible.  It's way, way
too complicated to implement smoothly in Javascript.  But you know,
the entire *point* of using wikisyntax rather than HTML is to make
editing *easier*.  If it stands in the way of creating an
easier-to-use interface, don't you think it's outlived its usefulness?

So how about this.  Design a WYSIWYG editor that works with cleaned
HTML, plus whatever syntaxes aren't replicable in HTML.  Make sure
this editor is high-quality, and then make it the default editor.
Then, anytime someone requests a section or page, just convert all the
wikisyntax (tables, bold, italics, headers, etc.) into HTML before
sending it, so it will work with the WYSIWYG.  Then, the user saves
it, and the wikisyntax is converted irreversibly to HTML.  But the
underlying representation will no longer be important to most users;
anyone who wants to edit it directly is probably hardcore enough to
deal with HTML in any case.  This would have a side benefit of greatly
simplifying wikitext parsers, ours included (we can even assume that
the submitted HTML is XML-compliant!).

So does anyone see any reason to keep wikisyntax at this point, beyond
what actually needs to be parsed beyond sanitization?


from_name: Christiaan Briggs

body:
In your world the human should bend to the computer. My users think
it should be the other way round.

You're not elitist Jay, you're just a prick.

Christiaan

On 10 Aug 2006, at 4:28 PM, Jay R. Ashworth wrote:

> On Wed, Aug 09, 2006 at 12:57:58PM +0100, Christiaan Briggs wrote:
>> For your interest, it looks like Apple has come to the party with a
>> wiki of its own, without the need for people to learn markup
>> language:
>> http://www.apple.com/server/macosx/leopard/wikiserver.html
>
> [ looks ]
>
> Oh, it's a wiki with a WYSIWYG editor on the front.
>
> Yeah, we've got that.
>
>> We've been using MediaWiki as our office intranet over the years but
>> it's never been adopted to a level that we think it could be, because
>> of the requirement that users learn wiki markup. For this reason
>> we'll be ditching MediaWiki in our office next year for Apple's Wiki
>> Server.
>>
>> The reason I'm posting this is simply put forward the view that I
>> hope WYSIWYG or some relevant variant will be developed for Wikimedia
>> projects in the near future, because I think the hurdles that stop
>> many people from participating on our office intranet apply equally
>> to Wikimedia projects. And the hurdle is not that wiki markup is
>> "difficult" or "hard to learn" but that it is intimidating and time-
>> consuming to learn.
>
> With all due respect to your users, bullshit.
>
> Number one, you don't actually *need* to use any markup at all.
> Number
> two, the markup you might *want* to use is so trivial, that I have to
> say that anyone who can't be bothered to learn it -- it's just that:
> they can't be bothered.
>
> Screw 'em.
>
> If you're not willing to learn the tools, you're not entitled to the
> ease their use contributes to your life.  And good riddance.
>
> I'm elitest, sure, but that outlook is *not*, IMHO.
>
>> I have little doubt that one day using wiki markup only to edit
>> websites like Wikipedia will be seen as an anachronism, even more so
>> as other alternatives to MediaWiki (such as Apple's Wiki Server) come
>> online, but there's a few hurdles to overcome yet and they're not all
>> technical ones as far as I can work out.
>>
>> It's always surprised me that WYSIWYG editing has not been made a
>> high priority for Wikimedia, considering the fact that it was founded
>> on the idea of broad participation. Although technical difficulties
>> are often put forward as the reason, the biggest obstacle, it has
>> often seemed to me, is an installed base of Wikipedians who see wiki
>> markup as a way of protecting their territory and minimising
>> participation by others. I've even had people argue that wiki markup
>> is some kind of "intelligence" hurdle that people should have to
>> overcome before being allowed to edit Wikimedia projects. Somehow
>> this needs to be overcome if WYSIWYG is to gain traction and get a
>> higher priority it seems to me.
>
> Bullshit.
>
> There will need tobe markup in the internal storage format anyway; if
> you want WYSIWYG, you bolt it on around the outside.  That's the only
> design pattern that makes any sense at all.
>
> Given that, I see no reason to penalize those who *prefer* power by
> making the markup language inaccessible -- which I'd bet cash Apple
> has
> done -- and if you want or need a WYG editor, put one on there.
>
> But don't dis MediaWiki because the native interface is ... the native
> interface.  That's just strawman.
>
>> Thanks to those who have been working on WYSIWYG for MediaWiki,
>> particularly in trying to integrate FCKEditor, and I wish you well.
>> However, if integrating an editor into the current environment is so
>> difficult maybe there needs to be a new approach, such as developing
>> new software/syntax with some type of WYSIWYG editor built in from
>> the start? Worth a discussion at least, I should imagine.
>
> I don't think so.
>
> Rebuilding MediaWiki from scratch?  That's crazy talk.
>
> If the problem is the weak definition of the markup language, then
> precess that around until you get it stable enough to WYG in front of.
>
> Anyone along the way for whom this isn't the right tool will no doubt
> find something else.  Darwin lives.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth
> jra at baylink.com
> Designer
> Baylink                             RFC 2100
> Ashworth & Associates        The Things I
> Think                        '87 e24
> St Petersburg FL USA      http://baylink.pitas.com             +1
> 727 647 1274
>
> 	The Internet: We paved paradise, and put up a snarking lot.
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


subject: [Wikitech-l] Categories

body:
On 8/10/06, Steve Bennett <stevage at gmail.com> wrote:
> The easiest solution to me would be to use the text space of a
> category as the list. You would end up with every entry listed twice:
> once by some arbitrary sort order (eg, year), and once alphabetically.
> In the list part at the top, you can put your annotations. The
> category listing at the bottom basically serves to check that the list
> part is up to date and that there aren't any stray additions.

That makes sense.  In order to prevent duplication, you could even
check if a link to an article has already been displayed in the top
list-part, and exclude it from the category-part at the bottom.

I'm poking through the category code right now, and I'll see which
approach (category text as list vs. extended attributes for category
tags) will work best.  I suspect the former, since it won't require
any database changes, although the extra parsing step to check for
duplicates (which I think is necessary to make this solution
palatable) might be too much.

-Bill Clark


body:
On 8/10/06, Steve Bennett <stevage at gmail.com> wrote:
> Ok, you're treating wikisyntax and HTML as essentially equivalent.
> Which they're not.

Some are, some aren't.  Note "beyond what actually needs to be parsed
beyond sanitization".  Internal links must be parsed beyond
sanitization, e.g., to generate what-links-here.  Since they're so
common, it might make sense to keep them separate from the HTML that
they generate.  That would be a specific decision that would have to
be made.  But the following can certainly all be dispensed with in
favor of XHTML:

horizontal rule
initial space (= <pre>)
wikilists
wikitables
headings
external links (probably)
italics/bold
everything newline-related (conversions should be dealt with on edit,
not on render)
HTML that's invalid XML

That's already what, probably cut the number of rules needed by a
factor of three?  More?  Then, in fact, just convert all remaining
markup to XML, and you can handle all parsing via library functions,
whether in PHP or Javascript or C or anywhere else.

> Wikisyntax is definitely "cleaner" than HTML and closer to the
> semantic representation of what we want to store. Storing only HTML
> (or XHTML) really ties us to a pretty specific presentation platform.

The above list consists exclusively of things that have a one-to-one
mapping with HTML tags.

> The more practical approach to me would be to layer an increasingly
> powerful GUI over the top that allows the user to edit most wikisyntax
> without even seeing it.

The problem is the complexity of the wikimarkup.  Look at
http://www.mediawiki.org/wiki/Markup_spec for how many rules are
needed on top of the SGML parsing that we need anyway.  A Javascript
app that could parse all that in real time without noticeable lag
would probably be very difficult to impossible to write.  And it's
also led pretty directly to the slowness and complexity of our current
parser, too.  It's all unnecessary: the markup doesn't need to be
easily human-readable if we have WYSIWYG.


from_name: Brianna Laugher

subject: [Commons-l] Stats on deletion

body:
On 10/08/06, Patrick-Emil Z?rner <paddyez at yahoo.de> wrote:
>
> --- Brianna Laugher <brianna.laugher at gmail.com> schrieb:
>
> > Who's in the top 10? :)
> >
> >
> http://commons.wikimedia.org/wiki/User:Kotepho/admin#Ordered_list_of_total_deletions
> >
> > Maybe we should award monthly prizes to those who (a) increase their
> > ranking by the most places, (b) perform the most deletions and (c)
> > have the largest increase on their previous month's performance.
>
> Maybe we should delete this page because it is a vast intrusion into
> every admins private life. Is WM "Big Brother"? Maybe you should
> install a camera and monitor my doings? I do not even know if the
> stuff he does is legal.

What the hell?? Admin actions on-wiki are part of their private life???

Paddy, you might be disturbed to learn of the existence of
http://commons.wikimedia.org/wiki/Special:Log ... from which all of
this data could be obtained.

Brianna


from_name: The Cunctator

body:
There's a difference between backend complexity and complexity for the user.

On 8/10/06, Simetrical <Simetrical+wikitech at gmail.com> wrote:
>
> On 8/10/06, Steve Bennett <stevage at gmail.com> wrote:
> > Ok, you're treating wikisyntax and HTML as essentially equivalent.
> > Which they're not.
>
> Some are, some aren't.  Note "beyond what actually needs to be parsed
> beyond sanitization".  Internal links must be parsed beyond
> sanitization, e.g., to generate what-links-here.  Since they're so
> common, it might make sense to keep them separate from the HTML that
> they generate.  That would be a specific decision that would have to
> be made.  But the following can certainly all be dispensed with in
> favor of XHTML:
>
> horizontal rule
> initial space (= <pre>)
> wikilists
> wikitables
> headings
> external links (probably)
> italics/bold
> everything newline-related (conversions should be dealt with on edit,
> not on render)
> HTML that's invalid XML
>
> That's already what, probably cut the number of rules needed by a
> factor of three?  More?  Then, in fact, just convert all remaining
> markup to XML, and you can handle all parsing via library functions,
> whether in PHP or Javascript or C or anywhere else.
>
> > Wikisyntax is definitely "cleaner" than HTML and closer to the
> > semantic representation of what we want to store. Storing only HTML
> > (or XHTML) really ties us to a pretty specific presentation platform.
>
> The above list consists exclusively of things that have a one-to-one
> mapping with HTML tags.
>
> > The more practical approach to me would be to layer an increasingly
> > powerful GUI over the top that allows the user to edit most wikisyntax
> > without even seeing it.
>
> The problem is the complexity of the wikimarkup.  Look at
> http://www.mediawiki.org/wiki/Markup_spec for how many rules are
> needed on top of the SGML parsing that we need anyway.  A Javascript
> app that could parse all that in real time without noticeable lag
> would probably be very difficult to impossible to write.  And it's
> also led pretty directly to the slowness and complexity of our current
> parser, too.  It's all unnecessary: the markup doesn't need to be
> easily human-readable if we have WYSIWYG.
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


body:
On 10 Aug 2006, at 5:02 PM, Jay R. Ashworth wrote:

> Then your users are perfectly welcome to use something that does
> what they need done, which is, to my understanding, the official
> position of the Mediawiki developers.

And, as I said in my initial email, they will. But that wasn't the
point of my post. As I said: "The reason I'm posting this is simply
to put forward the view that I hope WYSIWYG or some relevant variant
will be developed for Wikimedia projects in the near future, because
I think the hurdles that stop many people from participating on our
office intranet apply equally to Wikimedia projects."

In your haste to prove your self-image as an opinionated bastard of
extraordinary magnitude you completely missed my point.

> You don't know me from Adam; you're neither entitled, nor informed
> enough, to call me a prick.

Someone who says I and the people I work with are talking bullshit
and should get screwed because they want computers to work for them
instead of the other way around is entitled to the label of prick as
far as I'm concerned. By all means, be opinionated but if you're
going to use such language then get used to having it thrown back at
you.

> An opinionated bastard of extraodrinary magnitude?  Yes.  But it
> seems to me that "MediaWiki should gravitate in -- or be rewritten
> into -- something that happens to suit *my* user base's needs,
> whether that would be suitable to the WMF -- which is how your
> comments read, to me -- is *much* more presumptious than my comments.

Then you need to read a little more slowly.

Christiaan


body:
On 8/10/06, The Cunctator <cunctator at gmail.com> wrote:
> There's a difference between backend complexity and complexity for the user.

Not in this case, if we accept that a) a WYSIWYG editor is simpler for
the user but b) will be much faster to write and maintain with a
simple backend.


subject: [Wikitech-l] Break out links-How are they done?

body:
On 8/10/06, Jay R. Ashworth <jra at baylink.com> wrote:
> Again, Steve, no, you can't.  If the link says TARGET=new, I am no
> aware of any unmodified browser that will permit you to override that.
> In Firefox, you can ctrl-click it, and get it in a new tab, but there's
> no way I'm aware of to get it in *the current tab*.

I was wrong. You were right.

Steve


body:
Having said that, actually it's easy: drag and drop the link onto the
address bar. Try it!

Steve

On 8/10/06, Steve Bennett <stevage at gmail.com> wrote:
> On 8/10/06, Jay R. Ashworth <jra at baylink.com> wrote:
> > Again, Steve, no, you can't.  If the link says TARGET=new, I am no
> > aware of any unmodified browser that will permit you to override that.
> > In Firefox, you can ctrl-click it, and get it in a new tab, but there's
> > no way I'm aware of to get it in *the current tab*.
>
> I was wrong. You were right.
>
> Steve
>


body:
On 8/10/06, Jay R. Ashworth <jra at baylink.com> wrote:
> On Wed, Aug 09, 2006 at 12:57:58PM +0100, Christiaan Briggs wrote:
> > For your interest, it looks like Apple has come to the party with a
> > wiki of its own, without the need for people to learn markup language:
> > http://www.apple.com/server/macosx/leopard/wikiserver.html
>
> [ looks ]
>
> Oh, it's a wiki with a WYSIWYG editor on the front.
>
> Yeah, we've got that.

Do we? I was thinking about this. Even the wikiwyg we looked at a
couple of weeks ago essentially forces you to edit wikitext, and
separately shows it to you. Do we have anything that works like Word,
for instance?

I ask this not as a clueless user, or on behalf of people who are too
lazy to learn syntax. But as someone who does a *lot* of editing in
MediaWiki, and who finds the "spot the mistake, click edit, find the
same spot in the code, change, save" cycle far too slow. Editing would
be a hell of a lot more efficient if one could simply click on the
place to edit, and start typing. I imagine the basic cycle looking
like this:

1. Click on the text.
2. A surrounding patch of text (a sentence? a paragraph?) is "locked"
(no one else can edit it) and highlighted, and somehow rendered
"editable".
3. Edit, drag text around etc. If necessary, mark other bits of text
as being "locked" as well so you can edit them.
4. Press a commit button.

I don't know that this would work well for more complex syntax like
tables, but even if it only worked for small, local changes (like typo
fixing) it would be a major improvement.

Steve


body:
On 8/10/06, Jay R. Ashworth <jra at baylink.com> wrote:
> On Thu, Aug 10, 2006 at 07:58:29AM +0200, Steve Bennett wrote:
> > and then:
> > {{opendiv}}
> > *foo {{template2}}
> > {{closediv}}
> >
> > then MediaWiki automatically closes the div tag for you, and it doesn't work.
>
> That formatting which is opened in one included template and closed in
> a different one won't work was covered in depth here about 2 or 3 weeks
> ago; it's interrelated with whether tidy's turned on, I think; check
> the archives.

Yes, I know. My question is, is there any remotely elegant way I can
achieve what seems like a perfectly reasonable thing to me: using a
template to apply a character style to a block of text. Having to use
a table (which is the only way I could find to do it) is not imho
elegant.

Steve


subject: [Commons-l] Stats on deletion

body:
On 10/08/06, Patrick-Emil Z?rner <paddyez at yahoo.de> wrote:
>
> --- Brianna Laugher <brianna.laugher at gmail.com> schrieb:
>
> > What the hell?? Admin actions on-wiki are part of their private
> > life???
>
> Your girlfriend/wife, boyfriend/husband or employer might find exactly
> this data without going through Special:Log. Easily done an mighty
> disturbing.

I don't really get why they would be disturbed to learn that you
delete images as part of your administrator duties. If they're going
to be disturbed that you are an administrator period, or you have an
account on a wiki, well those pieces of information are already
available aside from this one page.

Wiki actions are public; that is a very basic thing that if you can't
accept, you should probably never have hit "edit" in the first place.
let alone joined a publicly archived mailing list from an email
account that has your real name on it.

> > Paddy, you might be disturbed to learn of the existence of
> > http://commons.wikimedia.org/wiki/Special:Log ... from which all of
> > this data could be obtained.
>
> I know that this exists but sorting data and making it transperent is
> what disturbs me.

Is not transparency in admin actions a good thing?

> BTW see last post.

I saw it, but considering I can't read German, it didn't do much for me.

Brianna


body:
On 8/10/06, Brion Vibber <brion at pobox.com> wrote:
> It wouldn't hurt for a little warning message on some of those special pages, I
> suspect.

That's a good idea.  I got confused by this before too.


from_name: Anthere

subject: [Foundation-l] board candidacies

body:
Hello all,

Being back from Wikimania, I have a look at the list of candidates and
here is what I see:

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

I'd like to make a very serious appeal for candidates.
I would hate to discourage some of you, but rather to be frank.

Being on the board is not a game.
It is not about changing the policies on the english wikipedia.
It is not about improving welcome templates for newbies on wikipedia either.
And it is not even about pushing the use of the german userboxes.

What we need (desperately need) is people who understand what the
Foundation is, what our needs are, where the challenges are located.

I listed some of the challenges in my presentation at Wikimania;
(http://wikimania2006.wikimedia.org/wiki/Proceedings:FD1). I have no
idea when the audio will be accessible, but I think any candidate should
at least have a look/ear to it.

What would be best are people who already know and participate to
Wikimedia Foundation issue. I could cite dozen, many of whom were at
wikimania. A couple candidated, but I also know they are controversial
so might end up not being in the top.

I would like that non english editors take the chance to run. Not being
english is certainly an handicap due to the huge number of english
voters. Naturally, if you are mostly known in one community, you'll get
a disadvantage. But if you are also a meta participant, the word can be
disseminated that you are a high quality person. Because meta people
know you and can tell about you in the local communities. You have a
chance !

I will not hide the fact that being on the board is highly frustrating.
It is a lot of work. It costs personal money. It is little rewarded. It
carries its generous load of humiliation.

But... if you care about the projects, if you care about their future,
if you care about giving a chance to the content to stay free for real,
if you care about the risk of being "adopted" by a commercial firm, if
you care about the risk of seeing the freedom being reduced to protect
what is merely a legal entity, if you care about us being an
international entity rather than being a pure american business and
professional foundation, please, do help.

Please.


subject: [Foundation-l] board candidacies


subject: [Wikitech-l] Categories

body: This is basically bug 1775: http://bugs.wikimedia.org/show_bug.cgi?id=1775


subject: [Foundation-l] board candidacies

body:
A minor point

But for Arno, absolutely all discussion pages for board candidacies on
the english wikipedia.

What are the implications in terms of international representation AND
in terms of project representation ?

ant


subject: [Foundation-l] board candidacies


body:
On 10 Aug 2006, at 5:24 PM, Jay R. Ashworth wrote:

> Expand, then, on your point, based on Wikipedia's article count and
> sustained network transfer rates.

I don't know of any way to prove this point when it comes to
Wikipedia. If people are put off by wiki markup (which I know,
anecdotally, they are) this is not going to show up in any Wikipedia
data I know of. Possibly edit clicks vs. exits?

However, I think I have enough experience trying to get people to
participate on Wikipedia and on our local intranet (which uses
MediaWiki) to be worthy of reporting. I also have my own personal
experience, which is that I don't like using wiki markup, I don't
like relearning it each time I use it, and I don't like seeing a sea
of monospaced text every time I use it. So I understand their point
of view.

In any case my point has already been answered. There are already
moves afoot to prioritise and bring some sort of WYSIWYG to MediaWiki
from what some people have said.

Christiaan


from_name: valdelli at bluemail.ch

subject: [Foundation-l] board candidacies

body:
I completely agree,
when I have seen the candidatures, I have had this first feeling:
"a lot of candidates only english speaking (with a little knowledge
of another language)".

The board should have a good communication and should be
representative...  this don't mean that the members should be
polyglot, but these are little signs... how many languages has got
Wikipedia? Why?

Ilario

----Messaggio originale----
Da: notafishz at gmail.com
Data: 10.08.06 19.58
A: "Wikimedia Foundation Mailing List"<foundation-l at wikimedia.org>
Oggetto: Re: [Foundation-l] board candidacies

On 8/10/06, Anthony <wikilegal at inbox.org> wrote:
> On 8/10/06, Anthere <anthere9 at yahoo.com> wrote:

> Internationally, it means that countries where the English
languages
> is widespread are probably going to have a greater
representation.
> Changing this would be likely be extremely difficult and/or
expensive.
>  And it's somewhat of a catch-22: Wikimedia probably won't have
very
> much representation from non-English speakers until it's easy
for
> Wikimedians of different languages to communicate with each
other, but
> until Wikimedia has more representation from non-English
speakers
> translation issues will probably remain a relatively low
priority.
>
> As for project representation, I don't think board members should
be
> representing individual projects in the first place.  Wikipedia
is by
> far the largest and most successful project, so it doesn't
surprise me
> that board candidates use that project for their discussion
pages.

I think you are missing the point entirely.
What we are asking is for this election to be representative of
the
Wiki*m*edia community in its entirety, ie. all languages and all
projects. Being on the board of the Wikimedia Foundation as
Florence
pointed out, does not mean changing policies in the English
Wikipedia,
no more than in Wikisource or the Chinese Wikipedia for that
matter.
It means seeing the greater vision, understanding, or be ready to
understand what's at stake in all projects and all languages,
making
sure the projects are able to flourish regardless of their size or
fame in the outside world. It means taking the right decisions as
to
where Wikimedia will use the money it has, the right decision on
which
partners to choose so as to allow to pursue our mission, ie.
support
free and open knowledge and access to information.


subject: [Foundation-l] board candidacies


from_name: Jean-Denis Vauguet

subject: [Foundation-l] board candidacies

references:
<ebfkoi$bup$1@sea.gmane.org> <ebflq6$fkg$1@sea.gmane.org>
	<44DB66B3.8010205@wolfmountaingroup.com>

body:
Jeff V. Merkey a ?crit :
> Anthere wrote:
>
>> A minor point
>>
>> But for Arno, absolutely all discussion pages for board candidacies on
>> the english wikipedia.
>>
>> What are the implications in terms of international representation AND
>> in terms of project representation ?
>>
>>
>
> Where do the translations go for the candidates for discussion pages? I
> assume these are left in English.
>
> I have stopped translating the lower candidate statements for Cherokee
> since I noticed the short list is out of sync with
> the main list since a lot of folks have submitted and gotten pulled
> before making the top list. Is the top list the approved candidates?
> I have translated these into Cherokee (and one from German into English).

I am currently working on that, basically creating a templates-based
system which will make the translation process easier AND allow for
discussions on Meta, not on en: or any other local wiki. Let me one or
two hours to get all this done and alive :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/foundation-l/attachments/20060810/6dd0e1c1/attachment.pgp


subject: [Foundation-l] board candidacies

body:
Jeff V. Merkey a ?crit :
> Anthere wrote:
>
>> A minor point
>>
>> But for Arno, absolutely all discussion pages for board candidacies on
>> the english wikipedia.
>>
>> What are the implications in terms of international representation AND
>> in terms of project representation ?
>>
>>
>
> Where do the translations go for the candidates for discussion pages? I
> assume these are left in English.
>
> I have stopped translating the lower candidate statements for Cherokee
> since I noticed the short list is out of sync with
> the main list since a lot of folks have submitted and gotten pulled
> before making the top list. Is the top list the approved candidates?
> I have translated these into Cherokee (and one from German into English).

I am currently working on that, basically creating a templates-based
system which will make the translation process easier AND allow for
discussions on Meta, not on en: or any other local wiki. Let me one or
two hours to get all this done and alive :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/foundation-l/attachments/20060810/6dd0e1c1/attachment-0001.pgp


subject: [Foundation-l] board candidacies

body:
Jeff V. Merkey a ?crit :
> Anthere wrote:
>
>> A minor point
>>
>> But for Arno, absolutely all discussion pages for board candidacies on
>> the english wikipedia.
>>
>> What are the implications in terms of international representation AND
>> in terms of project representation ?
>>
>>
>
> Where do the translations go for the candidates for discussion pages? I
> assume these are left in English.
>
> I have stopped translating the lower candidate statements for Cherokee
> since I noticed the short list is out of sync with
> the main list since a lot of folks have submitted and gotten pulled
> before making the top list. Is the top list the approved candidates?
> I have translated these into Cherokee (and one from German into English).

I am currently working on that, basically creating a templates-based
system which will make the translation process easier AND allow for
discussions on Meta, not on en: or any other local wiki. Let me one or
two hours to get all this done and alive :)

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


subject: [Foundation-l] board candidacies

body:
Jeff V. Merkey a ?crit :
> Anthere wrote:
>
>> A minor point
>>
>> But for Arno, absolutely all discussion pages for board candidacies on
>> the english wikipedia.
>>
>> What are the implications in terms of international representation AND
>> in terms of project representation ?
>>
>>
>
> Where do the translations go for the candidates for discussion pages? I
> assume these are left in English.
>
> I have stopped translating the lower candidate statements for Cherokee
> since I noticed the short list is out of sync with
> the main list since a lot of folks have submitted and gotten pulled
> before making the top list. Is the top list the approved candidates?
> I have translated these into Cherokee (and one from German into English).

I am currently working on that, basically creating a templates-based
system which will make the translation process easier AND allow for
discussions on Meta, not on en: or any other local wiki. Let me one or
two hours to get all this done and alive :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikimedia-l/attachments/20060810/6dd0e1c1/attachment-0001.pgp>


from_name: Alphax (Wikipedia email)

subject: [Commons-l] Stats on deletion

body:
Patrick-Emil Z?rner wrote:
> --- Brianna Laugher <brianna.laugher at gmail.com> schrieb:
>
>> Who's in the top 10? :)
>>
>>
> http://commons.wikimedia.org/wiki/User:Kotepho/admin#Ordered_list_of_total_deletions
>> Maybe we should award monthly prizes to those who (a) increase their
>> ranking by the most places, (b) perform the most deletions and (c)
>> have the largest increase on their previous month's performance.
>
> Maybe we should delete this page because it is a vast intrusion into
> every admins private life. Is WM "Big Brother"? Maybe you should
> install a camera and monitor my doings? I do not even know if the
> stuff he does is legal.
>

The stupid German laws might apply to the Toolserver which is hosted by
Wikimedia DE, but they do NOT apply to Commons, which is hosted in Florida.

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 569 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/commons-l/attachments/20060810/9d598b9f/attachment.pgp


body:
On 10 Aug 2006, at 6:33 PM, Jay R. Ashworth wrote:

> But again: the amount of wikitext markup syntax you have to carry
> around in your head to use it approaches zero more closely than
> anything else I've ever worked with.

And what you think matters not one iota when it comes to other
people's experiences. People are different from you and many of us
think it's worth catering for those differences in order to broaden
participation in Wikimedia projects.

Christiaan


body:
Sean Barrett wrote:
> Dabljuh stated for the record:
>
>> Actually I meant to be ad hominem ....
>
> Would the list admins please ban (or at least moderate) this troll?
>

Only if you complain directly. Like so...

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 569 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060810/e49ffba2/attachment.pgp


body:
Dabljuh wrote:
<snip>
> Since your statement appears to imply that you want
> constructive suggestions, here's one.
>
> Give WP:NPOV a "facts override" clause. That is,
> if something is a simple and verifiable fact, npov is
> not meant to relativate it when a majority of people
> are misinformed or simply don't like the information.
>

All attempts to determine the Truth instead of the NPOV are predestined
to be complete failures for the simple reason that the Truth is a
construct of the mind and as such necessarily subjective.
-- Loom91's First Law

Wikipedia is not the venue for negotiating ultimate truth nor the secret
history of the world. They have Usenet for that.
-- Geogre's Law

Wikipedia is about verifiable facts, not truth. If it's truth you're
looking for, Dr. Tyree's philosophy class is right down the hall.
-- Andjam's first law

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 569 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060810/9a29bf7a/attachment.pgp


from_name: David Spencer, MediaWiki User

body:
Re: Break out links-How are they done?

Thanks for all your feedback on my post about break out links.

1. I feel it is a shame that the wiki publisher does not have the option
to code break out links to external web sites. It is very easy for those
new to computers to head to a new link and forget what they originally
were looking for on the original wiki. Then they leave our wiki.

2. When I send someone to an external link from my wiki, I am not
responsible for the content of that external site. Sometimes "newbies"
may think that I created the external link page too.

3. FYI... I am a Mac user using FireFox. To make a break out link, all I
have to do is hover over the link, press lightly and choose "Open link
in new window".

4. The wiki I am developing is here  http://www.christianmedia.ca

Thanks again for all of your comments and words of wisdom. This is a
very helpful listserv!

David Spencer
Ontario, Canada

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

David Spencer wrote:
> August 8, 2006
>
> Hello:
>
> Break out links-How are they done?

Hi David,

I remember seeing this topic here a few weeks ago. The answer was that
MediaWiki will never be scripted to do break out links because break
out links are bad Web design. Web site visitors are supposed to control
that part of their own Web surfing experience, not Web site authors.

Click on a normal Web link with the *middle mouse button* and see how
your browser behaves.

Roger :-)

-------------------
From: Simetrical

They aren't.  You'd have to hack the software.  This is a deliberate
design decision, I believe: the user's browser gives them ways to
decide where to open a link, and overriding them should be
unnecessary.  Let the user decide whether they want a new window or
not.

-----
Just because I'm controversial I'll disagree. Gmail, for example,
always opens *every* external link in a new window. It works extremely
well - you never have to worry about "losing your gmail window". It
wouldn't be a bad thing if MediaWiki did similar - you're unlikely to
really want to navigate away from Wikipedia, for instance, when you
follow a link - most likely you'll read it then want to come back.

The user's browser can override any behaviour, but that's not to say
that providing good default behaviour isn't necessary.

Steve

-------

On 8/9/06, Steve Bennett <stevage at gmail.com> wrote:
> > Since we've established that you can override the suggestion provided
> > to the browser, no one's forcing anything...

I missed where we established how an average user (IE or unextended
Firefox, say, with default settings) is supposed to a) determine in
advance that a link will open in a new window/tab and b) override the
behavior and open it in the same window/tab.  I can do the latter via
a Firefox extension, but even that requires two clicks plus picking an
option out of a context menu rather than just middle-clicking.

------
On 8/9/06, Tels <nospam-abuse at bloodgate.com> wrote:
> > Mouse middle click opens the page in a new tab (!) for me in
firefox - left
> > click in the same tab. (Who wants a new browser windows, anyway?)

I tend to use new windows for new "themes" (work vs personal browsing,
Wikipedia vs organising a holiday). 2-3 browser windows is a good
total number.

> > So let _me_ decide where I open up links, and stop trying to force me.

Since we've established that you can override the suggestion provided
to the browser, no one's forcing anything...

Steve

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

For a highly interactive site, new-windows make sense... but I don't really
see it making sense for MW.

-- Ben Garney Torque Technologies Director GarageGames.Com, Inc.

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


subject:
[WikiEN-l] Article bragging (was: Re: en: well on the way to
 ... 2 million!)

body:
maru dubshinki wrote:
> On 8/9/06, David Gerard <dgerard at gmail.com> wrote:
>>> But I've always wondered something about FOLDOC; does its name come
>>> from the foldr and foldl operators in functional languages?
>>
>> Free On-Line Dictionary Of Computing.
>
> Well, I knew *that*, from looking in the en entry if nothing else. But
> c'mon. Doesn't the "On-Line" look even a little contrived?
>

Would you rather it was FODOC? :)

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 569 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060810/e960102c/attachment.pgp


subject: [WikiEN-l] Norman Technologies AfD

body:
Steve Bennett wrote:
> On 8/9/06, Rob <gamaliel8 at gmail.com> wrote:
>> Well, there's a natural reaction to anything that looks like corporate
>> advertising, but I wouldn't call it a "bias against corporations".
>>
>> I don't see anything inherently wrong with MyWikiBiz, esp. since they
>> are pretty open about what they're doing.  But I also don't think
>> Wikipedia's mission is served by cluttering up the place with articles
>> on every small consulting firm in the US. This corporation has only 26
>> employees and the only citations are a local business journal.  Is
>> this really a significant enough company to make it into an
>> encyclopedia?
>
> That definitely depends on what your definition of "significant
> enough" is. If we had room for only 10 corporations, I would say no.
> But we're not pressed for space, and unlike pure vanity articles (my
> name is Jim and I have a dog called Nelly!), this type of article
> meets a genuine need.
>

Does it? How are they unique? The following,

"Norman Technologies is the only U.S.-based private-sector I.T.
consultancy focused solely on global trade initiatives. The company is
also unique in that it provides the only non-bank representative to the
International Chamber of Commerce's Committee on Banking Technique &
Practice. The firm is also a member of the International Financial
Services Association."

uses a heap of weasel words/buzzwords/business jargon ("global trade
initiatives") which don't really mean much; and what is the
International Chamber of Commerce's Committee on Banking Technique &
Practice anyway?

> I think there is a valid viewpoint that says "Wikipedia is the sum of
> human knowledge, except for a bit of total dross that doesn't interest
> anyone". However, a genuine company with 26 full time employees that
> has been around for 5 years and does some interesting things at the
> global level is not such dross.
>

You're wrong. /Nobody cares/ about J. Random Company, manufacturer of
Gnomovision, which makes passes about compilers, even if Gnomovision is
notable[0].

> Purely and simply, is Wikipedia better off *with* this information
> than *without* it? If the answer is "without", then why? Because we
> saved a couple of kilobytes?
>

Because it's just one more article which people are going to edit war
and email OTRS about, and it's not particularly interesting or
informative; the aim of an encyclopedia is to be factual, informative
and interesting.

[0] Guess the reference...
--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 569 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060810/dc12af0b/attachment.pgp


from_name: maru dubshinki

body:
On 8/10/06, Death Phoenix <originaldeathphoenix at gmail.com> wrote:
> On 8/10/06, maru dubshinki <marudubshinki at gmail.com> wrote:
> >
> > On 8/10/06, Alphax (Wikipedia email) <alphasigmax at gmail.com> wrote:
> > > Would you rather it was FODOC? :)
> > >
> > > --
> > > Alphax - http://en.wikipedia.org/wiki/User:Alphax
> >
> > I'd rather it was FDC, so that way it is a curse word - "FDC it!" "FDC
> > you, man."
> >
>
> Oh, fsck you.

Hey, just because I don't want to be grepped and mounted and given
stds is no call to ncurses me out; just screen & background out people
who give you the stderr of rejection.

~maru
or, don't know how to make "love"


body:
On 8/10/06, Steve Bennett <stevage at gmail.com> wrote:
> I think what I was proposing would not necessarily require a
> javascript parser. I think? Instead, it would work something like
> this:
>
> 1. Engine simultaneously presents rendered output and wikitext, with
> synchronisation points between them
> 2. User edits some rendered output, transforming it purely at the
> appearance level
> 3. Page sends rendered text back, engine compares it somehow with what
> it sent, and works out the wikitext transformations required.

I see.  Yes, that would be quite possible, given an HTML-to-wikitext
converter, but also quite pointless, at least IMO.  Just ditch the
wikitext altogether ? it's served its purpose.


from_name: David Gerard

subject: [WikiEN-l] A busy article!

body:
On 10/08/06, Steve Bennett <stevagewp at gmail.com> wrote:

> http://en.wikipedia.org/wiki/2006_transatlantic_aircraft_plot
> Close to 1000 modifications and 54 footnotes, in less than 24 hours.
> Nice work, Wikipedia.

One of the raids happened just down the street from me, and I got a
photo of police outside with tape around the house half an hour ago.
I'll just go upload it and add it to the article ... there's probably
a Wikinews article that could do with it as well.

- d.


subject:
[WikiEN-l] Technical solution to bad fair use (was:Uploading
	images should be a privilige...)

body:
On 10/08/06, Steve Bennett <stevagewp at gmail.com> wrote:

> > So the German Wikipedia will never be able to fulfill its mission?

> I think Wikipedia's mission is sufficiently open that it would never
> be a question of saying "our mission is now fulfilled". I do believe
> that EN fulfils its mission better than DE when it comes to this
> issue, yes.

en: operates as if work is under US law and somewhat under UK law; de:
assumes a majority of its contributors will be in Germany, so operates
as if work is also under German law. Which may be overly conservative
(though I think it's a good idea Commons operates under very
conservative rules for maximum international usability), but probably
makes sense in that case.

It does detract from what can be depicted in de:, which will reduce
the usefulness of the resulting encyclopedia - e.g. my favourite
example is that [[Xenu]] on en: would be significantly diminished
without the single existing sample of the word "Xenu" in Hubbard's own
handwriting - and there's also the moral issue of asserting that our
shared culture should morally be usable when talking about it, even
with odiously overextended copyright laws to deal with - e.g. Jimbo's
kind offer to the National Portrait Gallery to sue and be damned
(since which they've been rather quiet). It's all a tricky one.

- d.


body:
On 10 Aug 2006, at 7:13 PM, Jay R. Ashworth wrote:

> Well, I dunno; I've made a reasonably comfortable living for the
> last two decades exercising professional judgement about software
> design, so I suspect my opinions are neither *merely* opinions, nor
> worthless.

I meant that your opinion doesn't change people's experience. Their
experience is what it is. It doesn't matter to me or anyone else that
you think our experience is "bullshit." To say such a thing is
meaningless and indicates that you live in a self-aggrandising
fantasy world. I can't help that.

> Well, your original argument actually soudned like it was as much
> concerned with catering to *non* WMF projects, to me

That's probably be because you choose to read into people's words
whatever you want to hear. I couldn't have been more explicit about
why I wrote what I wrote and I've already reiterated once.

Christiaan


from_name: Delphine Ménard

subject: [Foundation-l] board candidacies

references:
<ebfkoi$bup$1@sea.gmane.org> <ebflq6$fkg$1@sea.gmane.org>
	<71cd4dd90608101016y80834albe8cb906c2bc5c@mail.gmail.com>

body:
On 8/10/06, Anthony <wikilegal at inbox.org> wrote:
> On 8/10/06, Anthere <anthere9 at yahoo.com> wrote:

> Internationally, it means that countries where the English languages
> is widespread are probably going to have a greater representation.
> Changing this would be likely be extremely difficult and/or expensive.
>  And it's somewhat of a catch-22: Wikimedia probably won't have very
> much representation from non-English speakers until it's easy for
> Wikimedians of different languages to communicate with each other, but
> until Wikimedia has more representation from non-English speakers
> translation issues will probably remain a relatively low priority.
>
> As for project representation, I don't think board members should be
> representing individual projects in the first place.  Wikipedia is by
> far the largest and most successful project, so it doesn't surprise me
> that board candidates use that project for their discussion pages.

I think you are missing the point entirely.
What we are asking is for this election to be representative of the
Wiki*m*edia community in its entirety, ie. all languages and all
projects. Being on the board of the Wikimedia Foundation as Florence
pointed out, does not mean changing policies in the English Wikipedia,
no more than in Wikisource or the Chinese Wikipedia for that matter.
It means seeing the greater vision, understanding, or be ready to
understand what's at stake in all projects and all languages, making
sure the projects are able to flourish regardless of their size or
fame in the outside world. It means taking the right decisions as to
where Wikimedia will use the money it has, the right decision on which
partners to choose so as to allow to pursue our mission, ie. support
free and open knowledge and access to information.

A good wikipedian or wikisourcian does not automatically make a good
board member. And vice versa. We are not electing people on the basis
of their number of edits or their influence in the projects, but
rather on a program they might have concerning the organisation, to
structure it, better it and make it realize its potential while
keeping in mind its real responsibilities.

I sincerely hope that the international and cross project community
will get organized and vote on this election, so as to balance the
natural weight of the English Wikipedia and make sure that the person
elected on the board has the skills necessary to the position.Whether
they are or not from the English Wikipedia is indeed, irrelevant.

Delphine
--
~notafish


subject: [Foundation-l] board candidacies


subject: [Foundation-l] board candidacies

body:
On 8/10/06, Anthere <anthere9 at yahoo.com> wrote:

> I listed some of the challenges in my presentation at Wikimania;
> (http://wikimania2006.wikimedia.org/wiki/Proceedings:FD1). I have no
> idea when the audio will be accessible, but I think any candidate should
> at least have a look/hear to it.

http://wikimania2006.wikimedia.org/wiki/Archives#Florence_Devouard:_Wikimedia_Foundation:_building_in_diversity

It's here.

Delphine
--
~notafish


subject: [Foundation-l] board candidacies


body:
On 8/10/06, Steve Bennett <stevage at gmail.com> wrote:
> If you "ditched the wikitext" you would end up storing metadata in
> some other form, like additional XHTML attributes, comments or
> something. Meaning a whole new grammar to define?

A whole new *grammar* to define, to a point, but no need to define a
*syntax*, because it would all use XML syntax.  Not only is that
simple (and, ergo, fast) to parse, there are parsers available for it
in virtually any language you want.  What's more, client-side parsing
would take less time than for *any* possible nonstandard syntax,
because major browsers have built-in XML parsers that are made
accessible to Javascript: http://www.w3schools.com/xml/xml_parser.asp.
 These are, of course, written in a language like C, which would
execute probably 50 to 1,000 times faster than equivalent Javascript
code.

(For those who don't quite get what XML is, it basically means that
instead of [[Target page|displayed text]] we'd have something like
<wikilink target="Target page">displayed text</wikilink>.  Of course,
you won't have to look at it.  ;) )


subject: [Commons-l] Stats on deletion

body:
Patrick-Emil Z?rner wrote:
> --- "Alphax (Wikipedia email)" <alphasigmax at gmail.com> schrieb:
>> The stupid German laws might apply to the Toolserver which is hosted
>> by
>> Wikimedia DE, but they do NOT apply to Commons, which is hosted in
>> Florida.
>
> Apart from the fact that if German laws are stupid or not you are
> totally beside the point. BTW your laws in your country are stupid too
> (just to prove the point that arguments like that are useless).
>
> I noticed that if people point out legal infringements people argue
> 1) The uploader is liable
> 2) The servers are in Florida
> They choose what suits them best.
>
> Fact is that if you do not care about showing your ass in public there
> are still people that do. I see no argument for not respecting other
> peoples behaviour in the internet/in public. Give an argument why
> these statistical evaluations are so important for the project and why
> we can not do without. Otherwise I would like to see the page deleted.
>

In accordance with Sharia law (in effect in Iran, Syria, Saudia Arabia
etc.) I will start deleting all images which portray people.

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 569 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/commons-l/attachments/20060810/2f6e4acc/attachment.pgp


from_name: Steve Bennett

body:
On 8/10/06, Jay R. Ashworth <jra at baylink.com> wrote:
> Well, I think the other guy's answer was "sure, you can use a div, you
> just can't open the div in one template and close it in a different
> one."

Yeah, and since nested templates apparently don't work, the end result
is divs aren't going to work.

> IOW: I think that elegant may be too much to ask at this point.
>
> I don't like putting HTML in my wikitext either, but I think you're
> gonna have to.

It's not so much a question of not wanting to pollute my wikitext with
HTML, it's more a question of actually wanting to reduce the amount of
wikitext and wanting to gain some modularity. I really want to use a
template to mark some text as having a certain attribute, then display
that attribute some particular way (ie, grey, small text on a pale
grey background or something).

I guess the most elegant way would be to define a CSS class somewhere,
then just do
.....

This all makes me think that templates trying to be "clean" by
refusing to leave dangling tags is probably going beyond what they
were designed for - straight text substitution.

Steve


subject: [WikiEN-l] A busy article!

body:
On 10/08/06, Steve Bennett <stevagewp at gmail.com> wrote:
> http://en.wikipedia.org/wiki/2006_transatlantic_aircraft_plot
>
> Close to 1000 modifications and 54 footnotes, in less than 24 hours.
>
> Nice work, Wikipedia.

I rode herd on it for a few hours this morning - it's remarkable how
much can be achieved just by insisting on sources. Most of those 54
footnotes could be cleaned up and merged together, though - there's no
reason to cite a dozen news stories saying the same thing...

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


from_name: Edward Z. Yang

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

Simetrical wrote:
> (For those who don't quite get what XML is, it basically means that
> instead of [[Target page|displayed text]] we'd have something like
> <wikilink target="Target page">displayed text</wikilink>.  Of course,
> you won't have to look at it.  ;) )

More like <mw:a href="Main Page">Main Page</mw:a> with namespaces,
because we'd want to mix it with XHTML.

Heck, we should have done that for <mw:nowiki>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE28wUqTO+fYacSNoRAo0lAJ9TdkPn36l4nFL4ghzl0UPzjXub0QCdFTPc
1G9QgawtWOcE2OtrIxweSIg=
=rjA3
-----END PGP SIGNATURE-----


subject: [WikiEN-l] Guardian article about Wikipedia

body:
David Gerard wrote:
> On 09/08/06, Rob <gamaliel8 at gmail.com> wrote:
>
>> Does anyone really call it "wiki-crack"?
>
>
> Presumably Raul did. I'm sure I've used the term too.
>

"To pinch a quote from David Gerard, your first puff of wikicrack's
free." -- Rob Church

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 569 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060810/61ccd569/attachment.pgp


from_name: Plyd

body:
On 8/10/06, cohesion <cohesion at sleepyhead.org> wrote:
> When you are designing the UI people really need to think about
> specifics, sure having a bold button would be easy to make something
> bold, but what would be the easiest way to fill in {{Taxobox}}. That
> is a hard question, but I can guarantee you trying to mimic the
> formatting toolbar in Word is not the answer.

The example of filling a template is not, imho, very difficult.
We can easily imagine a box opening and asking for every field of the
template. Click "insert" and hop, done :D

Plyd


body:
On 8/10/06, Brion Vibber <brion at pobox.com> wrote:
> It takes some time for the queue to run through and update all entries,
> especially when the queue is already full from some widely-used template being
> edited.
>
> Please learn patience. :)

Oh, sorry, I wasn't complaining that the update wasn't happening fast
enough, I simply thought that it wasn't happening at all. I'll check
back tomorrow and see if it's updated then.

(in other words, what JRA said)

Steve


body:
On 8/10/06, cohesion <cohesion at sleepyhead.org> wrote:
> That would be nice, and I would consider that a UI improvement, but
> not really in the same direction as wysiwyg editing. Personally, I am
> not convinced that wysiwyg editing is as simple a process as people
> think. Sure it would be nice to let anyone edit as easily as they do
> in Word, but Word doesn't have templates, and wikilinks, and wikilinks
> with alternate text.

Word has all those things, and much more besides, like floating text
frames, headers and footers, flexible section numbering (flexible
sections for that matter), columns, all kinds of fancy interactions
between pictures and text, a drawing mode, etc etc. MediaWiki ain't
got nothing on Word, trust me :)

> When you are designing the UI people really need to think about
> specifics, sure having a bold button would be easy to make something
> bold, but what would be the easiest way to fill in {{Taxobox}}. That
> is a hard question, but I can guarantee you trying to mimic the
> formatting toolbar in Word is not the answer.

IMHO, the formatting toolbar we have is almost useless. It helps the
absolute newbie carry out the simplest tasks, and that's it - for
anyone else, it's faster typing '''foo''' then typing foo, selecting
it, and pressing the bold button. OTOH, the one piece of syntax I
struggle to remember is tables, and there's no assistance there.

I don't know exactly how far it's possible to go in javascript, but
using ctrl+b for bold, ctrl+k for wikilinks etc would be great. You
know, as a minimal solution, if it was possible to select some text on
the screen, and have an edit box appear with the corresponding
wikitext that you could edit, that would still be a significant step
forward. For that to happen, we'd really need MediaWiki to be spitting
out pointers in its output that the GUI could use to match up source
and rendered text.

> When people start to edit a wiki there is some learning they have to
> do, no matter how easy you make it. The set of skills people need to
> edit a word document are not all the skills they need, even at a
> conceptual level, to edit a wiki. They will have to learn new

Yes...but everyone already knows how to edit a word document. Making a
wiki usable by someone with no new skills would be a good thing.

> concepts. Now, that's not to say that the system we have is perfect,
> having to find the text once, then click edit and find it again is a
> good example, and some of the obvious formatting things (bold etc)
> could actually use standard UI, but there is a lot of stuff that is
> honestly conceptually new.

Like templates. And that's about it. There's nothing remotely
conceptually new about a piped wikilink.

> Dealing with that is a difficult problem, but I'm not sure if the
> wikiwyg project is being very useful in that direction.

It's easier to locate the wikitext corresponding to certain output
with wikiwyg than without it.

Steve


from_name: Brion Vibber

subject:
[Wikitech-l] 404 on en.wikipedia.org: Server-side HTTP header
 instead of client-side meta-refresh?

body:
Nick Jenkins wrote:
> If I go to http://en.wikipedia.org/Tokyo (note the missing "/wiki"), I get a
> 404 page that contains a 5 second-client side refresh tag like so: <meta
> http-equiv="Refresh" content="5; URL=http://en.wikipedia.org/wiki/Tokyo">
>
> Is there any chance we could follow the great example of the PHP folks, and
> immediately give the user what they really want (e.g. http://php.net/date ,
> which instantly shows the user the content of the
> http://php.net/manual/en/function.date.php page) ?

I nixed that because then you've got scary unstable URLs being linked to. The
URL system may change, potentially dramatically so, and they'll no longer work.
(But I'm a bit of a stickler about stable URLs on articles.)

The PHP manual example is particularly dangerous because they don't even issue
an HTTP redirect, it just spits the content right back. Bad for caching and for
linking.

-- 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/20060810/624c72ac/attachment.pgp>


from_name: Aphaia

subject: [Foundation-l] Willy on Wheels and ISP Reporting Changes

references:
<44D7498A.3010505@wolfmountaingroup.com>
	<DAF157A5-073B-4D78-B43F-EDF4FD927B0B@ctelco.net>
	<44D76104.9090405@wolfmountaingroup.com>
	<B9449F9C-0AD2-4EFC-9C85-3ADE9FD6E399@ctelco.net>
	<44D77408.8050202@wolfmountaingroup.com>
	<44D77C24.3050603@wolfmountaingroup.com>

body:
I ask anyone on the project, because Mr. Merkey is now not a part of
our community as far as I know, please ignore this off topic thread
and not reply you to save other editors' time.

Or please explain what is relevant to our project and the organization
which supports it.

Please,

On 8/8/06, Jeff V. Merkey <jmerkey at wolfmountaingroup.com> wrote:
> Jeff V. Merkey wrote:
>
> >Fred Bauder wrote:
> >
> >
> >
> >>>
> >>>
> >>>
> >>>
> >>I chickened out when I connected to those. But let's keep talking
> >>about them.
> >>
> >>Fred
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> Fred,
>
> I checked on arrangements and if the foundation is interested in an
> appliance, I will pick up the costs for it and
> donate it to the Foundation at no cost. My contribution to Wikimedia
> this year if they wish to use it.
>
> Jeff
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>

--
Kizu Naoko
  Wikiquote: http://wikiquote.org
  * vivemus, mea Lesbia, amemus *


body:
On 8/10/06, Christiaan Briggs <christiaan at yurkycross.co.uk> wrote:
> However, I think I have enough experience trying to get people to
> participate on Wikipedia and on our local intranet (which uses
> MediaWiki) to be worthy of reporting. I also have my own personal
> experience, which is that I don't like using wiki markup, I don't
> like relearning it each time I use it, and I don't like seeing a sea
> of monospaced text every time I use it. So I understand their point
> of view.

I quite agree. Where I work uses a mediawiki. The software developers
have no problem with it (although I had to explain a few concepts to
them that they hadn't come across by themselves), but the sales,
marketing and support people are much less comfortable with it, and
make much fewer strides beyond "put this text where someone told me to
put it".

MediaWiki does *not* have a great user interface. It's ok, and it's a
hell of a lot better than the shots I've seen of the original
Wikipedia. But it could be a lot better. I don't have many
constructive suggestions to make for the moment, but I could start by
suggesting that getting metadata about pages out of the page text
itself (categories, interwikis and redirects come to mind), would be
an improvement.

But until I'm in a position to really help, I'll try and keep a lid on it :)

> In any case my point has already been answered. There are already
> moves afoot to prioritise and bring some sort of WYSIWYG to MediaWiki
> from what some people have said.

It's going fairly slowly.

Steve


subject: [WikiEN-l] A busy article!

body:
http://en.wikipedia.org/wiki/2006_transatlantic_aircraft_plot

Close to 1000 modifications and 54 footnotes, in less than 24 hours.

Nice work, Wikipedia.

Steve


body:
On 8/10/06, Nyenyec N <nyenyec at gmail.com> wrote:
> > Don't fall into the trap of thinking that *every* fair image has some free
> > twin that could replace it. In the cases of CD covers or images of Superman
> > or whatever, it's just no the case. To fulfil our mission, we're always
> > going to need fair use images.
> >
> > Steve
>
> So the German Wikipedia will never be able to fulfill its mission?

I think Wikipedia's mission is sufficiently open that it would never
be a question of saying "our mission is now fulfilled". I do believe
that EN fulfils its mission better than DE when it comes to this
issue, yes.

Steve


body:
On 10/08/06, Kirill Lokshin <kirill.lokshin at gmail.com> wrote:
> On 8/10/06, jkelly at fas.harvard.edu <jkelly at fas.harvard.edu> wrote:

> >  To what extent are we duplicating effort or competing with Wikinews here?  Are
> > we doing something substantially different?

> We're citing everything to external sources, for one.  The WikiNews
> policy of allowing "original reporting" basically makes their articles
> unsuitable for direct copying to Wikipedia, which means that we have
> to write our own if we think the topic deserves an encyclopedia entry
> rather than merely a news report.

Yep. I've just added my photo to the Wikipedia and Wikinews articles
(original photojournalism! and then there were the other five
photojournalists on the corner as well) and I'm about to write up what
I saw this morning. And [[User:Arkady Rose]] got some shots of the
helicopters overhead around the time of the actual raid, and I'll add
those and note down what she saw as well for the Wikinews article. But
only the photos would be suitable for Wikipedia.

- d.


from_name: Will

subject: [WikiEN-l] A busy article!

body:
Well, that's what you get with Breaking News current events, such as the
Tsunami, or possibly 9/11.


from_name: Phil Sandifer

subject: [WikiEN-l] MyWikiBiz

body:
On Aug 10, 2006, at 3:31 AM, Steve Bennett wrote:
> Heh, nice thought. When you think about it, if an academic's mission
> is to spread knowledge about some topic, writing a Wikipedia article
> or two would probably be a lot more effective than writing a book
> which very few people will ever read.

The problem is that, generally speaking, an academic's mission is to
engage in research. Original research, specifically.

-Phil


from_name: Brianna Laugher

subject: [Commons-l] Stats on deletion

body:
Also note:

http://en.wikipedia.org/wiki/Wikipedia:List_of_Wikipedians_by_number_of_edits
http://en.wikipedia.org/wiki/Wikipedia:List_of_administrators_by_edit_count
http://en.wikipedia.org/wiki/User:NoSeptember/crat_stats (bureaucrat
statistics rather similar to what we were doing on commons - breaking
up type of priveleged action)
even look at this!
http://stats.wikimedia.org/wikispecial/EN/TablesWikipediaCOMMONS.htm
I think it's quite out of date... but it exists.

As it does for all projects, including de.wp:
http://stats.wikimedia.org/EN/TablesWikipediaDE.htm

As I said on the deletion request... all the information - totals - is
available on Interiot's edit tool
http://tools.wikimedia.de/~interiot/cgi-bin/count_edits?user=Pfctdayelise&dbname=commonswiki_p
. The totals are not opt-in.

And the data is even there for de.wp!
http://tools.wikimedia.de/~interiot/cgi-bin/count_edits?user=Duesentrieb&dbname=dewiki_p

So I think this is really nothing new.

Brianna

On 10/08/06, odder <odder.wiki at gmail.com> wrote:
> 2006/8/10, Matt Brown <morven at gmail.com>:
>
> It's my first mail here, on commons-l, so hello all :)
>
> > Part of being a Wikipedia user is that your actions are public.  Part
> > of being a Wikipedia administrator - a voluntary position nobody is
> > obliged to accept or keep - is public oversight.
>
> > -Matt
>
> Just a small thing:
>
> http://tinyurl.com/hsyjs
> http://tinyurl.com/hdf5b
>
> and a link with all statistics of admin activity on pl:
> http://tinyurl.com/l5fd7
>
> I see no reason for deleting this page.
>
> --
> odder
> _______________________________________________
> Commons-l mailing list
> Commons-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/commons-l
>


from_name: Walter Vermeir

subject: [Foundation-l] board candidacies

body:
Delphine M?nard schreef:
> On 8/10/06, Anthere <anthere9 at yahoo.com> wrote:
>
>> I listed some of the challenges in my presentation at Wikimania;
>> (http://wikimania2006.wikimedia.org/wiki/Proceedings:FD1). I have no
>> idea when the audio will be accessible, but I think any candidate should
>> at least have a look/hear to it.
>
> http://wikimania2006.wikimedia.org/wiki/Archives#Florence_Devouard:_Wikimedia_Foundation:_building_in_diversity
>
> It's here.
>
> Delphine

And this is a compilation from the board discussion and a very large
part of the presentaton of Anthere with parts that is about the board
and the elections.

http://tinyurl.com/rdnxu - Ogg Vorbis 11,9Mb 32min
http://tinyurl.com/s2j66 - Webbased Player playing the same file

--
Contact: walter AT wikizine DOT org
Wikizine.org - news for and about the Wikimedia community


subject: [Foundation-l] board candidacies


body:
The interesting thing about this conversation is that I'm employed
precisely to stop people like Christiaan and JRA from having to talk
to each other.

Steve

On 8/10/06, Christiaan Briggs <christiaan at yurkycross.co.uk> wrote:


body:
On 8/10/06, Simetrical <Simetrical+wikitech at gmail.com> wrote:
> So does anyone see any reason to keep wikisyntax at this point, beyond
> what actually needs to be parsed beyond sanitization?

Ok, you're treating wikisyntax and HTML as essentially equivalent.
Which they're not.
For example, [[Foo]] and [http://en.wikipedia.org/wiki/Foo Foo] both
convert to Foo in a
given context, but they're not "the same". Maybe their difference
isn't important either? Hard to say.

Wikisyntax is definitely "cleaner" than HTML and closer to the
semantic representation of what we want to store. Storing only HTML
(or XHTML) really ties us to a pretty specific presentation platform.
By all means avoid the user having to see the wikisyntax as much as
possible, but don't make the choice "HTML or GUI".

The more practical approach to me would be to layer an increasingly
powerful GUI over the top that allows the user to edit most wikisyntax
without even seeing it. Items that can't be edited (for the sake of
argument, tables) would simply become atomic - there's a table there,
but you can't edit it. You can delete it, you can copy it, you can
paste it - but you can't edit it. If you want to edit it, you need to
switch into a "hardcore" mode, where you actually see the code.

The obvious downside in any such system though is that the generated
wikitext would necessarily look different from handcoded wikitext, and
in our current MediaWiki system, every difference between two
revisions is significant...

Steve


subject: [WikiEN-l] A busy article!

body:
On 8/10/06, Andrew Gray <shimgray at gmail.com> wrote:
> I rode herd on it for a few hours this morning - it's remarkable how
> much can be achieved just by insisting on sources. Most of those 54

Yeah, I noticed that the comment that you had to taste your own breast
milk if you wanted to take it on board was repeated twice, and sourced
to two different sources, and neither of them actually said that!
Verifiability is nice sometimes...

> footnotes could be cleaned up and merged together, though - there's no
> reason to cite a dozen news stories saying the same thing...

Yes and no. If they're all AAP or Reuters-derived, then no. Other
times I like to provide links to *every single* source, if there
aren't ridiculously many of them.

Steve


from_name: Andrew Gray

subject: [WikiEN-l] A busy article!

body:
On 10/08/06, Steve Bennett <stevagewp at gmail.com> wrote:
> On 8/10/06, Andrew Gray <shimgray at gmail.com> wrote:

> > footnotes could be cleaned up and merged together, though - there's no
> > reason to cite a dozen news stories saying the same thing...
>
> Yes and no. If they're all AAP or Reuters-derived, then no. Other
> times I like to provide links to *every single* source, if there
> aren't ridiculously many of them.

The problem is... well, every general news story about this lists,
say, six citable facts (number of arrests, hypothesis of number of
planes, Reid quote, flight cancellations, type of explosive) out of a
dozen things that we need to cite; it's just they don't all say the
same six. And when someone says "we need a cite for "up to ten
aircraft", that gets cited from the news story you're reading, which
might not be one of the news stories already used as a source which
says that.

I think at one point we had two seperate sources for the same quote,
two others for a single figure, because it got listed in two parts of
the article. That sort of thing.

One source alone is a bad idea, yes, but there's no need to cite eight
instead of two. I'll have a hack at the article tomorrow and
rationalise some of the sources.

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


from_name: Julien Lemoine

subject: [Wikitech-l] Wikipedia Suggest

body:
Hello,

I wrote a new version of Wikipedia suggest (version 0.3) which includes :
 - an option to enable usage of MemoryQuery (-m) in TcpQuery command,
you can also specify the number of threads that you want.
 - an heuristic to choose the correct redirection to keep (based on
similarity with the query)
 - handling of articles with different capitalization (keep all
different capitalizations)
 - includes the patch of Nick Jenkins.

I will regenerates the index for english/french on suggest.speedblue.org
tomorrow. You can download the sources now on :
http://suggest.speedblue.org/tgz/wikipedia-suggest-0.3.tar.gz

I also look the mysql tables (page and pageslink), but I have two
questions :
 - is there a way to get the target of a redirection ? There is a
is_redirected flag on the page table, but I do no see information about
the redirected article
 - is the url available in a table ?

If I can have these two informations on the tables, I will write a SQL
version of the analyzer. If these two informations are not available,
what will be the best way to write a analyzer for Wikipedia ? (work on
the pages-articles.xml
<http://download.wikipedia.org/enwiki/20060717/enwiki-20060717-pages-articles.xml.bz2>
file ? ).

Best Regards.
Julien Lemoine


from_name: Warhog (aja Julian Fleischer)

body:
in firefox and konqueror it is possible, i think it should be possible
this way in MSIE too, but i guess very few people are aware of it.

you can dran and drop any link to any tab/window where you want it to be
opened. That way you can override "open in new window". In MSIE i thin
kyou have to drag it to the adressbar or the title-bar of the window,
i'm not sure. in KOnqueror and Firefox you simply pull it onto the
current tab. If you configured firefox to not show only one tab i don't
know what to do. I think pull it to the locationbar will help there to.

Jay R. Ashworth schrieb:
> On Wed, Aug 09, 2006 at 06:21:37PM +0200, Steve Bennett wrote:
>>> So let _me_ decide where I open up links, and stop trying to force me.
>> Since we've established that you can override the suggestion provided
>> to the browser, no one's forcing anything...
>
> Again, Steve, no, you can't.  If the link says TARGET=new, I am no
> aware of any unmodified browser that will permit you to override that.
> In Firefox, you can ctrl-click it, and get it in a new tab, but there's
> no way I'm aware of to get it in *the current tab*.
>
> If you know of anything, please share.
>
> Cheers,
> -- jra


from_name: Anna

body:
----- Original Message -----
From: "Brianna Laugher" <brianna.laugher at gmail.com>
To: "Wikimedia Commons Discussion List" <commons-l at wikimedia.org>
Sent: Wednesday, August 09, 2006 10:24 AM
Subject: Re: [Commons-l] Deletion of still-used images

In 08/08/06, Patrick-Emil Z?rner <paddyez at yahoo.de> wrote:
>
> --- Brianna Laugher <brianna.laugher at gmail.com> schrieb:
>
> > On 08/08/06, Artur Fija?kowski <wiki.warx at gmail.com> wrote:
> > > I fully agree - every day I'm trying to see all newimages on
> > > special:newimages and I try to delete all copyvio-looking images.
> > I
> > > know that it's a bit agressive, but I think, that blanking user's
> > > upload is the best method of saying ''hi, something is wrong with
> > your
> > > images''.
> >
> > Er, I hope you write them a note explaining what they're doing
> > wrong?!
> > Simply deleting someone's images tells them nothing about what
> > mistakes they're making, and therefore does not help them to avoid
> > making them in the future.
>
> Tell people twice? There is a big fat notice telling you what to do
> when you upload an image. The consequences are known (BTW red and even
> fat letters):

People are stupid and don't read instructions; Wikimedians are no
exception. Of course you don't _have_ to (explain what they're doing
wrong). But if you want to stop the root behaviour, I think it's more
helpful than not explaining. Because if you're already at the point
where you need to delete someone's work, it's pretty obvious they
didn't read/understand the instructions.... isn't it?

Brianna

That's very true. Some people don't even bother to get in touch with the
admin who posted the warning and ask for more explanations, but if you dare
to delete his/her wrong images then they rush to your talk page to moan, so
I think warnings are useful in the end, sooner or later the uploaders react
and break their mute attitude and try to contact with the person who warned
them.

Anna.
_______________________________________________
Commons-l mailing list
Commons-l at wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/commons-l