body:
On Sun, Jun 25, 2006 at 02:44:10PM -0400, Jay R. Ashworth wrote:
> On Sun, Jun 25, 2006 at 12:26:36PM -0600, Chad Perrin wrote:
>
> > While we're at it, we might consider whether to allow line wrapping, but
> > provide a line-wrap indicator syntax to show that what appears on a
> > separate line of the page is in fact meant to be part of the same
> > semantic line of code.  I'm thinking of examples such as the plus-syntax
> > used on websites such as perlmonks.org.  An example of this usage might
> > look something like this:
> >
> >  |while (<>) {
> >  |  if ( $scalar_foo <= $scalar_bar ) && ( $scalar_bar <= $array_qux[2]
> > +|) {
> >  |    print;
> >  |  }
> >  |}
> >
> > . . . where the plus character is typically some differentiating color,
> > such as red.  That may or may not be appropriate for something like
> > MediaWiki -- I only bring it up as something to consider.
>
> Mutt does that with wrapped URL's in my mail.  It's a pain because you
> can't then paste the copied text in without having to fix it.
>
> On one-line URL's, this is practical.
>
> If it's a couple hundred lines of code, maybe not so much.

I, too, use mutt, and have the same issue from time to time.  It's
easily solved with XHTML and CSS, though: use block elements and styles
to position the plus signs (or whatever) in a separate block from the
stuff you want to wrap, or use inline element styles to attach some
visual cue like a left-side or right-side thin and understated border,
or use a left-aligned background image on wrapped lines, or turn the
block of code with line-wraps into a link to a plaintext file without
linewraps, or . . .

One of the benefits of rendered markup with styles is that it allows you
to use something other than content characters within the same block of
content as visual presentation, thus allowing for visually associated
characteristics that are not associated as closely according to what
your mouse will highlight for copying and pasting.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Ben Franklin: "As we enjoy great Advantages from the Inventions of
others we should be glad of an Opportunity to serve others by any
Invention of ours, and this we should do freely and generously."


list: wikitech-l

source: pipermail-mbox

from_name: Chad Perrin

subject: [Wikitech-l] Wikimarkup request: -- to em-dash

body:
On Sun, Jun 25, 2006 at 08:47:37PM +0200, Andrew Dunbar wrote:
> On 6/23/06, Jay R. Ashworth <jra at baylink.com> wrote:
> > On Thu, Jun 22, 2006 at 12:21:28PM -0600, Chad Perrin wrote:
> > > Would requiring spaces on either side of the double dash before
> > > converting it into an emdash improve the parsing behavior any?
> >
> > Please don't.
> >
> > <snob type=typography>
> > Em dashes are properly set in English text without spacing on either
> > side, though the ASCIIography of this usage is much less picky.
>
> Can you provide a reference for this? Also can you be
> sure this is the only style and that it doesn't vary by
> style guide, by publisher, by country, by newspaper vs
> novels, etc.
> The reason I ask is that I've been studying casually how
> they are typeset in books as part of my thinking about
> an XML format for e-texts. I have seen so many cases
> both with and without spaces that I've been pondering
> whether it would best be handled as a style issue.

I think it most definitely is best handled as a style issue, or perhaps
as a per-document or per-content-block formatting issue.  I still have
my preference for spaces, though.  They make it look less like an
oversized hyphen.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The ability to quote is a serviceable
substitute for wit." - W. Somerset Maugham


list: foundation-l

from_name: Gregory Maxwell

subject: [Foundation-l] Open source CRM needed for Wikimedia

body:
On 6/25/06, Angela <beesley at gmail.com> wrote:
> I'm not buying into the arguments Brad and his friends are putting
> forward for Wikimedia to turn away from it's reliance on open source
> software. Especially when that decision is being taken by some unknown
> group of people with no community or Board consultation about possible
> alternatives.
>
> So, I'm asking if people can suggest to Brad some open source (fully
> open source, not "can be open source if you don't need the security
> package") CRM software
> (http://en.wikipedia.org/wiki/Customer_relationship_management). I've
> no doubt that people on this list have contacts in the free/OS
> software world, so I'm hoping you can now use those contacts to help
> with this.

Will you also be removing MacOS from Jimmy's laptop, from Brion's G5?
Will we be replacing IOS in our Cisco routers with Linux PCs running
XORP?  The folding at home client that consumes large amounts of the
CPU time on our servers is proprietary as well
(http://fah-web.stanford.edu/cgi-bin/main.py?qtype=userpage&username=wikimedia%2Eorg).
The hard disks which store our data in our servers have proprietary
firmware too... Much of our donations come through Pay-pal... Yet no
one outside of paypal has access to paypal's source!  I could go on
all day and make hundreds of examples. They'd all by stupid, but so is
an objection about some internal piece of web based management
software.

The fact is that none of these things where we currently use
proprietary software are in the critical path for creating or serving
Wikipedia content, they are infrastructure.

For the same reasons that most of the world should prefer Free
infrastructure we should too, however, we should not forget that the
purpose of the Wikimedia Foundation is not "to be an example of Free
Software at all costs".  The use of a quasi-free CRM would not harm
our neighbors, it would increase the prevalence of proprietary file
formats, it would not cause our readers, donors, editors, or even
employees to need to run any more proprietary software on their system
(SugarCRM is web based, like Paypal).

SugarCRM is also, by far, the most open of all the available CRM
packages... Were we not interested in using open software we would be
using something like Blackbaud's The Raiser's Edge which is software
targeted at funddrive management... It's very powerful stuff with the
right tools to operate multi-million-dollar fundraisers. However, it
also would require building a parallel Microsoft infrastructure.

So...
1) We already use proprietary web based software for critical
infrastructure which impacts our donors (we force them to use the
remote proprietary software as well).
2) We already installed and run proprietary software on our servers
(folding at home for example)

3) But you're making a fuss over running a single piece of non-free
web based internal software which will not touch our readers, donors,
or editors... and only touch the staff and perhaps some volunteers in
the same manner that Paypal does. When we already run proprietary
software on our servers.

So why is it that you are making a big deal about CRM, delaying a
critical part of our infrastructure which I suspect we desperately
need, when instead we could be calling out for a better alternative to
Paypal (which not only is non-free but has a public history of
unethical behavior and which costs us a lot of money)?   Or why not
first ask Tim to remove the proprietary electrical power sucking code
he is running on our cluster?

With comments like "Brad and his friends" and non-reality based claims
"Wikimedia to turn away from it's reliance on open source software"
you end up looking as contemptuous towards Brad as I am towards
Erik...  Now *that* is shameful.

In any case, if the stupid politics continue on this I'm sure I can
find someone to run SugarCRM on their own equipment and sell Wikimedia
Foundation webbased access to it for a small premium.  Doing so would
make it less open and more costly but when does reality have anything
to do with rhetoric?


list: wikimedia-l


from_name: Anthere

subject:
[Foundation-l] Opinions/suggestions for "outside" members of
	the board?

