No, unfortunately, the only people I know who have access to it at this point are developers who went to Apple's developer conference on Monday, and who got a preview version of Mac OS X Server. And they're under a NDA.

Christiaan

On 9 Aug 2006, at 1:46 PM, Plyd wrote:

On 8/9/06, Christiaan Briggs christiaan@yurkycross.co.uk wrote:

...

For your interest, it looks like Apple has come to the party with a wiki of its own, without the need for people to learn markup language: http://www.apple.com/server/macosx/leopard/wikiserver.html

Do you know a sandbox where we could try it ?

Plyd

On 9 Aug 2006, at 2:00 PM, Steve Bennett wrote:

On 8/9/06, Christiaan wrote:

...

Monday, and who got a preview version of Mac OS X Server. And they're under a NDA.

A leaky one! :)

I hope so! :)

Christiaan

On 08/09/06 05:46, Plyd wrote:

On 8/9/06, Christiaan Briggs christiaan@yurkycross.co.uk wrote:

...

For your interest, it looks like Apple has come to the party with a wiki of its own, without the need for people to learn markup language: http://www.apple.com/server/macosx/leopard/wikiserver.html

Do you know a sandbox where we could try it ?

Yes!

1) Use Firefox 2) Install the extension: https://addons.mozilla.org/firefox/748/ 3) Restart firefox 4) Install the wikipedia/mediawiki script: http://demo.wikiwyg.net/wikiwyg/demo/wikipedia/wikipedia.user.js (You will now have a "Install This User Script" in the Tools menu)

Now Firefox is ready to WYSIWYG edit.

Try out the demo mediawiki site:

1) Go to http://wikiwyg.wikia.com/ 2) Click on "Wikiwyg Disabled" to switch to "Wikiwyg Enabled" (*) 3) Now edit! http://wikiwyg.wikia.com/index.php/Testpage

You will see the normal [Edit] tags are now [Wysiwyg Edit]

Attached is a image of trying it...

Enjoy, Jeff oops, I see you wanted the non-free proprietary apple thing :)

(*) A beta site where it's enabled by default would be cool.

I don't know what kind of formatting you need in Wikipedia other than italics. We should make it as hard as possible to use stupid shit like bold.

On 8/9/06, Christiaan Briggs christiaan@yurkycross.co.uk wrote:

Fantastic, thanks Walter.

Christiaan

On 9 Aug 2006, at 6:01 PM, Walter Vermeir wrote:

...

[MediaWiki] will also be developed by full-time employees of the private organizations Wikia.com (the company of Jimbo) and Socialtext.com. This should increase strongly the development of MediaWiki. A new component to MediaWiki is expected to make "wysiwyg"-editing possible. This means that you will have an editbox that looks like the compose window of Hotmail or Gmail with options the edit a page without to see all the sourcetext with all the code. There is hope that this will lower the barrier for new people to work on the projects. http://wikiwyg.net/ - with a picture how it will (possibly) look like http://www.socialtext.com/node/90 http://ross.typepad.com/blog/2006/08/wysiwyg_and_wik.html

---

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

On 8/10/06, Jay R. Ashworth jra@baylink.com wrote:

On Wed, Aug 09, 2006 at 12:57:58PM +0100, Christiaan Briggs wrote:

...

For your interest, it looks like Apple has come to the party with a wiki of its own, without the need for people to learn markup language: http://www.apple.com/server/macosx/leopard/wikiserver.html

[ looks ]

Oh, it's a wiki with a WYSIWYG editor on the front.

Yeah, we've got that.

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

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

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

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

Steve

On 8/10/06, cohesion cohesion@sleepyhead.org wrote:

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

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

Plyd

1. Click on the text.
2. A surrounding patch of text (a sentence? a paragraph?) is "locked"

(no one else can edit it) and highlighted, and somehow rendered "editable". 3. Edit, drag text around etc. If necessary, mark other bits of text as being "locked" as well so you can edit them. 4. Press a commit button.

No losks are needed. If several people is editing, they will have an edit conflict, like now. 'Please compare it'. And they aren't too frequent.

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

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

Christiaan

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

On Wed, Aug 09, 2006 at 12:57:58PM +0100, Christiaan Briggs wrote:

...

For your interest, it looks like Apple has come to the party with a wiki of its own, without the need for people to learn markup language: http://www.apple.com/server/macosx/leopard/wikiserver.html

[ looks ]

Oh, it's a wiki with a WYSIWYG editor on the front.

Yeah, we've got that.

...

We've been using MediaWiki as our office intranet over the years but it's never been adopted to a level that we think it could be, because of the requirement that users learn wiki markup. For this reason we'll be ditching MediaWiki in our office next year for Apple's Wiki Server.

The reason I'm posting this is simply put forward the view that I hope WYSIWYG or some relevant variant will be developed for Wikimedia projects in the near future, because I think the hurdles that stop many people from participating on our office intranet apply equally to Wikimedia projects. And the hurdle is not that wiki markup is "difficult" or "hard to learn" but that it is intimidating and time- consuming to learn.

With all due respect to your users, bullshit.

Number one, you don't actually *need* to use any markup at all. Number two, the markup you might *want* to use is so trivial, that I have to say that anyone who can't be bothered to learn it -- it's just that: they can't be bothered.

Screw 'em.

If you're not willing to learn the tools, you're not entitled to the ease their use contributes to your life. And good riddance.

I'm elitest, sure, but that outlook is *not*, IMHO.

...

