Hello all,
I think this is a debate/discussion that has been a long time coming. We need to have this.
Many may not realize this, but there is a HUGE disparity between the stub ratio (related to average article length) in the different Wikipedias.
http://s23.org/wikistats/wikipedias_html.php?sort=ratio_asc
For a little visual demonstration of the fact:
http://ceb.wikipedia.org/wiki/Special:Random (Random page on Cebuano Wikipedia, with the "stubbiest" stub ratio) -- clicking randompage 10 times, I got 9 different stubs about communes in France and one about a place in the Philippines
I think that there has been too much emphasis on article count in the past, causing people to think that it is much more important than it really is and wanting to inflate it by adding hundreds or even thousands of "hollow" articles with little information on semi-obscure topics that probably won't be read at all by anyone ever, and if they are, will not be useful.
Now, I know I sound critical with that sentiment, but hey, who am I to say that it could not be useful to have those stubs?
But I do think we should discuss it... is it better to have 1000 stubs or 100 long well-written articles?
And also here's a little nudge to everyone... why not go to Special:Shortpages or Special:Random on your favourite Wiki and expand some articles? How about it?
Mark
I think that there has been too much emphasis on article count in the past, causing people to think that it is much more important than it really is and wanting to inflate it by adding hundreds or even thousands of "hollow" articles with little information on semi-obscure topics that probably won't be read at all by anyone ever, and if they are, will not be useful.
You're right of course, but writing long articles is pretty hard compared to 'stub-length' ones. Also, stub-length ones with basic information can be generated quite easily with bots. See for example:
http://tg.wikipedia.org/wiki/%D0%9E%D0%BC%D0%B0%D0%B5%D0%B7%D0%B0%D0%BA% D0%B8
At some point these articles will have to be written, and is it easier to start with a stub, or with nothing? Furthermore, stubs allow people who aren't particularly fluent in the language to contribute.
And as to your question, 100 well written articles is better than 1000 stubs, but where to find the people to write them?
Fran
But I do think we should discuss it... is it better to have 1000 stubs or 100 long well-written articles?
I originally rated stubs as no more than a trick to fake a higher article count. I have to admit that stubs succeeded in capturing activity, people start adding stuff, those who cannot write properly add pictures, but there is a quantity of activity they capture.
Same applies to red links, although a stub seems to be more immediate in asking participation. On the other hand, stubs grow quite casually and eventually need to be rewritten into a proper article, because they do capture stuff but have no underlying scheme.
I suppose there's no general rule, though. It would be easier to judge if we could have a curve about "stub growth in time". Ours started to grow some 4-5 months after being made, some are just moving now after a year and some are still empty stubs. Intuitively I'd say some 30-40% of them did capture material (it was about 300-500 pieces about botanic and zoology).
Maybe it would have been better if we had used a wider distribution as per subject. Who knows?
Bèrto d Sèra Personagi dlann 2006 për larvista american-a Time (tanme tuti vojàotri) http://www.time.com/time/magazine/article/0,9171,1569514,00.html
Well, I talk as an admin of Friulian Wiki (fur.wiki). I don't like thousand of stubs, I prefer less articles, but more complete. This doesn't mean as complete as in big Wikis, because it would take me too much time to translate a full article from, say, en.wiki, I usually translate instead from the Wikipedia in Catalan, since they seem to have a good balance between length and completeness. I also think every wiki should rather add stubs that have good chances to develop. We are currently adding the States of the world, since this is a subject which is pretty well covered in other languages. I instead said no to adding as stubs the 8000 "communites" of Italy. That addition could bring us to the magic 10 000 threshold (we are at 2000) but most of those articles IMHO will stay stub forever, since even in Italian wiki they're in this state. What we are focusing on are articles about local themes, personalities and so on, stuff that you can't find elsewhere, and so you have to create from scratch, but are pretty interesting for casual users; we also had some media exposure, and so there's room for more development. I'm proud that we have already the biggest collection of text in Friulian language, and we are following the official orthography (that is very important, I wouldn't even start if there wasn't an unique orthography. Cope with different versions is really too much work). Hope you can understand my bad English ;-) Andre
On 4/28/07, Berto 'd Sera albertoserra@ukr.net wrote:
But I do think we should discuss it... is it better to have 1000 stubs or 100 long well-written articles?
I originally rated stubs as no more than a trick to fake a higher article count. I have to admit that stubs succeeded in capturing activity, people start adding stuff, those who cannot write properly add pictures, but there is a quantity of activity they capture.
Same applies to red links, although a stub seems to be more immediate in asking participation. On the other hand, stubs grow quite casually and eventually need to be rewritten into a proper article, because they do capture stuff but have no underlying scheme.
I suppose there's no general rule, though. It would be easier to judge if we could have a curve about "stub growth in time". Ours started to grow some 4-5 months after being made, some are just moving now after a year and some are still empty stubs. Intuitively I'd say some 30-40% of them did capture material (it was about 300-500 pieces about botanic and zoology).
Maybe it would have been better if we had used a wider distribution as per subject. Who knows?
Bèrto 'd Sèra Personagi dl'ann 2006 për l'arvista american-a Time (tanme tuti vojàotri) http://www.time.com/time/magazine/article/0,9171,1569514,00.html
Wikipedia-l mailing list Wikipedia-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikipedia-l
Hi Andre,
Your English is actually very good :-)
I think the Friulian Wikipedia should be a shining example for other Wikipedias -- since the very beginning, it has had good quality articles, written in official orthography, and dedicated contributors, even when they didn't have much time for fur.wiki. (I have kept an eye on it because I helped place the initial request for it and I think the language is beautiful)
Your attitude of quality over quantity is unique among Wikis of that size and deserves applause and attention, especially as you have paved the way for the Friulian language into the 21st century.
Mark
On 30/04/07, A. Decorte adecorte@gmail.com wrote:
Well, I talk as an admin of Friulian Wiki (fur.wiki). I don't like thousand of stubs, I prefer less articles, but more complete. This doesn't mean as complete as in big Wikis, because it would take me too much time to translate a full article from, say, en.wiki, I usually translate instead from the Wikipedia in Catalan, since they seem to have a good balance between length and completeness. I also think every wiki should rather add stubs that have good chances to develop. We are currently adding the States of the world, since this is a subject which is pretty well covered in other languages. I instead said no to adding as stubs the 8000 "communites" of Italy. That addition could bring us to the magic 10 000 threshold (we are at 2000) but most of those articles IMHO will stay stub forever, since even in Italian wiki they're in this state. What we are focusing on are articles about local themes, personalities and so on, stuff that you can't find elsewhere, and so you have to create from scratch, but are pretty interesting for casual users; we also had some media exposure, and so there's room for more development. I'm proud that we have already the biggest collection of text in Friulian language, and we are following the official orthography (that is very important, I wouldn't even start if there wasn't an unique orthography. Cope with different versions is really too much work). Hope you can understand my bad English ;-) Andre
On 4/28/07, Berto 'd Sera albertoserra@ukr.net wrote:
But I do think we should discuss it... is it better to have 1000 stubs or 100 long well-written articles?
I originally rated stubs as no more than a trick to fake a higher article count. I have to admit that stubs succeeded in capturing activity, people start adding stuff, those who cannot write properly add pictures, but there is a quantity of activity they capture.
Same applies to red links, although a stub seems to be more immediate in asking participation. On the other hand, stubs grow quite casually and eventually need to be rewritten into a proper article, because they do capture stuff but have no underlying scheme.
I suppose there's no general rule, though. It would be easier to judge if we could have a curve about "stub growth in time". Ours started to grow some 4-5 months after being made, some are just moving now after a year and some are still empty stubs. Intuitively I'd say some 30-40% of them did capture material (it was about 300-500 pieces about botanic and zoology).
Maybe it would have been better if we had used a wider distribution as per subject. Who knows?
Bèrto 'd Sèra Personagi dl'ann 2006 për l'arvista american-a Time (tanme tuti vojàotri) http://www.time.com/time/magazine/article/0,9171,1569514,00.html
Wikipedia-l mailing list Wikipedia-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikipedia-l
Wikipedia-l mailing list Wikipedia-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikipedia-l
Hoi!
What we are focusing on are articles about local themes, personalities and so on, stuff that you can't find elsewhere,
Yes, that's an option we are discussing, too. It really makes sense to produce specialized content since you cannot compete at horizontal level with en.wiki anyway. I hear the Galicians are on that road, too.
My doubt on the subject is that people come and write what they please (usually a few lines, more rarely a proper article), so how do you manage to plan your content? I'll be grateful for any info you can share.
I think we should open a forum (with normal forum software, not a wiki) to host discussions among small wikies. We have our dimensions, problems and needs; it could be useful to share ideas where people are like you.
FMI, is Furlan taught in public schools? When you have schools you don't need to make an alphabetized user base out of thin air and subsequently don't need sandbox stubs and the like. :)
Bèrto d Sèra Personagi dlann 2006 për larvista american-a Time (tanme tuti vojàotri) http://www.time.com/time/magazine/article/0,9171,1569514,00.html
My doubt on the subject is that people come and write what they please (usually a few lines, more rarely a proper article), so how do you manage to plan your content? I'll be grateful for any info you can share.
Well, if I'm writing an article from scratch, I usually search for information in encyclopedias and different books (mostly in Italian), I gather them than I write down a first textual version, that I'll later wikify. But there are also articles started from other people, even anonymous, and they usually add just few infos as you said. We usually try to add thing like their bibliography or more about their life, even if there is always the problem that you don't find much on Internet, so it's a heavier work. And consider also that (like you AFAIK) I don't live in Friuli, so I can't access to many sources normally. This is a problem that people usually think is limited to developing countries, but it affects also smaller, minorized language in the Western world. That of the forum could be a good idea, IMHO this would be very useful (I'm thinking for example at bots for international stuff like countries, or domains).
About school, you touch a big issue. Teaching is already mentioned in 1999 minority law, but it should *probably* start next year; there's a lot of problems tough, I don't know if it will start but I hope so. This would be a huge help, before it's too late. Here [ http://www.lenghe.net/read_art.php?articles_id=1243&PHPSESSID=f5a34db500... ] you can for example see that CGIL (which is one of the main trade unions in Italy) is opposing since "the 50% of the teacher come from elsewhere, and they don't speak Friulian.
I think we should open a forum (with normal forum software, not a wiki) to host discussions among small wikies. We have our dimensions, problems and needs; it could be useful to share ideas where people are like you.
FMI, is Furlan taught in public schools? When you have schools you don't need to make an alphabetized user base out of thin air and subsequently don't need sandbox stubs and the like. :)
Bèrto 'd Sèra Personagi dl'ann 2006 për l'arvista american-a Time (tanme tuti vojàotri) http://www.time.com/time/magazine/article/0,9171,1569514,00.html
Wikipedia-l mailing list Wikipedia-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikipedia-l
Hoi!
And consider also that (like you AFAIK) I don't live in Friuli, so I can't access to many sources normally.
Yes... most speakers of Italian minority languages seem to be either emigrants or foreigners that live in Italy and are immune to the nationalistic pressure. It's sad that my piemontese friends in Kazakhstan find it more normal to write in PMS than Italian residents do. One more example of why nations are bad for your health, me thinks :)
This is a problem that people usually think is limited to developing countries, but it affects also smaller, minorized language in the Western world.
Yes. Size is size, no matter where you are from. We basically have the problems that any low-alphabetized language has.
That of the forum could be a good idea, IMHO this would be very useful (I'm thinking for example at bots for international stuff like countries, or domains).
Okay. Have this as a formal promise from the western to the eastern Alps. If we don't have one from wmf by the end of the month I'll open one myself at my expenses. It will be open to everyone, but focused on wikies our size.
About school, you touch a big issue. Teaching is already mentioned in 1999 minority law, but it should *probably* start next year;
I know how big that *probably* is. On the opposite side of the Alps we have the left wings using a law written by the right wings (a law they opposed like crazy when they were the opposition) to delete even the mention of the piemontese language from all public documents. Same kind of stuff is happening south, AFAIK.
No matter what Law you can obtain you always end up in front of an officer who will rather destroy the Colosseum in Rome than change his personal schedule. He will obviously call that a "defense of the Integrity of the Nation" (when there is a right-wing government) or an "anti-racist policy" (when it's the leftists in power). Public officers are indifferent to changes; they simply load the current language file and keep saying the some thing in the proper translation :)))))))))))))))))))))))
CGIL (which is one of the main trade unions in Italy) is opposing since "the 50% of the teacher come from elsewhere, and they don't speak Friulian.
LOLOLOL how heroic of them!! Will they also oppose teaching geography, based on the fact that more than 50% of the teachers are specialized in other issues? :))))) Why should we have canals in Venice?? Most Italians drive cars, not gondolas :)))))))))))))) What about a ritual mass suicide to conform to the fact that most of our ancestors are dead? :)))))))))))))))
I mean, that's the teachers... go figure out the intellectual level of a 17 y.o. football hooligan in Italy... on a second thought... with such a school he will have just the level it takes for him to support any of the existing Italian political parties, i.e. the lower his culture level, the better for the establishment (mafia) :)))))))))))))))) School IS efficient, after all :)))))))))
See you soon with some final news on the forum.
Bèrto d Sèra Personagi dlann 2006 për larvista american-a Time (tanme tuti vojàotri) http://www.time.com/time/magazine/article/0,9171,1569514,00.html
Ok, thanks for your work, it's really appreciated. I agree fully with your positions, the level of Italian politics is incredibly low and they seem to agree only in fighting minorities. Everybody nowadays underlines the importance of protecting smaller languages and they keep saying that Italian school should focus more on English, while I think the hours of English lessons are enough, still the knowledge of it is embarrassing, even among young people... Let's hope that our Wikipedias can help at least a little. Bye
But I do think we should discuss it... is it better to have 1000 stubs or 100 long well-written articles?
I think the key point here is when you want the encyclopedia to be good. If you want it to be good now, then 100 long articles is best. If you want it to be good in a couple of years, then 1000 stubs (assuming they are good stubs, but that's another debate) is better.
This is based on the assumption than stubs will eventually become articles (and faster than non-existent pages do). This would suggest that younger wikis will have more stubs. To test this hypotheses, I copy and pasted the table linked to in the parent email into excel and plotted edits (well, log of edits, actually) against stub ratio (I'm using edits as a measure of age, seems better than time since creation). The result surprised me. For wikis with less than 20000 edits there is a very wide range of stub ratios, but there is an overall (weak) upward trend, as I was expecting. At 20,000 edits there is a very sharp cutoff and the range of ratios becomes much smaller (from about 0.5 before 20,000 to 0.2 after, excluding a few outliers in both categories, which include the English wikipedia) and there is no trend visible at all.
Any guesses on what happens to wikis at the 20,000 edits mark? It's an amazingly sharp cutoff.
"Thomas Dalton" thomas.dalton@gmail.com wrote in message news:a4359dff0704271734h1dbf5e98lf5fc65da1978b313@mail.gmail.com...
But I do think we should discuss it... is it better to have 1000 stubs or 100 long well-written articles?
I think the key point here is when you want the encyclopedia to be good. If you want it to be good now, then 100 long articles is best. If you want it to be good in a couple of years, then 1000 stubs (assuming they are good stubs, but that's another debate) is better.
This is based on the assumption than stubs will eventually become articles (and faster than non-existent pages do). This would suggest that younger wikis will have more stubs.
Any guesses on what happens to wikis at the 20,000 edits mark? It's an amazingly sharp cutoff.
I am primarily a reader/editor of en.wp, and if I enter a topic into the search and there is no article for it I tend to assume that either (a) the article exists under some other name, (b) the important information relating to the topic is already covered in some other related article or (c) the topic failed one of en.WPs exhaustive criteria for inlclusion and so is not welcome.
Therefore I do nothing.
In the 'good old days' I would (time permitting) write a stub for that topic. However, nowadays I tend to assume that my contribution would not be welcome (either because the topic is already covered, or because it deliberately does not have an article).
The point being that I would expect stub article creation to be pretty high in new Wikipedias, and to tail off as the Wikipedia in question comes to be seen as more authoritative.
-- - Mark Clements (HappyDog)
- Mark Clements (HappyDog)
Most established users and administrators focus on clearing backlogs, dealing with vandalism, etc.
We need more dedicated article writers. I'm trying to be one.
2007/4/28, Mark Clements gmane@kennel17.co.uk:
"Thomas Dalton" thomas.dalton@gmail.com wrote in message news:a4359dff0704271734h1dbf5e98lf5fc65da1978b313@mail.gmail.com...
But I do think we should discuss it... is it better to have 1000 stubs or 100 long well-written articles?
I think the key point here is when you want the encyclopedia to be good. If you want it to be good now, then 100 long articles is best. If you want it to be good in a couple of years, then 1000 stubs (assuming they are good stubs, but that's another debate) is better.
This is based on the assumption than stubs will eventually become articles (and faster than non-existent pages do). This would suggest that younger wikis will have more stubs.
Any guesses on what happens to wikis at the 20,000 edits mark? It's an amazingly sharp cutoff.
I am primarily a reader/editor of en.wp, and if I enter a topic into the search and there is no article for it I tend to assume that either (a) the article exists under some other name, (b) the important information relating to the topic is already covered in some other related article or (c) the topic failed one of en.WPs exhaustive criteria for inlclusion and so is not welcome.
Therefore I do nothing.
In the 'good old days' I would (time permitting) write a stub for that topic. However, nowadays I tend to assume that my contribution would not be welcome (either because the topic is already covered, or because it deliberately does not have an article).
The point being that I would expect stub article creation to be pretty high in new Wikipedias, and to tail off as the Wikipedia in question comes to be seen as more authoritative.
--
Mark Clements (HappyDog)
Mark Clements (HappyDog)
Wikipedia-l mailing list Wikipedia-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikipedia-l
Hi,
One observation that may be related to the rate of creation of new articles: the markup is becoming positively bewildering.
In some ways it's harder than HTML -- just figuring out where the first paragraph is in the markup can be non-trivial. I've had the experience of contributing something, clicking preview, and seeing that I've borked someone's infobox or table or thicket of <ref>s or whatever. To be honest I often will just not submit my contribution, rather than sort out what's going on in the markup. And I'm not a new user; I've been making small contributions on and off for several years.
I can't imagine what a brand new user's first impression is when they click "edit" for the first time... I suspect it's often something along the lines of "eek, I don't want to break this."
I'm certainly not trying to disparage the fine work that's been done to create the Mediawiki software, I'm just trying to simulate the POV of a newbie here (I imagine there aren't many on this list).
- Pat
As a newbie, I had huge problems with markup, and even now, I find it confusing. I agreee with Patrick.
We need to make markup easier for newcomers. This is one way of not biting them.
And as I previously mentioned, we need more dedicated article writers. There's an increasing gulf between writers and Wikipedias who handle meta tasks.
2007/4/28, Patrick Hall pathall@gmail.com:
Hi,
One observation that may be related to the rate of creation of new articles: the markup is becoming positively bewildering.
In some ways it's harder than HTML -- just figuring out where the first paragraph is in the markup can be non-trivial. I've had the experience of contributing something, clicking preview, and seeing that I've borked someone's infobox or table or thicket of <ref>s or whatever. To be honest I often will just not submit my contribution, rather than sort out what's going on in the markup. And I'm not a new user; I've been making small contributions on and off for several years.
I can't imagine what a brand new user's first impression is when they click "edit" for the first time... I suspect it's often something along the lines of "eek, I don't want to break this."
I'm certainly not trying to disparage the fine work that's been done to create the Mediawiki software, I'm just trying to simulate the POV of a newbie here (I imagine there aren't many on this list).
- Pat
Wikipedia-l mailing list Wikipedia-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikipedia-l
On Apr 27, 2007, at 7:40 PM, Patrick Hall wrote:
Hi, One observation that may be related to the rate of creation of new articles: the markup is becoming positively bewildering.
Example, please?
In some ways it's harder than HTML -- just figuring out where the first paragraph is in the markup can be non-trivial.
I have not seen this kind of problem in articles. Templates, perhaps, but not articles. Maybe we need a template for {{excessivemarkup}} in articles? (and maybe template Talk pages?)
I can't imagine what a brand new user's first impression is when they click "edit" for the first time... I suspect it's often something along the lines of "eek, I don't want to break this."
I have "broken" many a page in my day, if by "broken", someone means "shifted content around on the display level", (and to users with table-based page rendering, this can be a terrifying thing), but the problem there, IMNSHO, is not the newbie user, it's broken CSS programming, and/or a fundamental misunderstanding of content vs. display.
-Bop
I have "broken" many a page in my day, if by "broken", someone means "shifted content around on the display level", (and to users with table-based page rendering, this can be a terrifying thing), but the problem there, IMNSHO, is not the newbie user, it's broken CSS programming, and/or a fundamental misunderstanding of content vs. display.
As true as that all may be, I don't think that's what's being talked about. I think people mean when you edit a sentence and end up losing a } somewhere and you end up with the whole article's source code appearing in the infobox or something.
It is an issue, but I'm not sure what the solution is. Complicated templates shouldn't be substed if at all possible, that's an easy one, but more than that, I'm drawing a blank. We need the power of a comprehensive syntax, but the ease of use of a very simply one - I don't think that's possible.
2007/4/28, Patrick Hall pathall@gmail.com:
I can't imagine what a brand new user's first impression is when they click "edit" for the first time... I suspect it's often something along the lines of "eek, I don't want to break this."
I'm certainly not trying to disparage the fine work that's been done to create the Mediawiki software, I'm just trying to simulate the POV of a newbie here (I imagine there aren't many on this list).
An idea to improve this: How about the following - it requires an extra piece of markup, but it would still I think simplify matters for newbies:
Create an extra piece of markup, or maybe a template, with the following effect (I will choose ((..)) as my markup, probably not ideal, but if there is interest in it, we can think of something better):
Starting from a page:
blablabla {{some ingenious but complicated template}} blablabla
we change to:
blablabla ((template|{{some ingenious but complicated template}})) blablabla
This has no effect on the page as it is shown normally, but when one checks the edit page, one sees:
blablabla ((template)) blablabla
and below the edit field there is a second edit field, with a header 'template:' and content
{{some ingenious but complicated template}}
That way, the starting user, when editing the page does not need to bother with complicated or boring stuff like tables, templates and interwikis, but can just work in the top screen, where there is much more content and simple makeup, and much less complicated makeup to worry about screwing up.
For experienced editors and especially for bots it would be useful to have an alternative 'raw' input screen, where the normal edit text can be found.
Advantages: * easier editing by newbies * less searching for the correct place to edit
Disadvantages: * creating an edit page will require a (small) amount of parsing * if one goes wrong, the results will probably be larger (removing the complicated markup rather than just making a mess of it) * yet another addition to MediaWiki markup
An idea to improve this: How about the following - it requires an extra piece of markup, but it would still I think simplify matters for newbies:
Create an extra piece of markup, or maybe a template, with the following effect (I will choose ((..)) as my markup, probably not ideal, but if there is interest in it, we can think of something better):
Starting from a page:
blablabla {{some ingenious but complicated template}} blablabla
we change to:
blablabla ((template|{{some ingenious but complicated template}})) blablabla
This has no effect on the page as it is shown normally, but when one checks the edit page, one sees:
blablabla ((template)) blablabla
and below the edit field there is a second edit field, with a header 'template:' and content
{{some ingenious but complicated template}}
That's section editing on steroids - I like it. There is probably a lot of work needed refining the idea, but the basic concept is good. A way to separate articles into sections other than just with headers would be very powerful - it would allow edit links on infoboxes, etc., it would allow users to edit a section of text without editing the templates that just happen to be in that section too, and probably more that I can't think of right now. The idea is definitely worth a full discussion.
The point being that I would expect stub article creation to be pretty high in new Wikipedias, and to tail off as the Wikipedia in question comes to be seen as more authoritative.
Authoritative? Or just more bureaucratic? I personally believe the problem is the later.
Maury
_________________________________________________________________ Add the Windows Live Messenger NHL Stats Agent to your buddy list and get your stats fix instantly http://sports.sympatico.msn.ca/NHL/NHL_Stats_Agent
"Maury Markowitz" maury_markowitz@hotmail.com wrote in message news:BAY141-F20F0CA5B8F7FE92233C356884C0@phx.gbl...
The point being that I would expect stub article creation to be pretty
high
in new Wikipedias, and to tail off as the Wikipedia in question comes to
be
seen as more authoritative.
Authoritative? Or just more bureaucratic? I personally believe the problem is the later.
Authoritative. This has nothing to do with the internal systems, but with external impressions. If a user thinks of Wikipedia as an authoratitive resource, they are unlikely to add stubs because they assume that the content is already there (they just haven't managed to find it) or has been deliberately omitted.
It's the same kind of argument by which scrabble players will say a word is invalid because it is not in their dictionary. It is a falacious argument, but a common one.
- Mark Clements (HappyDog)
Mark Clements wrote:
Authoritative. This has nothing to do with the internal systems, but with external impressions. If a user thinks of Wikipedia as an authoratitive resource, they are unlikely to add stubs because they assume that the content is already there (they just haven't managed to find it) or has been deliberately omitted.
Perhaps there is a "law" (of nature) that some 20,000 stubs will always be tolerated. For a new Wikipedia, that is the whole site. For a Wikipedia of 200,000 articles, it's only 10% of them.
One way to encourage longer articles would be to rank languages on the www.wikipedia.org front page by word count (or perhaps byte count) rather than article count. According to [1] the Chinese Wikipedia has 50.6 M words in March 2007 and the Russian has 47.1 M words, compared to the Swedish Wikipedia's 36.2 M words. Changing the ranking of the Swedish one from 9th to 11th would send a clear message to the stub-happy swedes.
[1] http://stats.wikimedia.org/EN/TablesDatabaseWords.htm
One way to encourage longer articles would be to rank languages on the www.wikipedia.org front page by word count (or perhaps byte count) rather than article count. According to [1] the Chinese Wikipedia has 50.6 M words in March 2007 and the Russian has 47.1 M words, compared to the Swedish Wikipedia's 36.2 M words. Changing the ranking of the Swedish one from 9th to 11th would send a clear message to the stub-happy swedes.
The amount of information in each word varies from language to language, so that doesn't work too well. It works for comparing similar languages, but Chinese and Swedish could end up having very different numbers of words for exactly the same content.
100% true. Just compound words in german may make a great difference towards English, in piemontese we thousands of 'L L' n' 'n that would count as words and are but pronominal particles, plus we usually say everything twice (double subject, double locatives, etc).
Quantitative methods are hardly going to help in such cases.
Berto 'd Sera Personagi dl'ann 2006 per l'arvista american-a Time (tanme tuti vojaotri) http://www.time.com/time/magazine/article/0,9171,1569514,00.html
-----Original Message----- From: wikipedia-l-bounces@lists.wikimedia.org [mailto:wikipedia-l-bounces@lists.wikimedia.org] On Behalf Of Thomas Dalton Sent: Tuesday, May 01, 2007 1:52 PM To: wikipedia-l@lists.wikimedia.org Subject: Re: [Wikipedia-l] Quality vs Quantity
One way to encourage longer articles would be to rank languages on the www.wikipedia.org front page by word count (or perhaps byte count) rather than article count. According to [1] the Chinese Wikipedia has 50.6 M words in March 2007 and the Russian has 47.1 M words, compared to the Swedish Wikipedia's 36.2 M words. Changing the ranking of the Swedish one from 9th to 11th would send a clear message to the stub-happy swedes.
The amount of information in each word varies from language to language, so that doesn't work too well. It works for comparing similar languages, but Chinese and Swedish could end up having very different numbers of words for exactly the same content.
_______________________________________________ Wikipedia-l mailing list Wikipedia-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikipedia-l
Berto 'd Sera wrote:
100% true. Just compound words in german may make a great difference towards English, in piemontese we thousands of 'L L' n' 'n that would count as words and are but pronominal particles, plus we usually say everything twice (double subject, double locatives, etc).
The size of the compressed article dumps would be a better comparison then, because the same content would still occupy the same space after all redundancies have been removed.
Probably, yes. At least as an immediate number.
Maybe a good thing would be (if and when we get to that) to have some decent machine translation made by the omegawiki thing and count the number of "defined meanings" you can get.
It would also interesting to see how many of them happen to be related to each other, which would already be a primitive estimate of the "shift in meaning" among different linguistic versions of one entry.
Berto 'd Sera Personagi dl'ann 2006 per l'arvista american-a Time (tanme tuti vojaotri) http://www.time.com/time/magazine/article/0,9171,1569514,00.html
-----Original Message----- From: wikipedia-l-bounces@lists.wikimedia.org [mailto:wikipedia-l-bounces@lists.wikimedia.org] On Behalf Of Lars Aronsson Sent: Thursday, May 03, 2007 9:02 AM To: wikipedia-l@lists.wikimedia.org Subject: Re: [Wikipedia-l] Quality vs Quantity
Berto 'd Sera wrote:
100% true. Just compound words in german may make a great difference towards English, in piemontese we thousands of 'L L' n' 'n that would count as words and are but pronominal particles, plus we usually say everything twice (double subject, double locatives, etc).
The size of the compressed article dumps would be a better comparison then, because the same content would still occupy the same space after all redundancies have been removed.
Berto 'd Sera schrieb:
Probably, yes. At least as an immediate number.
Maybe a good thing would be (if and when we get to that) to have some decent machine translation made by the omegawiki thing and count the number of "defined meanings" you can get.
Probably you are talking about the connection between OmegaWiki and Apertium here - well: we are on a way to get Apertium XML in OmegaWiki and that will change a lot, because from that moment on we will be able to handle paradigms, that is inflections, conjugations etc for Apertium. This means Machine Translation is a step nearer - remember: Machine Translation will not be able to translate everything, but it will help a lot to create contents. From Spanish to Catalan they have a very low errorquote (I have some confirmation about that by a colleague who tranlates that language pair). Wikipedia is fairly easy to translate since there is no hidden meaning in there - so: yes, the software can do quite a lot there.
It would also interesting to see how many of them happen to be related to each other, which would already be a primitive estimate of the "shift in meaning" among different linguistic versions of one entry.
I don't understand what you mean with this Berto - could you please explain?
Thanks :-)
Ciao, Sabine
Hoi,
Probably you are talking about the connection between OmegaWiki and Apertium
Yes, it's what I meant :)
I don't understand what you mean with this Berto - could you please explain?
I mean that when an entry says that water is wet and thru an interwiki link I get to another where it says that water is dry I can have the software signal the contradiction and ask humans to take some action.
Actually it can make much more than that, because it can suggest expansions of the existing material by providing a machine translation of the existing material in other languages.
Thus far migrating content from one language into another has been a job limited to us multilingual people, when we get to that we are in a situation where "anyone can play", so we can expect a vertical growth for interlinguistic transits.
Berto 'd Sera Personagi dl'ann 2006 per l'arvista american-a Time (tanme tuti vojaotri) http://www.time.com/time/magazine/article/0,9171,1569514,00.html
Berto 'd Sera schrieb:
Hoi,
I don't understand what you mean with this Berto - could you please explain?
I mean that when an entry says that water is wet and thru an interwiki link I get to another where it says that water is dry I can have the software signal the contradiction and ask humans to take some action.
Ok, I understand what you mean, but please be patient: it is too soon to talk about this. The problem alway is that if we cannot show things people will not understand and will think we are talking about something that will never exist. The concept is difficult to explain and it is better to come up with this option when it really is there and people can try it out.
Do you remeber the beginning of Ultimate Wiktionary? We were seen as some quite crazy bunch believing in something that is impossible ... well it is there, not perfect by now ... but well: how long did it take to get the Mediawiki software to the level it has now? So: wer are not really so bad on schedule ;-)
The problem often is how people percieve us. Instead of seeing us as people who just want to give the most value possible to people's time, work and knowledge we are often perceived as a threat to I don't know what. But that is also normal and understandable - and there is a famous quote by Ghandi that confirms exactly that :-) (no, I am not telling you ... there is wikiquote for that ;-)
There will be a time when things are clearer and then is the time to talk about this and then I hope people will start to understand that we are just about getting the most out of the available means and not against anybody.
I don't know if I can go ahead discussing here - some work is calling my attention :-)
Ciao, Sabine
Hoi!
Ok, I understand what you mean, but please be patient: it is too soon to talk about this.
No probs :) We were just freewheeling about wiki-fiction :))) It wasn't meant to put peopler under any pressure :))) Even if it takes 42 seconds I cam wait :))))))))))))) No, seriously, it really was just "talkin sci-fi" :)
Berto 'd Sera Personagi dl'ann 2006 per l'arvista american-a Time (tanme tuti vojaotri) http://www.time.com/time/magazine/article/0,9171,1569514,00.html
Berto 'd Sera wrote:
I mean that when an entry says that water is wet and thru an interwiki link I get to another where it says that water is dry I can have the software signal the contradiction and ask humans to take some action.
Actually it can make much more than that, because it can suggest expansions of the existing material by providing a machine translation of the existing material in other languages.
It needs to be able to explain why dry wine is wet. ;-)
Ec
LOLOL yes, that would a good thing to do :)
Berto 'd Sera Personagi dl'ann 2006 per l'arvista american-a Time (tanme tuti vojaotri) http://www.time.com/time/magazine/article/0,9171,1569514,00.html
-----Original Message----- From: wikipedia-l-bounces@lists.wikimedia.org [mailto:wikipedia-l-bounces@lists.wikimedia.org] On Behalf Of Ray Saintonge Sent: Monday, May 07, 2007 12:12 AM To: wikipedia-l@lists.wikimedia.org Subject: Re: [Wikipedia-l] Quality vs Quantity
Berto 'd Sera wrote:
I mean that when an entry says that water is wet and thru an interwiki link I get to another where it says that water is dry I can have the software signal the contradiction and ask humans to take some action.
Actually it can make much more than that, because it can suggest expansions of the existing material by providing a machine translation of the existing material in other languages.
It needs to be able to explain why dry wine is wet. ;-)
Ec
_______________________________________________ Wikipedia-l mailing list Wikipedia-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikipedia-l
Hoi!
As previously promised, I opened a space for small wikies: http://eng.i-iter.org/small-wikies
Feel free to use it as you please. The one and only boundary is: we are limited to discussion of small communities related material/problems.
Berto 'd Sera Personagi dl'ann 2006 per l'arvista american-a Time (tanme tuti vojaotri) http://www.time.com/time/magazine/article/0,9171,1569514,00.html
The point being that I would expect stub article creation to be pretty high in new Wikipedias, and to tail off as the Wikipedia in question comes to be seen as more authoritative.
That's a very valid point. That would contribute to an upward trend of stub ratios with increasing edits, which is exactly what I see for Wikipedias with less than 20,000 edits, but after that it levels out, and becomes much less variable. I can't think why.
Thomas Dalton wrote:
The point being that I would expect stub article creation to be pretty high in new Wikipedias, and to tail off as the Wikipedia in question comes to be seen as more authoritative.
That's a very valid point. That would contribute to an upward trend of stub ratios with increasing edits, which is exactly what I see for Wikipedias with less than 20,000 edits, but after that it levels out, and becomes much less variable. I can't think why.
Perhaps it's the point at which a project becomes more authoritarian than authoritative. It's where people become concerned that stubs somehow reflect badly on the project, and they start to delete the stubs on that basis.
Ec
"Ray Saintonge" saintonge@telus.net wrote in message news:46337960.3030906@telus.net...
Thomas Dalton wrote:
The point being that I would expect stub article creation to be pretty
high
in new Wikipedias, and to tail off as the Wikipedia in question comes to
be
seen as more authoritative.
That's a very valid point. That would contribute to an upward trend of stub ratios with increasing edits, which is exactly what I see for Wikipedias with less than 20,000 edits, but after that it levels out, and becomes much less variable. I can't think why.
Perhaps it's the point at which a project becomes more authoritarian than authoritative. It's where people become concerned that stubs somehow reflect badly on the project, and they start to delete the stubs on that basis.
While that may be true, that's not the point I was trying to make. The issue is not with people deleting stubs so much as people no longer creating them once the Wikipedia has reached a critical mass. If I search for an article on en and it doesn't exist, my assumption (unless it's something very obscure) is that there is a reason it doesn't exist, e.g. it is under another name, or covered as part of a wider article. If I did anything it would be to create a redirect to some other article, not to create a stub.
- Mark Clements (HappyDog)
2007/4/28, Thomas Dalton thomas.dalton@gmail.com:
But I do think we should discuss it... is it better to have 1000 stubs or 100 long well-written articles?
I think the key point here is when you want the encyclopedia to be good. If you want it to be good now, then 100 long articles is best. If you want it to be good in a couple of years, then 1000 stubs (assuming they are good stubs, but that's another debate) is better.
This is based on the assumption than stubs will eventually become articles (and faster than non-existent pages do).
Indeed. My own idea here is that 1. The great majority of non-stubs have at least one macro-edit, that is, an edit that adds so much new material that the material from that edit alone would already be a non-stub (looking at size only). 2. Although stubs are more likely to be edited than new pages are to be created, macro-edits on stubs are neither more nor less likely than new pages are to be created as non-stubs in the first place.
The first assumption is one that I think most people would agree on. The second one might be based too much on my own pattern of editing. Minor and meso (neither minor nor macro) edits are usually done because I stumble upon a page and find there is something for me to correct or improve, but the idea for macro-edits usually come when I am not editing Wikipedia at all, but reading about the subject or something similar. This might be different for other people, but I am not sure about that. Is a stub really more inviting *for macro-edits* than a red link?
Still, I guess that for the small Wikipedias, there is another thing that could speak in favor of the '1000 stubs': Their first issue will be to get people, more than to get articles. And the 1000 stubs would mean 10 times as many interwiki links and 10 times as many pages on Google (although I assume Google and other search engines might give higher status to larger articles, thus partly undoing that advantage), and thus 10 times as many chances for people to learn that there is a Wikipedia in their language as well.
Hoi!
- Although stubs are more likely to be edited than new pages are to
be created, macro-edits on stubs are neither more nor less likely than new pages are to be created as non-stubs in the first place.
Yes, I'd say it's 100% true, based on what I see.
Still, I guess that for the small Wikipedias, there is another thing that could speak in favor of the '1000 stubs': Their first issue will be to get people, more than to get articles
Yes, that's your main problem in a small wiki. You also have to get people use to that idiotic wiki-markup (WHEN will we have a NORMAL WYSIWYG?????) and they are good scratch-boxes.
People are also much less frightened to modify asemi-desert stub with little more than "small alpine village of 234 humans, 34 cows, 4 dogs and a cat" than they are of making a change on a 18.000 words entry on Kafka.
The new wikies are all like this, big wikies have long been opened. For all newcomers getting traffic and finding people who are willing to cope with the inner weirdness of wmf is the most relevant job.
Berto 'd Sera Personagi dl'ann 2006 per l'arvista american-a Time (tanme tuti vojaotri) http://www.time.com/time/magazine/article/0,9171,1569514,00.html
On 29/04/07, Berto 'd Sera albertoserra@ukr.net wrote:
Yes, that's your main problem in a small wiki. You also have to get people use to that idiotic wiki-markup (WHEN will we have a NORMAL WYSIWYG?????)
This is a vexed question. The technical reason is that MediaWiki markup doesn't have a specification - the specification is, quite literally, the PHP code in the parser.
There have been various attempts to write the specification out in EBNF format. However, this is actually mathematically *impossible*. So all such attempts at doing so have gotten to 90% and died.
Put it this way: liberate MediaWiki from the PHP parser code and the devs will worship you.
- d.
Hoi,
I know, but it's a hell a problem in marketing mediawiki to minorities. They mostly already have problems with the IT as such, and first thing you do is tell them they cannot simply "hit enter".
I already had a major project deleting wikimedia and switch to Drupal because users rate that editing mediawiki is too weird, and most users were... british. Imagine the equivalent result in an alpine community.
BTW, imagine what it means in terms of lost contributors for en.wiki.
Berto 'd Sera Personagi dl'ann 2006 per l'arvista american-a Time (tanme tuti vojaotri) http://www.time.com/time/magazine/article/0,9171,1569514,00.html
-----Original Message----- From: wikipedia-l-bounces@lists.wikimedia.org [mailto:wikipedia-l-bounces@lists.wikimedia.org] On Behalf Of David Gerard Sent: Sunday, April 29, 2007 2:34 PM To: wikipedia-l@lists.wikimedia.org Subject: Re: [Wikipedia-l] Quality vs Quantity
On 29/04/07, Berto 'd Sera albertoserra@ukr.net wrote:
Yes, that's your main problem in a small wiki. You also have to get people use to that idiotic wiki-markup (WHEN will we have a NORMAL WYSIWYG?????)
This is a vexed question. The technical reason is that MediaWiki markup doesn't have a specification - the specification is, quite literally, the PHP code in the parser.
There have been various attempts to write the specification out in EBNF format. However, this is actually mathematically *impossible*. So all such attempts at doing so have gotten to 90% and died.
Put it this way: liberate MediaWiki from the PHP parser code and the devs will worship you.
- d.
_______________________________________________ Wikipedia-l mailing list Wikipedia-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikipedia-l
On 29/04/07, Berto 'd Sera albertoserra@ukr.net wrote:
I know, but it's a hell a problem in marketing mediawiki to minorities. They mostly already have problems with the IT as such, and first thing you do is tell them they cannot simply "hit enter".
You can actually get by tolerably well just knowing to type text and maybe [[ ]] for linking.
People are still working on the problem. Here's hoping.
- d.
Not if you need tables. Tables in wiki-markup are the most awful things I ever saw. And most technical data is traditionally presented in tables.
Berto 'd Sera Personagi dl'ann 2006 per l'arvista american-a Time (tanme tuti vojaotri) http://www.time.com/time/magazine/article/0,9171,1569514,00.html
-----Original Message----- From: wikipedia-l-bounces@lists.wikimedia.org [mailto:wikipedia-l-bounces@lists.wikimedia.org] On Behalf Of David Gerard Sent: Sunday, April 29, 2007 3:44 PM To: wikipedia-l@lists.wikimedia.org Subject: Re: [Wikipedia-l] Quality vs Quantity
On 29/04/07, Berto 'd Sera albertoserra@ukr.net wrote:
I know, but it's a hell a problem in marketing mediawiki to minorities.
They
mostly already have problems with the IT as such, and first thing you do
is
tell them they cannot simply "hit enter".
You can actually get by tolerably well just knowing to type text and maybe [[ ]] for linking.
People are still working on the problem. Here's hoping.
- d.
_______________________________________________ Wikipedia-l mailing list Wikipedia-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikipedia-l
Not if you need tables. Tables in wiki-markup are the most awful things I ever saw. And most technical data is traditionally presented in tables.
A table generator would be good - not full WYSIWYG, just somewhere to input number of rows and columns and then you get a textbox for each cell and type the appropriate code in them, and then it gives you the full wikisyntax for the table.
Hoi,
It would be better than nothing, yes. Just see how many interesting articles with formulas we have thanks to "math" (or how it is called) and how little elementary data tables we publish even on en.wiki.
Pls pls pls make sure the input interface does clearly look like a table and not like a gizmo for geeks. Otherwise it will be filed under "the hell knows what it is" by most users and you will have wasted your time in making it.
Berto 'd Sera Personagi dl'ann 2006 per l'arvista american-a Time (tanme tuti vojaotri) http://www.time.com/time/magazine/article/0,9171,1569514,00.html
-----Original Message----- From: wikipedia-l-bounces@lists.wikimedia.org [mailto:wikipedia-l-bounces@lists.wikimedia.org] On Behalf Of Thomas Dalton Sent: Sunday, April 29, 2007 5:17 PM To: wikipedia-l@lists.wikimedia.org Subject: Re: [Wikipedia-l] Quality vs Quantity
Not if you need tables. Tables in wiki-markup are the most awful things I ever saw. And most technical data is traditionally presented in tables.
A table generator would be good - not full WYSIWYG, just somewhere to input number of rows and columns and then you get a textbox for each cell and type the appropriate code in them, and then it gives you the full wikisyntax for the table.
_______________________________________________ Wikipedia-l mailing list Wikipedia-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikipedia-l
Thomas Dalton wrote:
Not if you need tables. Tables in wiki-markup are the most awful things I ever saw. And most technical data is traditionally presented in tables.
A table generator would be good - not full WYSIWYG, just somewhere to input number of rows and columns and then you get a textbox for each cell and type the appropriate code in them, and then it gives you the full wikisyntax for the table.
There's an extra toolbar button on en-wiki which will create a table skeleton for you. Here's the result of simply clicking the button: http://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&oldid=127636442
It should not be too difficult for people to understand that they simply replace the text in the skeleton, and that the various symbols create the table structure. Surely this is easier than translating HTML tags from not-exactly-english to whatever language you're dealing with.
That button used to fire up a basic table-editing widget, but it broke some browsers (and probably some other stuff) and was replaced with the simpler version. However that code would still be available (see here http://preview.tinyurl.com/342nby)if someone wanted to take a shot at making it less horrible.
HTH HAND
Yes, that's your main problem in a small wiki. You also have to get people use to that idiotic wiki-markup (WHEN will we have a NORMAL WYSIWYG?????) and they are good scratch-boxes.
The problem with WYSIWYG is that it goes against the concept of separating content and presentation. There are lots of different ways of displaying the same wikitext (see all the different skins, but that's only the beginning of what is theoretically possible), WYSIWYG encourages people to write stuff that only looks right in the skin that's used on the edit page. Writing in code encourages people to just write the content and let the skin worry about the presentation, which is generally preferable.
Hoi!
I've been using drupal for months now with lots of different skins and never had any such problem. If what you allow is regular XHTML you have no reason to worry.
Anyway, the effect of wiki-markup is that it separetes users from a service they should receive (being able to edit). I'd say it's more relevant than the way we "look".
Berto 'd Sera Personagi dl'ann 2006 per l'arvista american-a Time (tanme tuti vojaotri) http://www.time.com/time/magazine/article/0,9171,1569514,00.html
-----Original Message----- From: wikipedia-l-bounces@lists.wikimedia.org [mailto:wikipedia-l-bounces@lists.wikimedia.org] On Behalf Of Thomas Dalton Sent: Sunday, April 29, 2007 4:02 PM To: wikipedia-l@lists.wikimedia.org Subject: Re: [Wikipedia-l] Quality vs Quantity
Yes, that's your main problem in a small wiki. You also have to get people use to that idiotic wiki-markup (WHEN will we have a NORMAL WYSIWYG?????) and they are good scratch-boxes.
The problem with WYSIWYG is that it goes against the concept of separating content and presentation. There are lots of different ways of displaying the same wikitext (see all the different skins, but that's only the beginning of what is theoretically possible), WYSIWYG encourages people to write stuff that only looks right in the skin that's used on the edit page. Writing in code encourages people to just write the content and let the skin worry about the presentation, which is generally preferable.
_______________________________________________ Wikipedia-l mailing list Wikipedia-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikipedia-l
On 29/04/07, Thomas Dalton thomas.dalton@gmail.com wrote:
The problem with WYSIWYG is that it goes against the concept of separating content and presentation. There are lots of different ways of displaying the same wikitext (see all the different skins, but that's only the beginning of what is theoretically possible), WYSIWYG encourages people to write stuff that only looks right in the skin that's used on the edit page. Writing in code encourages people to just write the content and let the skin worry about the presentation, which is generally preferable.
That's a sweet thought, but in practice it puts people off writing at all.
By the way, is '' and ''' in the virtuous Wiki markup content or presentation?
- d.
By the way, is '' and ''' in the virtuous Wiki markup content or presentation?
They count as emphasis, which is part of content. How that emphasis is displayed is up to the renderer - they could be italic and bold, they could be underline and blinking, they could be red and green. However they are rendered, they serve the same purpose - emphasising a particular part of the text.
On Apr 29, 2007, at 6:10 AM, David Gerard wrote:
On 29/04/07, Thomas Dalton thomas.dalton@gmail.com wrote:
The problem with WYSIWYG is that it goes against the concept of separating content and presentation.
Exactly. How does a person "see" what a blind wikipedian's text reader is going to say? :)
There are lots of different ways of displaying the same wikitext (see all the different skins, but that's only the beginning of what is theoretically possible), WYSIWYG encourages people to write stuff that only looks right in the skin that's used on the edit page. Writing in code encourages people to just write the content and let the skin worry about the presentation, which is generally preferable.
That's a sweet thought, but in practice it puts people off writing at all. By the way, is '' and ''' in the virtuous Wiki markup content or presentation?
Content. A text synthesizer program may take those tags and use a higher pitched voice, louder volume, etc. A web page version of that same content could take that tags and use them to change text colors, fonts, convert to ALLCAPS, etc. Or, alternately, ignore them entirely.
I certainly will concur that not having WYSIWYG *does* turn off a certain segment of the population, a segment which is deeply ingrained with the idea that they can make a page look "just right", by manually playing with colors, fonts, line breaks, widows & orphans, kerning, ligatures, etc. (the list is quite long, I know this because I come from DTP, where designers obsess over such things), but I think working towards that goal might distract us from making an encyclopedia for everybody, not just "an encyclopedia that looks/sounds exactly the way Ronald Chmara wanted it to look/sound for the pages he has edited, on the output targets he tested".
My personal idea of how the web-page should look is certainly an opinion, but with all the content debates we already have, I'm not sure we should extend additional presentation debates onto all of our pages as well (beyond what we already have). As it already stands, I have been involved in discussions over template order and alignment, picture order and alignment, etc., usually with personalities who are using heavily hand-tweaked User: pages, which of course, are completely non-portable for the blind, hard to translate for RTL, etc.
I think it's good to have a certain amount of presentation-focused folks working on the project, but I think it would be bad to extend that level of presentation control into to a per-edit basis.
-Ronabop
Yes, one of the advantages of a formal layout is the greater ease of using adaptive technology--and the related one of the greater accessibility to those with another primary language. I occasional check topics in languages I do not really know, and I rely heavily on the conventional WP structure of a page and the links for orientation, and to select the part that needs translation. --DGG
On 4/29/07, Ronald Chmara ron@opus1.com wrote:
On Apr 29, 2007, at 6:10 AM, David Gerard wrote:
On 29/04/07, Thomas Dalton thomas.dalton@gmail.com wrote:
The problem with WYSIWYG is that it goes against the concept of separating content and presentation.
Exactly. How does a person "see" what a blind wikipedian's text reader is going to say? :)
There are lots of different ways of displaying the same wikitext (see all the different skins, but that's only the beginning of what is theoretically possible), WYSIWYG encourages people to write stuff that only looks right in the skin that's used on the edit page. Writing in code encourages people to just write the content and let the skin worry about the presentation, which is generally preferable.
That's a sweet thought, but in practice it puts people off writing at all. By the way, is '' and ''' in the virtuous Wiki markup content or presentation?
Content. A text synthesizer program may take those tags and use a higher pitched voice, louder volume, etc. A web page version of that same content could take that tags and use them to change text colors, fonts, convert to ALLCAPS, etc. Or, alternately, ignore them entirely.
I certainly will concur that not having WYSIWYG *does* turn off a certain segment of the population, a segment which is deeply ingrained with the idea that they can make a page look "just right", by manually playing with colors, fonts, line breaks, widows & orphans, kerning, ligatures, etc. (the list is quite long, I know this because I come from DTP, where designers obsess over such things), but I think working towards that goal might distract us from making an encyclopedia for everybody, not just "an encyclopedia that looks/sounds exactly the way Ronald Chmara wanted it to look/sound for the pages he has edited, on the output targets he tested".
My personal idea of how the web-page should look is certainly an opinion, but with all the content debates we already have, I'm not sure we should extend additional presentation debates onto all of our pages as well (beyond what we already have). As it already stands, I have been involved in discussions over template order and alignment, picture order and alignment, etc., usually with personalities who are using heavily hand-tweaked User: pages, which of course, are completely non-portable for the blind, hard to translate for RTL, etc.
I think it's good to have a certain amount of presentation-focused folks working on the project, but I think it would be bad to extend that level of presentation control into to a per-edit basis.
-Ronabop
Wikipedia-l mailing list Wikipedia-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikipedia-l
"Ronald Chmara" ron@Opus1.COM wrote in message news:B203BF24-4A66-48BA-8ADE-3D94AB249B5E@opus1.com...
On Apr 29, 2007, at 6:10 AM, David Gerard wrote:
On 29/04/07, Thomas Dalton
thomas.dalton@gmail.com wrote:
The problem with WYSIWYG is that it goes against the concept of separating content and presentation.
[SNIP]
I certainly will concur that not having WYSIWYG *does* turn off a certain segment of the population, a segment which is deeply ingrained with the idea that they can make a page look "just right", by manually playing with colors, fonts, line breaks, widows & orphans, kerning, ligatures, etc. (the list is quite long, I know this because I come from DTP, where designers obsess over such things), but I think working towards that goal might distract us from making an encyclopedia for everybody, not just "an encyclopedia that looks/sounds exactly the way Ronald Chmara wanted it to look/sound for the pages he has edited, on the output targets he tested".
That is not really an argument against WYSIWYG. You are arguing about what features should be included in a WISIWYG editor, not whether we should have such an editor.
I think that everyone on this list would agree that any such editor for Wikipedia would NOT include options for changing font/text color/text-size, etc. They would also probably agree that having a button which pops up a friendly 'insert link' dialog box, or the ability to edit lists with an indent/outdent button (just two examples) would make editing for the uninitiated a whole load easier without crossing the content/presentation boundary.
There will be some arguments in the middle ground, but to be honest I don't think there will be many. Anything that can already easily be done in pure wiki markup will probably be included, anything else probably won't and that's probably where most of the arguments will begin and end.
I also suspect that if someone has the perseverence and dedication to actually implement this out of our current wacky parser, then the feature list will be whatever they happen to choose, and so the bike shed will already be painted before any discussion starts...
- Mark Clements (HappyDog)
The problem with WYSIWYG is that it goes against the concept of separating content and presentation.
[SNIP]
I certainly will concur that not having WYSIWYG *does* turn off a certain segment of the population, a segment which is deeply ingrained with the idea that they can make a page look "just right"
I've been listening to this *exact* same debate since the 1980s. It's as wrong now as it was then.
Don't *ever* underestimate the barrier to entry that complex systems create. In a world where most people can't get a digital clock to stop blinking 12:00, do you really expect that the wiki's technocratic interface is acceptable. GUI's and WYSIWYG democratize content.
I'm a wiki power-user and I utterly detest the interface. I have a 19" monitor at work and a 30" at home, but dragging the resize doesn't change the editor so I have to pick the smaller size so it doesn't disappear off my screen when I change monitors. Single mouse clicks even millimeters away from what I want will result in navigations that throw away edits, as will many keystrokes that the browsers bind to navigation -- and of course it's different for each browser which makes such mistakes very easy to make (thank god for Mozilla, I can't count the number of edits it's cache has saved me). I create links without any idea of whether or not they work without opening another browser and testing them out. Citations are so complex I simply ignore the entire cite system and just use ref. Spell checking is a function of the browser, as is find in the editor, so I have my choice of Mozzilla's terrible checker, or Safari's lack of in-editor find. I have absolutely no idea how to create working template links other than by cut and paste from other articles that I have to hunt for, and each one has it's own unique and incompatible syntax.
It's abysmal. It's so bad that I've taken to cutting the content out into a 3rd party text editor for editing. Not a wiki editor mind you, a plain text editor. I'd kill for a system that gave me a good offline WYSIWYG editor with a palette of includable content templates. On the Mac.
Maury
_________________________________________________________________ Win a webcam! Nominate your friends Windows Live Space in the Windows Live Spaces Sweetest Space Contest and you both could win! http://www.microsoft.com/canada/home/contests/sweetestspace/default.aspx
On 30/04/07, Maury Markowitz maury_markowitz@hotmail.com wrote: ...
Don't *ever* underestimate the barrier to entry that complex systems create. In a world where most people can't get a digital clock to stop blinking 12:00, do you really expect that the wiki's technocratic interface is acceptable. GUI's and WYSIWYG democratize content.
...
Well, *some* of this can be remedied, *to an extent*, by using OpenOffice with modified UniWakka wiki export filter. Then one can use headers, emphasises, lists, footnotes in OpenOffice file, then export it to the wiki syntax, then throw it to wiki edit window via the clipboard.
Not the other way around, though. And the conversion xslt I, personally, was able to produce is capable only of very simplified version of MediaWiki syntax (so, no <ref name="name"/>). And no WYSIWYG tables.
---
Yury Tarasievich wrote:
On 30/04/07, Maury Markowitz maury_markowitz@hotmail.com wrote: ...
Don't *ever* underestimate the barrier to entry that complex systems create. In a world where most people can't get a digital clock to stop blinking 12:00, do you really expect that the wiki's technocratic interface is acceptable. GUI's and WYSIWYG democratize content.
...
Well, *some* of this can be remedied, *to an extent*, by using OpenOffice with modified UniWakka wiki export filter. Then one can use headers, emphasises, lists, footnotes in OpenOffice file, then export it to the wiki syntax, then throw it to wiki edit window via the clipboard.
Not the other way around, though. And the conversion xslt I, personally, was able to produce is capable only of very simplified version of MediaWiki syntax (so, no <ref name="name"/>). And no WYSIWYG tables.
You've just proven Maury's point.
Ec
wikipedia-l@lists.wikimedia.org