body:
Gerard Meijssen wrote:
> Ray Saintonge wrote:
>
>>Anthere wrote:
>>
>>
>>
>>>Fred Bauder wrote:
>>>
>>>
>>>
>>>
>>>>I have always viewed Jimbo's suggestion that we "distribute a paper
>>>>encyclopedia to African children" as quixotic but I have in
>>>>connection with a possible board member wondered if we could create a
>>>>series of documents which focus on public health which would prove
>>>>useful in Africa, possibly also in China and other regions, and be
>>>>worth distributing as part of a public health education campaign.
>>>>There was lately a cholera epidemic in Angola which affected most of
>>>>the country. There is a lot of ignorance involved in this sort of
>>>>situation. I don't see this project so much directed to children as
>>>>to local decision makers. It would contain information about disease
>>>>and disease prevention, etc. The question, bottom line, is would a
>>>>project of this nature actually prove effective? Or should we first
>>>>see if we could even mobilize around it? One of the good aspects
>>>>regarding this possible board member is that he is a hands on,
>>>>computer literate guy with experience in give and take.
>>>>
>>>>
>>>>
>>>
>>>Regarding "would a project of this nature actually prove effective", I
>>>am giving a presentation end of august in an international health forum
>>>(http://www.hcuge.ch/genevahealthforum/) and this is exactly the type of
>>>question I hope can receive a beginning of an answer.
>>>
>>>I do not really believe we can mobilize around it before setting up a
>>>framework around. We need partners for such project and these partners
>>>input will be essential to define which content should be included or
>>>not included, and what the audience would be.
>>>
>>>However, admittedly, what I would worry about is, if a framework is set,
>>>with partners and of course, a deadline, I am not sure we would succeed
>>>to mobilize enough and in a sufficiently effective way to respect the
>>>limits. I think we can do huge things, but generally, we are bad with
>>>deadlines because a volunteer may come and go.
>>>
>>>Also, one of the reasons why Wikipedia typically is successful is that
>>>it can be build by tiny bits. Doing just a bit is easy. A little step
>>>that most of us can climb without too much efforts. It is much more of a
>>>problem to participate to a long term project, in which significant
>>>amounts of efforts must be brought be each contributor.
>>>
>>>
>>
>>The idea is commendable but strikes me as well beyond the scope of the
>>things we do.  We are more in a kind of educational publishing business
>>rather than a vehicle for mibilising health care.  Our information could
>>include medical information, but publishing that information is not
>>enough.  We could include "The Barefoot Doctor's Manual" in Wikisource.
>>(The English translation was published by the National Institute of
>>Health in 1974, and that would likely make it copyright free as a US
>>government publication despite the claims of subsequent reprinters.)
>>
>>But the advances in Chinese medical practice at that time involved more
>>than just publishing a book.  It was a textbook for teaching.  Putting
>>it on-line won't do much for people who don't have computers.  What the
>>barefoot doctor mobilization did in China was was bring medical care to
>>rural areas where no care at all was previously available; one should
>>not, therefore, judge the skill of these practitioners by reference to
>>the medical personel in developed countries where there is access to
>>sophisticated equipment and drugs.
>>
>>What's needed is to mobilize local people, give them a basic level of
>>medical training, and send them out through the country  where, as much
>>as possible, they can use indiginous supplies in the practice of
>>medicine.  This may seem like quackery by Western standards, but it's
>>better than the nothing that that public currently has.  Our role in
>>this can only be very limited.
>>
>>Ec
>
> Hoi,
> If we want to make a difference in Africa, we should make Africa more
> relevant. This is something that is not impossible, we should however
> consider the issues that we face to support Africa.
>
> * Our user interface is not localised for the many African languages
> * Many people are reluctant to edit and have a bias against their own
> language
> * Due to "peering agreements" traffic from Europe or America is REALLY
> expensive and slow to reach Africa
> * We should spend more effort on African subjects in the Arab, English
> and French wikipedia
>
> Localising the MediaWiki user interface is a job that takes in between
> two days and a week. It takes a week when the vocabulary does not exist
> in language. This means some research. Particularly the languages where
> Microsoft or Open Office have done there thing should be in relative
> good shape for the many other languages it is just a lot of work. This
> work can be done by people we pay or by people an NGO pays. In my
> opinion it is best when we do not pay and that it is done within
> existing organisations. When an NGO organises this, it is software that
> they are likely to use as well.. This helps a lot.
>
> Many people who are literate in one language are semi-literate in their
> mother tongue. When they edit, they expect the same level of
> completeness, the same consistency of spelling. Many languages however
> do not have one formalised orthography and for many people this hinders
> rather than helps. When an NGO uses MediaWiki to spread its own message,
> people will see how it can be done. Getting a message in their own
> language is really powerful from a marketing point of view. It will also
> help make it easier for people to start contributing.. (Wikipedia is
> very much monkey see, monkey do)
>
> We could have some servers in Africa... There is some reluctance of the
> developers to overcome.. We could hope that the project of the Vrije
> Universiteit bears fruit.. and help it where we can. With this project
> successful, it would mean a peer to peer MediaWiki whereby content is
> near the people that want it.

Hello

How having servers in Africa would help the goal ?

Ant

> When we want to make Wikipedia itself more relevant, there is nothing
> stopping us, we can enrich the content about Africa. It is still very
> poor compared to what we know about the first world.
>
> Oh yes, and when you want medical information, it is good to know that
> medical subjects have a mondial relevance. Would it work? Sure, but do
> not forget that people are looking for sex, sport and politics first in
> Wikipedia and it is important to get all the eyeballs that we can get.
>
> Thanks,
>     GerardM


body:
On 6/25/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> our neighbors, it would increase the prevalence of proprietary file formats

gah. Would *not*.

> SugarCRM is also, by far, the most open of all the available CRM
> packages...

Available ''full service'' CRM packages.  There a dozens of free
software tools for CRM like tasks.  A piece of paper is an open CRM
tool. We could use Emacs no doubt!  There is a presumption I made in
that statement that we need something more powerful than a blank sheet
of paper or a basic contact book.  If that assumption is correct, my
statement on Sugar is correct.


subject: [Wikitech-l] Poem extension on Wikisource

body:
On Sun, Jun 25, 2006 at 02:49:56PM -0400, Jay R. Ashworth wrote:
> On Sun, Jun 25, 2006 at 12:14:06PM -0600, Chad Perrin wrote:
> > > The distinction I'm accustomed to seeing made is between "semantics",
> > > the meaning of things, and "presentation", the way that meaning is
> > > wrapped in a look, to convey it to the user.
> >
> > Yes, and there's a difference between basing presentation on semantics
> > and creating a semantic class of presentation.  In one case, you have
> > presentation classes based on their presentational characteristics, and
> > associate your semantic classes of content with those classes of
> > presentation, and change the associations when you want to modify how a
> > semantic class of content is presented.  In the other, you define a
> > semantic class of content as having specific presentational
> > characteristics, which lends itself to the likelihood that you will end
> > up defining three or four semantically-identified classes of
> > presentation that all have roughly the same presentational
> > characteristics, providing greater probability of violation of the DRY
> > principle of design -- which can get messy rather quickly.
>
> Unless I'm misunderstanding you, you're suggesting that the concept
> that there might be many different tags, for different categories of
> source material, but which we want all to render in the same fashion,
> is *bad*.

Well . . . yeah, kinda.  At least, I don't see a reason that it would be
good, and plenty of opportunity for it to be bad.

I might have accidentally assumed familiarity with a concept that may
not be familiar to you: mea culpa.  I'll try to fix that now.

  DRY = Don't Repeat Yourself

Unnecessary repetition leads to unmaintainability, because when you need
to change one thing you often end up having to run around changing it in
numerous places, and sometimes people miss things.

> >
> > I'm not saying we shouldn't distinguish between content semantics.  I'm
> > just questioning the decision to tie presentation characteristics
> > directly to semantic classes of content.
>
> If I understood brion correctly, we're not: that will be handled in the
> CSS.

I suppose I should probably just look at the source code for all this at
some point and get a better idea of what's going on behind the scenes.

>
> >                                          I'm also curious as to why a
> > database query (for example) would care that it's fetching a poem, as
> > opposed to a fondue recipe: I was pretty sure we hadn't developed DBMSes
> > that have aesthetic taste just yet.
>
> I believe the answer to that is "ask the Semantic MediaWiki people",
> though I'm not sure.
>
> But the point isn't the DBMS.
>
> It's programs people later write to crawl the data, and do statistics
> on how many poems we have, etc.

Ahhh, that makes more sense.  Sorry, I guess I just didn't get what you
were trying to say.

>
> > That's a good point.  Tag properties may not be the best way to handle
> > it.  In fact, there's no reason that a simple tag syntax can't be used
> > for semantic markers, and that these cannot be used as cues for applying
> > presentation styles.  What concerns me about this is that it seems the
> > way we're implementing a tag syntax for semantic markers is by actually
> > making the semantic markers and presentational style cues synonymous,
> > rather than merely associated (and decoupled).
>
> Ah.  No, as I say, if I understood brion correctly, it's a CSS thing.

That doesn't necessarily mean they're "merely associated (and
decoupled)", though at least it's not being handled via direct
characteristic definitions for XML tags -- which would probably be a Bad
Thing for purposes of later maintainability.

>
> > To further muddy the waters of the use of the term "semantic":
> > I'm not worried about the syntax of assigning semantic markers and
> > presentational styles.  Rather, I'm considering the semantic structure
> > of our markup, and how best it can be planned out for future
> > maintainability.  It looks to me like extensions to the semantic
> > structure of the wiki markup are being implemented as features, when
> > such should instead be approached as core functionality.  After all, the
> > parser is an implementation detail: the language definition is what
> > makes the parser worth using.
>
> Ok, I'll admit to having completely fallen off the wagon on that last
> graf.  Could you expand?

I'm speaking of the syntax and semantic structure of languages (thinking
of programming languages as my usual example, though markup has roughly
the same division of design characteristics).  Um.  I'm basically saying
that I don't care too much about the actual appearance of the markup we
use, so long as it's vaguely readable and somewhat consistent (and,
preferably, doesn't make typing a chore with lots of underscores and
tildes) -- instead, what I care about is the rule set for the language,
on which that syntax is built.  For instance, there's an underlying
structure to romance languages (Italian, et cetera) that is different
from that of a language like Japanese.  One cannot simply swap out words
one-for-one in Italian to make Japanese: rather, one must rearrange the
structure of the sentence, certain parts of speech exist in one language
and not in the other, and so on.  The latter is characteristic of
differing semantic structure for a language.

I'd like to see a consistent semantic structure that lends itself to a
consistent syntax that in turn lends itself to maintainable use.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"A script is what you give the actors.  A program
is what you give the audience." - Larry Wall


body:
On 6/25/06, Erik Moeller <eloquence at gmail.com> wrote:
> I won't comment on the specific question, but on the underlying
> Wikimedia policy issue.
[snip]
> Does that make sense?
>
> Best,
> Erik

I agree with Erik's position here, in general.

I'd like to add is that we should include consideration of two important axes.

1) The influence the software has on the outside world.

    Compare the impact of an internal house keeping app with the
impact of running Microsoft Office and sending out official foundation
documents in Word format. Non-free software solutions should probably
never be used for applications which land on the 'most impacting' side
of the spectrum. For example, we should never make official use of a
proprietary file format for official communication to our editors,
creating a barrier to entry for users of free software, even if there
is no good alternative available.

2) Critically to the critical path of our project's purpose.

   Compare the use of a proprietary software address book in the
office to storing the Wiki content in a proprietary format. This is
the distinction between 'involved with the content' and everything
else.

Various problems will have some position on these axis, for example,
Erik's OCR example is very much involved with the content, but is
almost totally invisible outside of the person using it. A CRM
solution is not involved with the content but has impact on a few more
people, although not widescale impact (Some on foundation staff and
perhaps volunteers; none on general readers, donors, or editors).
Paypal has significant impact on outsiders, but it's outside of the
content critical path (and webbased).


from_name: Brion Vibber

body:
Jay R. Ashworth wrote:
> On Sun, Jun 25, 2006 at 12:14:06PM -0600, Chad Perrin wrote:
[snip way too much text]

Let me summarize what <poem> does, how, and why. <poem> does two things:

1) It *modifies the behavior* of wiki syntax within its borders to preserve line
breaks and initial whitespace in a different way from general text.

A CSS class by itself is insufficient to do this due to the transformations done
in wikitext processing, so the extension preprocesses the input to allow the
"natural" way of pasting in poem-like text to work.

2) It *marks* the contents with a distinct style class ('poem') which allows
distinct styling to be applied to all <poem>s via the global style sheet.

For instance, one might use block indentation, color, or a different font style
to make poems visually distinct in text output, and a different voice style or
pitch for text-to-speech output.

One could also use this class marking to extract poem contents from rendered
HTML data, as one could use the <poem> extension's presence to extract collected
poem contents from the wikitext.

Further, a quick note about HTML. Plain old HTML contains a lot of
often-forgotten semantic elements, such as:

<abbr>
<acronym>
<address>
<code>
<dfn>
<kbd>
<q>
<samp>
<var>

Some of those are supported in our wikitext because UseMod supported them;
others we've never added. But in general, you can note that they often would not
necessarily have distinct default styles. <samp>, <kbd> and <code> usually all
render in a monospaced font, like <tt>. But they don't have to, and using
distinct elements allows you to style them consistently, or to treat them
differently when machine-extracting data. etc.

The set of semantic elements in HTML hints at its creation in a physics research
lab full of computer geeks. It has excellent coverage for writing software
manuals and project summary pages, but more limited coverage for, say, literature.