I have little doubt that one day using wiki markup only to edit websites like Wikipedia will be seen as an anachronism, even more so as other alternatives to MediaWiki (such as Apple's Wiki Server) come online, but there's a few hurdles to overcome yet and they're not all technical ones as far as I can work out.

It's always surprised me that WYSIWYG editing has not been made a high priority for Wikimedia, considering the fact that it was founded on the idea of broad participation. Although technical difficulties are often put forward as the reason, the biggest obstacle, it has often seemed to me, is an installed base of Wikipedians who see wiki markup as a way of protecting their territory and minimising participation by others. I've even had people argue that wiki markup is some kind of "intelligence" hurdle that people should have to overcome before being allowed to edit Wikimedia projects. Somehow this needs to be overcome if WYSIWYG is to gain traction and get a higher priority it seems to me.

Bullshit.

There will need tobe markup in the internal storage format anyway; if you want WYSIWYG, you bolt it on around the outside. That's the only design pattern that makes any sense at all.

Given that, I see no reason to penalize those who *prefer* power by making the markup language inaccessible -- which I'd bet cash Apple has done -- and if you want or need a WYG editor, put one on there.

But don't dis MediaWiki because the native interface is ... the native interface. That's just strawman.

...

Thanks to those who have been working on WYSIWYG for MediaWiki, particularly in trying to integrate FCKEditor, and I wish you well. However, if integrating an editor into the current environment is so difficult maybe there needs to be a new approach, such as developing new software/syntax with some type of WYSIWYG editor built in from the start? Worth a discussion at least, I should imagine.

I don't think so.

Rebuilding MediaWiki from scratch? That's crazy talk.

If the problem is the weak definition of the markup language, then precess that around until you get it stable enough to WYG in front of.

Anyone along the way for whom this isn't the right tool will no doubt find something else. Darwin lives.

Cheers,

-- jra

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

The Internet: We paved paradise, and put up a snarking lot. _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l

Christiaan Briggs wrote: Hey! What kinda' dialogue is this - certainly you can find better ways to express yourself. If not, then perhaps you might just want to "turn down the volume".

Human-Computer-Interaction/Computer-Human-Interaction both exist, sometimes they overlap sometimes that don't. The truth, or the real-world (as it were) lies somewhere in-between the poles of pure research.

In some cases one works better than others - by way of the absurd consider the brakes on Fred Flintstone's car and the vitech brakes on my Mazda. Which is better? depends on the environment and the limits of existing, local technology.

All that aside - there really was no reason to be rude.

r

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

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

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

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

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

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

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

Then you need to read a little more slowly.

Christiaan

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

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

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

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

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

Christiaan

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

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

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

Christiaan

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

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

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

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

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

Christiaan

On Thu, Aug 10, 2006 at 10:21:24PM +0200, Steve Bennett wrote:

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

Hee.

Cheers, -- jra

On 8/10/06, Simetrical Simetrical+wikitech@gmail.com wrote:

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

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

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

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

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

Steve

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

On 8/10/06, Simetrical Simetrical+wikitech@gmail.com wrote:

On 8/10/06, Steve Bennett stevage@gmail.com wrote:

...

Ok, you're treating wikisyntax and HTML as essentially equivalent. Which they're not.

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

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

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

...

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

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

...

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

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

On 8/10/06, Simetrical Simetrical+wikitech@gmail.com wrote:

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

<snip> Sounds sensible.

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

We should examine this proposal in more detail, it's kind of interesting...

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

I think what I was proposing would not necessarily require a javascript parser. I think? Instead, it would work something like this:

1. Engine simultaneously presents rendered output and wikitext, with synchronisation points between them 2. User edits some rendered output, transforming it purely at the appearance level 3. Page sends rendered text back, engine compares it somehow with what it sent, and works out the wikitext transformations required.

Or something.

Steve

On 8/11/06, Simetrical Simetrical+wikitech@gmail.com wrote:

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

If you "ditched the wikitext" you would end up storing metadata in some other form, like additional XHTML attributes, comments or something. Meaning a whole new grammar to define?

Steve

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

Simetrical wrote:

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

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

Heck, we should have done that for mw:nowiki

I'm afraid my message may have been lost in the postings, but I think it's an important point:

What does Wikipedia need WYSIWYG? We already have noobs writing POV articles, now you want

* Large red text * tons of bold * Large purple text

?

I honestly don't see the point.

mboverload

On Fri, Aug 11, 2006 at 01:29:09PM +0200, Steve Bennett wrote:

• We haven't specifically talked about Wikipedia - MediaWiki is used

by lots of other sites, businesses etc, which would definitely benefit from being more "noob"-friendly.

No, but it's been suggested that *major* (replacing wikitext entire with XML is 'major') structural changes be made to MediaWiki *which would likely make things harder for Wikipedia, for the benefit of those non-WMF users of MW.

It's been said before (check the archives) that changes in that category just aren't gonna hunt.

Cheers, -- jra

On 8/11/06, Christiaan Briggs christiaan@yurkycross.co.uk wrote:

On 11 Aug 2006, at 11:51 AM, mboverload wrote:

...

What does Wikipedia need WYSIWYG? We already have noobs writing POV articles, now you want ...

And there's an example of the attitude I was talking in my first post. It's curious in that it accepts that wiki markup is barrier to participation but that this is somehow a good thing.

Sometimes barriers to participation *are* a good thing. Various online communities have noticed that the harder you make it to participate, the better quality participants you get.

OTOH, Wikipedia explicitly wants contributions from *everyone*, even if they are 14 and have trouble spelling Pokémon...

Steve

Steve Bennett wrote:

Sometimes barriers to participation *are* a good thing. Various online communities have noticed that the harder you make it to participate, the better quality participants you get.

OTOH, Wikipedia explicitly wants contributions from *everyone*, even if they are 14 and have trouble spelling Pokémon...

Well, actually, no we do not want those. I agree with you about barriers to participation.

But the problem is: wikitext as a barrier to participation is not particularly effective: it is too broad, and too narrow.

It does not generally exclude the wired generation of 14 year old pokemon fans who grew up on the web. It does generally exclude scholars of ancient Chinese poetry.

Better to use a different filter, like the "block" function in the software, I think.

Jay R. Ashworth wrote:

For Wikipedia, specifically, any cost which much be paid by potential editors -- within reasonable limits -- is a *good* thing, as it weeds out an increasingly larger pool of potential vandals.

This is less of an issue on non-WMF sites, but I really *do* think it's a good thing for wp, et al, yes. It *is* possible for vandalism to outstrip the capability of the active userbase to clean it up; negative feedback is useful.

I am not so sure that "difficult editing" is an appropriate filter, though.

First, to be a vandal, one need not learn the nuances of the table syntax. Second, most vandals are young and web savvy... we are probably slowing them down less than we are slowing down wise and thoughtful people who are not web savvy.

--Jimbo

Hi all,

Just a quick question on this topic. Is it really the wiki syntax that people have difficulties to use (I mean the fact that you need to enter keywords and delimiter instead of clicking on "title1") or is it the semantic (not sure of the term) approach?

I mean, most word beginners only use direct formatting command (bold, font size), whereas wikipedia encourages a more advanced solution (well, not as much as it should be) where you define that something is a level 3 title, not the way it should be displayed.

Maybe I'm completely wrong (I come from the LaTeX world), but I wouldn't be surprised if the main difficulty for newcomers was this semantic approach more than the lack of GUI.

What do you think?

Cyril

Just found this: http://www.socialtext.com/node/90

this: http://ross.typepad.com/blog/2006/08/jimmy_wales_kic.html

and this: http://wikiwyg.wikia.com/

Includes:

Wikiwyg is a joint venture between Socialtext and Wikia to bring WYSIWYG to MediaWiki.. Release date uncertain, but both wikia and Socialtext are devoting full time development resources towards it. My anticipation is that this is a big part of wiki editing and free culture. My friend who when to Harvard to study Chinese history spent the last 16 years looking at the 8th century. Read about Wikipedia and was excited to contribute. Looked up articles on what she knew (read like an elderly chinese man in san francisco who loved the old poets). She never edited. She clicked on edit and saw some scary markup. Some think this was a good thing, a barrier to entry, but it keeps out some smart people, and it doesn't keep out idiots (they are highly motivated). Wikiwyg, in some shape or form is the future of the internet.

On 8/11/06, mboverload mboverload@gmail.com wrote:

What does Wikipedia need WYSIWYG? We already have noobs writing POV articles, now you want

• Large red text
• tons of bold
• Large purple text

?

Nobody said what buttons will be available. A "color" button is not available now, and should never be available . . . but the markup will still be available to those who know how to enter it, however that will be, just as it's available now.

The goal is to increase accessibility as much as possible.

On 8/11/06, Jay R. Ashworth jra@baylink.com wrote:

But the data is completely anecdotal: we have people who complain about it. Great. But we have *hundreds of thousands* of editors who have created, literally, millions of pages on Wikipedia.

Pfft. That's equally anecdotal.

And I rather strongly suspect that you'd find that *lots* of the editors we have now would much prefer to stay in wikitext. I'm damned sure I would.

If the WYSIWYG editor were actually good, and actually displayed *exactly* what the end result would be, I think you'd find that you'd acclimate to it extremely quickly. I agree that most existing WYSIWYG editors are obnoxious in various ways; this plan is contingent upon making one that is not. If you would still prefer to edit it directly, hey, XML is meant to be human-readable.

On 8/11/06, Jay R. Ashworth jra@baylink.com wrote:

Wikitext is one of the simplest markup schemata -- for it's power -- that I have *ever* seen, in 20 years of staring at markup languages.

In terms of easiness to learn and type, yes. In terms of the backend syntax, it's hell, especially when prefab syntaxes are available that will serve the purpose just as well. Some people are currently struggling to put together a grammar so that a decent parser can be compiled, effort that's completely pointless when we could just use XML.

On 8/11/06, Jay R. Ashworth jra@baylink.com wrote:

But you remain correct: an overlay WYSIWYG editor, perhaps within the contstraints Steve mentioned in an earlier message, will serve the requirements you have, without requiring much (if any) underlying modification.

If one can be written that doesn't show up massive discrepancies with the actual displayed text . . . if the Wikiwyg programmers didn't have to deal with the crazy syntax, they could work on stuff like displaying templates properly instead of getting weird mixes of varying numbers of apostrophes to mimic the behavior of our labrynthine parser.

On 8/11/06, Jay R. Ashworth jra@baylink.com wrote:

No it's not. It's statistical.

It's anecdotal, because it's not controlled. Something does not become statistical evidence just because the numbers are big. It must be statistically analyzed with respect to whatever you're gathering evidence for, which requires some kind of baseline to compare it to.

Really, no. It's long since been scientifically tested and proven that people who keep their hands on the keyboard can accomplish tasks much faster than those who have to move them to the mouse.

Ever heard of keyboard shortcuts?

Evolutionary change.

Is sometimes not the best solution.

On 8/13/06, mboverload mboverload@gmail.com wrote:

On 8/11/06, Simetrical Simetrical+wikitech@gmail.com wrote:

...

If the WYSIWYG editor were actually good, and actually displayed *exactly* what the end result would be, I think you'd find that you'd acclimate to it extremely quickly.

That's not WYSIWYG, that's live preview.

Oops, that came out wrong, what I meant was that live preview can do that, no need for WYSIWYG

mboverload wrote:

Maybe I need to simplify it further:

The only syntax people need to learn is [[link]]. That's it. Maybe ''italics'' if they feel like it. There's no need to do anything else.

That's damn simple.

Hoi, If we are going to be that simple just leave the ''italics'' as it is incompatible with some languages. Thanks, GerardM

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

Simetrical wrote:

I don't know why you think a WYSIWYG editor necessarily needs to encourage anyone to make large bold red text.

It's a hyperbole, I agree, however, the basic gist is there. People have their own idea of "What looks right", and then, if given the tools to do so, will reformat the text to their vision, not necessarily preserving structural meaning. (And, many other times, it just looks plain bad. Check out all those free-hosted amateur websites out there).

A good example happened a while ago in a series of articles on a few bands. A few anonymous editors had been trying to spruce up the pages with lots of HTML, adding non-standard styling and the whole nine yards. Now, this was troublesome from a few editors who knew how to write HTML. Give that weapon to regular people.

The bottom-line is WYSIWYG is an even worse offender of causing people to base things around presentation rather than structure. Granted, wikitext can be abused, but when all that extra possible styling is stuffed away in esoteric <span>s and <div>s, it will prevent most Joe Averages from excessively formatting text.

One may argue that Wikitext doesn't really enforce structure. At least we don't have people typing [font size=5][b]Header[/b][/font] (bbcode, see it a lot in tutorials).

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

Simetrical wrote:

That's why you don't give them easy access to tools like font color, just as they don't have easy access now (they have to know the right HTML). The editor will have to display such text correctly, and give *some* way to allow it to be added (unless you want to ban inline style altogether), but it doesn't have to be easier than now.

Well, right now, there's really no reason for people to be using inline style except for formatting templates, infoboxes, and portals. So yeah, banning inline style wouldn't be too much of a stretch.

On 8/13/06, Edward Z. Yang edwardzyang@thewritingpot.com wrote:

The bottom-line is WYSIWYG is an even worse offender of causing people to base things around presentation rather than structure. Granted, wikitext can be abused, but when all that extra possible styling is stuffed away in esoteric <span>s and <div>s, it will prevent most Joe Averages from excessively formatting text.

I'm not sure I share the attitude that the only way to avoid Wikipedians making incredibly ugly articles with too much character formatting is to make it difficult for them.

Steve

On 8/14/06, Edward Z. Yang edwardzyang@thewritingpot.com wrote:

There's a difference between making things difficult and not making shortcuts for those things. You could look at wikitext as HTML on steroids: non-SGML shortcuts for the most commonly used formatting, but after that you have to use HTML.

If we make a WYSIWIG editor, I wouldn't give users a box to pick colors with. I probably wouldn't let them change font either (though switching to monospace is acceptable) or let them change font size. If they want to do that, let them switch to HTML mode and write the HTML themselves.

I would probably do that too, but simply because font-changing is an incredibly rare thing to want to do at Wikipedia, and therefore of little value in the GUI. I don't think I've ever changed typeface, and only occasionally changed point size, mostly for tables. Changing font color is occasionally useful for tables - but it would be much better to have predefined styles for that.

All of this is quite a tangent from the original question about WYSIWYG editors though. The basic question is "is it possible to have a user-friendly, genuine WYSIWYG editing tool that does not conflict with editors working directly in wikitext". The follow-up question is "is anyone going to write it?"

Steve

On Sun, Aug 13, 2006 at 06:29:30PM -0400, Simetrical wrote:

On 8/13/06, Steve Bennett stevage@gmail.com wrote:

...

All of this is quite a tangent from the original question about WYSIWYG editors though. The basic question is "is it possible to have a user-friendly, genuine WYSIWYG editing tool that does not conflict with editors working directly in wikitext".

Certainly it is. As has been noted, it's going to be difficult to make it 100% until the syntax is formalized.

And my counter-question is "What about a WYSIWYG editor that's good enough to make working directly in wikitext unnecessary for even the most hardcore power-users?"

*Why do you continue to presume that those hardcore power-users Won't Want To Use Wikitext.* I'm *not* one of them, and I damned sure want to.

...

The follow-up question is "is anyone going to write it?"

That's a definite yes. Jimbo hath spoken, and I think work is supposed to already be underway (but apparently not in our SVN repo).

Quite so.

Cheers, -- jra

On Sun, Aug 13, 2006 at 09:48:50PM -0400, Simetrical wrote:

On 8/13/06, Jay R. Ashworth jra@baylink.com wrote:

...

*Why do you continue to presume that those hardcore power-users Won't Want To Use Wikitext.* I'm *not* one of them, and I damned sure want to.

I don't assume that. I assume that many will be sufficiently averse to WYSIWYG editors, based on prior negative experiences with them, to not want to. But I also assume that if there are no areas in which the editor is genuinely lacking compared to wikitext editing, they'll quickly get used to it, like it or not.

I disagree, entirely.

You're indifferent to those who are turned off by wikitext, and suspect that they aren't too numerous. I'm indifferent to those who are turned off by WYSIWYG, and suspect that they aren't too numerous. Fair's fair, hmm?

I am not indifferent to those who are turned off to wikitext. I actively think they're lazy, and disinclined to learn about the world around them.

But I realize that they exist, and I understand that some of them have contributions to make to Wikipedia.

As for people who are turned off by WYSIWYG... you're generalizing from me, and I don't think that's reasonable, either. I'm not "turned off" by WYSIWYG. I just feel that there are good reasons why it's not necessarily the best solution *in this particular use case* -- particularly if it's implementation *penalizes* the people who prefer not to use it.

Please, let's not mischaracterise my opinion just because we don't agree with it.

Cheers, -- jra

On Sun, Aug 13, 2006 at 10:16:06PM -0400, Simetrical wrote:

On 8/13/06, Jay R. Ashworth jra@baylink.com wrote:

...

I am not indifferent to those who are turned off to wikitext. I actively think they're lazy, and disinclined to learn about the world around them.

That only strengthens my point, if anything.

But don't bother to quote the part of my message wherein I prove reasonable.

Nice rhetoric there...

Cheers, -- jra

On 14/08/06, Simetrical Simetrical+wikitech@gmail.com wrote:

On a somewhat different topic . . . the WYSIWYG editor we use will be open-source, yes? If so, and if it's under development, where's the repo? If not . . . that's a surprise, I must say.

Obviously we missed the part where they decided to use the waterfall method of development, but not to worry - I'm sure the decision on what brand of coffee will be drunk is IMMINENT, and we all know that is a VITAL step.

Christ, there's a lot of throwing words around on this list. I turn my back for a month or two and you lot start fighting without me? I call that downright rude!

On a more serious note, let's all just chill out for a second and remember that everyone is bound to have a different opinion regarding interacting with the software; editing is, after all, the main functionality within MediaWiki, and as a consequence, the editing interface is one of the most critical. Which means that any changes being made to it, or to supplement it or <insert chosen verb arrangement here> need careful thought, and discussion...

...sure. But then, if it doesn't *hurt* in the short term, and someone has the balls to hack a few test implementations and ideas together, good for them.

Rob Church

On 14/08/06, Edward Z. Yang edwardzyang@thewritingpot.com wrote:

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

Rob Church wrote:

...

Rob Church

Rob! You're back! :-)

Not quite, see mediawiki-l archive. But I can't resist making a tasteless comment and winding up an explosive situation once in a while. Or something.

...

But then, if it doesn't *hurt* in the short term, and someone has the balls to hack a few test implementations and ideas together, good for them.

Hmm... so the core MediaWiki developers had nothing to do with this?

We still have those? No, I was under the impression we were going to do sensible things like formalise the parser specification and stuff before we got onto that. At least, that's what our CTO advised and explained to me, and I agreed. But if the President has given his Orders...

The rationale behind the statement I made above was, "Proof of concept doesn't hurt. Ideas, thoughts - scribbled notes on how something might be done...it all saves time and patent applications for Wheel 2.0 later on, doesn't it?

Rob Church

On 14/08/06, Jay R. Ashworth jra@baylink.com wrote:

Certainly. Never argued that. I was just trying to rein in a little people's flights on completely replacing the internal storage format with, say, XML, in the service of that sort of work.

Oh, I don't know. XML is very enterprisey. Do we want to be enterprisey?

Rob Church

On 14/08/06, Simetrical Simetrical+wikitech@gmail.com wrote:

On 8/14/06, Rob Church robchur@gmail.com wrote:

...

Oh, I don't know. XML is very enterprisey. Do we want to be enterprisey?

Possibly, but more to the point, most major browsers have XML parsers built-in and accessible to Javascript, which means WYSIWYG speed and simplicity unachievable by any custom syntax. Although possibly the reply is too serious for the question.

ENTERPRISEY! Come on, I was bloody teasing! Surely the references to the waterfall method gave you some idea?

I fear for the future of sarcasm; of parodies and piss-takes, etc.

Rob Church

On Mon, Aug 14, 2006 at 02:54:43AM -0400, Simetrical wrote:

On 8/14/06, Rob Church robchur@gmail.com wrote:

...

Oh, I don't know. XML is very enterprisey. Do we want to be enterprisey?

Possibly, but more to the point, most major browsers have XML parsers built-in and accessible to Javascript, which means WYSIWYG speed and simplicity unachievable by any custom syntax. Although possibly the reply is too serious for the question.

My Blackberry will not parse XML.

(Don't laugh: that's an enterprise-y answer to the question. Non-WMF implementations are not the prime goal of the code, but any implementer who ignores them does the community a disservice as well, IMHO.)

Cheers, -- jra

On Mon, Aug 14, 2006 at 03:22:41PM -0400, Simetrical wrote:

...

You do; I gather Simetrical does not.

More precisely: I contemplated the possibility that the current markup is no longer necessary. I do not necessarily adhere to that view dogmatically or without reservation, although up to this point I may have allowed myself to be drawn into the argument beyond my level of conviction.

Noted. My apologies if I presumed you to be more partisan than you actually are.

On 8/14/06, Jay R. Ashworth jra@baylink.com wrote:

...

My Blackberry will not parse XML.

Which is why there would be a Javascript fallback, which could probably be grabbed from any number of open-source projects. Since the syntax is well-defined, popular, and much simpler than that of wikicode.

While my BlackBerry *will* run JavaScript, if I tell it to, it would probably choke on something the size of a Wysieditor.

Cheers, -- jra

On 8/14/06, Jay R. Ashworth jra@baylink.com wrote:

...

And my counter-question is "What about a WYSIWYG editor that's good enough to make working directly in wikitext unnecessary for even the most hardcore power-users?"

*Why do you continue to presume that those hardcore power-users Won't Want To Use Wikitext.* I'm *not* one of them, and I damned sure want to.

I think it's fair to assume that there will be people who will always prefer working directly "in the code" (whatever that means). It's probably also reasonable to say that a full WYSIWYG layer which makes wikitext redundant for the user is also a good thing.

In other words, the "hardcore user" should have the option of editing directly, but he shouldn't have to, no matter how hardcore he is :)

Steve

On 14/08/06, GerardM gerard.meijssen@gmail.com wrote:

Hoi, It is "nice" to have things both ways. However you have to realise that one reason why the parser is ugly is because of all the provisions to make life easy for people who do not code properly their wikisyntax. When the code is generated, there is no excuse for these "abominations" and much saner text can be generated.

Yes, yes, I know. Users don't embrace concepts such as matching tag pairs and making stuff clean, else we could let them use an XHTML subset. C'est la vie.

However, I think it's more correct to state that a lot of parser ugliness comes from bolting on behaviour and hacking stuff in at a fast clip, to provide extras. A lot of the behaviour people depend upon is due to bugs in the parser, which are now considered de facto, but which shouldn't be happening.

There is also the long standing wish by many to make the wikisyntax universal as in software independent. When the wikisyntax is hidden from view, this is possible. An other thing is, it will allow us to fix problems like the '' problem with the Neapolitan language. As it is, the wikisyntax is ugly, it does not work properly in all circumstances and consequently the arguments to do away with direct editing of the MediaWiki syntax are quite powerful.

Indeed. There's also a long standing wish by many for world peace, worldwide nuclear disarmament, an end to global poverty and fair trade for everyone. But unfortunately, those things can't practically be done in a single sweeping step.

I don't agree that hiding wiki markup is the productive step. As has been pointed out often on this list, power users and people who are comfortable with it are more productive with markup. Your solution is "let's break the syntax and hide the mess behind a graphical user interface", which I don't agree with.

Do that, and I won't edit. Do that, and people using older browsers (long live lynx) and screen readers, or not embracing "newfangled" script technologies, etc. can't. So hiding wiki markup and locking it out of sight is not an option, and it should not be. If Joe User wants to view his markup, he should be allowed to. WYSIWYG is *not* a quick fix for the parser.

Rob Church

On Mon, Aug 14, 2006 at 03:06:18AM -0400, Simetrical wrote:

So how about using XHTML internally and when sending to WYSIWYG, but if the user wants to manually edit it can be converted to wikitext and then back?

Size.

One of the reasons wikitext is as easy to comprehend as Rob and I assert that it is (and you disagree with) is that it is *physically compact*.

Hey, brion: what's the size of article bodies right now, in GB? :-)

          That way, third parties can make easy use of the dumps,

and WYSIWYG becomes easier to work with, but those who really want the old markup can use it. There's no particular reason there shouldn't be a basically one-to-one correspondence between wikitext and XHTML ??? the latter would largely just be a translation of the former into different syntax.

If there are two formats which are exactly round-trippable, and one of them is a) smaller, and b) supported by the current code... why would we change, again?

