hi,
i searched the web on how to set up mediawiki multilanguage site. but the only thing i could find was "use a dedicated database scheme per language".
what would be the best strategy to have the mediawiki installed once, and use it for en.site.com and fr.site.com?
solo.
I used a browser language detection for my mediawiki, but it works only for the dynamic menu on the left(default english, but different for french and german). I really would like it to work also for the whole site, but I found the discussion page namespace a big a big problem in my attempt to internationalize the wiki (so I droped the idea for now)
François http://www.fxparlant.net
solo turn wrote:
hi,
i searched the web on how to set up mediawiki multilanguage site. but the only thing i could find was "use a dedicated database scheme per language".
what would be the best strategy to have the mediawiki installed once, and use it for en.site.com and fr.site.com?
solo.
On Fri, 11 Mar 2005 22:22:58 +0100, solo turn soloturn@gmail.com wrote:
hi,
i searched the web on how to set up mediawiki multilanguage site. but the only thing i could find was "use a dedicated database scheme per language".
what would be the best strategy to have the mediawiki installed once, and use it for en.site.com and fr.site.com?
The way the Wikimedia projects (Wikipedia, Wiktionary, etc) do it is [I think, approximately] by installing a seperate database for each one, and a seperate LocalSettings.php, but then including a CommonSettings.php (for things which should be the same for all languages) and one central copy of the actual MediaWiki PHP files. I'm not sure if they use symlinks or PHP includes or what for this, but that's the basic idea. Then, of course, you set up the interwiki tables in each database to let you do inter-language links like [[en:Page title]] / [[fr:Titre de page]]
I think there's various bits and pieces about this on http://meta.wikimedia.org, but I don't know of a single page that gives a complete guide I'm afraid.
Can anyone tell me if there is already in existence an editor program that enables one to edit mediawiki pages in a "what you see is what you get" mode (editing for dummies)?
I have an associate who says he could build such a program quite easily. I'm thinking, if it's so easy why hasn't it been done; surely it has been done; if so, where?
Thanks
Sterling D. Allan Executive Director, PES Network Inc http://pureenergysystems.com http://freeenergynews.com http://peswiki.com http://pesn.com
Not sure if this helps: http://www.plog4u.org/index.php/Main_Page
Cheers, Tony.
Sterling D. Allan wrote:
Can anyone tell me if there is already in existence an editor program that enables one to edit mediawiki pages in a "what you see is what you get" mode (editing for dummies)?
I have an associate who says he could build such a program quite easily. I'm thinking, if it's so easy why hasn't it been done; surely it has been done; if so, where?
Thanks
Sterling D. Allan Executive Director, PES Network Inc http://pureenergysystems.com http://freeenergynews.com http://peswiki.com http://pesn.com
MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
On Sun, 13 Mar 2005 19:49:49 +0000, Tony Linde tony@linde.me.uk wrote:
Not sure if this helps: http://www.plog4u.org/index.php/Main_Page
The plog4u eclipse editor plugin isn't a direct "what you see is what you get" editor. It's focusing on editing Wikipedia articles offline (through downloading and uploading articles) and creating PDF documents from the articles.
The built-in "html preview browser" refreshs it's view if you save the edited text to the local file system and let "you see what you get".
On Sunday 13 March 2005 02:22 pm, Axel wrote:
The built-in "html preview browser" refreshs it's view if you save the edited text to the local file system and let "you see what you get".
I believe the word you're looking for is YAFIYGI: You Asked For It, You Got It. I think YAFIYGI with a preview is a Good Thing(tm) for all the reasons the rotary phone was beautiful: They're both a dumbass tax. You have to think about what you're doing to properly phrase what you're going to say before you commit to it.
I would not go quite so far as Paul, but I think there are better places to put resources than WYSIWYG editing.
The beauty of Wiki is it is collaborative. Some people have ideas they don't articulate well. Some people are expert wordsmiths, but don't necessarily have ideas. Some people are editors and copyreaders. Some people delight in formatting arcana.
The downside of WYSIWYG is Bad Design. Now everyone with a pirated copy of Word is a publisher -- NOT!
I've been through various flavors of roff, TeX, Merganthalier and Quikset typesetting codes, HTML, and many others. I think the beauty of formatting code is it makes you think. Because of the "high entry fee" (aka "dumbass tax"), you spend a bit more time figuring out how things are going to go together, and it shows in the results.
That's one of the reasons I Don't Do Word. Most Word docs are atrocious, with multiple spaces used for indentation and multiple line feeds used for vertical spacing. Someone sends me a Word document, and by the time my translators get through with it, it needs to be re-formatted anyway. I avoid hurting anyone's feelings that I re-formatted their "masterpiece" by explaining that I don't have Word, and my translation software "must have messed it up." :-)
It's not that WYSIWYG doesn't have a place. But let's just keep it there, okay?
On 14 Mar 2005, at 00:28, Paul Johnson wrote:
On Sunday 13 March 2005 02:22 pm, Axel wrote:
The built-in "html preview browser" refreshs it's view if you save the edited text to the local file system and let "you see what you get".
I believe the word you're looking for is YAFIYGI: You Asked For It, You Got It. I think YAFIYGI with a preview is a Good Thing(tm) for all the reasons the rotary phone was beautiful: They're both a dumbass tax. You have to think about what you're doing to properly phrase what you're going to say before you commit to it.
:::: Some call it vision; some call it temporal lobe epilepsy. :::: Jan Steinman http://www.Bytesmiths.com
Two thoughts:
While the editing difficulty of wiki as it is does weed out the less motivated, in my particular nook of the Internet (cutting edge energy tech), it is weeding far more than I would like. People might be brilliant in science, but often are not so brilliant in word composition. I hope to make it as easy as possible for them.
I can see that the sheer number of HTML/Wiki code possibilities used in mediawiki would make the WYSIWYG task nearly impossible if one wanted to be able to enable all possible formatting options. So the "price" one will pay in going with a WYSIWYG editor would be a narrowing of formatting options.
In my case, that is a price that I would be willing to pay because I want to make it easy for those brilliant scientists who barely know how to spell.
Sterling D. Allan http://peswiki.com
p.s. thanks for the input
----- Original Message ----- From: "Jan Steinman" Jan@Bytesmiths.com To: "MediaWiki announcements and site admin list" mediawiki-l@Wikimedia.org Sent: Monday, March 14, 2005 11:19 AM Subject: Re: [Mediawiki-l] what-you-see-is-what-you-get edit program?
I would not go quite so far as Paul, but I think there are better places to put resources than WYSIWYG editing.
The beauty of Wiki is it is collaborative. Some people have ideas they don't articulate well. Some people are expert wordsmiths, but don't necessarily have ideas. Some people are editors and copyreaders. Some people delight in formatting arcana.
The downside of WYSIWYG is Bad Design. Now everyone with a pirated copy of Word is a publisher -- NOT!
I've been through various flavors of roff, TeX, Merganthalier and Quikset typesetting codes, HTML, and many others. I think the beauty of formatting code is it makes you think. Because of the "high entry fee" (aka "dumbass tax"), you spend a bit more time figuring out how things are going to go together, and it shows in the results.
That's one of the reasons I Don't Do Word. Most Word docs are atrocious, with multiple spaces used for indentation and multiple line feeds used for vertical spacing. Someone sends me a Word document, and by the time my translators get through with it, it needs to be re-formatted anyway. I avoid hurting anyone's feelings that I re-formatted their "masterpiece" by explaining that I don't have Word, and my translation software "must have messed it up." :-)
It's not that WYSIWYG doesn't have a place. But let's just keep it there, okay?
On Mon, 14 Mar 2005 11:59:47 -0700, Sterling D. Allan wrote:
I can see that the sheer number of HTML/Wiki code possibilities used in mediawiki would make the WYSIWYG task nearly impossible if one wanted to be able to enable all possible formatting options. So the "price" one will pay in going with a WYSIWYG editor would be a narrowing of formatting options.
In my case, that is a price that I would be willing to pay because I want to make it easy for those brilliant scientists who barely know how to spell.
Or, say, for my mother, who is likewise not going to learn wiki syntax any time soon. Just opening an existing page to make a typo edit is slightly baffling to her. Especially since by default she doesn't have section-editing turned on, and figuring out how to scroll to where you were in the viewable document is... non-trivial.
When I ask regular readers why they don't contribute, the most common response is they're not experts in anything, they don't feel they have anything to add. A close runner-up is that they tried once but got frustrated; they're not sure where to add an idea, or how the syntax works; or they don't have time. The clearer and more intuitive the editing interface, the faster the learning curve, and the fewer people who will think they don't have time to figure it out.
It seems to me that early on the development curve of wiki software made a choice (a bad one, in my opinion) to go the code direction rather than the WYSIWYG direction. The longer they linger in code, the harder it will be to do a course correction to a WYSIWYG interface, which is really where this needs to be to draw from the widest pool of contributors around the planet and see the wiki achieve its full potential. The chasm presently is so great that the typical developer is probably going to be scared off by the daunting task. Overwhelming.
Perhaps PESWiki can provide some leadership by combining these two and showing how well it works to do so.
Sterling Allan http://peswiki.com
----- Original Message ----- From: "Sj" 2.718281828@gmail.com To: "MediaWiki announcements" mediawiki-l@wikimedia.org Sent: Monday, March 14, 2005 12:41 PM Subject: Re: [Mediawiki-l] what-you-see-is-what-you-get edit program?
[snip]
When I ask regular readers why they don't contribute, the most common response is they're not experts in anything, they don't feel they have anything to add. A close runner-up is that they tried once but got frustrated; they're not sure where to add an idea, or how the syntax works; or they don't have time. The clearer and more intuitive the editing interface, the faster the learning curve, and the fewer people who will think they don't have time to figure it out.
On Mon, 14 Mar 2005 14:08:38 -0700, Sterling D. Allan sterlingda@pureenergysystems.com wrote:
It seems to me that early on the development curve of wiki software made a choice (a bad one, in my opinion) to go the code direction rather than the WYSIWYG direction.
Well, *extremely* early on in the development of wiki software, the choice was made to favour *simplicity*. Ward Cunningham called it "wiki wiki", meaning quick, and that's what it was - a barebones structure, that "just worked", without too much fuss. To "go in the WYSIWYG direction" you have to first create some underlying machine-readable code [you have to store it somehow], and then make some kind of human graphical interface that produces that code. So if you're going for simplicity, human-oriented code is the way to go, because you can just dispense with the last step - it's not so much "going in the code direction" as "not going as far as the crossroads".
Simplicity also meant that there wasn't really much to learn - mostly, you were just typing text with the odd CamelCaseLinkPattern in. Plus, of course, it was never meant to be "for as wide as possible an audience" - it was a kind of collabourative notebook for those interested enough to take part, and most of the people who were involved spent more time using their wikis to discuss things than developing them to be flashy and user-friendly. So my guess is that for the first, slow, wave of wikis the syntax really wasn't that big a problem.
Bear in mind also that the original wiki dates all the way back to 1995, when the idea of a reliable in-browser WYSIWYG editor would probably have seemed like asking for the moon on a stick [1]. And, AIUI, MediaWiki is only 2-and-a-half steps removed from that original wiki, with a distinct feel of 'evolution' [2] so it's maybe not surprising that although people have started looking at the WYSIWYG end of things, it's tended to be in more "revolutionary" takes on the wiki concept.
That's not to say the time hasn't come to WYSIWYGify MediaWiki - although the limited JavaScript editting toolbar we now have demonstrates just how cleverly something has to work to be "idiot proof" (just look around for newbies inserting text like '''Bold text''' and [[example link]]...) - but I think the claim that a decision, bad or otherwise, was taken in the past is somewhat naive.
Notes: ===== [1] I couldn't resist referencing this: http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/moon-on-stick.htm...
[2] I believe the progression goes: WikiWikiWeb --> UseModWiki (a "WikiClone"; the one WikiPedia started using) --> "Phase 2 Wikipedia" (UseMod rewritten in PHP with bells on) --> MediaWiki ("Phase 3")
On Mon, 14 Mar 2005 21:53:50 +0000, Rowan Collins rowan.collins@gmail.com wrote:
On Mon, 14 Mar 2005 14:08:38 -0700, Sterling D. Allan sterlingda@pureenergysystems.com wrote:
It seems to me that early on the development curve of wiki software made a choice (a bad one, in my opinion) to go the code direction rather than the WYSIWYG direction.
Well, *extremely* early on in the development of wiki software, the choice was made to favour *simplicity*. Ward Cunningham called it "wiki wiki", meaning quick, and that's what it was - a barebones structure, that "just worked", without too much fuss.
It seem to me that there's a kind of vicious circle here.
I was one of the early user's of Ward's original web site, which is still plugging away on c2.com. It's still quite simple, there is minimal markup, and the output is pretty close to the input, so it's almost wysiwyg. Ward didn't implement any fancy features.
Newer wiki implementations, as new implementations of anything tend to do, have added features, mediawiki is the most feature rich wiki I've run across. I was personally attracted to it because of the support for inline images. I was using twiki which is much closer in it's markup language "sophistication" to wikiwikiweb than mediawiki is, but wanted to put images in my articles rather than just as e-mail like attachments so I moved to mediawiki.
I guess my point is that the features have driven things to be less wysiwyg than they used to be in wiki land where wyg is more restricted.
Not that I wouldn't love to have better tools to allow less markup language literate folks to contribute to my wiki.
On 14 Mar 2005, at 13:53, Rowan Collins wrote:
Well, *extremely* early on in the development of wiki software, the choice was made to favour *simplicity*... you were just typing text with the odd CamelCaseLinkPattern in.
So let people enter plain text! What's wrong with that? Why must EVERY USER be a graphic artist? (I assure you, they are not!)
With the exception of [[square brackets]] instead of CamelCase, one can use MediaWiki in pretty much the same way as one uses c2.com, no?
The only exception I can bring to mind is if unsophisticated users are interested in correcting typos in heavily-marked-up text. And if that's the case, nothing short of a full WYSIWYG authoring environment is going to do the job. (Those who are seeking "full WYSIWYG", take a look at GoLive or Dreamweaver. Do you really want to turn THAT loose on your unsophisticated users?)
Page authors should either assume THEY are going to be doing 95% of the maintenance, on they should KISS the complications goodbye, and make it inviting for less sophisticated users.
:::: Sell your cleverness, and purchase bewilderment -- Rumi :::: Jan Steinman http://www.Bytesmiths.com/Item/99-6313-15
Related to all this... I am planning to use Mediawiki to build a website that allows collaborative edition, but aimed to everybody (including users that only know to use Internet, and barely).
I doubt between integrate with KBabel or other .po editor free source, or build a new editor, but it seems for your sayings that they should learn marks, and that that's not the idea..although it would be brief texts without bold nor that things.
Better integrate Mediawiki with external editors (free source also) is best solution, not only in my case, but also generallly?
Thanks
Jordi
Quoting Jan Steinman Jan@Bytesmiths.com:
On 14 Mar 2005, at 13:53, Rowan Collins wrote:
Well, *extremely* early on in the development of wiki software, the choice was made to favour *simplicity*... you were just typing text with the odd CamelCaseLinkPattern in.
So let people enter plain text! What's wrong with that? Why must EVERY USER be a graphic artist? (I assure you, they are not!)
With the exception of [[square brackets]] instead of CamelCase, one can use MediaWiki in pretty much the same way as one uses c2.com, no?
The only exception I can bring to mind is if unsophisticated users are interested in correcting typos in heavily-marked-up text. And if that's the case, nothing short of a full WYSIWYG authoring environment is going to do the job. (Those who are seeking "full WYSIWYG", take a look at GoLive or Dreamweaver. Do you really want to turn THAT loose on your unsophisticated users?)
Page authors should either assume THEY are going to be doing 95% of the maintenance, on they should KISS the complications goodbye, and make it inviting for less sophisticated users.
:::: Sell your cleverness, and purchase bewilderment -- Rumi :::: Jan Steinman http://www.Bytesmiths.com/Item/99-6313-15
MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Better integrate Mediawiki with external editors (free source also) is best solution, not only in my case, but also generallly?
it's not difficult if you know how. I use BBEdit and Applescript to edit pages. I have complete non-geeks editing pages happily. How can wiki text get 'heavily marked up'? anyway? It's not that bad, however bad it is (we're not talking HTML, are we?)
WYSIWYG is usually very poor under the hood - I don't even use Word Processors any more. Trying to do some kind of Dreamweaver would be really over the top! As for Word import, it hasn't worked with any other Word Processor properly (believe me, I've tried...) so what's the point?
Quoting Jan Steinman, from the post of Mon, 14 Mar:
The only exception I can bring to mind is if unsophisticated users are interested in correcting typos in heavily-marked-up text. And if that's the case, nothing short of a full WYSIWYG authoring environment is
well, if you have a full-blown wysiwyg, may as well do the spellchecker as well. I've seen spellcheckers on a wiki, wasn't it twiki or something?
going to do the job. (Those who are seeking "full WYSIWYG", take a look at GoLive or Dreamweaver. Do you really want to turn THAT loose on your unsophisticated users?)
not GL or DW, but a simplified WYSIWYG editor like the one in Netscape (and maybe still in Mozilla Seamonkey may it RIP)
:::: Sell your cleverness, and purchase bewilderment -- Rumi
Wish I could...
as a final note, there is Diderot that was advertised here a while back, though it's windows only and at pre-alpha stage: http://wikiwriter.sourceforge.net/
Gotta love the "catch". if you want an easy UI, you'll have a complicated installation, however if you stick to your sumple browser you'll have the learning curve of the Wiki ML.
the solution, of course, is a XUL application for Mozillas. cross platform and built into the browser. I hope this is where this is going: https://addons.update.mozilla.org/extensions/moreinfo.php?id=351
links naturally came from here and other places: http://meta.wikimedia.org/wiki/WYSIWYG_editor
Gotta love the "catch". if you want an easy UI, you'll have a complicated installation, however if you stick to your sumple browser you'll have the learning curve of the Wiki ML.
Is there any cheatsheet on wiki-tags, easily printable sheet with all the wiki-tags.. so that newbies like me can print it and keep it aside while working on wiki's ?
TIA,
-=skillz=-
Is there any cheatsheet on wiki-tags, easily printable sheet with all the wiki-tags.. so that newbies like me can print it and keep it aside while working on wiki's ?
sounds like a good task for a newbie... compiling it will teach you most of them off by heart...! tell you what, you create one somewhere, I'll check it over (I don't have time to do it from scratch) and then everyone gets to use it (other helpers very welcome...).
Jason Davies wrote:
Is there any cheatsheet on wiki-tags, easily printable sheet with all the wiki-tags.. so that newbies like me can print it and keep it aside while working on wiki's ?
sounds like a good task for a newbie... compiling it will teach you most of them off by heart...! tell you what, you create one somewhere, I'll check it over (I don't have time to do it from scratch) and then everyone gets to use it (other helpers very welcome...).
http://meta.wikimedia.org/wiki/Help:Editing is pretty much what you want ;-) I suppose it would be useful to do it up as a single page printable PDF or similar, to stick on the wall or whatever.
- d.
On 16 Mar 2005, at 06:04, skill2die4@secguru.com wrote:
Is there any cheatsheet on wiki-tags, easily printable sheet with all the wiki-tags.. so that newbies like me can print it and keep it aside while working on wiki's ?
I need such a thing within the next two weeks, when I'll be giving a Wiki class to our group.
If someone else is going to work on such a thing in the meantime, I'll be willing to review and/or collaborate.
If not, I'll roll my own and make it available. But it would be nice if two or more of us DIDN'T do the same thing at the same time, no?
Worst case, I was simply going to print out and distribute the Meta "edit help" page from "http://meta.wikimedia.org/wiki/Help:Editing", possibly extracting just the tables from "#The_wiki_markup". This is a GREAT resource, but it would be nice to have a version that would fit nicely on two sides of a sheet of paper! (Wikis do not make good page-layout programs!)
BTW: I have hacked my site's "edit help" to point to this page, having given up on exporting and importing all the help into a new site.
:::: The earth's immune system, so to speak, has recognized the presence of the human species and is starting to kick in. The earth is attempting to rid itself of an infection by the human parasite. -- Richard Preston :::: Jan Steinman http://www.Bytesmiths.com
Worst case, I was simply going to print out and distribute the Meta "edit help" page from "http://meta.wikimedia.org/wiki/Help:Editing", possibly extracting just the tables from "#The_wiki_markup".
While they don't cover everything, I re-wrote some of the help tables into what I think is a bit more readable form. See http://wolfandturtle.net/Indigo/index.php/Help:Contents mostly the 'Editing and formating' page.
Myria
On Wed, 2005-16-03 at 07:41 +0200, Ira Abramov wrote:
the solution, of course, is a XUL application for Mozillas.
I think using the built-in WYSIWYG HTML editor is a more logical choice, and one used by all kinds of CMS and blog tools. See htmlArea, Kupu, ePoz, etc.
~Evan
Quoting Evan Prodromou, from the post of Wed, 16 Mar:
On Wed, 2005-16-03 at 07:41 +0200, Ira Abramov wrote:
the solution, of course, is a XUL application for Mozillas.
I think using the built-in WYSIWYG HTML editor is a more logical choice, and one used by all kinds of CMS and blog tools. See htmlArea, Kupu, ePoz, etc.
I think those were mentioned in the beginning of this thread as being problematic when crossing platforms.
indeed, maybe a Java implementation will be the most standard (won't be as quick and flexible as a Flash implementation, but will run on more platforms I guess)
A "third possibility" that exists somewhere between utterly complete and accurate WYSIWYG editing and markup-submit-preview might be live preview.
I've really grown fond of a number of live preview text editors out there for doing HTML. SubEthaEdit, for example, updates the HTML view with each keystroke in the editor.
This should be moderately easy to do client-side in Java, or perhaps even JavaScript. Pop open a "preview" window that instantly shows what the result is going to look like, with some minor restrictions, like not showing the proper state of links, for example.
:::: God told me to strike at Al Qaeda and I struck them. And then he instructed me to strike at Saddam, which I did. With the might of God on our side we will triumph. -- George W. Bush :::: I believe that I am acting in accordance with the will of the Almighty Creator. -- Adolf Hitler :::: Never forget that everything Hitler did in Germany was legal. -- Dr. Martin Luther King :::: Jan Steinman http://www.Bytesmiths.com
My user base ranges from wiki-experts to computer novices. The novices are usually unable to grasp the idea of a markup language and give up before making contributions. On the other hand, some of my wiki-experts are frustrated with YAWML--Yet Another Wiki Markup Language. It's nice to live in one wiki world, but it's not always possible and the local markup dialects seem unending. Both extremes and many users in between would benefit from a more direct editing approach that avoided the markup nature of current wikis. Even a limited set of capabilities would provide scaffolding for the novice and a welcome relief to the expert. The current markup can be available for those who want to add complexity or elegance.
This issue is probably not a MediaWiki issue. Supporting Wikipedia and family is obviously job #1, and it seems well-served by the current structure. But there are many of us who have borrowed the MediaWiki tool (for all it's benefits) and applied it to other contexts. If WE want different editing capabilities, then WE will probably need to step up to the plate and make it happen.
Con Rodi Center for Human-Computer Interaction Virginia Tech
On Mar 14, 2005, at 1:59 PM, Sterling D. Allan wrote:
I can see that the sheer number of HTML/Wiki code possibilities used in mediawiki would make the WYSIWYG task nearly impossible if one wanted to be able to enable all possible formatting options. So the "price" one will pay in going with a WYSIWYG editor would be a narrowing of formatting options.
In my case, that is a price that I would be willing to pay because I want to make it easy for those brilliant scientists who barely know how to spell.
Some day, browsers will come equipped with WYSIWYG editors that will automatically detect the wiki code and present it in the most user-friendly manner possible.
"Import document" features will enable conversion from other formats from WordPerfect to Word and HTML.
Some day.
Quoting Sterling D. Allan, from the post of Mon, 14 Mar:
Some day, browsers will come equipped with WYSIWYG editors that will automatically detect the wiki code and present it in the most user-friendly manner possible.
ok, this is the third thread to open on the subject in two days. I feel like this is starting to look like a trolling frenzy.
Features like that are hard to implement, as people posted here. If you want your dream - build it and we will come. now let's make room on the list for other stuff.
(one tiny final note, I agree with Jan's view that a tool with more options does not necessarily cause users to start using it right. I prefer non-techie people to post informative articles, even if badly phrased or stylized and have other wikipedians fix it up for them, then have them avoid posting altogether.
My user base ranges from wiki-experts to computer novices. The novices are usually unable to grasp the idea of a markup language and give up before making contributions.
I don't understand this. I have people who can barely switch on their computer using the wiki happily. A lot of users find it hard to get started, so I often spend a bit of time getting them on to it, then add more capabilities (like Categories) later. Maybe they need a bit of coaching. You don't have to do it all - I have them training each other now.
maybe borrow our 'beginner's overview'? A lot of them have said it is very useful. http://tinyurl.com/7yhjy. It's for mediawiki not any other software.
Jason Davies wrote:
I don't understand this. I have people who can barely switch on their computer using the wiki happily. A lot of users find it hard to get started, so I often spend a bit of time getting them on to it, then add more capabilities (like Categories) later. Maybe they need a bit of coaching. You don't have to do it all - I have them training each other now.
That's because, as any Wikipedia wikiholic knows, it's *utterly compelling*.
maybe borrow our 'beginner's overview'? A lot of them have said it is very useful. http://tinyurl.com/7yhjy. It's for mediawiki not any other software.
That's excellent! What are the copyright terms? GFDL or something else?
- d.
That's excellent! What are the copyright terms? GFDL or something else?
I think they're 'help yourself'...I spent a surprising amount of time making it that simple. I am very happy for it to help as many people as possible...an acknowledgement is usually nice, but I don't think it's in the wiki spirit, so just copy away...
On Mon, Mar 14, 2005 at 10:19:46AM -0800, Jan Steinman wrote:
I would not go quite so far as Paul, but I think there are better places to put resources than WYSIWYG editing.
I agree almost completely with you ... the problem comes with tables where the text layout becomes complicated and where a WYSIWYG interface would be useful.
Twiki for example has a great add-in via a %TABLE command that allows for the formatting of the table (header, footer, alternate rows) to be defined without having to put the code in the actual table.
I have tried numerous open source packages and none of them allow for easy tables in a wiki -- this is what is missing for the masses.
Regards
James
I think offline editing is extrmely useful, probably not for Wikipedia, but for MediaWiki sites: it'd be useful to be able to create and maintain a set of pages in an offline 'project'. I've not tried the plugin to see if it can handle non-wikipedia sites.
Tony.
Axel wrote:
On Sun, 13 Mar 2005 19:49:49 +0000, Tony Linde tony@linde.me.uk wrote:
Not sure if this helps: http://www.plog4u.org/index.php/Main_Page
The plog4u eclipse editor plugin isn't a direct "what you see is what you get" editor. It's focusing on editing Wikipedia articles offline (through downloading and uploading articles) and creating PDF documents from the articles.
The built-in "html preview browser" refreshs it's view if you save the edited text to the local file system and let "you see what you get".
Hi
A new plog4u version 1.1.5 is available here * http://prdownloads.sourceforge.net/plog4u/plog4u.community_tools_1.1.5.bin.z...
I must admit that the greatest change in the latest release is the move to a new sf.net project page: * http://sf.net/projects/plog4u Please submit your bugs and features on this new project page. Anyone who likes to help in the development of the wikipedia editor plugin is welcomed.
Description of a new configuration option: * http://www.plog4u.org/index.php/Using_Eclipse_Wikipedia_Editor:Configuration...
On Sun, 2005-13-03 at 12:43 -0700, Sterling D. Allan wrote:
Can anyone tell me if there is already in existence an editor program that enables one to edit mediawiki pages in a "what you see is what you get" mode (editing for dummies)?
I have an associate who says he could build such a program quite easily. I'm thinking, if it's so easy why hasn't it been done; surely it has been done; if so, where?
This is a subject near and dear to my heart. There's a good discussion on meta.wikimedia.org:
http://meta.wikimedia.org/wiki/WYSIWYG
Here'd be my guess why it hasn't been implemented yet:
* If you use an in-browser WYSIWYG HTML editor (the best user experience, in my opinion), you've got to create an HTML-to-Wikitext converter. We keep changing the Wikitext format, so it's a moving target. * Also, for an in-browser WYSIWYG HTML editor, there's tons of customization to do. Links? Images? Templates? These are all kind of hard. And you have to figure out how to block out unwanted HTML elements, like <span> and <div>. * There are too many cross-browser in-browser WYSIWYG HTML editor tools (Kupu, htmlArea, fckEditor, epoz, dot dot dot). Nobody's up for committing to one or the other. * If you use an out-of-browser editor (I think there's some other ideas for doing that), you have to figure out how to get your Wikitext in and out of the server, avoid edit conflicts, and deal with lots and lots and lots of platform issues. * The main developers of MediaWiki concentrate on the needs of Wikimedia, and most of their development effort goes into a) reducing load on their servers and b) putting in stricter security features. * It will probably require some serious prioritization by MediaWiki developers, and it's just not there. * It's a huge frickin' undertaking. Most features in MediaWiki are wedged-in 4-liners. * There are few other public systems using in-browser WYSIWYG HTML editors (I think Wacko Wiki is the only major Wiki engine doing it, for example), so there's not a lot of pressure to get it working.
If your associate is really interested in helping out with this, it needs to be done. I think if we ever get around to making a development roadmap, WYSIWYG editing should be part of a 2.x system.
~Evan
On Sun, 13 Mar 2005 16:03:36 -0500, Evan Prodromou evan@bad.dynu.ca wrote:
On Sun, 2005-13-03 at 12:43 -0700, Sterling D. Allan wrote:
Can anyone tell me if there is already in existence an editor program that enables one to edit mediawiki pages in a "what you see is what you get" mode (editing for dummies)?
This is a subject near and dear to my heart. There's a good discussion on meta.wikimedia.org:
http://meta.wikimedia.org/wiki/WYSIWYG
It might also be worth looking at http://meta.wikimedia.org/wiki/Alternative_parsers and http://en.wikipedia.org/wiki/Wikipedia:Tools for some of the things people *have* already coded. From memory, the only thing that comes anywhere close is the Eclipse plugin [as linked by Tony] - it's not wysiwyg, but I believe it does "understand" wikitext natively, and render it live, as well as interfacing with the server, so it's possibly only that one step away (I haven't actually used it by the way, just read about it).
A WYSIWYG option for wiki-editing would be just wonderful. In fact, since one of the problems with this is finding a tool that works in all browsers, simply offering options for what the user's edit-area looks like, would be a good place to start.
Evan makes some great points:
http://meta.wikimedia.org/wiki/WYSIWYG
<
* If you use an in-browser WYSIWYG HTML editor... you've got to create an HTML-to-Wikitext converter.
It might be possible to just make it a wikitext editor, and run a Wikitext-to-HTML converter for displaying it as you type. To get an idea of how much wiki-formatting there is to handle, see for instance Pilaf's preview-javascript: http://en.wikipedia.org/w/index.php?title=User:Pilaf/livepreview.js
< customization to do. Links? Images? Templates? These are all
Checking to see if a link is red or not is hard. Images and templates don't have to be rendered immediately, but could be displayed more intuitively; i.e., * "<green><i>Template:my-text</i></green>" * "<green><b>Image:Mary figurine</b> (right-aligned, 200 pixels wide)</green> <blue><i>Luminescent figurine</i></blue>" rather than "{{my-text}}" or "[[Image:Mary figurine|right|200px|Luminescent figurine]]"
< * It will probably require some serious prioritization by
MediaWiki developers, and it's just not there.
Perhaps. It seems to me that someone could write an in-browser wiki editor which did a decent job of providing WYSIWYG for 90% of an editor's needs, without worrying about the parsing details for cutting-edge wiki syntax. Then you could make switching to that editor a preference which could be toggled from the edit page:
________________________________________ <h1> Editing PAGENAME </h1>
From Wikipedia, the free encyclopedia
[ ] Show edit toolbar | Edit tool: [ ] Walt's WYSIWYG editor [ ] Default wiki editor ________________________________________
* There are few other public systems using in-browser WYSIWYG HTML editors (I think Wacko Wiki is the only major Wiki engine doing it, for example), so there's not a lot of pressure to get it working.
Don't forget about Web's Biggest. Their site may be slooooow, but they at least have a "major" sense of self-worth. http://dirs.org/dir-wiki.cfm?cat=Wikipedia_1&tab=edit
mediawiki-l@lists.wikimedia.org