Our wiki text has a strong affinity with HTML; we render to it, we allow subsets
of it, etc. But we aren't HTML exactly, and where our needs differ it is fully
appropriate to have distinct semantic elements.

-- 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/20060625/159722c4/attachment.pgp>


from_name: Jay R. Ashworth

body:
On Sun, Jun 25, 2006 at 07:22:53PM +0200, Steve Bennett wrote:
> > We do, however, quite often want source code in our articles.
>
> And it would probably be appropriate to have a good way of doing that.
> Source code doesn't necessarily demand lack of line wrapping.

It doesn't?

Certainly there are languages in which wrapping a line breaks the
syntax; the Bourne Shell is only the first one that comes to mind...

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

     A: Because it messes up the order in which people normally read text.
     Q: Why is top-posting such a bad thing?

     A: Top-posting.
     Q: What is the most annoying thing on Usenet and in e-mail?


list: commons-l

from_name: Brianna Laugher

subject:
[Commons-l] An interactive copyright tutorial as a
	requirementfor uploading?

body:
On 24/06/06, Platonides <Platonides at gmail.com> wrote:
>
> >*Users can simply try answers until they find the correct one
> The software could realise it and... deny him tutorial access for some
> hours? set him as can't-upload until an admin verifies him?

No, I think there's nothing wrong with guessing (as Eloquence also
said, IIRC). The important part is that they find out which is the
correct answer and we explain why. Anyway if we use the quiz I wrote
it won't take them long to figure out that guessing "False" is a
pretty safe bet. ;)

> >*There's too much work for admins
> We're talking of adding a 'can upload' permission. Also add an can review
> permission, automatically got after N uploads and no copyright problem.
> Admins could always add/remove this permission.

Do you mean 'we' as in the people on this list, or 'we' as in the
developers? If it's the dev's then I'm very glad to hear it (so that
we can block people from uploading only). But to my knowledge
MediaWiki is not set up for this kind of thing, is it? B'crats can
add/remove bot flags.

> Another problem would be people creating new accounts to bypass this limit
> system.

Yeah, but I think we'll just have to wear that (not much we can do
about it, and hopefully not too much of a problem).

Brianna


from_name: Gerard Meijssen

subject:
[Foundation-l] Opinions/suggestions for "outside" members of
 the board?

body:
Anthere wrote:
> Hello
>
> How having servers in Africa would help the goal ?
>
> Ant
>
Hoi,
African ISP's pay for traffic coming from America or Europe.
Consequently the speed of American and European websites is really poor.
Within Africa, African websites perform as we would expect them to. By
having servers in Africa the speed in which we serve our pages would be
dramatically better. I would argue that we should have our projects in
African languages completely in Africa and do caching for English and
French as well.

Hosting in Africa is not as cheap as in either America or Europe.
Bandwidth is much more expensive. It would be good to find a partner who
would pay the hosting of our content. There are plenty of universities
and NGO's who could provide part of such a service. Universities can
provide expertise and NGO's the funding.

The signal value of us having servers in Africa is very important. It
would help us not only in getting more readers, it would help our
localisation effort. It would help the adoption of MediaWiki as a
platform to provide information. The marketing value for our projects is
really big. It would also help make the use of African languages
acceptable by providing content.

Thanks,
    GerardM

PS these are the latest *localisation *statistics and the problematic
messages:
http://nike.users.idler.fi/betawiki/Localisation_statistics
http://nike.users.idler.fi/dev/problems.txt


list: wikien-l

from_name: stevertigo

subject:
[WikiEN-l] Category:<Subjective-pejorative>, weak consensus,
	and ! NPOV

body:
--- Mark Gallagher
<m.g.gallagher at student.canberra.edu.au> wrote:

> > Dont make this personal.
> Fair enough.  It wasn't really called for, was it?
> Bit childish of me, there.

I much appreciate that! Let us you and I henceforth
agree to not be dicks, either by dickishness itself or
by accusal thereof.

> What Cobb was alluding to --- always and only --- is
> his inability to get all fancruft deleted
immediately.

Ah. Well thats... practical.

I guess I now would be a good time for me to make note
of some 'Pediacruft (self-refs), wikicruft (references
to wiki tknlgy), and Jimbocruft (fans apparently).
Nah, I wont mention it.

> Fair enough.

We have to come up with a better term for "newbie
indoctrination" though.

> What you see as "making an argument weak" I see as
> trying not to get those you're trying to convince
>  off-side.

Yeah, I can see that. But that doesnt really work when
dealing with POV pushers. If the issue is adherence to
POV, my addition of [[Category:Anti-French people]]
for example should be rightly seen as POINT and not as
POV.

Naturally someone can report me to the Arbcom for
POINT, and get me deadminned or something like that
without much consideration of NPOV. If we really need
to 'kick out bad writers', what good does it do when
not just the Arbcom, but the whole community fails to
understand or apply some basic NPOV?

I agree what you said in another email that "the
Trifecta" is simple and therefore effective for
newbies. But what we have yet to do IMHO is to
elaborate more on NPOV as our most elevated,
trancendent and fundamental core doctrine,
by way of drills, practices, examples, and organized
religion-style propaganda.

-Stevertigo
PS: I could just go ahead and edit-integrate the
policy pages though myself but Im lazy.

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


from_name: mboverload

subject: [WikiEN-l] popular POV not NPOV? (was:New York Times article)

body:
Wait, NPOV doesn't mean No Point of View?

=D

On 6/25/06, Fred Bauder <fredbaud at ctelco.net> wrote:
>
>
> On Jun 25, 2006, at 2:37 PM, Nathan wrote:
>
> > I never thought I'd say this, but I agree with Phil Welch.
> >
> > - Nathan (nathanrdotcom)
> >
> > On Sat, 24 Jun 2006, Philip Welch wrote:
> >
> >
> >> I think we should replace "neutral point of view" (which is
> >> abbreviated to the misunderstood acronym NPOV) to
> >> "neutrality" (which, like "verifiability", is easier to understand).
> >>
>
> We already have trouble with editors who try to use neutral washed
> out language rather than allowing opposing points of view to be fully
> expressed.
>
> Fred
> _______________________________________________
> 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: Tim Starling

subject:
[Wikitech-l] Cross-Site-Scripting arbitrary JavaScript
 execution and HTML insertion vulnerability in the live Wikipedia.

body:
Brion Vibber wrote:
> Nick Jenkins wrote:
>> Please note that MediaWiki 1.6 (current stable) does NOT appear to be affected. However current SVN and the live Wikipedia are
>> affected by this vulnerability.
>
> As I understand it, this was fixed a few hours ago, and was present for just a
> few hours before that; so if you updated from SVN trunk in the last day, make
> sure you update again. :)

This sort of thing really doesn't need to be reported to wikitech-l. There
are transient bugs in the trunk all the time, we make no guarantee about its
security or stability. Any security problem on Wikipedia can be fixed in a
few minutes by reporting it by private message on IRC.

-- Tim Starling


references:
<NABBJGECPILFNLFEAPIKGENDIFAA.nickpj@gmail.com>	<449CF051.903@pobox.com>
	<e7l2s8$48h$1@sea.gmane.org>

body:
I wrote:
> This sort of thing really doesn't need to be reported to wikitech-l. There
> are transient bugs in the trunk all the time, we make no guarantee about its
> security or stability. Any security problem on Wikipedia can be fixed in a
> few minutes by reporting it by private message on IRC.

Further to that, I would appreciate it if Nick would commit his testing
scripts to SVN, and document them fully. It would be easier if we could do
this testing before we commit, rather than go through all this rigmarole.

-- Tim Starling


subject: [WikiEN-l] Spoiler Boilerplates

body:
On 6/25/06, Steve Bennett <stevagewp at gmail.com> wrote:
>
> I have to admit to a sense of irony that we warn users of excessively
> technical language, and we warn them if the title of the page isn't
> quite right. We even warn them that the article uses unicode
> characters. But we refuse to warn them that they may witness seriously
> obscene material or have their enjoyment of a work of fiction totally
> spoilt.

It makes sense to me. When an article is bad (or not complete enough, too
technical, whatever), a reader should be warned. But when a reader looks up
something 'obscene', he shouldn't be surprised to see something 'obscene',
or when a reader looks up a movie, he shouldn't  be surprised to find a plot
summary there. To me a warning in those cases seems unnecessary.

Garion


body:
On Sun, Jun 25, 2006 at 12:26:36PM -0600, Chad Perrin wrote:
> > > And it would probably be appropriate to have a good way of doing that.
> > > Source code doesn't necessarily demand lack of line wrapping.
> >
> > It doesn't?
> >
> > Certainly there are languages in which wrapping a line breaks the
> > syntax; the Bourne Shell is only the first one that comes to mind...
>
> If by "wrapping a line" you mean inserting a linebreak, yes, you're
> absolutely correct.  Others include Logo, BASIC, and Python (though Logo
> at least provides for the ability to break a line on the page without
> breaking a semantic line of code via a work-around syntax).
>
> On the other hand, the words "doesn't necessarily" seem technically
> accurate, since there are many languages that don't care what linebreaks
> you have in a file, with the possible exception of linebreaks in the
> midst of comments and partway through keywords, function names, et
> cetera.  I suppose the question that needs to be asked at this point is
> whether the necessities of some languages suggest that we should impose
> the same limits on presentation of other languages that do not share
> those necessities.

Certainly, you might add an attribute like "linebreak=ok", though
I'm not sure how the HTML markup would have to go there...

> While we're at it, we might consider whether to allow line wrapping, but
> provide a line-wrap indicator syntax to show that what appears on a
> separate line of the page is in fact meant to be part of the same
> semantic line of code.  I'm thinking of examples such as the plus-syntax
> used on websites such as perlmonks.org.  An example of this usage might
> look something like this:
>
>  |while (<>) {
>  |  if ( $scalar_foo <= $scalar_bar ) && ( $scalar_bar <= $array_qux[2]
> +|) {
>  |    print;
>  |  }
>  |}
>
> . . . where the plus character is typically some differentiating color,
> such as red.  That may or may not be appropriate for something like
> MediaWiki -- I only bring it up as something to consider.

Mutt does that with wrapped URL's in my mail.  It's a pain because you
can't then paste the copied text in without having to fix it.