Cheers, -- jra

On 8/14/06, Eric Astor eastor1@swarthmore.edu wrote:

Just a note on size - this is an argument that I think holds a lot of value. XHTML is, on average, about 12x larger than wikitext...

Out of curiosity, where'd you get that figure? Recall that we aren't talking about the page output, just an XMLized wikimarkup (so something like <wm:a href="link">display</wm:a> instead of [[link|display]]).

On 8/14/06, Eric Astor eastor1@swarthmore.edu wrote:

Experiments with page output, actually, for the full Simple English Wikipedia... My experiments also showed compressed HTML for the full page output to be roughly 3x larger than compressed wikitext. That is full page output, so the point is probably lost somewhat - but considering that the full output should be *more* repetitive than the XML-ized markup, I'd still be surprised if the database didn't double in size, at a minimum. Anyone care to run the full database through a conversion to XML and run the experiments? I'm a little short on time lately.

I've converted the first few sections of [[Paris]] (by hand) and done the comparison on them. (The XML isn't perfect — I didn't convert character entities, for instance — but it suffices.) The input was 12.7 KB, the XML 17.1 KB; after ZIPping with normal compression, the difference dropped to 5.12 KB to 5.43 KB, and with best-compression RAR, the XML was actually a bit smaller (4.47 to 4.61). If we *do* work with compressed databases, then increase in size from XML looks to be trivial.

