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(a)ukr.net> wrote:

Hoi! 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 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

Hoi! 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 :) Yes. Size is size, no matter where you are from. We basically have the problems that any low-alphabetized language has. 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. 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 :))))))))))))))))))))))) 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 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

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(a)kennel17.co.uk>uk>:

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(a)gmail.com>om>:

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.

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.

"Maury Markowitz" <maury_markowitz(a)hotmail.com> wrote in message news:BAY141-F20F0CA5B8F7FE92233C356884C0@phx.gbl... high be 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)

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.

Berto 'd Sera wrote: 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. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

Berto 'd Sera schrieb: 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. I don't understand what you mean with this Berto - could you please explain? Thanks :-) Ciao, Sabine

Berto 'd Sera schrieb: 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

Berto 'd Sera wrote: It needs to be able to explain why dry wine is wet. ;-) Ec

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

Thomas Dalton wrote: 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

2007/4/28, Thomas Dalton <thomas.dalton(a)gmail.com>om>: 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. -- Andre Engels, andreengels(a)gmail.com ICQ: 6260644 -- Skype: a_engels

On 29/04/07, Berto 'd Sera <albertoserra(a)ukr.net> wrote: 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.

On 29/04/07, Berto 'd Sera <albertoserra(a)ukr.net> wrote: 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.

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.

Thomas Dalton wrote: 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 -- Phil -- View this message in context: http://www.nabble.com/Quality-vs-Quantity-tf3660405.html#a10282417 Sent from the Wikipedia General mailing list archive at Nabble.com.

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(a)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(a)lists.wikimedia.org Subject: Re: [Wikipedia-l] Quality vs Quantity 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(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikipedia-l

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.

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 &lt;ron(a)opus1.com&gt; wrote: -- David Goodman, Ph.D, M.L.S.

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 friend’s 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

Yury Tarasievich wrote: You've just proven Maury's point. Ec