On one-line URL's, this is practical.

If it's a couple hundred lines of code, maybe not so much.

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

     A: Because it messes up the order in which people normally read text.
     Q: Why is top-posting such a bad thing?

     A: Top-posting.
     Q: What is the most annoying thing on Usenet and in e-mail?


from_name: Ian Woollard

body:
On 23/06/06, Mark Gallagher <m.g.gallagher at student.canberra.edu.au> wrote:
> > I dont know what else to say. Either we have a culture
> > which respects NPOV or we do not.
>
> You think the category is incompatible with NPOV.  I think you're right.

That's wrong. Or atleast please refer me to the part of NPOV that it
would violate.

I don't think that that category would be a very good idea at all (it
doubtless violates other policy).

IMO having carefully read the NPOV, it doesn't violate NPOV. If you
think it does, point me to the place which it violates.

There's a lot of myths about NPOV. Practically nobody gets NPOV right.
This annoys me a lot.

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

--
-Ian Woollard

"Victory can be perceived but not created."


body:
On Sun, Jun 25, 2006 at 12:14:06PM -0600, Chad Perrin wrote:
> > The distinction I'm accustomed to seeing made is between "semantics",
> > the meaning of things, and "presentation", the way that meaning is
> > wrapped in a look, to convey it to the user.
>
> Yes, and there's a difference between basing presentation on semantics
> and creating a semantic class of presentation.  In one case, you have
> presentation classes based on their presentational characteristics, and
> associate your semantic classes of content with those classes of
> presentation, and change the associations when you want to modify how a
> semantic class of content is presented.  In the other, you define a
> semantic class of content as having specific presentational
> characteristics, which lends itself to the likelihood that you will end
> up defining three or four semantically-identified classes of
> presentation that all have roughly the same presentational
> characteristics, providing greater probability of violation of the DRY
> principle of design -- which can get messy rather quickly.

Unless I'm misunderstanding you, you're suggesting that the concept
that there might be many different tags, for different categories of
source material, but which we want all to render in the same fashion,
is *bad*.

I admit, we're clearly off into your territory here; I almost slid out
of that last curve.
>
> > While many meanings may carry the same look, the reason people suggest
> > that the tagging should reflect the *specific* meaning in each case is
> > so that back-end processes which might want to can distinguish.
>
> I'm not saying we shouldn't distinguish between content semantics.  I'm
> just questioning the decision to tie presentation characteristics
> directly to semantic classes of content.

If I understood brion correctly, we're not: that will be handled in the
CSS.

>                                          I'm also curious as to why a
> database query (for example) would care that it's fetching a poem, as
> opposed to a fondue recipe: I was pretty sure we hadn't developed DBMSes
> that have aesthetic taste just yet.

I believe the answer to that is "ask the Semantic MediaWiki people",
though I'm not sure.

But the point isn't the DBMS.

It's programs people later write to crawl the data, and do statistics
on how many poems we have, etc.

Generally, we're metamorpohsing wikitext into XML.  :-)

> > > I'm not sure I agree that semantic presentation is really a great idea
> > > to implement in markup tags.  Rather, it seems to be something that
> > > should be managed via properties that are attached to tags.  It provides
> > > sort of a natural hierarchical inheritance model, rather than (by way of
> > > analogy) sticking every single file on your hard drive in the root
> > > directory, like the FAT12 filesystem did.
> >
> > Well, as long as the tags are distinguishable, yeah, but it seems
> > easier to do <poem> than <special type=poem>, particular in the
> > Wikipedia milieu.
>
> That's a good point.  Tag properties may not be the best way to handle
> it.  In fact, there's no reason that a simple tag syntax can't be used
> for semantic markers, and that these cannot be used as cues for applying
> presentation styles.  What concerns me about this is that it seems the
> way we're implementing a tag syntax for semantic markers is by actually
> making the semantic markers and presentational style cues synonymous,
> rather than merely associated (and decoupled).

Ah.  No, as I say, if I understood brion correctly, it's a CSS thing.

> To further muddy the waters of the use of the term "semantic":
> I'm not worried about the syntax of assigning semantic markers and
> presentational styles.  Rather, I'm considering the semantic structure
> of our markup, and how best it can be planned out for future
> maintainability.  It looks to me like extensions to the semantic
> structure of the wiki markup are being implemented as features, when
> such should instead be approached as core functionality.  After all, the
> parser is an implementation detail: the language definition is what
> makes the parser worth using.

Ok, I'll admit to having completely fallen off the wagon on that last
graf.  Could you expand?

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

     A: Because it messes up the order in which people normally read text.
     Q: Why is top-posting such a bad thing?

     A: Top-posting.
     Q: What is the most annoying thing on Usenet and in e-mail?


body:
Gerard Meijssen wrote:
> Anthere wrote:
>
>>Hello
>>
>>How having servers in Africa would help the goal ?
>>
>>Ant
>>
>
> Hoi,
> African ISP's pay for traffic coming from America or Europe.
> Consequently the speed of American and European websites is really poor.
> Within Africa, African websites perform as we would expect them to. By
> having servers in Africa the speed in which we serve our pages would be
> dramatically better. I would argue that we should have our projects in
> African languages completely in Africa and do caching for English and
> French as well.

By dramatically, what do you mean ? Do you have statistics to show the
speed of delivery for a same page, in USA, in the Netherlands and in
South Africa ?

> Hosting in Africa is not as cheap as in either America or Europe.
> Bandwidth is much more expensive. It would be good to find a partner who
> would pay the hosting of our content. There are plenty of universities
> and NGO's who could provide part of such a service. Universities can
> provide expertise and NGO's the funding.

But would the drawbacks of finding and coping with a partner be
significant with regards to the current percentage of readers for which
there would be an improvment and for the level of improvement ?

> The signal value of us having servers in Africa is very important. It
> would help us not only in getting more readers,

Frankly... I do not follow you here. Whether the site is hosted in
Africa or hosted somewhere else is likely to be invisible to the great
majority of reader. I gather most will not care... nor even ask
themselves who host the site. Actually most readers have no idea what
hosting means...

it would help our
> localisation effort.

I do not see how hosting the site on the African continent (say South
Africa) will increase the percentage of translation of the software...

It would help the adoption of MediaWiki as a
> platform to provide information.

Which might be nice, but is not the goal of the Foundation.

The marketing value for our projects is
> really big.

I am not convinced. We also have hosting provided in Korea. Do you think
it improved marketing value of our projects in Asia ? Do you have figures ?

  It would also help make the use of African languages
> acceptable by providing content.

I certainly see the benefit of having mediawiki interface translated, I
just fail to see how hosting Wikipedia and other sites in Africa will
help use of African languages more acceptable :-(

> Thanks,
>     GerardM
>
> PS these are the latest *localisation *statistics and the problematic
> messages:
> http://nike.users.idler.fi/betawiki/Localisation_statistics
> http://nike.users.idler.fi/dev/problems.txt

Interesting data !


from_name: Steve Bennett

subject: [WikiEN-l] Spoiler Boilerplates

body:
On 6/25/06, Garion1000 <garion1000 at gmail.com> wrote:
> It makes sense to me. When an article is bad (or not complete enough, too
> technical, whatever), a reader should be warned. But when a reader looks up
> something 'obscene', he shouldn't be surprised to see something 'obscene',

I would be very much surprised to see explicit pornography if I looked
up "hard-core pornography". We're an encyclopaedia, after all - not
normally the sort of place one expects to find porn.

> or when a reader looks up a movie, he shouldn't  be surprised to find a plot
> summary there. To me a warning in those cases seems unnecessary.

Seems to be a common problem that "spoiler" is confused with "plot
summary". Consider a movie review in the paper. You'll usually get a
decent plot summary of the first two-thirds of the film. You would
never see anything like the surprise twist at the end revealed. Now, I
think we can go a little further than that, but when it comes to
revealing that twist, we should be careful to respect our readers, who
may be reading the article in order to decide whether the film is
worth seeing or not.

Has anyone trialed using javascript hide/show buttons to hide/show the
spoiler? One benefit is it would force judicious labelling of the
"spoiler" - in most cases, it should only be a sentence or two.

Steve


subject: [Foundation-l] Re : Where we are headed

body:
James Hare wrote:
> To respond to Jimmy's e-mail,
>
> Another problem with communication is all the pages it spans. I maintained
> several user and user talk pages, but I only need two of them. Although the
> normal MediaWiki software can maintain the status quo, Wikimedia's should be
> designed a bit differently: the projects can have the mainspace, the portal
> space, and the project space, but a central wiki (Meta, anyone?) would have
> the help pages and the user/user talk pages. Surely this has been discussed
> before?
>
Hoi,
Yes, it has. There are people, myself included who present themselves
slightly different depending on the project. For instance what is the
relevance to the Wiktionary crowd that I have written about the fish
that swim in the Dutch sweet waters?? Some information is of value never
mind the project eg the language proficiency that can be found in the
Babel templates. However, this is only of relevance to the projects
where someone is active.

Centralising the Help pages assumes that all projects have the same
policies. They don't. It also assumes that the way people people can
edit is universally the same, it is not; Wiktionary insists on you to
comply with entering information in a prescribed format, a format that
is different from language version to language version while the
Wikipedias are much more free format.

The system messages can be very much centrally maintained. This however
requires two things:
    * No project specific information in the system messages
    * Continued participation in the Betawiki project of people
interested in maintaining the localisation of MediaWiki.

Thanks,
    GerardM


subject: [Foundation-l] Re : Where we are headed


from_name: Fred Bauder

body:
On Jun 25, 2006, at 2:37 PM, Nathan wrote:

> I never thought I'd say this, but I agree with Phil Welch.
>
> - Nathan (nathanrdotcom)
>
> On Sat, 24 Jun 2006, Philip Welch wrote:
>
>
>> I think we should replace "neutral point of view" (which is
>> abbreviated to the misunderstood acronym NPOV) to
>> "neutrality" (which, like "verifiability", is easier to understand).
>>

We already have trouble with editors who try to use neutral washed
out language rather than allowing opposing points of view to be fully
expressed.

Fred


body:
On 6/24/06, Timwi <timwi at gmx.net> wrote:
> You seem to be implying that you think we should only introduce purely
> semantic tags if we already have other semantic tags. You therefore seem
> to be of the opinion that unsemantic tags are favourable in a context
> where most mark-up is already unsemantic. But if this was the case, then
> surely HTML would not have introduced things like <em> and <strong> and
> deprecated things like <font>, and instead have introduced things like
> <marquee> or <blink>.
>
> So, the reason <poem> was made a semantic tag is because semantic tags
> are good, independently of whether we already have semantic tags or not.

Ok, ok, slow down :) I haven't formed an opinion on semantic tags, I'm
just curious whether this reflects a long term direction for
MediaWiki, whether there will be others, and so forth.