(Files available upon request.)

Hoi, "Do that and I won't edit" .. here we have a power user speaking.. Not much of an argument really. I expect Lynx to be used, but how many people actually use it and how many people actually edit using Lynx ?

When progress in any direction is impossible because of external factors, you paint a great argument for abandoning MediaWiki altogether and come up with something that is more sane. Convert the data to NewMediaWiki and tell the "power" users and lynx users "live long and prosper".

Thanks, Gerard

On 8/14/06, Rob Church robchur@gmail.com wrote:

On 14/08/06, GerardM gerard.meijssen@gmail.com wrote:

...

Hoi, It is "nice" to have things both ways. However you have to realise that

one

...

reason why the parser is ugly is because of all the provisions to make

life

...

easy for people who do not code properly their wikisyntax. When the

code is

...

generated, there is no excuse for these "abominations" and much saner

text

...

can be generated.

Yes, yes, I know. Users don't embrace concepts such as matching tag pairs and making stuff clean, else we could let them use an XHTML subset. C'est la vie.

However, I think it's more correct to state that a lot of parser ugliness comes from bolting on behaviour and hacking stuff in at a fast clip, to provide extras. A lot of the behaviour people depend upon is due to bugs in the parser, which are now considered de facto, but which shouldn't be happening.

...

There is also the long standing wish by many to make the wikisyntax universal as in software independent. When the wikisyntax is hidden from view, this is possible. An other thing is, it will allow us to fix

problems

...

like the '' problem with the Neapolitan language. As it is, the

wikisyntax

...

is ugly, it does not work properly in all circumstances and consequently

the

...

arguments to do away with direct editing of the MediaWiki syntax are

quite

...

powerful.

Indeed. There's also a long standing wish by many for world peace, worldwide nuclear disarmament, an end to global poverty and fair trade for everyone. But unfortunately, those things can't practically be done in a single sweeping step.

