Re: [Wikitech-l] Proposal for editing template calls within pages
On 9/30/09 5:59 PM, Aryeh Gregor wrote: [snip] Of course, this can get ugly if you later want to add more capabilities to the format, so JSON or YAML might make sense, but XML is overboard IMO. I'd use XML for text markup only, if that. But no point in bikeshedding -- if this gets done, whoever does it gets to decide the format. Yep. :) The main reasons to look at XML specifically (vs say JSON which is also available built-in for both our server and client sides) is that building a structure that's localization-friendly is straightforward, since you can easily tack on a 'lang' attribute. This could be done in JSON but probably with a different tree structure. Given we already had a proposed XML structure designed at the start of this thread (based in part on the previous work on German Wikipedia), I don't see much reason to continue talking formats unless there's an alternative structure proposal with solid benefits. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On 9/28/09 12:56 PM, Daniel Friesen wrote: On that note, what happened to Creole? I looked at the Creole wiki some time ago, and I remember a good deal of notes on how MediaWiki could handle Creole implementation. I haven't heard anything about creole on the wikitech list though. Dead as a doornail; there was never a clear benefit or incentive for anyone to move to it. You just end up with different confusing squiggly characters, and to get there you've had either an ugly transition or some kind of bizarre translation that's likely to break. If you're going to go through the pain, you should get some tangible benefit out of it. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On 9/27/09 4:25 AM, Aryeh Gregor wrote: Depending on what features are added, exactly, I'd imagine a lighter-weight markup language would be more than sufficient. Something where you can describe the syntax in less than a page and write a correct implementation in half an hour or less would probably be good enough. Like maybe just newline-delimited key=value pairs, or something like JSON at worst. I don't see any point to inventing yet another markup language for internal data transfer; I'd much rather use something that: 1) is a known, implemented standard 2) has standard support in PHP 3) has standard support in JavaScript If you feel the need to describe the syntax, you've already lost time and gained nothing. :) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Wed, Sep 30, 2009 at 8:29 PM, Brion Vibber br...@wikimedia.org wrote: I don't see any point to inventing yet another markup language for internal data transfer; I'd much rather use something that: 1) is a known, implemented standard 2) has standard support in PHP 3) has standard support in JavaScript If you feel the need to describe the syntax, you've already lost time and gained nothing. :) You've gained ease of use, because people don't have to bother learning how to use their language's standard library for the language, if it even has one. Is XML reliably supported in JavaScript? And didn't we have problems with PHP on RHEL not supporting the XML library that was supposed to be standard? If you can describe the language with a one-line regex, you're using a parser that's in *every* language out there, and that *every* programmer should already be familiar with. Not to mention they could just copy-paste the regex even if they don't know regex, modulo some slashes if their language prefers POSIX. If it can be described by one or two explode()s (like key=val;val;val), even better. Of course, this can get ugly if you later want to add more capabilities to the format, so JSON or YAML might make sense, but XML is overboard IMO. I'd use XML for text markup only, if that. But no point in bikeshedding -- if this gets done, whoever does it gets to decide the format. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
* Yaron Koren yaro...@gmail.com [Tue, 29 Sep 2009 00:53:07 -0400]: That would certainly simplify the format; on the other hand, it would lead to a lot of redundancy between the different documentation tags, which could lead to conflicting data structures; so it's probably not a workable solution. -Yaron There could be documentation lang=en, documentation lang=fr, documentation lang=de... ___ What if to have an documentation section to define common settings, such as parameter types and english names, and to use documentation lang=code to override the names and descriptions for the particular code of language? Or, maybe using XML-like trees, but with shorter syntax, without much of nested tags, something like JAML or alternative nested brackets syntax, like the one library was once described by Gregory Maxwell? But, in case it would not have to be source-edited, maybe XML will be the most proper way. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
David Gerard wrote: 2009/9/24 Aryeh Gregor simetrical+wikil...@gmail.com: On Thu, Sep 24, 2009 at 10:48 AM, dgerard dger...@gmail.com wrote: WYSIWYG editing is getting there bit by bit - FCKeditor would be fine on a fresh wiki without the unspeakable atrocities inventive geeks have perpetrated upon wikitext on en:wp and should continue to get better at dealing with more obtusities. Funnily enough, I just talked to a user in #mediawiki asking why FCKeditor didn't work right on his wiki when copy-pasting from MS Word. *facepalm* And then there's the obvious things users will do that I hadn't thought of, yes. - d. I had a user who copied an article from the html of Wikipedia (no edit button) into Wikia's RTE. The real disturbing part is unlike when people copy Wikipedia's html into the edit box where it results in tell tale ?'s (Anime related articles, 99.99% of articles copied in my case will be using the nihongo template) and various other patterns, something copied html to rte looks almost perfectly fine when looking at it, up till you hit the edit button and see the mangled source. T_T RTE makes it easier for inexperienced people to do stupid things. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
Brion Vibber wrote: ... Having this infrastructure in place further means we're in a better position to someday make a major markup transition (say to a different markup system or not exposing markup at all in a pure-WYSIWYG environment)... something we're now very far from... but doesn't commit us to any markup changes in the near or medium term. ... -- brion On that note, what happened to Creole? I looked at the Creole wiki some time ago, and I remember a good deal of notes on how MediaWiki could handle Creole implementation. I haven't heard anything about creole on the wikitech list though. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
Like YAML? ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] Aryeh Gregor wrote: On Fri, Sep 25, 2009 at 6:48 PM, Brion Vibber br...@wikimedia.org wrote: The field metadata can be fairly straightforwardly displayed and edited through a nice web interface. XML as such is simply a conveniently well-defined structured data tree format which can be used both for storing the field metadata in the DB and exposing it to the template invocation editor interface (whether client-side JS or server-side PHP or a custom bot-based tool speaking to our API). Depending on what features are added, exactly, I'd imagine a lighter-weight markup language would be more than sufficient. Something where you can describe the syntax in less than a page and write a correct implementation in half an hour or less would probably be good enough. Like maybe just newline-delimited key=value pairs, or something like JSON at worst. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Tue, Sep 29, 2009 at 5:55 AM, Daniel Friesen li...@nadir-seen-fire.com wrote: I had a user who copied an article from the html of Wikipedia (no edit button) into Wikia's RTE. Theoretically that use case could be supported, right? If there were enough id's in the HTML source, then we could map back onto the underlying wikitext and paste that in instead. Difficult though... OTOH, it might be easier to detect when this is happening and warn the user. Steve ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
That would certainly simplify the format; on the other hand, it would lead to a lot of redundancy between the different documentation tags, which could lead to conflicting data structures; so it's probably not a workable solution. -Yaron There could be documentation lang=en, documentation lang=fr, documentation lang=de... ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Fri, Sep 25, 2009 at 6:48 PM, Brion Vibber br...@wikimedia.org wrote: The field metadata can be fairly straightforwardly displayed and edited through a nice web interface. XML as such is simply a conveniently well-defined structured data tree format which can be used both for storing the field metadata in the DB and exposing it to the template invocation editor interface (whether client-side JS or server-side PHP or a custom bot-based tool speaking to our API). Depending on what features are added, exactly, I'd imagine a lighter-weight markup language would be more than sufficient. Something where you can describe the syntax in less than a page and write a correct implementation in half an hour or less would probably be good enough. Like maybe just newline-delimited key=value pairs, or something like JSON at worst. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
The idea of having the template specification be stored as something more human-readable, and possibly more like wiki-text, certainly has its appeal (at least, to those people who don't want wiki-text to be replaced by XML in the first place!) It would be easier for users to create and edit; unless there were a tool to edit the XML, and users always used that tool... I really don't know whether XML or something simpler would be the better solution in the long run. I do believe, though, that the thing that prevents a simpler storage format is the need for translation. Without it, a template parameter can be defined by a simple set of values: a label, a description, an input type, and then a handful of modifiers for the input type (like the list of allowed values, if it's a radiobutton or dropdown). If translation of different values is allowed, though, you really need the structure that XML provides, or else the whole thing devolves into chaos. Most wikis won't require translation, though; and that includes most Wikimedia projects - they're in one language at a time. The one big exception is Wikimedia Commons, which also happens to be the proposed first usage of this template-call-editing system. And for that site, translation really is necessary (I think). So, at the risk of complicating things even further - maybe it makes sense to have a split approach - one format that handles translation, another that doesn't? The non-translation format, given that it would be simpler, could even be embedded directly in the template - possibly within a documentation tag in the template, as Platonides suggested. I put together some ideas on how this could work, here: http://usability.wikimedia.org/wiki/Template_forms#Specification_structure -Yaron ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
* Tei oscar.vi...@gmail.com [Sat, 26 Sep 2009 02:40:06 +0200]:
Hello.
Heres a screenshot of me editing the wikipedia:
http://zerror.com/unorganized/crap/nogoodenough.png
All the webmasters on this mail list will spot the problem with this
text in 1 second: is unreadable. The space betwen lines, the lines
length, the complexity of the text... Is really hard to read.
A HTML textarea can server for writting emails, and simple text, but
on this image fail short. Textareas are not designed for this, or are
not good enough.
How a webmaster can make that text better? well.. you need to stop
using the HTML textarea widget. And emulate it with divs, css and
javascript. You need to colorize the code. Nowdays *ALL* good code
editors colorize code. If our code editor don't colorize the wiki
sintax, or don't even try, our editor is bad. I could be wrong, but
maybe [[links]] and {{templates}} can be detected and colorized. And
since you are emulating a editor, you can add a bit of usefull
beaviors: make so some areas are read only, so the cursor skip then.
Oh.. and you can make the whole think AJAXified,.. so wen you click
[Edit section] this section become editable, and wen you save, the
edit view send, and is replaced by the result. Why would you want to
people bounce here and there to post stuff in 2009?
He... our computers support 24 M colors, and we are showing text with
2 colors? pfff
I am very much supporting you! Both code colorizing and AJAX editing
preview. And maybe a links code completion - when yuu press [[ it will
open an JS-generated dialog with drop-down title search list. It's not
that wikitext is too hard (with the huge exception of templates) but the
editor is very much restricted.. Though templates surely aren't nice and
it's probably is better to keep them separate and XML-ize them.
Dmitriy
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/26 Dmitriy Sintsov ques...@rambler.ru: I am very much supporting you! Both code colorizing and AJAX editing preview. The usability initiative intends to do both, in addition to code folding (compressing long and complicated things such as templates, table calls and references into a small placeholder than can be expanded at wish). And maybe a links code completion - when yuu press [[ it will open an JS-generated dialog with drop-down title search list. We've done something similar to this idea, and hope to deploy it on Wikipedia soon. Basically it's a toolbar button that launches a link dialog with title suggestions for internal links. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Sat, Sep 26, 2009 at 10:14 AM, Dmitriy Sintsov ques...@rambler.ru wrote:
* Tei oscar.vi...@gmail.com [Sat, 26 Sep 2009 02:40:06 +0200]:
Hello.
Heres a screenshot of me editing the wikipedia:
http://zerror.com/unorganized/crap/nogoodenough.png
All the webmasters on this mail list will spot the problem with this
text in 1 second: is unreadable. The space betwen lines, the lines
length, the complexity of the text... Is really hard to read.
A HTML textarea can server for writting emails, and simple text, but
on this image fail short. Textareas are not designed for this, or are
not good enough.
How a webmaster can make that text better? well.. you need to stop
using the HTML textarea widget. And emulate it with divs, css and
javascript. You need to colorize the code. Nowdays *ALL* good code
editors colorize code. If our code editor don't colorize the wiki
sintax, or don't even try, our editor is bad. I could be wrong, but
maybe [[links]] and {{templates}} can be detected and colorized. And
since you are emulating a editor, you can add a bit of usefull
beaviors: make so some areas are read only, so the cursor skip then.
Oh.. and you can make the whole think AJAXified,.. so wen you click
[Edit section] this section become editable, and wen you save, the
edit view send, and is replaced by the result. Why would you want to
people bounce here and there to post stuff in 2009?
He... our computers support 24 M colors, and we are showing text with
2 colors? pfff
I am very much supporting you! Both code colorizing and AJAX editing
preview. And maybe a links code completion - when yuu press [[ it will
open an JS-generated dialog with drop-down title search list. It's not
that wikitext is too hard (with the huge exception of templates) but the
editor is very much restricted.. Though templates surely aren't nice and
it's probably is better to keep them separate and XML-ize them.
Dmitriy
For templates you can use a Code beatiffier, that unofuscate the code.
Templates can be hard to write, but theres no reason to let then be
hard to read. Maybe MW already do that..
Here is a example using another template language (bbcode):
[uRL]lalala[/URL] = [url]lalala[/url]
[quote=Dan]blabla bla bla[/img] =
[quote= Dani ]
bla bla bla
[/quote]
I know that this maybe is a bad idea, If this may cause other
problems, and theres one million others things that are worth our time
:-I
A serverside Code beatifier can also helps a clientside colorizer.
He can massage the template code first, and be smarter than the
colorizers and prevent problems before hit the colorizer. A code
beafifier can be implemented in a incremental way, the first version
can just lowercase all letter. The colorizer can also be
implemented in a incremental way, starting colorizing simple stuff.
If a colorizing or a beatifier become a problem, can be deactivated,
and things will continue smoothly.
--
--
ℱin del ℳensaje.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
Guys,
Why are we talking XML? Yaron's Semantic Forms survived without XML - yes,
it's definition language is not English, but it's good enough and works
relatively good with the rest of MW syntax.
I think using XML will not necessarily do good here as form creators would
want the language to be close to the rest of the wiki.
Here's the example of the form which is the mix of wikitext, HTML and
regular wiki formatting
http://www.techpresentations.org/w/index.php?title=Form:Presentationaction=edit
It worked for me. Maybe this kind of definition can be merged with Template
pages, but frankly SF's model works pretty well (of course, SF is also smart
about data because of SMW, but it can be more manual).
Thank you,
Sergey
--
Sergey Chernyshev
http://www.sergeychernyshev.com/
On Sat, Sep 26, 2009 at 8:11 AM, Tei oscar.vi...@gmail.com wrote:
On Sat, Sep 26, 2009 at 10:14 AM, Dmitriy Sintsov ques...@rambler.ru
wrote:
* Tei oscar.vi...@gmail.com [Sat, 26 Sep 2009 02:40:06 +0200]:
Hello.
Heres a screenshot of me editing the wikipedia:
http://zerror.com/unorganized/crap/nogoodenough.png
All the webmasters on this mail list will spot the problem with this
text in 1 second: is unreadable. The space betwen lines, the lines
length, the complexity of the text... Is really hard to read.
A HTML textarea can server for writting emails, and simple text, but
on this image fail short. Textareas are not designed for this, or are
not good enough.
How a webmaster can make that text better? well.. you need to stop
using the HTML textarea widget. And emulate it with divs, css and
javascript. You need to colorize the code. Nowdays *ALL* good code
editors colorize code. If our code editor don't colorize the wiki
sintax, or don't even try, our editor is bad. I could be wrong, but
maybe [[links]] and {{templates}} can be detected and colorized. And
since you are emulating a editor, you can add a bit of usefull
beaviors: make so some areas are read only, so the cursor skip then.
Oh.. and you can make the whole think AJAXified,.. so wen you click
[Edit section] this section become editable, and wen you save, the
edit view send, and is replaced by the result. Why would you want to
people bounce here and there to post stuff in 2009?
He... our computers support 24 M colors, and we are showing text with
2 colors? pfff
I am very much supporting you! Both code colorizing and AJAX editing
preview. And maybe a links code completion - when yuu press [[ it will
open an JS-generated dialog with drop-down title search list. It's not
that wikitext is too hard (with the huge exception of templates) but the
editor is very much restricted.. Though templates surely aren't nice and
it's probably is better to keep them separate and XML-ize them.
Dmitriy
For templates you can use a Code beatiffier, that unofuscate the code.
Templates can be hard to write, but theres no reason to let then be
hard to read. Maybe MW already do that..
Here is a example using another template language (bbcode):
[uRL]lalala[/URL] = [url]lalala[/url]
[quote=Dan]blabla bla bla[/img] =
[quote= Dani ]
bla bla bla
[/quote]
I know that this maybe is a bad idea, If this may cause other
problems, and theres one million others things that are worth our time
:-I
A serverside Code beatifier can also helps a clientside colorizer.
He can massage the template code first, and be smarter than the
colorizers and prevent problems before hit the colorizer. A code
beafifier can be implemented in a incremental way, the first version
can just lowercase all letter. The colorizer can also be
implemented in a incremental way, starting colorizing simple stuff.
If a colorizing or a beatifier become a problem, can be deactivated,
and things will continue smoothly.
--
--
ℱin del ℳensaje.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
* Sergey Chernyshev sergey.chernys...@gmail.com [Sat, 26 Sep 2009 21:23:25 -0400]: Guys, Why are we talking XML? Yaron's Semantic Forms survived without XML - yes, it's definition language is not English, but it's good enough and works relatively good with the rest of MW syntax. I think using XML will not necessarily do good here as form creators would want the language to be close to the rest of the wiki. Here's the example of the form which is the mix of wikitext, HTML and regular wiki formatting http://www.techpresentations.org/w/index.php?title=Form:Presentationaction=edit It worked for me. Maybe this kind of definition can be merged with Template pages, but frankly SF's model works pretty well (of course, SF is also smart about data because of SMW, but it can be more manual). Hi Sergey, To me it seems that MediaWiki is moving from pure wiki towards CMS, thus, broaden it's usage (in contrary to what's been stated in bold at meta and other sites that MediaWiki is not CMS). Semantic* extensions and Wikia to me looks like a step towards CMS. Many well-made CMS use XML because there are good XML libraries which allows various processing and transformations. Also, I believe that XML was proposed to define names, type and description of template parameters and that's also a good idea. Maybe even implementing the whole templating in XML? But, when it comes to NS_MAIN, I like wikitext, because I am a coder and I like to edit a source. I don't like visual tools, like Dreamweaver, MS Word and so on. Probably the power users, who contribute the most at wikipedia also like wikitext? I don't know whether there was any survey. To these who types fast and knows wikitext, it allows to produce formatted articles quicker than by using the GUI. But, Wikipedia probably requires an enlargement of it's user base, so wysiwyg is also very important. To me it seems that it would be great if Wikipedia was both friendly to these who likes source wikitext and to these who would love the GUI. But, I don't know whether anyone really likes wikitext, besides me. If nobody likes it, then it will be dropped. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
* Aryeh Gregor simetrical+wikil...@gmail.com [Thu, 24 Sep 2009 15:40:46 -0400]: Templates and refs are by far the worst offenders, for sticking tons of content in the page that doesn't have any obvious relationship to the actual content. Getting rid of them would be a huge step forward. But stuff like '''bold''' and ==headings== are also a real problem. What's complex in '''bold''' and ==headings== ? Here when we've installed the wiki for local historical records at the local Russian university the humanitarians got to understand such things really quickly. The Ms or PhD in History cannot be that much stupid.. To me it looks like you are overstating the complexity of the wikitext. But yes, they are calling technical staff for complex cases, but it happens _rarely_. Historical records are mostly just plain text with links and occasional pictures. Everything unexpected like that is going to increase the risk that a new user will get worried he doesn't know what he's doing, and give up rather than risk breaking something or put effort into figuring out what to do. If you give *anyone*[1] a WYSIWYG interface, they'll know how it works, because they're used to it from Word and whatnot. That's just not true of wikitext, no matter how simple it is once you *already* understand it. Maybe, but it would be nice if source wikitext will remain as aliernative. Anyway, you're the head developers, it's upon you. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Fri, Sep 25, 2009 at 4:00 PM, Dmitriy Sintsov ques...@rambler.ru wrote: What's complex in '''bold''' and ==headings== ? Here when we've It *looks* complex. That's pretty much most of the problem. Here's our desired use case: 1) User views a page that is deficient in some way. 2) User decides to edit. 3) User edits. 4) User has improved the world. Here's our actual use case. 1) User views a page that is deficient in some way. 2) User has no idea they can edit. Ok, moving on... 2) User decides to edit. 3) User sees wikitext. 4) User runs screaming. The Ms or PhD in History cannot be that much stupid. We're not in a position to offer training to our potential end users. Steve ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
* Steve Bennett stevag...@gmail.com [Fri, 25 Sep 2009 16:13:51 +1000]: On Fri, Sep 25, 2009 at 4:00 PM, Dmitriy Sintsov ques...@rambler.ru wrote: What's complex in '''bold''' and ==headings== ? Here when we've It *looks* complex. That's pretty much most of the problem. Here's our desired use case: You haven't convinced me. I am not the most bright person in the world (my coding skills aren't top - I am more of humanitarian brain person actually) but it was really easy to me to understand basics of wikitext. Just in few minutes. Also, such repeated single markup characters are faster to type than choosing formatting with GUI. I like wikitext. Anyway, the displays have a large resolution nowadays. What about splitting edit page in two areas? One for entering wikitext with syntax highlighting and another one - an AJAX generated on-the-fly preview how would it looks like after the save. Such way, the learning curve would be much lower. But I probably will stop arguing, because my opinion is hardly representative. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
David Gerard dger...@gmail.com wrote in message news:fbad4e140909241512h5c56dd09xe6d3d7de0603f...@mail.gmail.com... 2009/9/24 Platonides platoni...@gmail.com: Brian wrote: * wikitext parsing would be much faster if the language was well defined and we could use flex/bison/etc... Have you read the archives? It has been tried. Several times. There's even a mailing list for that. Getting a formal definition of ~90% of the wikitext syntax is easy. The other 10% drived nuts everyone trying to do it hard enough, so far. Keep trying, but build over what's already done. The 10% drove people off cliffs because it is, pretty much by definition, the horrible unexpected behaviour that is a *consequence* of not having a formal definition. Writing a formal definition is not impossible if you require that it be sensible at the final reading. The parser is, in many places, *not* sensible, and naturally those quirks are difficult to describe, but they're also undesirable overall. A true move to a formal language definition involves action from both ends: writing a formal definition that follows the current parser in general, *and* being prepared to alter the parser to remove some of the more egregious deviations from expected behaviour. --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
-Original Message-
From: wikitech-l-boun...@lists.wikimedia.org
[mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of
Dmitriy Sintsov
Sent: 25 September 2009 07:01
To: Wikimedia developers
Subject: Re: [Wikitech-l] Proposal for editing template calls
within pages
* Aryeh Gregor simetrical+wikil...@gmail.com [Thu, 24 Sep 2009
15:40:46 -0400]:
Templates and refs are by far the worst offenders, for
sticking tons
of content in the page that doesn't have any obvious
relationship to
the actual content. Getting rid of them would be a huge
step forward.
But stuff like '''bold''' and ==headings== are also a real
problem.
What's complex in '''bold''' and ==headings== ? Here when
we've installed the wiki for local historical records at
the local Russian university the humanitarians got to
understand such things really quickly. The Ms or PhD in
History cannot be that much stupid.. To me it looks like you
are overstating the complexity of the wikitext. But yes, they
are calling technical staff for complex cases, but it happens
_rarely_. Historical records are mostly just plain text with
links and occasional pictures.
The problem is the ambiguity with italics, (''italics''). So the
current parser doesn't really make its final decision on what should
be bold or what should be italic until it hits a newline. If there are
an even number of both bold and italics then it assumes it interpreted
the line correctly.
However if there is an uneven number of bold italic, it starts
searching for where it could have misinterpreted something.
I think this is part of what makes wikitext undescribable in a formal
grammar.
Jared
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/25 Dmitriy Sintsov ques...@rambler.ru: You haven't convinced me. I am not the most bright person in the world (my coding skills aren't top - I am more of humanitarian brain person actually) but it was really easy to me to understand basics of wikitext. Just in few minutes. Also, such repeated single markup characters are faster to type than choosing formatting with GUI. I like wikitext. At this point in the discussion, I'm thankful you're not the person who needs to be convinced. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
* Jared Williams jared.willia...@ntlworld.com [Fri, 25 Sep 2009
10:49:54 +0100]:
The problem is the ambiguity with italics, (''italics''). So the
current parser doesn't really make its final decision on what should
be bold or what should be italic until it hits a newline. If there are
an even number of both bold and italics then it assumes it interpreted
the line correctly.
However if there is an uneven number of bold italic, it starts
searching for where it could have misinterpreted something.
Shouldn't these cases be considered a syntax error? How much is common
to wikipedia to have uneven numbers of occurences of that? Is there any
use for that (weird templates)?
I think this is part of what makes wikitext undescribable in a formal
grammar.
Jared
Let's assume an odd occurence of ''' will be converted to wmf:bold and
an even occurence ''' to /wmf:bold (begin/end of the node)? Non-paired
occurence will simply cause XML parsing error - there should not be
uneven number of '' or '''.
Dmitriy
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/25 Dmitriy Sintsov ques...@rambler.ru: Let's assume an odd occurence of ''' will be converted to wmf:bold and an even occurence ''' to /wmf:bold (begin/end of the node)? Non-paired occurence will simply cause XML parsing error - there should not be uneven number of '' or '''. The point is that wikitext doesn't *have* parsing errors. The parser is very tolerant in that it tries to resolve 'invalid' and ambiguous constructs by some combination of guessing what was probably intended and trying not to mess up the rest of the article (the newline thing mentioned earlier fall in the latter category). I agree that this probably causes the weird quirks that make wikitext such a horribly complex language to define and parse, so I think a good way to continue this discussion would be to talk about how invalid, ambiguous and otherwise unexpected input should be handled. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
-Original Message-
From: wikitech-l-boun...@lists.wikimedia.org
[mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of
Dmitriy Sintsov
Sent: 25 September 2009 11:09
To: Wikimedia developers
Subject: Re: [Wikitech-l] Proposal for editing template calls
within pages
* Jared Williams jared.willia...@ntlworld.com [Fri, 25 Sep 2009
10:49:54 +0100]:
The problem is the ambiguity with italics, (''italics''). So the
current parser doesn't really make its final decision on
what should
be bold or what should be italic until it hits a newline.
If there are
an even number of both bold and italics then it assumes it
interpreted
the line correctly.
However if there is an uneven number of bold italic, it starts
searching for where it could have misinterpreted something.
Shouldn't these cases be considered a syntax error? How much
is common to wikipedia to have uneven numbers of occurences
of that? Is there any use for that (weird templates)?
I think this is part of what makes wikitext undescribable
in a formal
grammar.
Jared
Let's assume an odd occurence of ''' will be converted to
wmf:bold and an even occurence ''' to /wmf:bold
(begin/end of the node)? Non-paired occurence will simply
cause XML parsing error - there should not be uneven number
of '' or '''.
Dmitriy
Problem is quotes are also valid as part of the textual content, so
could not italics immediately before or after an apostrophe. As in
L'''arc de triomphe''
Which the current parser resolves to L'iarc de triomphe/i
Jared
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/25 Roan Kattouw roan.katt...@gmail.com: The point is that wikitext doesn't *have* parsing errors. The parser is very tolerant in that it tries to resolve 'invalid' and ambiguous constructs by some combination of guessing what was probably intended and trying not to mess up the rest of the article (the newline thing mentioned earlier fall in the latter category). I agree that this probably causes the weird quirks that make wikitext such a horribly complex language to define and parse, so I think a good way to continue this discussion would be to talk about how invalid, ambiguous and otherwise unexpected input should be handled. In past discussions I have noted that tag soup is a *feature* of human languages, not a bug. HTML was constructed as a computer markup language for humans. Unfortunately, the humans in question were nuclear physicists; lesser beings couldn't handle it. Note how HTML5 now defines how to handle bad syntax, in recognition of the fact that humans write tag soup. Wikitext spitting errors would be a bug in wikitext, not a feature. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/25 Dmitriy Sintsov ques...@rambler.ru: XML is used to store human-produced rich formatted text by many standalone and web apps. XML parsers are also very strict and spitting errors. As it's been mentioned recently, XML is really good for bots, too, for that reason (the input is error-free tree). I wonder, If the browsers can handle tag soup, most probably MediaWiki parser can handle wikitext soup, too? Eg, instead of parsing error, properly close the nodes. The existing wikitext of millions of articles has to be converted by commandline upgrade script in case the wikitext will be abandoned. Though I wonder whether it's possible to keep wikitext editing mode for backwards compatibility by using the same method online. Wikitext started as a shorthand for HTML. The horrible things that have happened since then are from ad-hoc additions to a parser and no formal spec, leaving the parser behaviour as, literally, the only definition. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
Jared Williams wrote:
The problem is the ambiguity with italics, (''italics''). So the
current parser doesn't really make its final decision on
what should be bold or what should be italic until it hits a
newline. If there are an even number of both bold and italics
then it assumes it interpreted the line correctly.
[SNIP]
I think this is part of what makes wikitext undescribable
in a formal grammar.
And he also wrote:
Problem is quotes are also valid as part of the textual content, so
could not italics immediately before or after an apostrophe. As in
L'''arc de triomphe''
Which the current parser resolves to L'iarc de triomphe/i
There lies one of the main problems with parsing wikitext - that it uses a
wide range of standard text characters to implement it's markup. In HTML,
there are basically two ( and ) plus an escape character (). Therefore
HTML can in theory[1] consist of Any text you like, with , and
replaced by lt; gt; and amp; respectively with two special markup
symbols (markup goes here and escaped_entity;). No room for ambiguity
there, and only minimal translation required to convert plain-text to a
format suitable for use in an HTML document.
In MediaWiki, just taking that single ' character as an example, it could be
one of several punctuation symbols (apostrophe, single-quote, prime, etc.)
or it could be part of an opening italic tag, a closing italic tag, an
opening bold tag, or a closing bold tag. As far as I understand, it is
impossible to deal effectively with this massive overloading of the
apostrophe character without the kind of special logic we have in place
already (as described by Jared). To take his example one step further,
here's something to really throw a formal grammar-based parser, but which
our parser handles just fine: '''Photo of L'''arc de triomphe'' by 'John
- Mark Clements (HappyDog)
[1] I'm ignoring all the document-structure requirements, plus
character-encoding issues, etc. that complicate things a bit.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
This thread has gotten WAY off topic - so I wanted to try and help clarify a few things and then get it back on-topic if at all possible. * As Roan mentioned, we are planning on implementing a *wiki-text *editing interface with collapsible blocks for template calls and tables. We may also get a bonus of basic syntax highlighting, but that's not a driving feature. * WYSIWYG is a hope, dream, intention, and long-term-plan of the Wikimedia Foundation - but it's not going to be a reality until we can make progress in at least 3 areas (explained below) and perhaps others as well. * It's important to understand that wiki-text it'self is not the enemy of WYSIWYG, these (and perhaps others as well) are... o *Data corruption: *All current solutions convert wiki-text to some kind of HTML, edit it as if it were HTML, and then convert it back, causing disconnection between the original content and edited content. This in-turn causes diffs to show changes made by the lossy process for conversion such as white-space, tables being in short or long notation, and HTML comments being stripped. More importantly of course, it changes the wiki-text of the page in ways the user did not intend to and wipes out important formatting and comments that people using text editing interfaces (by choice or because their browser is unsupported) need, want and use.* * o *Template abuse: *Template calls do not always result in whole objects. When expanding a template, the result is allowed entirely arbitrary. For instance, I've seen templates that create only the head, a single row, or the foot for a table. When the user wants to change the table, they click edit, and not only does the software not have any way of knowing that these consecutive template calls are related.* * o *Embedded page logic:* Template functions are not visually representable in any way I've ever seen that would make any sense to a non-programmer, yet they often have a profound impact on the content of the page. Nesting a series of if statements is especially going to be a mess in a GUI. * This is not to say I have no ideas or plans on how to solve these issues. We are actively making choices to pave the way for WYSIWYG, but a topic like this hasn't yet proven to be very useful in this process. So far I have only seen the same circle of Editing wiki-text sucks! - We need WYSIWYG! - WYSIWYG is broken - It must be wiki-text's fault! - Let's change wiki-text - But it's so easy to edit! - No it's not! Editing wiki-text sucks - and so on... So, FYI, this is not a new or in anyway original chain of thought or conversation - it's not bad, it's just going to be seen as spam to most people on this list. * The topic is supposed to be on Template Editing which is, at least in the way it's being proposed, a little less of a stale topic - so where is all the energy on that front? We have an XML format to design and complex problems to sort out. Help is really needed. Let's all take a look at the link provided at the beginning of this thread http://usability.wikimedia.org/wiki/Template_forms - Trevor ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Fri, Sep 25, 2009 at 12:30 PM, Trevor Parscal tpars...@wikimedia.orgwrote: * The topic is supposed to be on Template Editing which is, at least in the way it's being proposed, a little less of a stale topic - so where is all the energy on that front? We have an XML format to design and complex problems to sort out. Help is really needed. Let's all take a look at the link provided at the beginning of this thread http://usability.wikimedia.org/wiki/Template_forms - Trevor I do think that sufficient energy has been directed at this topic. People have complained that xml is harder to edit that wikitext and that it is too complicated, among other things. Additionally, several people have pointed out that solving this little part of the problem doesn't make sense in the context of the larger problem at hand here. You are trying to separate the issue of template editing from the larger issue of wikitext, and that doesn't make sense. Also, I am quite serious about my point that an entirely new language interface specification will be added to MediaWiki and that it will be widely adopted and propagate throughout the wikisphere, much like parser functions, and in the end will make the job of fixing MediaWiki much, much harder. As it is very important developers already thing the problem is so hard as to be impossible. I disagree with that, but at the same time I don't think it's a good idea to make it even harder. So I don't think help is needed in designing a new xml interface specification for mediawiki right now. I'm also a bit confused, because I thought we had this new strategic planning wiki, but it looks like the strategy aspect of this proposal is being largely ignored. From what I have heard, there was a meeting about how to solve this problem among core devs and a few others at wikimedia headquarters, they decided what the solution would be, and now you guys are moving forward on implementing it, totally ignoring the strategy wiki. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/25 Brian brian.min...@colorado.edu: Also, I am quite serious about my point that an entirely new language interface specification will be added to MediaWiki and that it will be widely adopted and propagate throughout the wikisphere, much like parser functions, and in the end will make the job of fixing MediaWiki much, much harder. Whatever wikitext ends up becoming, it will probably still have templates in some form. If the XML language is designed properly, it won't make any assumptions about the current state of wikitext and templates, other than that: * there are such things as templates * they accept parameters * parameters can, but need not, have names, types, descriptions, etc.; types may or may not be enforced This very limited set of assumptions will hold in any language that implements templates in a remotely sane way. From what I have heard, there was a meeting about how to solve this problem among core devs and a few others at wikimedia headquarters, they decided what the solution would be That's news to me; I'd very much like to hear from these people what their proposed solution is. , and now you guys are moving forward on implementing it, totally ignoring the strategy wiki. You make it sound like we're just going ahead and doing this, totally ignoring everyone else's opinions. Instead, we're proposing and discussing it on this list to get input from other people. If you think there's a more appropriate place to discuss this, just point us there; don't go around blasting us because we failed to read your mind. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Fri, Sep 25, 2009 at 1:49 PM, Roan Kattouw roan.katt...@gmail.comwrote: 2009/9/25 Brian brian.min...@colorado.edu: Also, I am quite serious about my point that an entirely new language interface specification will be added to MediaWiki and that it will be widely adopted and propagate throughout the wikisphere, much like parser functions, and in the end will make the job of fixing MediaWiki much, much harder. Whatever wikitext ends up becoming, it will probably still have templates in some form. If the XML language is designed properly, it won't make any assumptions about the current state of wikitext and templates, other than that: * there are such things as templates * they accept parameters * parameters can, but need not, have names, types, descriptions, etc.; types may or may not be enforced This very limited set of assumptions will hold in any language that implements templates in a remotely sane way. From what I have heard, there was a meeting about how to solve this problem among core devs and a few others at wikimedia headquarters, they decided what the solution would be That's news to me; I'd very much like to hear from these people what their proposed solution is. , and now you guys are moving forward on implementing it, totally ignoring the strategy wiki. You make it sound like we're just going ahead and doing this, totally ignoring everyone else's opinions. Instead, we're proposing and discussing it on this list to get input from other people. If you think there's a more appropriate place to discuss this, just point us there; don't go around blasting us because we failed to read your mind. Roan Kattouw (Catrope) It appears that there is a desire for this project to fit within the scope of the Usability Initiative, which to me says that there is a strong desire to implement it starting soon. Trevor's e-mail indicates as much - let's stop talking strategy and start designing so we can implement. I believe there was a meeting at headquarters with Brion, Trevor, Yaron, and maybe others. I don't know, I wasn't there. All I know is that at this meeting they decided that they would implement this feature. The XML aspect is honestly immaterial to me - it's just an implementational detail, the decision to do this having been decided entirely off wiki. I am not here saying that it is a bad feature, not a bit. In fact I have previously advocated on this list for the ability for users to specify form-like interfaces. What I am saying is that I think it's premature. There is a tradeoff that needs to be balanced here. It's easy to add new features and hard to fix the old one. As we add new features however we diverse farther and farther from the possibility of fixing wikitext. This is especially when efforts to add new features are done entirely out of the context of a clear strategy for eventually fixing wikitext. So before a feature such as this is implemented, or any new substantial language is added to MediaWiki (such as ParserFunctions, or this interface specification language), I would like to see work done on the Strategy wiki. I don't think new work such as this should be done outside of the context of a very clear vision of how we will eventually fix the whole problem. And I'm entirely willing to help. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Fri, Sep 25, 2009 at 2:03 PM, Brian brian.min...@colorado.edu wrote: On Fri, Sep 25, 2009 at 1:49 PM, Roan Kattouw roan.katt...@gmail.comwrote: 2009/9/25 Brian brian.min...@colorado.edu: Also, I am quite serious about my point that an entirely new language interface specification will be added to MediaWiki and that it will be widely adopted and propagate throughout the wikisphere, much like parser functions, and in the end will make the job of fixing MediaWiki much, much harder. Whatever wikitext ends up becoming, it will probably still have templates in some form. If the XML language is designed properly, it won't make any assumptions about the current state of wikitext and templates, other than that: * there are such things as templates * they accept parameters * parameters can, but need not, have names, types, descriptions, etc.; types may or may not be enforced This very limited set of assumptions will hold in any language that implements templates in a remotely sane way. From what I have heard, there was a meeting about how to solve this problem among core devs and a few others at wikimedia headquarters, they decided what the solution would be That's news to me; I'd very much like to hear from these people what their proposed solution is. , and now you guys are moving forward on implementing it, totally ignoring the strategy wiki. You make it sound like we're just going ahead and doing this, totally ignoring everyone else's opinions. Instead, we're proposing and discussing it on this list to get input from other people. If you think there's a more appropriate place to discuss this, just point us there; don't go around blasting us because we failed to read your mind. Roan Kattouw (Catrope) It appears that there is a desire for this project to fit within the scope of the Usability Initiative, which to me says that there is a strong desire to implement it starting soon. Trevor's e-mail indicates as much - let's stop talking strategy and start designing so we can implement. I believe there was a meeting at headquarters with Brion, Trevor, Yaron, and maybe others. I don't know, I wasn't there. All I know is that at this meeting they decided that they would implement this feature. The XML aspect is honestly immaterial to me - it's just an implementational detail, the decision to do this having been decided entirely off wiki. I am not here saying that it is a bad feature, not a bit. In fact I have previously advocated on this list for the ability for users to specify form-like interfaces. What I am saying is that I think it's premature. There is a tradeoff that needs to be balanced here. It's easy to add new features and hard to fix the old one. As we add new features however we diverse farther and farther from the possibility of fixing wikitext. This is especially when efforts to add new features are done entirely out of the context of a clear strategy for eventually fixing wikitext. So before a feature such as this is implemented, or any new substantial language is added to MediaWiki (such as ParserFunctions, or this interface specification language), I would like to see work done on the Strategy wiki. I don't think new work such as this should be done outside of the context of a very clear vision of how we will eventually fix the whole problem. And I'm entirely willing to help. Sorry for my typos: one - ones, diverse - diverge. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
Brian wrote: On Fri, Sep 25, 2009 at 12:30 PM, Trevor Parscal tpars...@wikimedia.orgwrote: * The topic is supposed to be on Template Editing which is, at least in the way it's being proposed, a little less of a stale topic - so where is all the energy on that front? We have an XML format to design and complex problems to sort out. Help is really needed. Let's all take a look at the link provided at the beginning of this thread http://usability.wikimedia.org/wiki/Template_forms - Trevor I do think that sufficient energy has been directed at this topic. People have complained that xml is harder to edit that wikitext and that it is too complicated, among other things. Additionally, several people have pointed out that solving this little part of the problem doesn't make sense in the context of the larger problem at hand here. You are trying to separate the issue of template editing from the larger issue of wikitext, and that doesn't make sense. Also, I am quite serious about my point that an entirely new language interface specification will be added to MediaWiki and that it will be widely adopted and propagate throughout the wikisphere, much like parser functions, and in the end will make the job of fixing MediaWiki much, much harder. As it is very important developers already thing the problem is so hard as to be impossible. I disagree with that, but at the same time I don't think it's a good idea to make it even harder. So I don't think help is needed in designing a new xml interface specification for mediawiki right now. I'm also a bit confused, because I thought we had this new strategic planning wiki, but it looks like the strategy aspect of this proposal is being largely ignored. From what I have heard, there was a meeting about how to solve this problem among core devs and a few others at wikimedia headquarters, they decided what the solution would be, and now you guys are moving forward on implementing it, totally ignoring the strategy wiki. AFAIK, the strategy wiki is designed to help formulate a 5-year strategic plan. According to the timeline, actual execution may not begin for at least another 4 months.[1] The usability project has its own timeline and deadlines and is more concerned more with short and medium term projects. I don't know if there is any plan to continue funding the usability initiative after the Stanton Foundation grant runs out. [1]http://strategy.wikimedia.org/wiki/Process#Timeline_.282009_-_2010.29 -- Alex (wikipedia:en:User:Mr.Z-man) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
Are the XML specifications intended as? A) A required addition to current and future templates OR B) An optional addition to aid / facilitate the functioning of some advanced tools The latter case seems far more achievable than the former case. -Robert Rohde On Fri, Sep 25, 2009 at 12:49 PM, Roan Kattouw roan.katt...@gmail.com wrote: 2009/9/25 Brian brian.min...@colorado.edu: Also, I am quite serious about my point that an entirely new language interface specification will be added to MediaWiki and that it will be widely adopted and propagate throughout the wikisphere, much like parser functions, and in the end will make the job of fixing MediaWiki much, much harder. Whatever wikitext ends up becoming, it will probably still have templates in some form. If the XML language is designed properly, it won't make any assumptions about the current state of wikitext and templates, other than that: * there are such things as templates * they accept parameters * parameters can, but need not, have names, types, descriptions, etc.; types may or may not be enforced This very limited set of assumptions will hold in any language that implements templates in a remotely sane way. From what I have heard, there was a meeting about how to solve this problem among core devs and a few others at wikimedia headquarters, they decided what the solution would be That's news to me; I'd very much like to hear from these people what their proposed solution is. , and now you guys are moving forward on implementing it, totally ignoring the strategy wiki. You make it sound like we're just going ahead and doing this, totally ignoring everyone else's opinions. Instead, we're proposing and discussing it on this list to get input from other people. If you think there's a more appropriate place to discuss this, just point us there; don't go around blasting us because we failed to read your mind. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Fri, Sep 25, 2009 at 2:14 PM, Alex mrzmanw...@gmail.com wrote: Brian wrote: On Fri, Sep 25, 2009 at 12:30 PM, Trevor Parscal tpars...@wikimedia.org wrote: * The topic is supposed to be on Template Editing which is, at least in the way it's being proposed, a little less of a stale topic - so where is all the energy on that front? We have an XML format to design and complex problems to sort out. Help is really needed. Let's all take a look at the link provided at the beginning of this thread http://usability.wikimedia.org/wiki/Template_forms - Trevor I do think that sufficient energy has been directed at this topic. People have complained that xml is harder to edit that wikitext and that it is too complicated, among other things. Additionally, several people have pointed out that solving this little part of the problem doesn't make sense in the context of the larger problem at hand here. You are trying to separate the issue of template editing from the larger issue of wikitext, and that doesn't make sense. Also, I am quite serious about my point that an entirely new language interface specification will be added to MediaWiki and that it will be widely adopted and propagate throughout the wikisphere, much like parser functions, and in the end will make the job of fixing MediaWiki much, much harder. As it is very important developers already thing the problem is so hard as to be impossible. I disagree with that, but at the same time I don't think it's a good idea to make it even harder. So I don't think help is needed in designing a new xml interface specification for mediawiki right now. I'm also a bit confused, because I thought we had this new strategic planning wiki, but it looks like the strategy aspect of this proposal is being largely ignored. From what I have heard, there was a meeting about how to solve this problem among core devs and a few others at wikimedia headquarters, they decided what the solution would be, and now you guys are moving forward on implementing it, totally ignoring the strategy wiki. AFAIK, the strategy wiki is designed to help formulate a 5-year strategic plan. According to the timeline, actual execution may not begin for at least another 4 months.[1] The usability project has its own timeline and deadlines and is more concerned more with short and medium term projects. I don't know if there is any plan to continue funding the usability initiative after the Stanton Foundation grant runs out. [1]http://strategy.wikimedia.org/wiki/Process#Timeline_.282009_-_2010.29 -- Alex (wikipedia:en:User:Mr.Z-man) The vision for the strategy wiki is much, much broader than that. Here is a recent e-mail from Sue on the subject: On Tue, Sep 22, 2009 at 7:35 PM, Sue Gardner sgard...@wikimedia.org wrote: 2009/9/22 Eugene Eric Kim ee...@blueoxen.com: On Mon, Sep 14, 2009 at 3:49 PM, Pavlo Shevelo pavlo.shev...@gmail.com wrote: Who will decide what the strategy will be, and what will be the decision-making process? this page explains nothing about (or explains in no detail if somebody prefers) how main stakeholder - Foundation will make decision about said strategy. The huge, extremely intensive (and effective, if we will do our best) Earth-wide pipeline for proposal preparation - it's good. But what will be in the very end? How Foundation will decide what idea is good enough to stand behind it (and to put money in it)? Sorry for taking so long to respond, Pavlo. I'm not sure I'm the right person to respond to this. I'll do my best, you can tell me if you think it's clear, and hopefully other folks from the Foundation will jump in. I just saw this thread; I'm happy to jump in. What Eugene says is all accurate -- let me expand a little. Essentially, the purpose of the project is to develop a strategy for the Wikimedia movement, not just for the Wikimedia Foundation. What that means is that no single entity will be able to approve and drive forward the whole thing: individual players will drive forward the pieces that compel and engage and inspire them. So for example: * If it looks like it makes sense to stage a lot of events aimed at broadening participation in developed countries, the chapters would logically take the lead on that. * If it looks like it would make sense to conduct a massive awareness campaign in India, that would probably be moved forward in partnership between the Wikimedia Foundation and what might be -by then- an approved, new Indian chapter. * If it looks like a very strong focus on mobile makes sense, I expect that would be something driven forward by the tech staff at Wikimedia, in partnership with individual volunteer devs, and possibly supported by relationships with for-profit firms such as Orange. * If there is a simple thing that looks sensible, and one person wants to, and is
Re: [Wikitech-l] Proposal for editing template calls within pages
On 9/25/09 1:18 PM, Robert Rohde wrote: Are the XML specifications intended as? A) A required addition to current and future templates OR B) An optional addition to aid / facilitate the functioning of some advanced tools The latter case seems far more achievable than the former case. -Robert Rohde On Fri, Sep 25, 2009 at 12:49 PM, Roan Kattouwroan.katt...@gmail.com wrote: 2009/9/25 Brianbrian.min...@colorado.edu: Also, I am quite serious about my point that an entirely new language interface specification will be added to MediaWiki and that it will be widely adopted and propagate throughout the wikisphere, much like parser functions, and in the end will make the job of fixing MediaWiki much, much harder. Whatever wikitext ends up becoming, it will probably still have templates in some form. If the XML language is designed properly, it won't make any assumptions about the current state of wikitext and templates, other than that: * there are such things as templates * they accept parameters * parameters can, but need not, have names, types, descriptions, etc.; types may or may not be enforced This very limited set of assumptions will hold in any language that implements templates in a remotely sane way. From what I have heard, there was a meeting about how to solve this problem among core devs and a few others at wikimedia headquarters, they decided what the solution would be That's news to me; I'd very much like to hear from these people what their proposed solution is. , and now you guys are moving forward on implementing it, totally ignoring the strategy wiki. You make it sound like we're just going ahead and doing this, totally ignoring everyone else's opinions. Instead, we're proposing and discussing it on this list to get input from other people. If you think there's a more appropriate place to discuss this, just point us there; don't go around blasting us because we failed to read your mind. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l The latter case for sure. Without the additional information, editing a template call will just be a list of field names and text inputs. - Trevor ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/25 Brian brian.min...@colorado.edu: I am not here saying that it is a bad feature, not a bit. In fact I have previously advocated on this list for the ability for users to specify form-like interfaces. What I am saying is that I think it's premature. There is a tradeoff that needs to be balanced here. It's easy to add new features and hard to fix the old one. As we add new features however we diverse farther and farther from the possibility of fixing wikitext. This is especially when efforts to add new features are done entirely out of the context of a clear strategy for eventually fixing wikitext. So before a feature such as this is implemented, or any new substantial language is added to MediaWiki (such as ParserFunctions, or this interface specification language), I would like to see work done on the Strategy wiki. I don't think new work such as this should be done outside of the context of a very clear vision of how we will eventually fix the whole problem. And I'm entirely willing to help. You seem to be missing my point (or at least are not refuting it): if implemented properly, with the minimal assumptions I mentioned, subsequent reworking of wikitext *wouldn't* *matter*, because the template call editor could easily be ported to the 'new language' or whatever we end up with. It wouldn't put us any further away from fixing wikitext; the trade-off you mentioned does not exist IMO. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Fri, Sep 25, 2009 at 2:20 PM, Roan Kattouw roan.katt...@gmail.comwrote: 2009/9/25 Brian brian.min...@colorado.edu: I am not here saying that it is a bad feature, not a bit. In fact I have previously advocated on this list for the ability for users to specify form-like interfaces. What I am saying is that I think it's premature. There is a tradeoff that needs to be balanced here. It's easy to add new features and hard to fix the old one. As we add new features however we diverse farther and farther from the possibility of fixing wikitext. This is especially when efforts to add new features are done entirely out of the context of a clear strategy for eventually fixing wikitext. So before a feature such as this is implemented, or any new substantial language is added to MediaWiki (such as ParserFunctions, or this interface specification language), I would like to see work done on the Strategy wiki. I don't think new work such as this should be done outside of the context of a very clear vision of how we will eventually fix the whole problem. And I'm entirely willing to help. You seem to be missing my point (or at least are not refuting it): if implemented properly, with the minimal assumptions I mentioned, subsequent reworking of wikitext *wouldn't* *matter*, because the template call editor could easily be ported to the 'new language' or whatever we end up with. It wouldn't put us any further away from fixing wikitext; the trade-off you mentioned does not exist IMO. Roan Kattouw (Catrope) I think calling it a 'template call editor' does not do the proposed new feature justice. It would fundamentally change MediaWiki. Once this language is created it will, if I understand it correctly (please correct me if I don't), immediately support the creation of interfaces that automatically create new interfaces, and so on and so forth. It is a fundamental departure from the way we currently do things on the wiki. However powerful it is, I'm not sure we can really rule out future incompatibility as you suggest by simply stating that we can easily forwardport. This feature is intended to hack a fix on top of the usability issues inherent in templates. Every time we have a discussion about the pitfalls of wikitext the center of this discussion is templates. Even without parser functions they are turing complete - with them it is a complete usability disaster. So it seems that when we finally get around to developing a consensus about the changes we want in wikitext, there will be widespread agreement that we need to change templates. But so far, without any clear strategy on that front, we have no idea what those changes will be. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/25 Brian brian.min...@colorado.edu: However powerful it is, I'm not sure we can really rule out future incompatibility as you suggest by simply stating that we can easily forwardport. This feature is intended to hack a fix on top of the usability issues inherent in templates. Every time we have a discussion about the pitfalls of wikitext the center of this discussion is templates. Even without parser functions they are turing complete - with them it is a complete usability disaster. So it seems that when we finally get around to developing a consensus about the changes we want in wikitext, there will be widespread agreement that we need to change templates. But so far, without any clear strategy on that front, we have no idea what those changes will be. It's important to separate template *calls* from template *implementation*: only the latter involves ParserFunctions and all that other ugliness. Even if and when we do completely redo the way templates are *written* on the inside, the way they're *called* from the outside would probably not change significantly, nor would the concepts of parameters and types. This means redoing template syntax does not require any changes to the XML format. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
Nikola Smolenski smolensk at eunet.rs writes:
What I am going to say is going to be the worst heresy, but could this
problem be solved by gradually migrating to a new wiki markup, for
example **bold** and //italic//? This markup is more logical and easier
to remember, more used outside of MediaWiki (unofficial email markup is
similar) and more easily visible than apostrophe markup, and I never
understood how the apostrophes came to be in the first place. The most
important for this discussion - it also has much less potential to
confuse the parser.
You avoid a lot of pain if the opening and closing markup is different.
That is IMHO the other big problem besides reusing the same characters in ''/'''
and {{/{{{.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Fri, Sep 25, 2009 at 2:42 PM, Roan Kattouw roan.katt...@gmail.comwrote: 2009/9/25 Brian brian.min...@colorado.edu: However powerful it is, I'm not sure we can really rule out future incompatibility as you suggest by simply stating that we can easily forwardport. This feature is intended to hack a fix on top of the usability issues inherent in templates. Every time we have a discussion about the pitfalls of wikitext the center of this discussion is templates. Even without parser functions they are turing complete - with them it is a complete usability disaster. So it seems that when we finally get around to developing a consensus about the changes we want in wikitext, there will be widespread agreement that we need to change templates. But so far, without any clear strategy on that front, we have no idea what those changes will be. It's important to separate template *calls* from template *implementation*: only the latter involves ParserFunctions and all that other ugliness. Even if and when we do completely redo the way templates are *written* on the inside, the way they're *called* from the outside would probably not change significantly, nor would the concepts of parameters and types. This means redoing template syntax does not require any changes to the XML format. Roan Kattouw (Catrope) It's certainly possible, particularly with something as generic as xml, to create an extension to mediawiki that supports a variety of backends. As I've suggested, however, without any clear vision of where we want wikitext, and more generally, MediaWiki to go, then it is impossible to evaluate the efficacy of this feature, especially considering that the consequences of it haven't even been evaluated. Given the power of the backend that this feature will be kludged on top of it will fundamentally change MediaWiki is used. And yet, I just checked Strategy, there is no vision for where MediaWiki should go moving into the future, let alone wikitext. As far as I can tell this feature was cooked up in order to improve usability, and yet when you improve usability by definition you make the software easier to use and provide new affordances to your users. We have no idea whether these affordances are in line with our general vision for how users should interact with MediaWiki because we simply do not have one. I have never seen a discussion about whether the ability to create new interfaces via an interface is in line with either our lesser mission to build an encyclopedia or our greater one to bring knowledge to every human being. Lastly I would just point out that everything that can be done with this new feature will be done, and I invoke the spirit of #qif to make my point. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On 9/25/09 11:39 AM, Brian wrote: I do think that sufficient energy has been directed at this topic. People have complained that xml is harder to edit that wikitext and that it is too complicated, among other things. You seem to be talking about something utterly unrelated to this thread... The only XML under discussion here is an internal back-end representation of template metadata to drive a sane template invocation user-interface: * field names and descriptions (localizable) * field types/validation info * field grouping and optional/required info * other documentation display info This would not be exposed to editors, viewers or readers; nor is it in any way related to whether, how, or when we might some day alter or replace wiki markup. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Fri, Sep 25, 2009 at 3:13 PM, Brion Vibber br...@wikimedia.org wrote: On 9/25/09 11:39 AM, Brian wrote: I do think that sufficient energy has been directed at this topic. People have complained that xml is harder to edit that wikitext and that it is too complicated, among other things. You seem to be talking about something utterly unrelated to this thread... The only XML under discussion here is an internal back-end representation of template metadata to drive a sane template invocation user-interface: * field names and descriptions (localizable) * field types/validation info * field grouping and optional/required info * other documentation display info This would not be exposed to editors, viewers or readers; nor is it in any way related to whether, how, or when we might some day alter or replace wiki markup. -- brion You have conveniently ignored the rest of my points, which are not, as you have claimed, off topic. (and you love to jump into threads and claim they have become off topic, historically, with only the points that you are considering being on topic.) To wrap them up for you: * This will fundamentally change mediawiki and the consequences of this feature have not been considered * It will support the creation of new interfaces from interfaces, simply by creating templates that create new templates and using the interface to that template to create the new interface. Is this correct? * We cannot evaluate the repercussions of this feature with respect to our broader vision for mediawiki because we (by which I mean we, not you personally) do not have one. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/25 Brian brian.min...@colorado.edu: * This will fundamentally change mediawiki and the consequences of this feature have not been considered * It will support the creation of new interfaces from interfaces, simply by creating templates that create new templates and using the interface to that template to create the new interface. Is this correct? Wait, what? Can you explain this better or provide an example? Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
Brian wrote:
On Fri, Sep 25, 2009 at 12:30 PM, Trevor Parscal wrote:
* The topic is supposed to be on Template Editing which is, at least
in the way it's being proposed, a little less of a stale topic -
so where is all the energy on that front? We have an XML format to
design and complex problems to sort out. Help is really needed.
Let's all take a look at the link provided at the beginning of
this thread http://usability.wikimedia.org/wiki/Template_forms
- Trevor
I do think that sufficient energy has been directed at this topic. People
have complained that xml is harder to edit that wikitext and that it is too
complicated, among other things.
I think this is an important point.
XML is hard to edit. That's the reason wikitext was created, to fix
the issues with the, even easier, html.
Now, it is being proposed to add a XML processing on top of wikitext to
describe templates.
Those descriptions will have to be edited by the same user base that
edit all other pages. Even if they are power users, it's not easy to
write correct XML on the wiki textarea. We would need to create an
editor for the language being created so a template editor can be made.
Look at
http://strategy.wikimedia.org/wiki/Call_for_participation/Task_force_application
It is a form definition, but the fields were defined like
* Name [SMALL TEXT FIELD]
* Email [SMALL TEXT FIELD]
It doesn't have a formal definition and is thus ambiguous, but it's an
example on how to make an user-friendly forms.
I advocate for a simpler syntax for form definition (but we shouldn't on
the way reinvent wikitext).
What about creating a documentation tag extension, with the elements
defined as a list?
It would implicitely be noinclude
If there're several instances, they are equivalent as one instance whose
content is the concatenation of all of them (so parameters can be
documented inline).
For the example template, we could have:
documentation
*Author: Person who made the work.
Anonymous works not allowed.
*License: License under which the work can be used.
The license must be determined by the copyright holder, if in doubt, ask
on the [[WP:Village Pump|]].
/documentation
We have two parameters: Author and License, with a short description
suitable as a caption, and a longer description available. Both fields
can allow wikitext (except list items for obvious reasons).
The syntax is simple to understand, and even with no special software,
it can be consulted by anyone.
Now we add parameters and form typing:
documentation
*Author:[TEXT] Person who made the work.
Anonymous works not allowed.
*License:{GFDL|CC-BY-SA}[Dropdown] License under which the work can be used.
The license must be determined by the copyright holder, if in doubt, ask
on the [[WP:Village Pump|]].
*Restrictions:[TEXTAREA] Additional restrictions imposed by the author.
/documentation
As expected, it gets a bit uglier, but it's still straightforward.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Fri, Sep 25, 2009 at 4:06 PM, Happy-melon happy-me...@live.com wrote: Brian brian.min...@colorado.edu wrote in message news:9839a05c0909251423j7152ae51y34a6a9e586f4f...@mail.gmail.com... You have conveniently ignored the rest of my points, which are not, as you have claimed, off topic. (and you love to jump into threads and claim they have become off topic, historically, with only the points that you are considering being on topic.) Considering that you're addressing the person who is ultimately responsible for drafting technical strategy for MediaWiki development, I'm not sure that asserting that his view of what comprises useful discussion is fundamentally flawed is a particularly constructive approach. --HM I don't believe the technical strategy for MediaWiki has been drafted, literally speaking. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On 9/25/09 2:23 PM, Brian wrote: You have conveniently ignored the rest of my points, which are not, as you have claimed, off topic. (and you love to jump into threads and claim they have become off topic, historically, with only the points that you are considering being on topic.) I felt no reason to address them since they're stuck in the tangent discussion about redoing the entire markup system from top to bottom... again... My experience based on 7 years of MediaWiki development is that this line of discussion has consistently lead to nothing useful being produced. Rather than go in circles for the millionth time, I recommend sticking to definable, achievable goals which can build on each other -- such as the original topic of this thread. To wrap them up for you: * This will fundamentally change mediawiki and the consequences of this feature have not been considered The direct consequence is that in the short term we'll actually be able to achieve the situation that normal people will be able to edit articles containing templates. Having this infrastructure in place further means we're in a better position to someday make a major markup transition (say to a different markup system or not exposing markup at all in a pure-WYSIWYG environment)... something we're now very far from... but doesn't commit us to any markup changes in the near or medium term. Morever this is all based on existing discussion, knowledge, and experience, not some sudden invention that's never been considered before. The current work here is most directly inspired by existing systems in the German Wikipedia's Vorlagen-Meister gadget and the Semantic Forms extension... We're hardly creating an idea from whole cloth here; this is real stuff that's been done before in parts and needs to be cleaned up and modernized for Wikipedia's needs. * We cannot evaluate the repercussions of this feature with respect to our broader vision for mediawiki because we (by which I mean we, not you personally) do not have one. Broadly, our strategy is as it always has been: to identify and implement real, measurable benefits to the reading and editing experiences of Wikipedia and other sites. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/25 Platonides platoni...@gmail.com: Those descriptions will have to be edited by the same user base that edit all other pages. Even if they are power users, it's not easy to write correct XML on the wiki textarea. We would need to create an editor for the language being created so a template editor can be made. Since the XML file describes the template, it need only be changed when the template is changed. Realistically, newbie editors don't edit templates; anyone skilled enough to edit templates can handle some simple XML. I advocate for a simpler syntax for form definition (but we shouldn't on the way reinvent wikitext). Exactly. XML is a decent choice here because it has a well-defined, pre-existing grammar with parsers already available, which means it's easy to parse and easy to learn (assuming you've got some shred of a technical background; see my earlier point about newbies not editing templates). Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On 9/25/09 3:39 PM, Roan Kattouw wrote: 2009/9/25 Platonidesplatoni...@gmail.com: Those descriptions will have to be edited by the same user base that edit all other pages. Even if they are power users, it's not easy to write correct XML on the wiki textarea. We would need to create an editor for the language being created so a template editor can be made. Since the XML file describes the template, it need only be changed when the template is changed. Realistically, newbie editors don't edit templates; anyone skilled enough to edit templates can handle some simple XML. I advocate for a simpler syntax for form definition (but we shouldn't on the way reinvent wikitext). Exactly. XML is a decent choice here because it has a well-defined, pre-existing grammar with parsers already available, which means it's easy to parse and easy to learn (assuming you've got some shred of a technical background; see my earlier point about newbies not editing templates). My preference is that we shouldn't actually expose the template definition markup at all during the normal course of events, even when changing a template. The field metadata can be fairly straightforwardly displayed and edited through a nice web interface. XML as such is simply a conveniently well-defined structured data tree format which can be used both for storing the field metadata in the DB and exposing it to the template invocation editor interface (whether client-side JS or server-side PHP or a custom bot-based tool speaking to our API). Of course if template creators *want* to dive into the raw field metadata definition as humans, we do love to expose such things to power power users for them to play with. :) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/26 Brian brian.min...@colorado.edu:
Roan, sorry that the idea is pretty hard to convey, I'll try again.
The basic idea is that you can create templates using templates
(just using current
tech). It's easy, you just pass parameters to a template that control
its output, and this
output is a new template. The parameters that you passed determine what the
new template looks like, and what it's output will be.
Right, so basically this is just templates calling other templates,
right? This already happens to some degree already.
We can imagine a master template on Wikipedia that is used to generate all
infoboxes. It could work in arbitrary ways, but suppose it works this way:
The master infobox template creates a template for each wikiproject. The
template that it creates for each wikiproject further creates templates
representing every kind of infobox that this wikiproject uses. So you have a
master template that creates baby templates that create infobox templates.
Using current tech this isn't exactly feasible, only advanced users will do
it since you have to directly interact with the templates and it would be
tough to code up. But if you make such a feature highly usable, by, for
example, tacking an easy to use interface on top of it, the usage of such
techniques will proliferate.
To use the master infobox example: such a template would have about a
dozen usage modes, each with dozens of parameters. Such constructs are
actually /easier/ to call by hand than with a form, because you'd
either have to store all the relationships between the parameters and
usage modes in the XML file and let the form handle all that (which is
a degree of complexity I personally would not like to see in a
template forms implementation) or just throw a couple hundred
parameters in the user's face.
Also, this being tough to code up would not change: again, we're not
simplifying the *writing* of templates *themselves* in any way. The
fact that these templates include template calls doesn't change that,
because 1) you're gonna be using #if constructs all over the place
anyway, 2) you'd need to use stuff like {{{2|{{{1|}} as arguments
to template calls, which the GUI doesn't simplify and 3) if you're
skilled enough to do 1 and 2 and familiar enough with the templates
you're calling to be writing a master templates, you don't need an
editor or form to build the template calls for you.
More general kinds of interface builders that build all imaginable kinds of
interfaces are conceivable.
Is this not possible within the scope of the suggested system?
Yes, but it's also possible within the scope of the current system.
You don't /need/ a template editor to be doing this kind of monkey
business. In fact, I think a template editor would actually discourage
these practices, because relatively unexperienced users must be able
to build a reasonable template call using the template editor. For the
latter to work out, templates need to be simpler rather than more
complex.
In short, I don't think introducing a template editor would encourage
master templates and similar complexification of templates; in fact, I
believe it will actually encourage simplification, because a
nice-looking GUI for a big incomprehensible parameter soup is worth
the soup.
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
-Original Message- From: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Roan Kattouw Sent: 25 September 2009 23:39 To: Wikimedia developers Subject: Re: [Wikitech-l] Proposal for editing template calls within pages 2009/9/25 Platonides platoni...@gmail.com: Those descriptions will have to be edited by the same user base that edit all other pages. Even if they are power users, it's not easy to write correct XML on the wiki textarea. We would need to create an editor for the language being created so a template editor can be made. Since the XML file describes the template, it need only be changed when the template is changed. Realistically, newbie editors don't edit templates; anyone skilled enough to edit templates can handle some simple XML. I advocate for a simpler syntax for form definition (but we shouldn't on the way reinvent wikitext). Exactly. XML is a decent choice here because it has a well-defined, pre-existing grammar with parsers already available, which means it's easy to parse and easy to learn (assuming you've got some shred of a technical background; see my earlier point about newbies not editing templates). Roan Kattouw (Catrope) One thing I think might be missing from the example template description is all the implicit parameters it depends on, like language. Jared ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
Roan Kattouw wrote: 2009/9/25 Platonides: Those descriptions will have to be edited by the same user base that edit all other pages. Even if they are power users, it's not easy to write correct XML on the wiki textarea. We would need to create an editor for the language being created so a template editor can be made. Since the XML file describes the template, it need only be changed when the template is changed. Realistically, newbie editors don't edit templates; anyone skilled enough to edit templates can handle some simple XML. But why make it harder? You could also stat that anyone skilled enough to edit templates can handle new complex syntax. I wouldn't feel comfortable mannually editing XML. Or worse, reviewing XML written by others that is invalid (How are you going to handle that?). I advocate for a simpler syntax for form definition (but we shouldn't on the way reinvent wikitext). Exactly. XML is a decent choice here because it has a well-defined, pre-existing grammar with parsers already available, which means it's easy to parse and easy to learn (assuming you've got some shred of a technical background; see my earlier point about newbies not editing templates). Roan Kattouw (Catrope) However, it's not easy to type. It's convenient just for developers. XML has the advantage of having many editors available, but if I need an external editor, the system is broken. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Fri, Sep 25, 2009 at 4:49 PM, Roan Kattouw roan.katt...@gmail.comwrote:
2009/9/26 Brian brian.min...@colorado.edu:
Roan, sorry that the idea is pretty hard to convey, I'll try again.
The basic idea is that you can create templates using templates
(just using current
tech). It's easy, you just pass parameters to a template that control
its output, and this
output is a new template. The parameters that you passed determine what
the
new template looks like, and what it's output will be.
Right, so basically this is just templates calling other templates,
right? This already happens to some degree already.
We can imagine a master template on Wikipedia that is used to generate
all
infoboxes. It could work in arbitrary ways, but suppose it works this
way:
The master infobox template creates a template for each wikiproject. The
template that it creates for each wikiproject further creates templates
representing every kind of infobox that this wikiproject uses. So you
have a
master template that creates baby templates that create infobox
templates.
Using current tech this isn't exactly feasible, only advanced users will
do
it since you have to directly interact with the templates and it would be
tough to code up. But if you make such a feature highly usable, by, for
example, tacking an easy to use interface on top of it, the usage of such
techniques will proliferate.
To use the master infobox example: such a template would have about a
dozen usage modes, each with dozens of parameters. Such constructs are
actually /easier/ to call by hand than with a form, because you'd
either have to store all the relationships between the parameters and
usage modes in the XML file and let the form handle all that (which is
a degree of complexity I personally would not like to see in a
template forms implementation) or just throw a couple hundred
parameters in the user's face.
Also, this being tough to code up would not change: again, we're not
simplifying the *writing* of templates *themselves* in any way. The
fact that these templates include template calls doesn't change that,
because 1) you're gonna be using #if constructs all over the place
anyway, 2) you'd need to use stuff like {{{2|{{{1|}} as arguments
to template calls, which the GUI doesn't simplify and 3) if you're
skilled enough to do 1 and 2 and familiar enough with the templates
you're calling to be writing a master templates, you don't need an
editor or form to build the template calls for you.
More general kinds of interface builders that build all imaginable kinds
of
interfaces are conceivable.
Is this not possible within the scope of the suggested system?
Yes, but it's also possible within the scope of the current system.
You don't /need/ a template editor to be doing this kind of monkey
business. In fact, I think a template editor would actually discourage
these practices, because relatively unexperienced users must be able
to build a reasonable template call using the template editor. For the
latter to work out, templates need to be simpler rather than more
complex.
In short, I don't think introducing a template editor would encourage
master templates and similar complexification of templates; in fact, I
believe it will actually encourage simplification, because a
nice-looking GUI for a big incomprehensible parameter soup is worth
the soup.
Roan Kattouw (Catrope)
* wizards, workflows, meta-interfaces, these are accidental implications of
a feature whose only purported design goal is to make editing templates on
articles easier. and i haven't been at all convinced that the new system
won't make it possible to create really elegant interfaces that are easy to
use. e.g., that make it really easy to create monstrosities of templates and
parser functions that no human can conceivably understand. :* historically,
if it can be done on the wiki it will be done
:* and it will be spread and copied, hundreds of thousands to millions of
times, within just a few years
* nobody intended to make template syntax turing complete - it was an
accident
* the obvious solution to templates is *not* to hack on an interface for
editing them. wikipedia is supposed to be the encyclopedia that anyone can
edit. it was a poor design decision to enable (or indeed, to create) a
template system on wikipedia that allowed people to create, in the first
place {{qif}}, and other things like it. the only reason even worse things
weren't created is that it was hard.
:* and the result of this accident was not just to put limits on
recursion and the things that could be done with templates, but to
further enable
those use cases (without much discussion or regard to long term strategy and
usability).
* so not only were templates bad, but this Incrementalism, otherwise known
as [[Feature creep]], which brion just described as his guiding strategy,
led us to kludge something even worse on top.
Re: [Wikitech-l] Proposal for editing template calls within pages
Hello.
Heres a screenshot of me editing the wikipedia:
http://zerror.com/unorganized/crap/nogoodenough.png
All the webmasters on this mail list will spot the problem with this
text in 1 second: is unreadable. The space betwen lines, the lines
length, the complexity of the text... Is really hard to read.
A HTML textarea can server for writting emails, and simple text, but
on this image fail short. Textareas are not designed for this, or are
not good enough.
How a webmaster can make that text better? well.. you need to stop
using the HTML textarea widget. And emulate it with divs, css and
javascript. You need to colorize the code. Nowdays *ALL* good code
editors colorize code. If our code editor don't colorize the wiki
sintax, or don't even try, our editor is bad. I could be wrong, but
maybe [[links]] and {{templates}} can be detected and colorized. And
since you are emulating a editor, you can add a bit of usefull
beaviors: make so some areas are read only, so the cursor skip then.
Oh.. and you can make the whole think AJAXified,.. so wen you click
[Edit section] this section become editable, and wen you save, the
edit view send, and is replaced by the result. Why would you want to
people bounce here and there to post stuff in 2009?
He... our computers support 24 M colors, and we are showing text with
2 colors? pfff
--
--
ℱin del ℳensaje.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
How a webmaster can make that text better? well.. you need to stop using the HTML textarea widget. And emulate it with divs, css and javascript. You need to colorize the code. Nowdays *ALL* good code Or use a canvas.. enter Bespin! https://bespin.mozilla.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Fri, Sep 25, 2009 at 2:57 PM, Platonides platoni...@gmail.com wrote: Brian wrote: On Fri, Sep 25, 2009 at 12:30 PM, Trevor Parscal wrote: * The topic is supposed to be on Template Editing which is, at least in the way it's being proposed, a little less of a stale topic - so where is all the energy on that front? We have an XML format to design and complex problems to sort out. Help is really needed. Let's all take a look at the link provided at the beginning of this thread http://usability.wikimedia.org/wiki/Template_forms - Trevor I do think that sufficient energy has been directed at this topic. People have complained that xml is harder to edit that wikitext and that it is too complicated, among other things. I think this is an important point. XML is hard to edit. That's the reason wikitext was created, to fix the issues with the, even easier, html. Now, it is being proposed to add a XML processing on top of wikitext to describe templates. snip Unless expressly forbidden by the software implementation, I would assume that helpful Wikipedians would very quickly write template description templates to replace the XML and give it a nice wiki interface. So, in practice, the question of whether XML is hard to edit will probably be moot and reduced solely to the issue that templates are hard to edit. -Robert Rohde ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On 9/25/09 6:07 PM, Daniel Schwen wrote: How a webmaster can make that text better? well.. you need to stop using the HTML textarea widget. And emulate it with divs, css and javascript. You need to colorize the code. Nowdays *ALL* good code Or use a canvas.. enter Bespin! https://bespin.mozilla.com/ Bespin is *very* cool, and we've definitely looked at it. (Even aside from the excellent syntax highlighting editor widget there are some *really* neat capabilities like the multi-user realtime editing, which if framed appropriately and combined with good chat tools could be insanely useful for Wikipedia.) Right now it's quite an experimental project, though, and doesn't have a good way to support IE, so for our key efforts on syntax highlighting and content-folding we're looking mainly at using the browser-provided rich text edit widgets. This can unfortunately have performance problems so we may be limited in what we can do well, but hopefully that'll tide us over for a couple years. ;) The wikEd editor gadget is an example of using this method to do syntax highlighting, though we'd want to scale it back to the key elements and avoid going overboard on the interface: http://en.wikipedia.org/wiki/User:Cacycle/wikEd -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On 9/25/09 6:11 PM, Robert Rohde wrote: On Fri, Sep 25, 2009 at 2:57 PM, Platonidesplatoni...@gmail.com wrote: Brian wrote: XML is hard to edit. That's the reason wikitext was created, to fix the issues with the, even easier, html. Now, it is being proposed to add a XML processing on top of wikitext to describe templates. snip Unless expressly forbidden by the software implementation, I would assume that helpful Wikipedians would very quickly write template description templates to replace the XML and give it a nice wiki interface. So, in practice, the question of whether XML is hard to edit will probably be moot and reduced solely to the issue that templates are hard to edit. It's unlikely that many people will ever see or edit the XML as there'll be a perfectly good structured user interface. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
* Nikola Smolenski smole...@eunet.rs [Thu, 24 Sep 2009 08:44:28 +0200]: Having said that, I don't see why would XML be necessary. Table and template markup are well structured and could be used by any editor just as XML would. Additionally, it is easier to observe diffs with wiki markup. So it would be menu and icon-driven editing, where the hands should move from keyboard to mouse and vice versa, like MS Word. Not very handy for programmers and people who prefer to do most of tasks in command line. But, the majority probably wants the WYSIWYG. It;s just with wikitext you may have both source text and WYSIWYG, with XML source text becomes a real pain.. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Thu, Sep 24, 2009 at 4:44 PM, Nikola Smolenski smole...@eunet.rs wrote: Having said that, I don't see why would XML be necessary. Table and template markup are well structured and could be used by any editor just as XML would. Additionally, it is easier to observe diffs with wiki markup. Is it possible, currently, to define the types of parameters to functions? Can you include hints in them about what the parameter is for? Can you specify maximum lengths, or choose from a small number of choices? Steve ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Thu, Sep 24, 2009 at 5:31 PM, Dmitriy Sintsov ques...@rambler.ru wrote: So it would be menu and icon-driven editing, where the hands should move from keyboard to mouse and vice versa, like MS Word. Not very handy for programmers and people who prefer to do most of tasks in command line. I think you're making a large number of unjustified assumptions here. If you look at the proposal (and remember - it's a proposal), it says it would be enabled by default for every user. Reading between the lines, that means you can disable it. Relax. Steve ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
Steve Bennett wrote: On Thu, Sep 24, 2009 at 4:44 PM, Nikola Smolenski smole...@eunet.rs wrote: Having said that, I don't see why would XML be necessary. Table and template markup are well structured and could be used by any editor just as XML would. Additionally, it is easier to observe diffs with wiki markup. Is it possible, currently, to define the types of parameters to functions? Can you include hints in them about what the parameter is for? Can you specify maximum lengths, or choose from a small number of choices? It seems that we are talking about two different things here: 1) What would be the markup of template description pages, that will be used to make template editing forms. 2) What would be the markup of a template call, that will be used in the source of article pages to make actual template call. Given that #1 is an entirely new thing, it can have an entirely new markup. I see no reason for it not to be XML. #2 however should be kept as is. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Thu, Sep 24, 2009 at 3:31 AM, Dmitriy Sintsov ques...@rambler.ru wrote: So it would be menu and icon-driven editing, where the hands should move from keyboard to mouse and vice versa, like MS Word. Not very handy for programmers and people who prefer to do most of tasks in command line. Programmers rank far, far below normal people when it comes to usability prioritization. Programmers can use WYSIWYG just as well as anyone else, even if it's not as powerful as they'd like. FWIW, on forums I go to where I can use either BB code or WYSIWYG, I use WYSIWYG most of the time -- it's just more convenient. I only resort to BB code to work around deficiencies in the WYSIWYG editor. Even for programmers, learning a new syntax is a significant issue. A few months ago I spoke to a programmer I know who tried editing Wikipedia a few times. He got lost in the wikitext. He knew he could figure out how to make the correction he wanted if he had to, but in practice, he just gave up without putting in the effort. It was too much of a barrier to entry to overcome his weak interest in fixing the error he saw. As far as I'm concerned, a situation in which WYSIWYG is the only supported editing method would be far superior to the current situation. If we could allow power users to edit manually, that would be a nice bonus. Note that even if we use a format like XML that's a pain to manually edit, programmers can write up their own front-ends if they like -- they're programmers, after all! And also note that as with most WYSIWYG editors, there would presumably be a slew of keyboard shortcuts for power users to memorize if they didn't want to use the mouse. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/24 Aryeh Gregor simetrical+wikil...@gmail.com: On Thu, Sep 24, 2009 at 3:31 AM, Dmitriy Sintsov ques...@rambler.ru wrote: So it would be menu and icon-driven editing, where the hands should move from keyboard to mouse and vice versa, like MS Word. Not very handy for programmers and people who prefer to do most of tasks in command line. Programmers rank far, far below normal people when it comes to usability prioritization. Indeed, as do robot editors. This is part of the no way, not even with logic twisting, is the impenetrability of wikitext a feature. As far as I'm concerned, a situation in which WYSIWYG is the only supported editing method would be far superior to the current situation. If we could allow power users to edit manually, that would be a nice bonus. Note that even if we use a format like XML that's a pain to manually edit, programmers can write up their own front-ends if they like -- they're programmers, after all! And also note that as with most WYSIWYG editors, there would presumably be a slew of keyboard shortcuts for power users to memorize if they didn't want to use the mouse. Realistically, Tim has already stated we're not throwing out wikitext because of the huge body of text already in it. WYSIWYG editing is getting there bit by bit - FCKeditor would be fine on a fresh wiki without the unspeakable atrocities inventive geeks have perpetrated upon wikitext on en:wp and should continue to get better at dealing with more obtusities. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Thu, Sep 24, 2009 at 10:48 AM, dgerard dger...@gmail.com wrote: Realistically, Tim has already stated we're not throwing out wikitext because of the huge body of text already in it. Not in the foreseeable future, but maybe someday. We'd just need a very careful and thorough migration plan. WYSIWYG editing is getting there bit by bit - FCKeditor would be fine on a fresh wiki without the unspeakable atrocities inventive geeks have perpetrated upon wikitext on en:wp and should continue to get better at dealing with more obtusities. Funnily enough, I just talked to a user in #mediawiki asking why FCKeditor didn't work right on his wiki when copy-pasting from MS Word. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
Hi, Just to clarify a few things: - yes, it's important to distinguish between the editing of templates and the editing of template calls. Most people understand that distinction, but just to clarify, this project would allow for editing of template *calls*; while template pages themselves would just get extended with a new XML file. - yes, users could opt out of it and stick with standard wiki-text editing. - I don't think there's any support for replacing wiki-text with XML, by the way. - there's no way currently within templates to specify the type of a parameter (that is, whether it's a string, date, enumeration, etc.), descriptions of parameters, etc.; that's why something like the XML subpage is needed. XML seems like a good solution for the task; and the German Wikipedia's implementation provides a good proof of concept for it. - this project isn't about getting WYSIWYG onto Wikipedia, although I think it's a step toward that goal: first, because it would put in place some sort of Javascript-enabled editor in place of the standard edit page textarea; and second, because, as far as I know, handling of template calls is one of the big stumbling blocks (though not the only one) preventing WYSIWYG from getting used on Wikimedia projects. -Yaron ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
* dgerard dger...@gmail.com [Thu, 24 Sep 2009 15:48:16 +0100]: Realistically, Tim has already stated we're not throwing out wikitext because of the huge body of text already in it. WYSIWYG editing is getting there bit by bit - FCKeditor would be fine on a fresh wiki without the unspeakable atrocities inventive geeks have perpetrated upon wikitext on en:wp and should continue to get better at dealing with more obtusities. It should be possible to have wikitext and XML in parallel, even mixed - there are already parser tags for extensions and I remember Robert Rohde wrote they can be patched to work recursively. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
* Aryeh Gregor simetrical+wikil...@gmail.com [Thu, 24 Sep 2009
09:57:27 -0400]:
Programmers rank far, far below normal people when it comes to
usability prioritization. Programmers can use WYSIWYG just as well as
anyone else, even if it's not as powerful as they'd like. FWIW, on
forums I go to where I can use either BB code or WYSIWYG, I use
WYSIWYG most of the time -- it's just more convenient. I only resort
to BB code to work around deficiencies in the WYSIWYG editor.
I prefer to use BB code and rarely use forum icons. That's a matter of
personal choice.
Even for programmers, learning a new syntax is a significant issue. A
few months ago I spoke to a programmer I know who tried editing
Wikipedia a few times. He got lost in the wikitext.
The only really complex part of wikitext are the templates - nested,
sometimes really weird subst and so on. I remember reading Advanced
Templates at meta and have the feeling I am reading something really
cryptic - I am still not good at making complex templates. Tables,
links, text formatting, images are easy to me (there were great guides
like Advanced tables at meta back in v1.9.3..v1.10 when I've started
to use MediaWiki). Of course it doesn't matter, because I am hardly a
representative.
He knew he could
figure out how to make the correction he wanted if he had to, but in
practice, he just gave up without putting in the effort. It was too
much of a barrier to entry to overcome his weak interest in fixing the
error he saw.
Only the complex template I can think of reason.
As far as I'm concerned, a situation in which WYSIWYG is the only
supported editing method would be far superior to the current
situation. If we could allow power users to edit manually, that would
be a nice bonus. Note that even if we use a format like XML that's a
pain to manually edit, programmers can write up their own front-ends
if they like -- they're programmers, after all! And also note that as
with most WYSIWYG editors, there would presumably be a slew of
keyboard shortcuts for power users to memorize if they didn't want to
use the mouse.
Maybe it should be possible to store everything in XML and map XML to
wikitext on the fly for these who like wikitext, and also to make future
core compatible with old bots. Eg. {| will be stored internally as
wmf:table.
Dmitriy
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Thu, Sep 24, 2009 at 12:47 PM, Dmitriy Sintsov ques...@rambler.ru wrote: The only really complex part of wikitext are the templates - nested, sometimes really weird subst and so on. Templates and refs are by far the worst offenders, for sticking tons of content in the page that doesn't have any obvious relationship to the actual content. Getting rid of them would be a huge step forward. But stuff like '''bold''' and ==headings== are also a real problem. Everything unexpected like that is going to increase the risk that a new user will get worried he doesn't know what he's doing, and give up rather than risk breaking something or put effort into figuring out what to do. If you give *anyone*[1] a WYSIWYG interface, they'll know how it works, because they're used to it from Word and whatnot. That's just not true of wikitext, no matter how simple it is once you *already* understand it. [1] Yes, yes, I mean anyone who uses computers much at all, not farmers in rural Africa or my maternal grandmother. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/24 Aryeh Gregor simetrical+wikil...@gmail.com: On Thu, Sep 24, 2009 at 10:48 AM, dgerard dger...@gmail.com wrote: WYSIWYG editing is getting there bit by bit - FCKeditor would be fine on a fresh wiki without the unspeakable atrocities inventive geeks have perpetrated upon wikitext on en:wp and should continue to get better at dealing with more obtusities. Funnily enough, I just talked to a user in #mediawiki asking why FCKeditor didn't work right on his wiki when copy-pasting from MS Word. *facepalm* And then there's the obvious things users will do that I hadn't thought of, yes. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/24 Dmitriy Sintsov ques...@rambler.ru: The only really complex part of wikitext are the templates - nested, sometimes really weird subst and so on. I remember reading Advanced Templates at meta and have the feeling I am reading something really cryptic - I am still not good at making complex templates. Tables, links, text formatting, images are easy to me (there were great guides like Advanced tables at meta back in v1.9.3..v1.10 when I've started to use MediaWiki). Of course it doesn't matter, because I am hardly a representative. Indeed. I can only recommend that you spend more time with people who can't work computers very well. We also need as editors people who are experts in things that you are a dunce in but who are dunces in the computers that you are an expert in. There's a lot more people who can't work computers very well than who can. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Thu, Sep 24, 2009 at 8:48 AM, dgerard dger...@gmail.com wrote: 2009/9/24 Aryeh Gregor simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com : On Thu, Sep 24, 2009 at 3:31 AM, Dmitriy Sintsov ques...@rambler.ru wrote: So it would be menu and icon-driven editing, where the hands should move from keyboard to mouse and vice versa, like MS Word. Not very handy for programmers and people who prefer to do most of tasks in command line. Programmers rank far, far below normal people when it comes to usability prioritization. Indeed, as do robot editors. This is part of the no way, not even with logic twisting, is the impenetrability of wikitext a feature. As far as I'm concerned, a situation in which WYSIWYG is the only supported editing method would be far superior to the current situation. If we could allow power users to edit manually, that would be a nice bonus. Note that even if we use a format like XML that's a pain to manually edit, programmers can write up their own front-ends if they like -- they're programmers, after all! And also note that as with most WYSIWYG editors, there would presumably be a slew of keyboard shortcuts for power users to memorize if they didn't want to use the mouse. Realistically, Tim has already stated we're not throwing out wikitext because of the huge body of text already in it. WYSIWYG editing is getting there bit by bit - FCKeditor would be fine on a fresh wiki without the unspeakable atrocities inventive geeks have perpetrated upon wikitext on en:wp and should continue to get better at dealing with more obtusities. - d. This round the Usability Initiative got 800,000 dollars. That's a load of money. If the Foundation decides that it wants to fix the problem the correct way then it can. And it can start at any time! We just need to agree on a solution. We can't fix the problem by looking backwards at the wikitext that has already been produced along with the language definition (5,000 lines of parser code) and saying that the problem is simply intractable. In fact, the problem does not depend in any way on the quantity of wikitext that has been produced - it only depends on an understanding (if not a definition) of the language as it currently exists. Hard work but not, at all, impossible. It doesn't seem productive to me to start by looking at the problem from that looking-backwards angle of oh my god there is so much wikitext written in this language that isn't even defined. It would be more productive to first decide what we would like to see. For example: * wikitext parsing would be much faster if the language was well defined and we could use flex/bison/etc... * usability would be greatly enhanced if all wikitext was easy to understand, even for newcomers. this includes a clear breakdown of the problem of including/querying remote resources and a clean solution to that problem (unlike templates) * if the language is well defined, then we can have a wysywig editor whose behavior is well defined * if the language is well defined, we can have multiple fully compatible parser implementations, for example, flex/bison, php, python and importantly, javascript. After we have together designed and implemented the new solution we could start work on the isomorphic mapping between old school wikitext and new school wikitext. Or they can happen in parallel. It certainly doesn't seem helpful to our movement to settle on the existing solution, which has so many flaws, when we can easily imagine so many other solutions which are clearly better. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Thu, Sep 24, 2009 at 4:03 PM, Brian brian.min...@colorado.edu wrote: This round the Usability Initiative got 800,000 dollars. That's a load of money. If the Foundation decides that it wants to fix the problem the correct way then it can. And it can start at any time! We just need to agree on a solution. Only at the expense of sacrificing some, most, or all of the work they're already doing. $800,000 is not a particularly large sum for a programming project, and the usability project had to prioritize it. They decided to target things other than WYSIWYG first. I'd be inclined to think that's wise, without having considered the issue very deeply. Full WYSIWYG *is* really needed, but it would be unjustifiably expensive when there are so many more minor improvements that could be (and are being) made much more easily. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Thu, Sep 24, 2009 at 2:22 PM, Aryeh Gregor simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com wrote: On Thu, Sep 24, 2009 at 4:03 PM, Brian brian.min...@colorado.edu wrote: This round the Usability Initiative got 800,000 dollars. That's a load of money. If the Foundation decides that it wants to fix the problem the correct way then it can. And it can start at any time! We just need to agree on a solution. Only at the expense of sacrificing some, most, or all of the work they're already doing. $800,000 is not a particularly large sum for a programming project, and the usability project had to prioritize it. They decided to target things other than WYSIWYG first. I'd be inclined to think that's wise, without having considered the issue very deeply. Full WYSIWYG *is* really needed, but it would be unjustifiably expensive when there are so many more minor improvements that could be (and are being) made much more easily. I definitely think it's a good idea to go after the low hanging fruit first, which it sounds like is what they are doing with this 800k. Fixing the core of the problem is definitely not low hanging fruit - it's hard work. On the other hand, the foundation just got a couple million in unrestricted funds, and when I say that they can start fixing the problem at any time, I mean they can seek out an additional grant if necessary for this specific issue. Basically what I am saying is that I don't jive with the perspective that we should accept wikitext as it is and hack in new fixes on top of it. I would like to see the foundation go out and try to fix this problem the correct way, starting nowish. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Thu, Sep 24, 2009 at 4:28 PM, Brian brian.min...@colorado.edu wrote: I definitely think it's a good idea to go after the low hanging fruit first, which it sounds like is what they are doing with this 800k. Fixing the core of the problem is definitely not low hanging fruit - it's hard work. On the other hand, the foundation just got a couple million in unrestricted funds, and when I say that they can start fixing the problem at any time, I mean they can seek out an additional grant if necessary for this specific issue. Basically what I am saying is that I don't jive with the perspective that we should accept wikitext as it is and hack in new fixes on top of it. I would like to see the foundation go out and try to fix this problem the correct way, starting nowish. They could do that. I wouldn't be surprised if they start serious WYSIWYG work in a year or two. But there are a *lot* of things on Wikipedia that could be improved. Even with the big grants Wikimedia's now getting, it operates on a budget less than 0.1% that of some comparably large websites (like Google). Right now I hope we're going to focus on getting more full-time experienced programmers, like hiring a CTO and letting Brion become only senior software architect. We have lots of junior people doing work, but code review is still a huge bottleneck AFAICT. Just look at the current discussion on JS2, for instance, or the outages caused by performance problems that weren't caught before deployment. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Thu, Sep 24, 2009 at 2:38 PM, Aryeh Gregor simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com wrote: On Thu, Sep 24, 2009 at 4:28 PM, Brian brian.min...@colorado.edu wrote: I definitely think it's a good idea to go after the low hanging fruit first, which it sounds like is what they are doing with this 800k. Fixing the core of the problem is definitely not low hanging fruit - it's hard work. On the other hand, the foundation just got a couple million in unrestricted funds, and when I say that they can start fixing the problem at any time, I mean they can seek out an additional grant if necessary for this specific issue. Basically what I am saying is that I don't jive with the perspective that we should accept wikitext as it is and hack in new fixes on top of it. I would like to see the foundation go out and try to fix this problem the correct way, starting nowish. They could do that. I wouldn't be surprised if they start serious WYSIWYG work in a year or two. But there are a *lot* of things on Wikipedia that could be improved. Even with the big grants Wikimedia's now getting, it operates on a budget less than 0.1% that of some comparably large websites (like Google). Right now I hope we're going to focus on getting more full-time experienced programmers, like hiring a CTO and letting Brion become only senior software architect. We have lots of junior people doing work, but code review is still a huge bottleneck AFAICT. Just look at the current discussion on JS2, for instance, or the outages caused by performance problems that weren't caught before deployment. Working through the current backlog of bugs definitely counts as low hanging fruit so I definitely agree that there should be more hackers on hand at the foundation and a CTO to guide them. On the other hand, given the admitted size of the wysiwyg problem and the large number of existing smaller problems it doesn't seem wise to to try and shoehorn it into the current usability initiative if we all agree that they already have their work cut out for them. The solution we come up with, for example this xml proposal for templates, could in practice end up being counter to our long term goals to standardize wikitext. It could quickly propagate throughout the wikisphere and not only will we have to deal with templates and parser functions, but now an entire form language. I think something much simpler and cleaner than all of that is desirable. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
Brian wrote: This round the Usability Initiative got 800,000 dollars. That's a load of money. If the Foundation decides that it wants to fix the problem the correct way then it can. And it can start at any time! We just need to agree on a solution. We can't fix the problem by looking backwards at the wikitext that has already been produced along with the language definition (5,000 lines of parser code) and saying that the problem is simply intractable. In fact, the problem does not depend in any way on the quantity of wikitext that has been produced - it only depends on an understanding (if not a definition) of the language as it currently exists. Hard work but not, at all, impossible. ... * wikitext parsing would be much faster if the language was well defined and we could use flex/bison/etc... Have you read the archives? It has been tried. Several times. There's even a mailing list for that. Getting a formal definition of ~90% of the wikitext syntax is easy. The other 10% drived nuts everyone trying to do it hard enough, so far. Keep trying, but build over what's already done. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/24 Platonides platoni...@gmail.com: Brian wrote: * wikitext parsing would be much faster if the language was well defined and we could use flex/bison/etc... Have you read the archives? It has been tried. Several times. There's even a mailing list for that. Getting a formal definition of ~90% of the wikitext syntax is easy. The other 10% drived nuts everyone trying to do it hard enough, so far. Keep trying, but build over what's already done. I suspect it'll be approached from the other end: FCKeditor will be improved until it can do quite a lot of the stuff, and there'll eventually be sufficiently little remaining that it can be bot-converted to a form FCKeditor can handle. At which point we formalise that and away we go with third-party parsers galore! Well, I can dream. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Thu, Sep 24, 2009 at 4:05 PM, Platonides platoni...@gmail.com wrote: Brian wrote: This round the Usability Initiative got 800,000 dollars. That's a load of money. If the Foundation decides that it wants to fix the problem the correct way then it can. And it can start at any time! We just need to agree on a solution. We can't fix the problem by looking backwards at the wikitext that has already been produced along with the language definition (5,000 lines of parser code) and saying that the problem is simply intractable. In fact, the problem does not depend in any way on the quantity of wikitext that has been produced - it only depends on an understanding (if not a definition) of the language as it currently exists. Hard work but not, at all, impossible. ... * wikitext parsing would be much faster if the language was well defined and we could use flex/bison/etc... Have you read the archives? It has been tried. Several times. There's even a mailing list for that. Getting a formal definition of ~90% of the wikitext syntax is easy. The other 10% drived nuts everyone trying to do it hard enough, so far. Keep trying, but build over what's already done. Platonides, if you had read the archives you would know that I am very familiar with previous work done on creating formal grammars for wikitext, and that I know it would take a redesign of certain parts of the language. Of course, this information is embedded in the very text you quote. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Fri, Sep 25, 2009 at 8:05 AM, Platonides platoni...@gmail.com wrote: Getting a formal definition of ~90% of the wikitext syntax is easy. The other 10% drived nuts everyone trying to do it hard enough, so far. I wouldn't put it quite like that. Yes, the problem gets harder as you get nearer the end - but it also doesn't matter, because you're dealing with rare examples. There are also parts of the language best not dealt with this way. For example, there's not much point attempting to parse template transclusions like this, because there will always have to be a pre-processor that handles them. What actually really drove me mad was ANTLR - it wasn't stable, and the effort in turning a language file into a working Java program that I could play with was a lot greater than I expected. And I discovered the usual problem with declarative languages - that small changes in one place can have huge impacts in others. I would definitely like to take up the challenge again sometime. I've sort of been waiting for ANTLR to become more stable. And we'd need some kind of plan of what to do with the language spec file, like whether to actually build a parser off it or whatever. Steve ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
Yaron Koren wrote: Hi everyone, Part of the Wikipedia Usability Initiative is a project to create a system whereby template calls are hidden (minimized, really) for most users on the edit page, and when users do want to edit template calls, they can do so via a form instead of editing the template call directly. I'm involved with that project; my previous experience with such matters was creating the Semantic Forms extension, which is similar in its basic concept. I've put together a page explaining the current thinking on how the system should work, here: http://usability.wikimedia.org/wiki/Template_forms We're looking for feedback; any thoughts or questions are welcome, either on that page's talk page or by responding to this email. Thanks, Yaron Perhaps it could be made so form parameters and template documentation can be defined at the same time? At first, I thought in the ability of embedding the documentation in the template, but if XML provides benefits, it could be made so the documentation can be provided from the XML. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
I like the XML way of resolving this problem but I think it MediaWiki has a bigger task to do. Restructure the wiki language, XML-ize the language completely. Forms and attributes will have a place in this WikiXML-definition. Pages can be constructed from one or more XML-sources. XML-source, or a transformed version of it, can be used on more than one page. 'Extensions' will be (sub)-elements of the standard MediaWiki definition. Recursive tasks can be done as long as the definition allows it. We are not depending on the MW-parser as is. Easier construction of editors. Use of XML-stylesheets for presentation. etc. non-realistic? May be. In my vision the only way to make a real difference. If this is a first step towards structuring the language than I think its ok. Andre Op 23 sep 2009, om 20:24 heeft Yaron Koren het volgende geschreven: Hi everyone, Part of the Wikipedia Usability Initiative is a project to create a system whereby template calls are hidden (minimized, really) for most users on the edit page, and when users do want to edit template calls, they can do so via a form instead of editing the template call directly. I'm involved with that project; my previous experience with such matters was creating the Semantic Forms extension, which is similar in its basic concept. I've put together a page explaining the current thinking on how the system should work, here: http://usability.wikimedia.org/wiki/Template_forms We're looking for feedback; any thoughts or questions are welcome, either on that page's talk page or by responding to this email. Thanks, Yaron ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Wed, Sep 23, 2009 at 4:37 PM, apri a.vd.wiel a.vd.w...@apri.nl wrote: I like the XML way of resolving this problem but I think it MediaWiki has a bigger task to do. Restructure the wiki language, XML-ize the language completely. Forms and attributes will have a place in this WikiXML-definition. Pages can be constructed from one or more XML-sources. XML-source, or a transformed version of it, can be used on more than one page. 'Extensions' will be (sub)-elements of the standard MediaWiki definition. Recursive tasks can be done as long as the definition allows it. We are not depending on the MW-parser as is. Easier construction of editors. Use of XML-stylesheets for presentation. etc. non-realistic? May be. In my vision the only way to make a real difference. If this is a first step towards structuring the language than I think its ok. Wikis are supposed to be easy to edit. Maybe I am misunderstanding your intent, but XML-ize everything sounds like an approach that would make it much harder for novice editors to figure out what they are doing. XML tends to be verbose and complicated when edited by hand, and rather opaque for people who have no experience with it. -Robert Rohde ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Wed, Sep 23, 2009 at 7:54 PM, Robert Rohde raro...@gmail.com wrote: Wikis are supposed to be easy to edit. Wikitext is not easy to edit. It's incredibly confusing and intimidating to any normal person. The only thing that would be easy to edit is something WYSIWYG-based. And AFAICT, the only way we're going to get that is to use some kind of backend storage that can round-trip sensibly with HTML. It doesn't have to be XML-based, but it needs to be a lot simpler (from a programming standpoint, not a human standpoint) than what we have now. But there would be transition costs here that are prohibitive in the medium term. Hopefully at some point we'll have the resources to devote to this, but in the short to medium term, there's a lot of low-hanging fruit that will give much better usability improvements per dev-hour than getting WYSIWYG reliable enough to deploy. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On 9/23/09 4:54 PM, Robert Rohde wrote: On Wed, Sep 23, 2009 at 4:37 PM, apri a.vd.wiela.vd.w...@apri.nl wrote: I like the XML way of resolving this problem but I think it MediaWiki has a bigger task to do. Restructure the wiki language, XML-ize the language completely. Forms and attributes will have a place in this WikiXML-definition. Pages can be constructed from one or more XML-sources. XML-source, or a transformed version of it, can be used on more than one page. 'Extensions' will be (sub)-elements of the standard MediaWiki definition. Recursive tasks can be done as long as the definition allows it. We are not depending on the MW-parser as is. Easier construction of editors. Use of XML-stylesheets for presentation. etc. non-realistic? May be. In my vision the only way to make a real difference. If this is a first step towards structuring the language than I think its ok. Wikis are supposed to be easy to edit. Maybe I am misunderstanding your intent, but XML-ize everything sounds like an approach that would make it much harder for novice editors to figure out what they are doing. XML tends to be verbose and complicated when edited by hand, and rather opaque for people who have no experience with it. -Robert Rohde ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Indeed. WikiText != XML on purpose. - Trevor ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
On Thu, Sep 24, 2009 at 9:54 AM, Robert Rohde raro...@gmail.com wrote: Wikis are supposed to be easy to edit. Maybe I am misunderstanding your intent, but XML-ize everything sounds like an approach that would make it much harder for novice editors to figure out what they are doing. XML tends to be verbose and complicated when edited by hand, and rather opaque for people who have no experience with it. I think the intention is that newbies will never even see the XML, let alone be expected to edit it. The XML defines the template, and tells MediaWiki how to construct the form that the user edits with. You would only need to edit the XML if you were modifying the template itself - hardly likely for a newbie. Steve ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal for editing template calls within pages
* Steve Bennett stevag...@gmail.com [Thu, 24 Sep 2009 14:18:17 +1000]: On Thu, Sep 24, 2009 at 9:54 AM, Robert Rohde raro...@gmail.com wrote: Wikis are supposed to be easy to edit. Maybe I am misunderstanding your intent, but XML-ize everything sounds like an approach that would make it much harder for novice editors to figure out what they are doing. XML tends to be verbose and complicated when edited by hand, and rather opaque for people who have no experience with it. I think the intention is that newbies will never even see the XML, let alone be expected to edit it. The XML defines the template, and tells MediaWiki how to construct the form that the user edits with. You would only need to edit the XML if you were modifying the template itself - hardly likely for a newbie. What if I need to add a simple table to the page? With wikitext that would take much less of keys to press than using html or xml. Even simple things, like headers, bolds, italics and images are shorter to define in wikitext. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