I suppose I was also thinking that if the only special formatting
provided by <poem> is that leading spaces are significant, then maybe
it would be attractive to just define <leadingspacesaresignificant>
(for example), then use templates, like {{poemstart}}/{{poemend}} for
the appropriate semantic markup. Is there a particular advantage in
having semantic markup at the wiki syntax level, rather than at the
template level?

>
> Imagine we use the same tag for poems and for cooking recipes. Some time
> in the future we decide we actually want the mark-up to behave slightly
> (or even completely) differently for recipes. This is why we need
> separate mark-up for separate purposes.

I would certainly recommend using {{poem}} and {{recipe}} or something
in that case. Then you could simply change the template when they
split.

> And yes, I know that ideally this reasoning also calls for separate
> mark-ups that are currently all handled with '' (emphasis, maths
> variables, song/film titles, etc.). Obviously in this situation it is
> futile to hope for the ideal. Doesn't mean we have to create the same
> suboptimal situation in something as rarely-used as poems, though.

I agree with your general argument that "just because X is bad,
doesn't mean Y has to be bad too". And I certainly have no objection
to this new tag, I'm just interested in its implications.

Steve


body:
On Sun, Jun 25, 2006 at 12:51:33PM -0600, Chad Perrin wrote:
> > Mutt does that with wrapped URL's in my mail.  It's a pain because you
> > can't then paste the copied text in without having to fix it.
> >
> > On one-line URL's, this is practical.
> >
> > If it's a couple hundred lines of code, maybe not so much.
>
> I, too, use mutt, and have the same issue from time to time.  It's
> easily solved with XHTML and CSS, though: use block elements and styles
> to position the plus signs (or whatever) in a separate block from the
> stuff you want to wrap, or use inline element styles to attach some
> visual cue like a left-side or right-side thin and understated border,
> or use a left-aligned background image on wrapped lines, or turn the
> block of code with line-wraps into a link to a plaintext file without
> linewraps, or . . .
>
> One of the benefits of rendered markup with styles is that it allows you
> to use something other than content characters within the same block of
> content as visual presentation, thus allowing for visually associated
> characteristics that are not associated as closely according to what
> your mouse will highlight for copying and pasting.

Excellent point, though I was thrown a bit there at first, wondering how
exactly you were going to get Mutt to issue XHTML.  :-)

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

     A: Because it messes up the order in which people normally read text.
     Q: Why is top-posting such a bad thing?

     A: Top-posting.
     Q: What is the most annoying thing on Usenet and in e-mail?


body:
On Sun, Jun 25, 2006 at 08:47:37PM +0200, Andrew Dunbar wrote:
> > <snob type=typography>
> > Em dashes are properly set in English text without spacing on either
> > side, though the ASCIIography of this usage is much less picky.
>
> Can you provide a reference for this? Also can you be
> sure this is the only style and that it doesn't vary by
> style guide, by publisher, by country, by newspaper vs
> novels, etc.

A formal reference?

No; not off hand.

Just personal experience from 35 years or so of reading American
typesetting, and at least 15 years of paying professional attention
thereto.

> The reason I ask is that I've been studying casually how
> they are typeset in books as part of my thinking about
> an XML format for e-texts. I have seen so many cases
> both with and without spaces that I've been pondering
> whether it would best be handled as a style issue.

You've seen commercial typesetting (that is, typesetting done by
typographers, not computer scientists :-) that put full spaces around
em-dashes?

I'd be interested in references myself, if you could lay hands on any.

It's a topic I'm close to, because my instinct is to want to render
standard typesetting as closely as possible in ASCII, but I just can't
bring myself to set ASCII em dashes--you know, these things--without
the surrounding spaces -- even though that's how I see them set in
type.

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

     A: Because it messes up the order in which people normally read text.
     Q: Why is top-posting such a bad thing?

     A: Top-posting.
     Q: What is the most annoying thing on Usenet and in e-mail?


from_name: Erik Moeller

subject: [Wikitech-l] mediawiki logo

body:
On 6/22/06, Anthere <Anthere9 at yahoo.com> wrote:
> By the way, my original flower was in gfdl and you asked me Erik, to put
> it in public domain so as to make use of the logo easier.
>
> The image you are considering is not public domain. Is that a problem ?

If we're going to seriously consider the logo I recently proposed,
I'll ask the photographer of the flower if he'd be OK with putting it
(or the cropped version) in the public domain. :-)

Erik


from_name: Steve Summit

subject: [WikiEN-l] Spoiler Boilerplates

body:
Zero wrote:
> This is the common view: "Other websites do it as "courtesy" and thus
> should be accepted about the Encyclopedia because people like it".

We're not doing it simply because other websites do it, and the
argument for why we're doing it is not "because other websites do
it".  What we've got here is correlation, not causation.  We do
it because it's a good idea, which is the same reason they do it.
When people make the argument "but all the other websites are
doing it", all they're saying is, "so it's not a preposterous idea".

> In view of "not all encyclopedias are the same", you lost me there.

It's simply the case that Wikipedia is more than just a an
encyclopedia.  Not only is it not paper, it also shares some
attributes of the more dynamic, information-sharing websites.
It's new and different; not all the old rules apply.

> That's an interesting comparison. I suppose you'll say then that the
> implementation of a template derived from the ideal of a networking
> site is appropriate in any encyclopedia.

No need to drag in the slippery-slope or strawman arguments.
We're calling these like we see 'em, really.

> We build an encyclopedia, not selctively dictate who might or might
> not view it on a personal whim.

But we're *not* dictating anything!  And that's why it's *not*
censorship.  In fact, what it *is*, is *providing additional
information* -- metainformation.  We're telling the reader,
"Oh, by the way, this next bit is something you might not want
to read -- your choice -- if you don't want any spoilers."

(If I wanted to get silly, I could accuse you of censorship for
trying to deny me my right to warn my readers in this way. :-) )


body:
On Sun, Jun 25, 2006 at 09:40:26PM +0200, Steve Bennett wrote:
> On 6/25/06, Jay R. Ashworth <jra at baylink.com> wrote:
> > It's a topic I'm close to, because my instinct is to want to render
> > standard typesetting as closely as possible in ASCII, but I just can't
> > bring myself to set ASCII em dashes--you know, these things--without
> > the surrounding spaces -- even though that's how I see them set in
> > type.
>
> Weird, I tend to use hyphens with spaces - like this - to achieve that effect.

I see that, too.  A good corpus to check would probably be a couple of
Usenet groups, selected for their length of posting.

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

     A: Because it messes up the order in which people normally read text.
     Q: Why is top-posting such a bad thing?

     A: Top-posting.
     Q: What is the most annoying thing on Usenet and in e-mail?


body:
Anthere wrote:
> Gerard Meijssen wrote:
>
>> Anthere wrote:
>>
>>
>>> Hello
>>>
>>> How having servers in Africa would help the goal ?
>>>
>>> Ant
>>>
>>>
>> Hoi,
>> African ISP's pay for traffic coming from America or Europe.
>> Consequently the speed of American and European websites is really poor.
>> Within Africa, African websites perform as we would expect them to. By
>> having servers in Africa the speed in which we serve our pages would be
>> dramatically better. I would argue that we should have our projects in
>> African languages completely in Africa and do caching for English and
>> French as well.
>>
>
> By dramatically, what do you mean ? Do you have statistics to show the
> speed of delivery for a same page, in USA, in the Netherlands and in
> South Africa ?
>
I base this information on what I learned from the many people I spoke
about this issue. Many of these people are expert in this field and deal
with this on a daily basis.
>> Hosting in Africa is not as cheap as in either America or Europe.
>> Bandwidth is much more expensive. It would be good to find a partner who
>> would pay the hosting of our content. There are plenty of universities
>> and NGO's who could provide part of such a service. Universities can
>> provide expertise and NGO's the funding.
>>
>
> But would the drawbacks of finding and coping with a partner be
> significant with regards to the current percentage of readers for which
> there would be an improvment and for the level of improvement ?
>
When we want to improve our presence in Africa, the first thing to do is
making it a priority. It is like starting a new business, when you have
good indicators that the opportunity is there you invest in the
expectation that the market will develop as a consequence. Given that we
intent to provide information to everyone on this earth in their own
language, I would say that it is very much a core deliverable of our
Wikimedia Foundation consequently the drawbacks are to be considered but
they are secondary.
>> The signal value of us having servers in Africa is very important. It
>> would help us not only in getting more readers,
>>
>
> Frankly... I do not follow you here. Whether the site is hosted in
> Africa or hosted somewhere else is likely to be invisible to the great
> majority of reader. I gather most will not care... nor even ask
> themselves who host the site. Actually most readers have no idea what
> hosting means...
>
Our readers may not care where their servers are. They care about the
increased service provided by better performance. With our hosting in
Africa, we will have an marketing opportunity for our projects. This is
really relevant. Remember, the Seigenthaler affair increased our traffic
no end it was one /great /side effect. When we actively promote our
projects it will lead to more eye balls, more content, better localisation.
>
>> it would help our localisation effort.
>>
>
> I do not see how hosting the site on the African continent (say South
> Africa) will increase the percentage of translation of the software...
>
I have contacts with organisations that are interested in using the
MediaWiki software for languages like Farsi and Lao. I have contacts
with organisations interested in localising MediaWiki for African
languages. With a better infra-structure for the Wikimedia projects and
more people making use of MediaWiki projects, this investment would be
more beneficial as more people will know how to participate.
>
>> It would help the adoption of MediaWiki as a platform to provide information.
>>
>
> Which might be nice, but is not the goal of the Foundation.
>
Call it a fringe benefit then.. It is a welcome fringe benefit right ?
>
>> The marketing value for our projects is
>> really big.
>>
>
> I am not convinced. We also have hosting provided in Korea. Do you think
> it improved marketing value of our projects in Asia ? Do you have figures ?
>
I would not know. You are in a much better position to tell us if we
used the Korean hosting as an opportunity to market our projects. I
would also say that Asia cannot be compared with Africa; there are many
BIG projects in Asia. There are none in Africa. The reason for hosting
in Africa are distinctly different; Asia does have the traffic Africa
does have poor response times. The reason for hosting in Africa is
therefore not comparable either.
>> It would also help make the use of African languages acceptable by providing content.
>>
>
> I certainly see the benefit of having mediawiki interface translated, I
> just fail to see how hosting Wikipedia and other sites in Africa will
> help use of African languages more acceptable :-(
>
By providing a quality localised user interface, it shows that there are
people who care for THEIR language. By providing a quality responsive
service we show that we care for THEIR custom. There is also a limit to
what we can do from America or Europe. We can make our African service
better than it currently is by orders of magnitude. I may remind you
that Google invests heavily to remove fractions of their response time
to build their market share, for us it is much easier. :)