I don't agree that hiding wiki markup is the productive step. As has been pointed out often on this list, power users and people who are comfortable with it are more productive with markup. Your solution is "let's break the syntax and hide the mess behind a graphical user interface", which I don't agree with.

Do that, and I won't edit. Do that, and people using older browsers (long live lynx) and screen readers, or not embracing "newfangled" script technologies, etc. can't. So hiding wiki markup and locking it out of sight is not an option, and it should not be. If Joe User wants to view his markup, he should be allowed to. WYSIWYG is *not* a quick fix for the parser.

Rob Church _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l

Hoi, If these other users like you do not have a chance to edit anyway.. what is your point ? And how many insist on their use of "power" by effectively threatening stagnation because of the unwillingness to move forward ? Should we not consider the gains made by providing a better environment and the potential influx of new capable people against the potential of "power" users that may or may not abandon editing MediaWiki ? Thanks, GerardM

On 8/14/06, Rob Church robchur@gmail.com wrote:

On 14/08/06, GerardM gerard.meijssen@gmail.com wrote:

...

Hoi, "Do that and I won't edit" .. here we have a power user speaking..

No. The statement means "if you take away the underlying ability to edit wiki markup and force users to use a GUI and all sorts of wonderful [E]TLAs in order to edit, then many users, this one included, won't bother."

Not that I get a chance to edit anything Wikimedia-related these days anyway.

Rob Church _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l

On 8/14/06, Rob Church robchur@gmail.com wrote:

My point is that if you start losing users, you're in trouble. No-one's threatening stagnation, we're simply trying to argue that restricting editing to a fancy interface is a bad idea...locking people out of the underlying markup layer is a bad idea...there is no unwillingness to move forward. I haven't said "this is a shit idea and Jimbo is a moron", have I?

Allow me to alienate everyone by proposing the controversial idea that if we made life easier on novice users, at the expense of hardcore users (who are "locked out" and hence leave Wikipedia for ever), Wikipedia would still be better off?

Discuss.

Steve

On 8/14/06, Rob Church robchur@gmail.com wrote:

It's not a controversial idea, it's just stupid. Sorry.

Heh. :) Here's my logic: There are lots more "non-technical" users than technical ones. We already have a heavy bias in favour of technical users. Therefore, encouraging non-technical users at the expense of technical ones increases the number of users *and* corrects our bias. Win, win!

Steve

Rob Church wrote:

On 14/08/06, GerardM gerard.meijssen@gmail.com wrote:

...

Hoi, If these other users like you do not have a chance to edit anyway.. what is your point ? And how many insist on their use of "power" by effectively threatening stagnation because of the unwillingness to move forward ? Should we not consider the gains made by providing a better environment and the potential influx of new capable people against the potential of "power" users that may or may not abandon editing MediaWiki ?

My point is that if you start losing users, you're in trouble. No-one's threatening stagnation, we're simply trying to argue that restricting editing to a fancy interface is a bad idea...locking people out of the underlying markup layer is a bad idea...there is no unwillingness to move forward. I haven't said "this is a shit idea and Jimbo is a moron", have I?

It's quite possible for us to provide a nice little WYSIWYG interface to start with, degrading gracefully to editing the markup for advanced users who specify thus in their user preferences, or whose browsers/environment don't support it. Doing anything other than that breaks Wikimedia's lovey-dovey pact of accessibility, and I'm sure we don't want to do *that*, now, do we?

Rob Church

Hoi, As I explained before, the current wikisyntax is broken. It discriminates against those users who have keyboards where the keys, "we" who use a "US-keyboard" take for granted, are missing. There is no strategy and we are unwilling to consider how to remove the use of the codes to indicate italic script. The double quote is used in the Neapolitan language. Suggesting that our current functionality is great is demonstratively wrong. Your suggestion does not allow these things to be fixed because people will be up in arms when we suggest that these things need fixing. Like you many will suggest that they will vote with their feet.

In many ways, this argument is like the one at the start of the previous century that someone has to walk with a flag in front of an automobile. We all know this did not last and we also know that the car is now one of the biggest killers of our society. However, nobody can seriously suggest that something can be done about it because it would diminish "freedom", when they do they are largely ignored.

Thanks, GerardM

May I remind you things "thing that newbies need" are ALREADY in buttons ABOVE the text box, along with headings, external links, images, nowiki, and others which even I never use.

I don't accept any argument that says WYSIWYG is needed for newbies.

Why do we need WYSIWYG to visualise italics and bold?

On 8/14/06, Steve Bennett stevage@gmail.com wrote:

Wikiwyg implementation as seen at http://wikiwyg.wikia.com

All I see is a not-so-live live preview

On Mon, Aug 14, 2006 at 01:29:02PM +0200, Steve Bennett wrote:

Make an effort. Please.

But I thought that wasn't an acceptable argument in this thread...

<gdrvvf>

Cheers, -- jra

On 8/14/06, GerardM gerard.meijssen@gmail.com wrote:

We need to change how we indicate italics and bold because the way it is implemented is incompatible with some natural languages.

They're incompatible, in a very minor way, with a somewhat uncommon grammatical construct, which occurs in exactly one natural language, spoken by comparatively few people - let's not exaggerate here. And the last I heard, the one problem they were having (notably, categories) had a simple workaround: using the unicode in place of one of the ' characters, like '&#14; or something.

Steve

Well: let's make some practical point: people on the nap.wikipedia are driven away because they have to use workarounds for '' - that is &#39; in whatever combination - we now uwse &#39;&#39; for '' to have a unique way to identify words and word combinations if some day we should need to use replace.py. Many now create non-standard artilces using the accent of à or á that it ` or ´ to create articles ... inserting spaces where they are not needed etc. (all sorts of strange solutions to avoid to see all in italics afterwards) before the &# thingie we needed to use <nowiki> to get things right. It is an annoyance to have continuously use workarounds - now I am quite "wikiphile" I'd say, being able to install my own wikis + extensions and create sometimes quite complicated templates ... imagine how someone feels who has no clue at all about wikis - someone who would like to start a first article and then, clicking on save gets weird stuff and therefore does not come back to edit again, because editing is "too difficult". I have also plenty of colleagues who maybe would like to help, but simply don't want to loose the time to learn wiki, because donating a translation is already a lot considering how much they would earn if they did translation jobs instead.

Next thingie - the | sign - you don't have it on the German keyboard - and it gets even worse if you have a laptop keyboard like I have - there is no way to reproduce it easily with alt+<numeric code> like I could do it on a normal keyboard.

How I work on the nap.wikipedia? Well there are two things to it: I first write in OOo or Word, then I subsitute all '' with the numeric code with search and replace and I avoid to create wiki-links, because I am simply very annoyed (better I remain with nice words...) to copy and paste it here and there. Or I write the article on the wiki and then substitute the parts needed - both ways require loads of time more.