One of the things I have observed in several small projects is that
people are hesitant to contribute, they are often literate in a language
other than there mother tongue. It is hard to convince people that an
occasional spelling or grammatical "error" can be due to no fixed
orthography. To overcome this shyness is not easy. This is often
accomplished by peer pressure.. This is one reason why we have to work
together with people in Africa, people in universities, NGO's etc..

Thanks,
   GerardM


body:
On Sun, Jun 25, 2006 at 03:36:01PM -0400, Jay R. Ashworth wrote:
> On Sun, Jun 25, 2006 at 08:47:37PM +0200, Andrew Dunbar wrote:
>
> > The reason I ask is that I've been studying casually how
> > they are typeset in books as part of my thinking about
> > an XML format for e-texts. I have seen so many cases
> > both with and without spaces that I've been pondering
> > whether it would best be handled as a style issue.
>
> You've seen commercial typesetting (that is, typesetting done by
> typographers, not computer scientists :-) that put full spaces around
> em-dashes?
>
> I'd be interested in references myself, if you could lay hands on any.

For my own part, the only references I have on-hand at the moment are:

* one professional writer's reference (AP style and media law guide)

* a bunch of books that are professionally printed

* periodicals and news sources that are professionally printed

In my experience, spaces tend to be more common in literary works, and
lack of spaces tends to be the norm in news media and the like -- though
news media, et cetera, tends to frown on emdashes (or endashes for that
matter) at least as much as it frowns on parentheses.  This is borne out
by the instruction set forth in the AP book.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
This sig for rent:  a Signify v1.14 production from http://www.debian.org/


body:
On Sun, Jun 25, 2006 at 03:32:04PM -0400, Jay R. Ashworth wrote:
> On Sun, Jun 25, 2006 at 12:51:33PM -0600, Chad Perrin wrote:
> >
> > One of the benefits of rendered markup with styles is that it allows you
> > to use something other than content characters within the same block of
> > content as visual presentation, thus allowing for visually associated
> > characteristics that are not associated as closely according to what
> > your mouse will highlight for copying and pasting.
>
> Excellent point, though I was thrown a bit there at first, wondering how
> exactly you were going to get Mutt to issue XHTML.  :-)

Er, no.  Heh.  It should be obvious on a second look that I wasn't
talking about mutt when referring to using XHTML for styling.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"A script is what you give the actors.  A program
is what you give the audience." - Larry Wall


body:
On Sun, Jun 25, 2006 at 03:49:51PM -0400, Jay R. Ashworth wrote:
> On Sun, Jun 25, 2006 at 09:40:26PM +0200, Steve Bennett wrote:
> > On 6/25/06, Jay R. Ashworth <jra at baylink.com> wrote:
> > > It's a topic I'm close to, because my instinct is to want to render
> > > standard typesetting as closely as possible in ASCII, but I just can't
> > > bring myself to set ASCII em dashes--you know, these things--without
> > > the surrounding spaces -- even though that's how I see them set in
> > > type.
> >
> > Weird, I tend to use hyphens with spaces - like this - to achieve that effect.
>
> I see that, too.  A good corpus to check would probably be a couple of
> Usenet groups, selected for their length of posting.

That's not a bad approximation of using endashes, really.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
This sig for rent:  a Signify v1.14 production from http://www.debian.org/


body:
On Sun, Jun 25, 2006 at 10:02:40PM +0200, Andrew Dunbar wrote:
> On 6/25/06, Jay R. Ashworth <jra at baylink.com> wrote:
> > On Sun, Jun 25, 2006 at 08:47:37PM +0200, Andrew Dunbar wrote:
> > > > <snob type=typography>
> > > > Em dashes are properly set in English text without spacing on either
> > > > side, though the ASCIIography of this usage is much less picky.
> > >
> > > Can you provide a reference for this? Also can you be
> > > sure this is the only style and that it doesn't vary by
> > > style guide, by publisher, by country, by newspaper vs
> > > novels, etc.
> >
> > A formal reference?
> >
> > No; not off hand.
> >
> > Just personal experience from 35 years or so of reading American
> > typesetting, and at least 15 years of paying professional attention
> > thereto.
>
> I ask for a reference because I've seen people say that
> serial commas (also known as Harvard commas or
> Oxford commas) are correct or incorrect whereas in that
> case it does turn out to depend on region, publisher, etc.
> but people wrongly assume there is a global rule.

Serial commas are historically more "proper", but that has been lost
with time.  I prefer them due to greater precision and communication of
intended meaning (particularly in cases where a series may contain
sub-series), and because they tend to better represent the conceptual
flow of the sentence as well as the verbal flow when it is pronounced
aloud.  In other words, use of serial commans enhances clarity.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"It's just incredible that a trillion-synapse computer could actually
spend Saturday afternoon watching a football game." - Marvin Minsky


body:
On Sun, Jun 25, 2006 at 01:28:46PM -0700, Brion Vibber wrote:
> Jay R. Ashworth wrote:
> > On Sun, Jun 25, 2006 at 12:14:06PM -0600, Chad Perrin wrote:
> [snip way too much text]
>
> Let me summarize what <poem> does, how, and why. <poem> does two
> things:
>
> 1) It *modifies the behavior* of wiki syntax within its borders to
> preserve line breaks and initial whitespace in a different way from

Aha.

> A CSS class by itself is insufficient to do this due to the
> transformations done in wikitext processing, so the extension
> preprocesses the input to allow the "natural" way of pasting in
> poem-like text to work.

Yes.

> 2) It *marks* the contents with a distinct style class ('poem') which
> allows distinct styling to be applied to all <poem>s via the global
> style sheet.

Ok; I thought you'd said that; thanks for confirming.

> Further, a quick note about HTML. Plain old HTML contains a lot of
> often-forgotten semantic elements, such as:
>
> <abbr acronym address code dfn kbd q samp var                        >
>
> Some of those are supported in our wikitext because UseMod supported
> them; others we've never added. But in general, you can note that
> they often would not necessarily have distinct default styles.
> <samp>, <kbd> and <code> usually all render in a monospaced font,
> like <tt>. But they don't have to, and using distinct elements allows
> you to style them consistently, or to treat them differently when
> machine-extracting data. etc.
>
> The set of semantic elements in HTML hints at its creation in a
> physics research lab full of computer geeks. It has excellent coverage
> for writing software manuals and project summary pages, but more
> limited coverage for, say, literature.
>
> Our wiki text has a strong affinity with HTML; we render to it, we
> allow subsets of it, etc. But we aren't HTML exactly, and where
> our needs differ it is fully appropriate to have distinct semantic
> elements.

Nicely put, and confirms what I'd been thinking (which is nice, cause
sometimes the sky in my world is a different color. :-)

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

     A: Because it messes up the order in which people normally read text.
     Q: Why is top-posting such a bad thing?

     A: Top-posting.
     Q: What is the most annoying thing on Usenet and in e-mail?


body:
On Sun, Jun 25, 2006 at 06:28:18PM -0400, Simetrical wrote:
> On 6/25/06, Chad Perrin <perrin at apotheon.com> wrote:
> > Unnecessary repetition leads to unmaintainability, because when you need
> > to change one thing you often end up having to run around changing it in
> > numerous places, and sometimes people miss things.
>
> But in this case, <poem> adds a class that styles the enclosed text as
> a poem.  Among other things, this class includes stuff that would be
> useful for cooking recipes as well, but that's not all it includes.
> What if it turns out people decide, six months down the road, that
> poems should all be blockquoted?  Then you could just add
> "left-margin: 2em;" or whatever to the CSS definition for .class, and
> voila, all poems are instantly blockquoted.  If people have used it
> for hundreds of cooking recipes in the meantime, all of them are going
> to be screwed up, unless coincidentally people also want the cooking
> recipes to be indented.  Users can also provide custom stylesheets, to
> which similar reasoning applies.  And non-visual Web readers will also
> be screwed over.

I'm running out of steam on this discussion, so I'll probably yield the
field after this, but I will say before I go:

I've already pointed out that a "does exactly what we want for thirty
things, but is named for only one, necessitating the creation of
twenty-nine more duplicates on the off-chance we'll change it later"
approach can be avoided for ease of differentiation later by separating
semantics from presentation, and merely linking the two together.  Brion
commented with an explanation of what's going on that sounds like it
might actually be taking the approach I favored, and only the initial
statements' description of what the <poem> tags do created a contrary
impression.  You seem to think that the behavior assumed in that
contrary impression is a better way to do things, however, and somehow
have chosen to avoid addressing my statements about the manner in which
the same positive effects can be had without the weighty negatives.

Guh.  I need a nap.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The first rule of magic is simple. Don't waste your time waving your
hands and hopping when a rock or a club will do." - McCloctnick the Lucid


from_name: Nathan

body:
I never thought I'd say this, but I agree with Phil Welch.

- Nathan (nathanrdotcom)

On Sat, 24 Jun 2006, Philip Welch wrote:

> I think we should replace "neutral point of view" (which is
> abbreviated to the misunderstood acronym NPOV) to
> "neutrality" (which, like "verifiability", is easier to understand).


from_name: Platonides

body:
"Steve Bennett" wrote:
>> Imagine we use the same tag for poems and for cooking recipes. Some time
>> in the future we decide we actually want the mark-up to behave slightly
>> (or even completely) differently for recipes. This is why we need
>> separate mark-up for separate purposes.
>
> I would certainly recommend using {{poem}} and {{recipe}} or something
> in that case. Then you could simply change the template when they
> split.
>

The parser may decide to close <poem> on the end of the template, so you
can't do it...


from_name: Ilmari Karonen

body:
Steve Bennett wrote:
>
> Thanks for this explanation. I don't quite follow the logical step
> that was made between "one common and important use" and "the way this
> should work", but, hey. In practice, in Wikipedia, this "common and
> important" use is basically never used - we certainly don't want ASCII
> art in our articles.

We do, however, quite often want source code in our articles.

--
Ilmari Karonen


from_name: George Herbert

subject: [WikiEN-l] Spoiler Boilerplates

body:
On 6/25/06, Zero <megamanzero521 at yahoo.com> wrote:
>   To whom's decision...? It is censorship. It thrives upon the ideal of a
> person perhaps not engaging in the action by merit of another group
> selectively in the belief they think it might be "cover-worthy", which
> is never the case in any encyclopedia.

How on earth is it censorship?  No information is removed from the article.

If information is there, but someone choses not to read it, as they
want to "be suprised" by the piece of fiction or film or whatever,
that is them using their own judgement.  Not anyone imposing
censorship on them from outside.

All the Spoilers warnings are is a warning flag.  Calling them
censorship is callous abuse of the english language.

--
-george william herbert
gherbert at retro.com / george.herbert at gmail.com


from_name: Vojtech Hala

subject: [Wikitech-l] Mass open proxy blocking

body:
Hello,

I want to discuss a problem that we face on CS Wikipedia. There is
relatively frequent abuse of sockpuppets, especially for ban elusion. It
is also a subject of currently running arbitration case on cswiki between
me (sysop) and a vandal that creates hundreds user accounts and (aside to
useful edits!) disrupts Wikipedia various ways. It is such an extensive
phenomenon that editors often feel sneaking suspicion against almost all
newbies. That's very bad for a wiki project. There is a common rule, that
all rules and sanctions apply to *persons* and not user accounts.

However, it's often very difficult to reliably identify the person on the
other end of the wire, when the persons makes some steps to hide. One way
to improve the identification is the new CheckUser interface that we
extensively use. God bless developers for that. However, it has no effect
when the user hides behind an open proxy server. That leads us to the rule
that forbids using open proxy for editing and allows sysops to block such
IPs permanently. So much to the reasons why we need to proceed mass IP
blocking. Now lets consider how could we do it.

According to several publicly available lists, there are about 20 (maybe
30) thousands such IP addresses. We have about 15 sysops. Not all sysops
are active, not all are interested in this issue, not all have enough
technical skills. This means that some sysop(s) has to perform thousands
of IP blocks. More on that, consider that the sysop should examine each
such address whether it is open on some port or not. It is a
time-consuming and traffic-generating operation which is considered
abusive by some providers. These are the reasons why we decided to use a
robot to do the job quickly and not to check each address. It simply reads
given lists from web, compares them to special:ipblocklist and blocks the
rest.

Initially I developed and run the robot under my sysop account. It blocked
about 500 IPs per night. The blocks were time limited (random interval)
since there was no real check that the address is open. So if some proxy
would close and disappear from the lists, the block would automatically
expire. If not, the next run of the robot would block it again. Later we
have improved it by creating a special account for the robot and setting
him bot and sysop flags. That hided the blocks from RC page and that
allowed us to use the robot through all day, not only at night when nobody
edits. The same thing we did succesfully on cs Wikisource.
http://cs.wikipedia.org/wiki/Wikipedie:N%C3%A1st%C4%9Bnka_spr%C3%A1vc%C5%AF/Archiv6#Proxybot
http://cs.wikipedia.org/wiki/Wikipedista:Proxybot
(pages in Czech)

We are sure that it made the vandal's life more difficult. That was our
goal. Some of the IP checks on sockpuppets shown open proxy addresses that
were blocked closely before the checks. Well done.

However, it has some disadvantages.

1) The biggest one is that setting the bot flag cleans the RC page but
doesn't clean the block logs. The robot messes them up so much that they
become nearly unusable.

2) So many blocked IPs lead to harder server-side checks performed on each
edit of the wiki.

3) Some "innocent" IPs may get blocked.

4) The bot and sysop flag should not be combined. It's probably only a bug
in MediaWiki that allowed us to do it. When you try to set bot flag to
sysop account, the software objects. When you do it in reverse order
(first the bot flag, than sysop) it succeeds. See
http://cs.wikisource.org/wiki/Special:Listusers/bot
that it is possible.

5) Time-limited blocks lead to repeating the same actions and in long time
scale it requires hundereds of block each night. This can be avoided by
infinite blocks.

In april, Anthere removed the sysop flag from Proxybot on cswiki.
http://meta.wikimedia.org/wiki/Requests_for_permissions/Archive_2006/May#Desysopping_of_cs:Wikipedista:Egg
I stoped it immediately, today it is not running even on Wikisource. Most
of the IPs are blocked, some others get blocked indefinitely by a sysop's
hand from time to time. But most of them are blocked for a finite period.
http://cs.wikipedia.org/wiki/Special:Ipblocklist

Currently, the problems with vandals continue, but we are able to manage
them. What we're afraid of is the time when the blocks expire. Let's find
a better solution. For example integrating a list of open proxies directly
into the Wikimedia servers instead of blocking by sysops would be a way to
deal with it.

Thanks for any advice!

--
Vojtech Hala (aka Egg), MFF UK, Prague


from_name: Simetrical

subject: [Wikitech-l] Mass open proxy blocking

body:
On 6/25/06, Vojtech Hala <egg at matfyz.cz> wrote:
> 1) The biggest one is that setting the bot flag cleans the RC page but
> doesn't clean the block logs. The robot messes them up so much that they
> become nearly unusable.

On enwiki, this is solved by the simple expedient of using indefinite
blocks.  These can be lifted by request if it's judged that the proxy
is no longer open.  (See
http://meta.wikimedia.org/wiki/Meta:No_open_proxies.)  Thus, no
clogging the blocklists.

> 2) So many blocked IPs lead to harder server-side checks performed on each
> edit of the wiki.

I wouldn't know whether that's a problem, but I do know that there are
over 60,000 blocks on enwiki, no doubt steadily increasing due to
accumulating infinite-blocked accounts.  I wouldn't worry about this,
or in fact anything techy, unless a) I'm told to worry about it by
brion or b) it seems from personal experience to do something
obviously distressing such as, e.g., crash the site.

> 3) Some "innocent" IPs may get blocked.

Unfortunately unavoidable.

> 4) The bot and sysop flag should not be combined. It's probably only a bug
> in MediaWiki that allowed us to do it. When you try to set bot flag to
> sysop account, the software objects. When you do it in reverse order
> (first the bot flag, than sysop) it succeeds. See
> http://cs.wikisource.org/wiki/Special:Listusers/bot
> that it is possible.

Clever.  Stewards were always able to combine the flags, it's just
Rob's MakeBot that imposed the additional restriction, but of course
that has no control over whether the standard bureaucrat extension can
add sysop to any user at all.

> 5) Time-limited blocks lead to repeating the same actions and in long time
> scale it requires hundereds of block each night. This can be avoided by
> infinite blocks.

Yep, that's what enwiki does.  Then there's no need for a bot, then,
at least past the initial blocks.

> For example integrating a list of open proxies directly
> into the Wikimedia servers instead of blocking by sysops would be a way to
> deal with it.

Well, there my knowledge of the situation ends, so I'll leave that to
the devs.  I couldn't find a feature request at
http://bugs.wikimedia.org/, which is where they generally go, but I
could easily have missed it.


subject: [WikiEN-l] "Good authors"

body:
Wikipedia: The encyclopedia anyone who isn't a douchebag can edit

On 6/25/06, George Chriss <GChriss at psu.edu> wrote:
>
> As much as "love in knowledge" is true, "anyone can edit" distinguishes us
> from other
> knowledge--based projects, such as Encyclopaedia Britannica.  The slogan
> is terribly catchy, and
> we still have readers unaware of the fact that they can edit.
>
> If I had to give Wikimedia projects a new, more accurate slogan, it would
> be "organizing knowledge
> by open editing".  Perhaps the Foundation proper should adopt "for people
> that love sharing
> knowledge"?
>
> -George
> [[User:GChriss]]
>
> <quote who="Erik Moeller">
> > On 6/25/06, Steve Bennett <stevagewp at gmail.com> wrote:
> >> How about "New editors always welcome!" - then, the assumption is that
> >> we will give *anyone* a *chance* (as opposed to implying that we will
> >> let anyone edit, no matter how destructive they are).
> >
> > I agree in principle that the slogan "the free encyclopedia that
> > anyone can edit" is overly simplistic. It reminds me of the famous
> > saying, "I would never want to belong to any club that would have
> > someone like me for a member." It's more of a technical definition
> > than one of principles and goals -- and can easily be confused with
> > the latter.
> >
> > I believe that we need to highlight the mission of providing a great,
> > free encyclopedia, along with the core principle _how_ we want to
> > accomplish it. And the single most important principle I can think of
> > here is not "anyone can edit". It's not even NPOV or any other policy.
> > It's "WikiLove" -- of which our commitment to openness is only an
> > expression. We share a love of knowledge, and we treat everyone who
> > shares the same love with respect and goodwill. (That's the idea, at
> > least.)
> >
> > If I wanted a three word slogan for Wikipedia, it would be something
> > like "Love in Knowledge": emphasizing the core principle of WikiLove
> > as well as the overarching goal to collect the sum of all human
> > knowledge. Come to think of it, "Love in Knowledge" might be a nice
> > slogan for the Wikimedia Foundation. Or is it too kitschy?
> >
> >> We're not elitist at all. The tone of most of our articles is very
> >> folksy and approachable
> >
> > I'm not sure about "folksy," but of course an encyclopedia should be
> > approachable. My idea of the perfect Wikipedia article is one which
> > presupposes very little, and allows me to zoom into any level of
> > detail which I require (following links and references to primary and
> > secondary sources if Wikipedia itself is exhausted). Naturally, by
> > "presupposing little", I don't mean that every concept needs to be
> > explained in every article: that's what links are for.
> >
> > "Elitism of results", as Jimmy put it, doesn't mean to me that we
> > already believe that we've created the best encyclopedia in history.
> > It only means that we believe that we should, and more importantly,
> > that we can. And I think that these beliefs are firmly rooted in
> > Wikipedia's culture.
> >
> > Erik
> > _______________________________________________
> > WikiEN-l mailing list
> > WikiEN-l at Wikipedia.org
> > To unsubscribe from this mailing list, visit:
> > http://mail.wikipedia.org/mailman/listinfo/wikien-l
> >
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