At least the {{ [[ are on the keyboard - so normal wiki-links are not much of an issue - for Wiktionary that works fine - but not for wikipedia where you have declensed forms of a word.

I find wikis great - but they are not suitable for the biggest part of potential contributors - maybe to 5% of them. See: I already said this last time I wrote about these issues here ... if Mediawiki was not developed by English sepaking people, but maybe by people speaking some kind of "strange" language - if it was not developed for the English speaking market only we would have more contributors in the regional editions it would be different - more conscious about such issues - no, please don't object - if people do things most of them only think about the English wikipedia - the other projects might exist, but are considered to be some kind of fun-stuff ... instead many of the small wikipedias are very serious projects - much more serious than anyone of you can imagine, they face many more problems you could ever imagine - a good software approach would help many of us to grow a better community and to be able to create more articles instead of having to re-read and adapt every article to our standards (&#39; is some kind of standard for nap now) and people, who already have difficulties in writing local languages, yes we have an alphabetization rate of approx 2 to 4%, would not have to concentrate on multiple issues at a time, they could concentrate on the text they are writing ... that would be great ... that would be really a step ahead ... that would mean "think about the users" not "for the majority it's fine ... so who cares ..."

I am sorry that I have to write this ... it should not be necessary.

I'll post this mail also on my blog in order to have it accessible to more people.

Thank you for taking the time to read ... well I hope one day I will be able to say "thank you for caring about the small communities".

Best, Sabine

***** Sabine Cretella Translations IT-DE, EN-DE Evangelist for WiktionaryZ s.cretella@wordsandmore.it skype: sabinecretella phone +39-340-1809828 http://sabinecretella.blogspot.com Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

Steve Bennett wrote:

Maybe something similar would work for | for Germans?

Just don't forget to check some facts about German keyboards first.

Steve Bennett wrote:

http://en.wikipedia.org/wiki/Image:Cherry_keyboard.jpg

Is that it down next to the Y? [...]

I would say so.

On 8/14/06, Steve Bennett stevage@gmail.com wrote:

On 8/14/06, Sabine Cretella sabine_cretella@yahoo.it wrote:

...

How I work on the nap.wikipedia? Well there are two things to it: I first write in OOo or Word, then I subsitute all '' with the numeric code with search and replace and I avoid to create wiki-links, because I am simply very annoyed (better I remain with nice words...) to copy and paste it here and there. Or I write the article on the wiki and then substitute the parts needed - both ways require loads of time more.

This kind of thing interests me greatly. I just did some Google searches for Neapolitan OR napolitano with alphabet OR spelling OR orthography OR apostrophe OR quote. I couldn't find anything. So instead I'll ask here in which kinds of cases this occurs. Does it represent a certain sound or omitted letters?

Andrew Dunbar (hippietrail)

Would it not be possible to add some javascript to the monobook.css at nap to do some substitution? Pick some character sequence that users will use to enter non-italic text (or even better, a character sequence for italics, and make '' natural). Then, when they go to edit text, substitute all the text as it apperas from the wiki. When they save, substitute it back. So, two solutions:

I think using // instead of '' would be cleaner for italics, but would be harder to implement, as you would need to substitute as follows:

1. When the edit box appears:

• Substitute '' (when not enclosed in <nowiki>...) with //.
• Substitute all instances of &#39;' '&#39; and &#39;&#39; with ''

2. When saving:

• Substitute all non-escaped '' with &#39;&#39;
• Susbitute all // with ''

A bit of tricky parsing involved, I suspect...

Maybe something similar would work for | for Germans?

The problem with simply saying "this punctuation is no good because there exists a language for which it doesn't work" is that it's probably next to impossible to find a syntax that is acceptable for *all* languages, present and future.

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

On 8/16/06, Jay R. Ashworth jra@baylink.com wrote:

On Tue, Aug 15, 2006 at 07:27:40PM +1000, Andrew Dunbar wrote:

...

This kind of thing interests me greatly. I just did some Google searches for Neapolitan OR napolitano with alphabet OR spelling OR orthography OR apostrophe OR quote. I couldn't find anything. So instead I'll ask here in which kinds of cases this occurs. Does it represent a certain sound or omitted letters?

Check the archive, last month; there was an *extensive* thread on this.

I took part in that thread and then, as now, as have not received a definitive answer and certainly no references at all to explain the orthography or the grammatical reasons for it.

My main question is does Neapolitan use a) a single character that looks like an English double quote mark or two adjacent apostrophes or b) a character that looks like an English apostrophe which in certain situations can occur as a "double letter"?

In the thread people describe the situation both ways and nobody clarifies it.

For instance, does Neapolitan use '' in contractions the way other languages use just ' ? Does Neapolitan use ' for something like palatalization or glottal stop and can that occur at the same place where a contractin occurs, thus necessitating '' ?

In Hebrew there is a single character "gershayim" which looks a bit like an English double quote character and it is not present on Hebrew keyboards though it is present in Unicode. People often use the English double quote character is place of gershayim.

In Amuzgo, an indigenous language of Mexico, there is a letter which looks like the English apostrophe which functions as a glottal stop. All consonants can be geminated in Amuzgo, and when they are they are written double - including the glottal stop. Unicode provides a character which looks like an English apostrophe but functions as a letter but again it's not present on keyboards so people use the English apostrophe (which can lead to an ugly mess if Word's Smart Quotes is not turned off).

Is the Neapolitan case more like the Hebrew case or more like the Amuzgo case, or unlike either case?

Andrew Dunbar (hippietrail)

Cheers,

-- jra

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

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

---

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

On 8/16/06, Andrew Dunbar hippytrail@gmail.com wrote:

My main question is does Neapolitan use a) a single character that looks like an English double quote mark or two adjacent apostrophes or b) a character that looks like an English apostrophe which in certain situations can occur as a "double letter"?

The best I can figure is that it uses a single character ' to indicate that a letter has been left out. This can occur at the end of a word, or at the start, or at the middle. Also, in a couple of specific cases, when it occurs at the end of a word *and* at the start of the following word, then those two words are written as one, with both the apostrophes: d''a

This is purely reverse engineering and speculation, based on the patterns I saw at nap. and the comments above. I'd also like to hear the definitive answer. Not that it will change much, obviously the spelling is important enough that people don't consider simply writing the word "d'a" a viable option.

Steve

On 8/16/06, Sabine Cretella sabine_cretella@yahoo.it wrote:

...

I took part in that thread and then, as now, as have not received a definitive answer and certainly no references at all to explain the orthography or the grammatical reasons for it.

My main question is does Neapolitan use a) a single character that looks like an English double quote mark or two adjacent apostrophes or b) a character that looks like an English apostrophe which in certain situations can occur as a "double letter"?

it substitutes the letters that are not pronounced

Articles

'o (male) 'a (feamale)

So if it substitutes letters which are not pronounced, what are those unpronounced letters in 'o and 'a? My guess is that they are a special exception which are always written 'o and 'a perhaps historically having had an official letter. If this is the case we could say the rule is:

A double apostrophe occurs when contraction is made with the definite articles, these being always written with an apostrophe.

So my further questions: a) Is there a "full spelling" for 'o and 'a? b) Are there any words besides 'o and 'a which take an apostrophe even when not part of a contraction?

de = preposition

like in Italian the preposition + the article become "one word" --> d''a

there is no "unique" character - one' belongs to the preposition the other to the article

pe + 'a --> p''a

That is the rule of course it also depends on pronunciation whenever a preposition that ends in a vowel meets a definite article this way of writing is neccessary. There is no Neapolitan keyboard as such - some created a keyboard layout that helps to type more easily, but that's all

• no official stuff.

The way of writing Neapolitan dates back to the 18th century when it still was used as written language in everyday life - then due to historical reasons Italian substituted Neapolitan. Of course some changes are needed to adapt these old ways of writing and communicating to our days ... only think about IT-terminology.

So well, the reason for having these double '' and for being them two distinct chars hopefully is cleared by this. If not: please let me know.

99% clear so thanks very much. My advice then is to adpot a policy of "use straight apostrophes for markup and curly apostrophes for words". Where d''o and d''a will break formatting or require ugly workarounds, d''o and d''a will always "just work". (And look better too).

Well it's my POV that this is the best goal to aim for for all Wikis and there are certainly many who disagree with me, but I suspect few of them are involved in Neapolitan wikis.

You could go half way and recommend straight apostrophes except in the case of the double apostrophe but that sounds ugly to me.

Andrew Dunbar (hippietrail)

Best, Sabine

Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l

On 8/17/06, Andrew Dunbar hippytrail@gmail.com wrote:

99% clear so thanks very much. My advice then is to adpot a policy of "use straight apostrophes for markup and curly apostrophes for words". Where d''o and d''a will break formatting or require ugly workarounds, d''o and d''a will always "just work". (And look better too).

That would be practical if keyboards had a "curly apostrophe" key. How do you propose that editors type it?

Steve

Steve Bennett wrote:

On 8/17/06, Andrew Dunbar hippytrail@gmail.com wrote:

...

99% clear so thanks very much. My advice then is to adpot a policy of "use straight apostrophes for markup and curly apostrophes for words". Where d''o and d''a will break formatting or require ugly workarounds, d''o and d''a will always "just work". (And look better too).

That would be practical if keyboards had a "curly apostrophe" key. How do you propose that editors type it?

Steve _______________________________________________

Use backquotes instead? eg. d``a, d``o, in which `` gets treated as a magic word (like RFC or ISBN) which is automagically, and transparently, converted to d&quot;&quot;a and d&quot;&quot;o within the parser at an early stage during page rendering?

Kludgy, yes, but backquote is a standard ASCII character, and at least on my keyboard, is easily accessible.

-- Neil

Andrew Dunbar schrieb:

On 8/14/06, Steve Bennett stevage@gmail.com wrote:

...

On 8/14/06, Sabine Cretella sabine_cretella@yahoo.it wrote:

...

How I work on the nap.wikipedia? Well there are two things to it: I first write in OOo or Word, then I subsitute all '' with the numeric code with search and replace and I avoid to create wiki-links, because I am simply very annoyed (better I remain with nice words...) to copy and paste it here and there. Or I write the article on the wiki and then substitute the parts needed - both ways require loads of time more.