subject: [WikiEN-l] Offline submissions?

body:
Maybe I'm the only one here, but I say "Who cares?"

If they don't have a computer they don't have the time to write an
encyclopedia.  They are trying to hold up two jobs and feed their kids.
There's a reason they don't edit:  they don't care enough and I don't blame
them.

mboverload

On 6/25/06, Anthere <Anthere9 at yahoo.com> wrote:
>
> Andrew Gray wrote:
> > According to the WikiProject Countering Systemic Bias, "The average
> > Wikipedian on English Wikipedia (1) is male, (2) is
> > technically-inclined, (3) is formally educated, (4) speaks English to
> > an extent, (5) is White , (6) is aged 15-49, (7) is from a
> > predominantly Christian country, (8) is from an industrialized nation,
> > and (9) is more likely to be employed in intellectual pursuits than in
> > practical skills or physical labor."
> >
> > The problem with this is the unfortunate gap in coverage that results
> > from a lack of interest from the typical demographic of Wikipedians
> > described above. While this demographic is definitely interested in
> > contributing to a free, online encyclopedia, that doesn't mean the
> > others aren't. One particular problem is that in order to contribute
> > to Wikipedia, you'll need to use a computer. There are others who
> > would probably be interested in contributing to our global effort,
> > too, but don't understand technology. We need to allow them to
> > contribute.
> >
> > For that purpose, I would like to start a project where people without
> > access to computers (or people who voluntarily choose not to use them)
> > can -write- their own Wikipedia entries and mail them in. The first
> > phase of this plan, of course, would be spreading the word. The least
> > expensive way would probably be distributing fliers in frequented
> > areas. People could then write their own articles, and mail them in to
> > the Wikimedia Office. Someone at the office (maybe Monica?) could open
> > the letters, scan them in, and email them to an offline submissions
> > mailing list.
>
> Hello,
>
> Just for the record, Monica is no more working for us. That let's Danny
> to open the letters and scan the content. Then an automatic machine
> could change it at least partially to electronic format. And others will
> have the fix what should be fixed.
>
> I am a bit perplex you call this the least expensive way...
> Of course, Danny frankly has no time to do this at all. I suppose we
> would have to hire students to be the interface... in all honesty, I
> think it is very unpractical, in particular in a language where there is
> already so much content. Most of the time, the article would have
> changed and the new content would need to be integrated to the online
> version. This would be very unpractical.
>
> It has much more chance to work locally, in a rather little developped
> language. Yes, your memory is good, it has been done, by Guaka, in
> Bambara, a bit over a year ago. Guaka directly visited some elders and
> picked up notes.
>
> One of the reasons the editing system works is that it is very simple
> and very quick.
>
>   From there, people interested in the project would
> > transcribe the article into Wikipedia (if applicable, see below) and
> > mail back a corresponding letter featuring a print-out of the new
> > article. Very simple process, plus it would allow people from
> > non-typical-of-Wikipedia-editor backgrounds to put in their word.
> >
> > What if their entry is redundant? Not to worry. If the written
> > submission has content the Wikipedia article doesn't, we add it in. If
> > it doesn't, that's okay. We don't necessarily have to tell them what
> > made it in and what didn't, but either way, a reply will be sent to
> > the writer with a print-out of the article.
>
> Additional costs. Who would support that ?
>
> > ----
> >
> > I'm passing the above on for en:User:Messedrocker, since he's not
> > subscribed to the list. My thoughts:
> >
> > a) This has certainly been done before on a local level with minor
> > languages - was it in West Africa somewhere? My mind is failing me,
> > but I've certainly seen it mentioned on wikipedia-l before - the
> > writing was done by a local elder, transcribed and put online by a
> > volunteer.
>
> Yes. Btw, Guaka will be at Wikimania in Boston. If you go, you may
> discuss this experience with him.
>
> > b) It might well work, but would probably require careful thought and
> > planning - who are we targeting? what sort of articles are we
> > targeting them for? how do we deal with unwanted and inappropriate
> > submissions without causing more badwill than we started with?
> >
> > c) Copyrights. This might get fun.
> >
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


subject: [WikiEN-l] New York Times article

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

> Anyway, the more I consider the facts, the less convinced I am. The
> problem is in the interpretation of "anyone can edit". Does it mean
> "anyone who wants to edit, can", or does it mean "anyone at all can
> edit". Normally this wouldn't matter, but it's critical if we're
> attempting to measure "anyone-can-edit-ness" (ACEN).

Anyone can drive on the public roads.  Of course you need a licence and need
to know the rules of the road.  It's just common sense, we don't need to
fine-tune it.

The problem is that semi-protection lasts longer
> than full protection, as a rule, so that in general this comparison is
> far from true.

What, they can't wait 4 days to edit an article that's a huge source of
vandalism - yet they can still edit the other 99.999% of articles? Boohoo.

mboverload


subject: [WikiEN-l] unblock namela

body:
Who is requesting this?

On 6/23/06, Nolan mccollum <nolanmccollumhotmail.com at hotmail.com> wrote:
>
> please unblock namela now he hasnt vandalized anything in a while.
>
> _________________________________________________________________
> On the road to retirement? Check out MSN Life Events for advice on how to
> get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
>
> _______________________________________________
> 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: Mark Gallagher

subject: [WikiEN-l] How to edit Wikipedia if you're a campaign manager

body:
On 15:42 Phoebe Ayers wrote:
<many snips/>
<quoting Michael Cornfield's article/>
> They have established a Counter Vandalism Unit.

Grr!

Apart from this one sentence, and a few moments where it's evident he's
not familiar with our far-too-complex terminology, this seems (from your
excerpt) a pretty reasonable article.

It's not about How To Whitewash Your Client's Entry, but rather How To
Ensure Wikipedia Is Fair To Your Client --- a noble goal, one we strive
for ourselves (although, unlike Mr Cornfield's target audience, we
aren't being paid for it).  If a bunch of campaign managers and press
agents and other such people want to provide well-sourced information
and try to keep Wikipedia neutral, then good luck to them ... if they
can resist the temptation to go too far in support of their clients.

Cheers,

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


body:
On 6/25/06, Chad Perrin <perrin at apotheon.com> wrote:
> Unnecessary repetition leads to unmaintainability, because when you need
> to change one thing you often end up having to run around changing it in
> numerous places, and sometimes people miss things.

But in this case, <poem> adds a class that styles the enclosed text as
a poem.  Among other things, this class includes stuff that would be
useful for cooking recipes as well, but that's not all it includes.
What if it turns out people decide, six months down the road, that
poems should all be blockquoted?  Then you could just add
"left-margin: 2em;" or whatever to the CSS definition for .class, and
voila, all poems are instantly blockquoted.  If people have used it
for hundreds of cooking recipes in the meantime, all of them are going
to be screwed up, unless coincidentally people also want the cooking
recipes to be indented.  Users can also provide custom stylesheets, to
which similar reasoning applies.  And non-visual Web readers will also
be screwed over.

Anyway, as far as Web standards are concerned, presentation is "indent
this two ems and don't break lines".  Semantics is "this is a poem, so
check if the end-user has set any display preferences for poems, and
if not, indent it two ems and don't break lines".


from_name: George Chriss

subject: [WikiEN-l] "Good authors"

body:
As much as "love in knowledge" is true, "anyone can edit" distinguishes us from other
knowledge--based projects, such as Encyclopaedia Britannica.  The slogan is terribly catchy, and
we still have readers unaware of the fact that they can edit.

If I had to give Wikimedia projects a new, more accurate slogan, it would be "organizing knowledge
by open editing".  Perhaps the Foundation proper should adopt "for people that love sharing
knowledge"?

-George
[[User:GChriss]]

<quote who="Erik Moeller">
> On 6/25/06, Steve Bennett <stevagewp at gmail.com> wrote:
>> How about "New editors always welcome!" - then, the assumption is that
>> we will give *anyone* a *chance* (as opposed to implying that we will
>> let anyone edit, no matter how destructive they are).
>
> I agree in principle that the slogan "the free encyclopedia that
> anyone can edit" is overly simplistic. It reminds me of the famous
> saying, "I would never want to belong to any club that would have
> someone like me for a member." It's more of a technical definition
> than one of principles and goals -- and can easily be confused with
> the latter.
>
> I believe that we need to highlight the mission of providing a great,
> free encyclopedia, along with the core principle _how_ we want to
> accomplish it. And the single most important principle I can think of
> here is not "anyone can edit". It's not even NPOV or any other policy.
> It's "WikiLove" -- of which our commitment to openness is only an
> expression. We share a love of knowledge, and we treat everyone who
> shares the same love with respect and goodwill. (That's the idea, at
> least.)
>
> If I wanted a three word slogan for Wikipedia, it would be something
> like "Love in Knowledge": emphasizing the core principle of WikiLove
> as well as the overarching goal to collect the sum of all human
> knowledge. Come to think of it, "Love in Knowledge" might be a nice
> slogan for the Wikimedia Foundation. Or is it too kitschy?
>
>> We're not elitist at all. The tone of most of our articles is very
>> folksy and approachable
>
> I'm not sure about "folksy," but of course an encyclopedia should be
> approachable. My idea of the perfect Wikipedia article is one which
> presupposes very little, and allows me to zoom into any level of
> detail which I require (following links and references to primary and
> secondary sources if Wikipedia itself is exhausted). Naturally, by
> "presupposing little", I don't mean that every concept needs to be
> explained in every article: that's what links are for.
>
> "Elitism of results", as Jimmy put it, doesn't mean to me that we
> already believe that we've created the best encyclopedia in history.
> It only means that we believe that we should, and more importantly,
> that we can. And I think that these beliefs are firmly rooted in
> Wikipedia's culture.
>
> Erik
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>