This kind of thing interests me greatly. I just did some Google searches for Neapolitan OR napolitano with alphabet OR spelling OR orthography OR apostrophe OR quote. I couldn't find anything. So instead I'll ask here in which kinds of cases this occurs. Does it represent a certain sound or omitted letters?

Andrew Dunbar (hippietrail)

This happens quite frequently with d''a d''o

which is a combination of the preposition + the article

People on the nap wikipedia, to avoid the mess or stop editing or use all sorts of strange combinations that shows correct but is wrong - some put a space inbetween, others use ´´ `` - well these are accents and even if they "show up" like this in a research they do not give good results. I cannot even handle the proof-reading of that stuff alone, because there is too much already in there. And we cannot do it with the bot since it would anyway not find all of them and also substitute occurances where these signs might be needed.

We had that discussion more than once.

http://nap.wikipedia.org/wiki/Napule is an article where I corrected it halfway through - it is on my todo list - but there are thousands of things to care about and so these often remain there, because I am waiting for the right person who takes over the job (this could be done by many ... it is just caring about some simple rules) - we are just two or three people working regularly on nap - so at a certain stage you have to choose what to do and what must wait.

The use of wrong characters is of course an error, but there are for now other things to be created and cleaned up. For now we have to live with it :-(

Best, Sabine Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

On 8/14/06, Sabine Cretella sabine_cretella@yahoo.it wrote:

Well: let's make some practical point: people on the nap.wikipedia are driven away because they have to use workarounds for '' - that is &#39; in whatever combination - we now uwse &#39;&#39; for '' to have a unique way to identify words and word combinations if some day we should need to use replace.py. Many now create non-standard artilces using the accent of à or á that it ` or ´ to create articles ... inserting spaces where they are not needed etc. (all sorts of strange solutions to avoid to see all in italics afterwards) before the &# thingie we needed to use <nowiki> to get things right. It is an annoyance to have continuously use workarounds - now I am quite "wikiphile" I'd say, being able to install my own wikis + extensions and create sometimes quite complicated templates ... imagine how someone feels who has no clue at all about wikis - someone who would like to start a first article and then, clicking on save gets weird stuff and therefore does not come back to edit again, because editing is "too difficult". I have also plenty of colleagues who maybe would like to help, but simply don't want to loose the time to learn wiki, because donating a translation is already a lot considering how much they would earn if they did translation jobs instead.

Next thingie - the | sign - you don't have it on the German keyboard - and it gets even worse if you have a laptop keyboard like I have - there is no way to reproduce it easily with alt+<numeric code> like I could do it on a normal keyboard.

In Latin America a similar problem occurs with < and >. While those keys are present on Spanish keyboards, a very large number of computers actually use American keyboards with fewer keys. And guess which keys are missing? Fortunately these are not required so frequently in wiki syntax.

Andrew Dunbar (hippietrail)

How I work on the nap.wikipedia? Well there are two things to it: I first write in OOo or Word, then I subsitute all '' with the numeric code with search and replace and I avoid to create wiki-links, because I am simply very annoyed (better I remain with nice words...) to copy and paste it here and there. Or I write the article on the wiki and then substitute the parts needed - both ways require loads of time more.

At least the {{ [[ are on the keyboard - so normal wiki-links are not much of an issue - for Wiktionary that works fine - but not for wikipedia where you have declensed forms of a word.

I find wikis great - but they are not suitable for the biggest part of potential contributors - maybe to 5% of them. See: I already said this last time I wrote about these issues here ... if Mediawiki was not developed by English sepaking people, but maybe by people speaking some kind of "strange" language - if it was not developed for the English speaking market only we would have more contributors in the regional editions it would be different - more conscious about such issues - no, please don't object - if people do things most of them only think about the English wikipedia - the other projects might exist, but are considered to be some kind of fun-stuff ... instead many of the small wikipedias are very serious projects - much more serious than anyone of you can imagine, they face many more problems you could ever imagine - a good software approach would help many of us to grow a better community and to be able to create more articles instead of having to re-read and adapt every article to our standards (&#39; is some kind of standard for nap now) and people, who already have difficulties in writing local languages, yes we have an alphabetization rate of approx 2 to 4%, would not have to concentrate on multiple issues at a time, they could concentrate on the text they are writing ... that would be great ... that would be really a step ahead ... that would mean "think about the users" not "for the majority it's fine ... so who cares ..."

I am sorry that I have to write this ... it should not be necessary.

I'll post this mail also on my blog in order to have it accessible to more people.

Thank you for taking the time to read ... well I hope one day I will be able to say "thank you for caring about the small communities".

Best, Sabine

---

Sabine Cretella Translations IT-DE, EN-DE Evangelist for WiktionaryZ s.cretella@wordsandmore.it skype: sabinecretella phone +39-340-1809828 http://sabinecretella.blogspot.com Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l

On 8/15/06, Steve Bennett stevage@gmail.com wrote:

On 8/15/06, Andrew Dunbar hippytrail@gmail.com wrote:

...

In Latin America a similar problem occurs with < and >. While those keys are present on Spanish keyboards, a very large number of computers actually use American keyboards with fewer keys. And guess which keys are missing? Fortunately these are not required so frequently in wiki syntax.

Hang on, in Latin America, people often use American keyboards which for some reason are missing the < and > keys? That sounds weird - do you have any more info on them? I notice http://en.wikipedia.org/wiki/Keyboard_layout doesn't have any information on Spanish keyboards (or US keyboards in Latin America...)

I just got back 4 weeks ago from a 12-month trip from Mexico to Panama and back again. Being an Internet and wiki junky I used dozens of different internet cafes in this time. The Spanish keyboard has a smaller left shift key and a smaller enter key. There is an extra key between the left shift key and the z key which has < and > - one is accessed by holding the shift key. With a US keyboard this key is absent and neither character is possible. I even tried to add them to MediaWiki:Edittools but they produced &lt; and &gt; so I had to resort to cut and paste!

Andrew Dunbar (hippietrail)

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

On 8/15/06, Steve Bennett stevage@gmail.com wrote:

On 8/15/06, Andrew Dunbar hippytrail@gmail.com wrote:

...

I just got back 4 weeks ago from a 12-month trip from Mexico to Panama and back again. Being an Internet and wiki junky I used dozens of different internet cafes in this time. The Spanish keyboard has a smaller left shift key and a smaller enter key. There is an extra key between the left shift key and the z key which has < and > - one is accessed by holding the shift key. With a US keyboard this key is absent and neither character is possible. I even tried to add them to MediaWiki:Edittools but they produced &lt; and &gt; so I had to resort to cut and paste!

Weird. Normally a "US keyboard" the < is on top of the comma (shifted) and the > is on top of the dot. I understand that the combined <> key doesn't exist on the US keyboard. Apart from the Romanian keyboard I can't see any at keyboards at [[Keyboard layout]] with no < and > keys at all.

No you are confusing the physical keyboard (hardware) with the keyboard layout (software). Latin Americans must use a Spanish keyboard layout (keymap, probably other names) so they can access the extra characters. Many learn to live with some letters on the keycaps not matching the letters which appear on the screen but at least they are accessible, which is more than can be said for < and > .

Andrew Dunbar (hippietrail)

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

mboverload wrote:

Why do we need WYSIWYG to visualise italics and bold?

What's wrong with this question is the word "we". We who are already great fans of Wikipedia and Mediawiki are obviously comfortable with the current wikitext markup, or otherwise we would be somewhere else. What WYSIWYG can bring is *new* people.

I don't see your point in protesting against this. Nobody is going to force you to use my Swedish keyboard layout and nobody is going to force you to use WYSIWYG editing. What's your problem?

On 8/14/06, Jay R. Ashworth jra@baylink.com wrote:

The problem, Lars, is that several of the partisans on the "WYSIWYG should take over the world" side of the argument are framing approaches that would, in fact, force us -- practically -- to use WYSIWYG editing: I don't think *anyone* who edits in wikitext now would bother if they had to do it in XML.

I certainly wouldn't.

Rob wouldn't either.

Can we just take it as read that any "solution" which involves a strict choice between WYSIWYG and editing in XML is not viable, not attractive and not worth further discussing?

Steve

Jay R. Ashworth wrote:

The problem, Lars, is that several of the partisans on the "WYSIWYG should take over the world" side of the argument are framing approaches that would, in fact, force us -- practically -- to use WYSIWYG editing:

Come on, if anybody is proposing that, they are either trolling or completely naive people, and either way they're not going to have any real influence at all. You and mboverlord are the only two people who don't get that this is a big joke. You are feeding these trolls. Can't you just ignore this, so we can get back to discussing technical issues?

On 8/15/06, Jay R. Ashworth jra@baylink.com wrote:

If that was trolling

It was not.

Hoi, In his speech Jimmy spoke about people he knows. People he knows to be really great at the subject they stand for. People that are intimidated by what you seem to say is perfectly adequate. People that do not contribute to our content.

The buttons above the text area where you can edit are abysmal in their functionality. They serve a need but once you have learned the codes, you will not use them.

It is nice that you do not accept any argument.. it implies that you are not willing to listen. Thanks, GerardM

On 8/14/06, mboverload mboverload@gmail.com wrote:

May I remind you things "thing that newbies need" are ALREADY in buttons ABOVE the text box, along with headings, external links, images, nowiki, and others which even I never use.

I don't accept any argument that says WYSIWYG is needed for newbies. _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l

Ok, present me a case on how WYSIWYG would help a new user on http://en.wikipedia.org/wiki/Roman_Empire

We are not assuming they are idiots. They can figure out by comparing the regular text and the final version that [[ ]] makes a link, ''' ''' makes bold, and == == makes a header.

mboverload

On Mon, Aug 14, 2006 at 02:06:39PM +0200, Steve Bennett wrote:

Put it this way. We have a lot of readers, and few contributors. The vast majority of our readers are willing to expend precisely zero effort learning how to use our system in order to help us.

Ok, let's focus right in on that, and hammer on it a bit, shall we?

An argument seems to be being made (by the side which, clearly, I am not on) that there is a group of contributors out there who

a) have something useful to contribute to WP b) have "precisely zero" interest in expending any effort to learn how to do so -- when that wall is *stunningly* low. (This isn't Framemaker, folks.)

If they can't be bothered to learn wikitext, can they be bothered to read [[Assume Good Faith]]? Or [[NPOV]]? Or follow the [[Village Pump]], etc, etc, ad nauseum?

Are we equipped, as a community, to deal with (let us say) tripling the number of active editors we have now, where most of the new ones can't be bothered to learn... well, anything?

Some would say we're in critical trouble on that front *now*; it doesn't make much sense to me to enable new people who "are willing to expend precisely zero energy" on working with our community, such as it is.

Cheers, -- jra

On Mon, Aug 14, 2006 at 05:25:21PM +0200, Steve Bennett wrote:

On 8/14/06, Jay R. Ashworth jra@baylink.com wrote:

...

An argument seems to be being made (by the side which, clearly, I am not on) that there is a group of contributors out there who

Let's call them "random people" rather than "group of contributors".

...

    a) have something useful to contribute to WP

Yep, whether it be fixing typos, pointing out errors, or even adding a sentence or two.

...

    b) have "precisely zero" interest in expending any effort
            to learn how to do so -- when that wall is *stunningly*
            low.  (This isn't Framemaker, folks.)

Yep. They're browsing the web. They're not doing homework.

...

If they can't be bothered to learn wikitext, can they be bothered to read [[Assume Good Faith]]? Or [[NPOV]]? Or follow the [[Village Pump]], etc, etc, ad nauseum?

Nope. But that's ok, you need very little of that to make such small contributions. WP:V is probably the only one worth knowing about, and that can be summarised in the sentence "Tell us where you heard this, so we can check it."

My perception of Jimbo's comment on this is that that is not, no, what he's talking about. He means subject matter people. I think.

...

Are we equipped, as a community, to deal with (let us say) tripling the number of active editors we have now, where most of the new ones can't be bothered to learn... well, anything?

I wouldn't call them "active editors". Is a one-time buyer of a train ticket an "active public transport user?" Someone who dropped some rubbish an "active litterer?" Etc.

But, to answer your question, yes. Haven't seen a lot of problems with newbies, most of the problems seem to come from oldbies.

Really? I'll be darned. Ok.

...

Some would say we're in critical trouble on that front *now*; it doesn't make much sense to me to enable new people who "are willing to expend precisely zero energy" on working with our community, such as it is.

Who would say that?

It has been the perception I've integrated from half a dozen or more sources; perhaps I'm wrong. I stay out of the fray, myself.

Cheers, -- jra

And let's remember that vandals aren't going to give a rat's arse about markup; you don't need to know what all that gibberish means to replace it all with "u eat poo-poo". But overall, yes, we want good-faith contributors who are willing to expend exactly zero effort learning how things work, because fixing typos will in many cases progress to fixing facts, which may lead to discussion and further involvement.

The point is a low barrier to *entry*. Once you've gotten comfortable with just editing, it's assumed that you might want to start discussing things and learning policies and so on. Or you might not, which is also fine as long as you stay away from anything controversial. You don't need to read Verifiability or Neutral point of view to know that things should be verifiable or neutral; you just need someone to add {{fact}} or {{npov}} or something to a page you edit, once.

But none of this will necessarily happen if you didn't do something to commit yourself first. It's the "foot in the door" principle: people who start small will be more willing to proceed to bigger things than they will be to start out with big things. What were *your* first edits to Wikipedia?

On 8/14/06, Chad Perrin perrin@apotheon.com wrote:

In the case of edits to existing articles, I tend to suspect that typo fixes might be among the highest percentage of first-time edits -- and that isn't really affected much by "weird" stuff like templates and heading wikimarkup.

Well, that's the whole issue. I, Jimbo Wales, etc. disagree. We think a large number of the less technically-inclined are probably scared off by this kind of stuff, rather than ignoring it as they should.

On Mon, Aug 14, 2006 at 02:49:33PM -0400, Simetrical wrote:

But none of this will necessarily happen if you didn't do something to commit yourself first. It's the "foot in the door" principle: people who start small will be more willing to proceed to bigger things than they will be to start out with big things. What were *your* first edits to Wikipedia?

http://en.wikipedia.org/w/index.php?title=Special:Contributions&offset=2...

plus about 4 or 5 where I thought I was logged in but it didn't stick; you'll note, my first logged contribution was a *bug report on that issue*.

But I've been doing this sort of thing for 25 years, and I *understand* that I'm not the mainstream user.

That does not, and will not, stop me from Wishing and Hoping that people will decide to Want to Learn again.

Cheers, -- jra

On Mon, Aug 14, 2006 at 11:53:05PM +0200, Steve Bennett wrote:

On 8/14/06, Jay R. Ashworth jra@baylink.com wrote:

...

That does not, and will not, stop me from Wishing and Hoping that people will decide to Want to Learn again.

Wikipedia is your hobby. Not theirs.

Clearly. I still sympathize with Jay's thoughts on the matter -- that it would be nice to see an increase in the desire to learn in the general populace.

On Tue, Aug 15, 2006 at 12:28:15AM +0200, Steve Bennett wrote:

Seriously. People are what they are. We can attempt to change everyone, or we can work with what we've got.

*Exactly*.

:-)

Cheers, -- jra

On Tue, Aug 15, 2006 at 12:28:15AM +0200, Steve Bennett wrote:

On 8/15/06, Chad Perrin perrin@apotheon.com wrote:

...

Clearly. I still sympathize with Jay's thoughts on the matter -- that it would be nice to see an increase in the desire to learn in the general populace.

Ok, now that we've enjoyed 5 seconds of wistful pondering, can we get back to the real world?

Seriously. People are what they are. We can attempt to change everyone, or we can work with what we've got.

Sure.

Responding in more depth off-list.

Maybe I'm missing something here:

You don't need to learn ANYTHING. Hit the edit button, fix the typo, and you're done.

On 8/14/06, Jay R. Ashworth jra@baylink.com wrote:

On Mon, Aug 14, 2006 at 11:53:05PM +0200, Steve Bennett wrote:

...

On 8/14/06, Jay R. Ashworth jra@baylink.com wrote:

...

That does not, and will not, stop me from Wishing and Hoping that people will decide to Want to Learn again.

Wikipedia is your hobby. Not theirs.

I wouldn't really characterise it as a hobby, for me, which is likely a large part of the reason for this disconnect. But apart from that, if I was going to contribute my knowledge to the world on any topic, I would want it to be useful and reflect well on me.

Cheers,

-- jra

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

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

---

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

On 8/14/06, mboverload mboverload@gmail.com wrote:

I still say utterly useless.

Are you looking for a pat on the head or a kick up the arse?

Steve