Wikitext-l

wikitext-l@lists.wikimedia.org

239 discussions

Visual Editor & WikiEditor Integration outside MediaWiki
by Jim Safley 21 May '12

21 May '12

Will I be able to implement the Visual Editor outside MediaWiki? For instance, could I install it as a JavaScript library in a separate application? I notice that the original edit toolbar and the toolbar that comes with the WikiEditor extension are coupled so tightly to MediWiki that it's near impossible to integrate them into a separate application. (If I'm wrong, please educate me.) I wonder if the same will apply to the rich-text editor. Thanks, Jim

2 3

Editing surface/UX: Inline menus
by Erik Moeller 04 May '12

04 May '12

How can we make the Visual Editor as efficient as, or more so than, wikitext editing when it comes to handling complex tasks like citations, templates, etc.? I know it's a bit early to talk about detailed aspects of the editing surface, but this may have some impact on architectural considerations for plug-ins and such, so I wanted to raise it on this list. I don't think it's that much of a stretch goal to be more efficient than wikitext editing for a lot of common cases. For example, using complex templates manually is extremely inefficient, usually requiring a visit to a Template: namespace to read the template documentation, then apply the correct syntax and hope you're not making a typo in the process. A few models: * Wikia's current-generation visual editor offers panels with access to templates and categories, autocompleting as you type. If our goal is to create an editing surface that focuses on the content and gets out of the way (and IMO it should be), these types of panels add clutter which is likely unacceptable. * Most RTE editing surfaces have toolbars, and some also add desktop application style pulldowns. The pulldown/toolbar combination has many known usability issues as software complexity increases -- they become cluttered, and keyboard shortcuts for anything but the stuff you use all the time become hard to remember. * Code IDEs use a lot of hinting/autocompletion based on intelligence gathered from parsing the file you're editing, or any other files. This works well when what gets rendered in the editing surface is identical to what the user is typing. It's easy to auto-complete "myObject.getSomeStuff()", but it's less discoverable that I should start typing "{{Infobox country" to get a beautiful right-aligned table. * vi is the best example of a powerful modal editor which can perform complex operations by essentially entering an in-editor command-line. It's also well-known to be very difficult to learn and master, in large part because its UX is so different from other applications people commonly use. What other models ought to be/are being considered? A couple of ideas: == Inline menus == You could have a menu key, say Ctrl+I or, if we want to be more radical, a single compose key like "\", which triggers an in-editor menu structure with associated keyboard hints. E.g. if the user types <menu key>c, they see an overlay expanding at cursor position: w - cite a website b - cite a book n - cite a newspaper j - cite a journal So by typing: <menu key>cw, I could enter whichever the appropriate dialog is for citing a website (which itself could be rendered in-line if that gives us additional efficiency). This type of system could intelligently trigger auto-completion where appropriate. Say "y" is the shortcut for category, and I type: <menu key>yChurches in <cursor down><cursor down><cursor down><enter/tab> to insert the category "Churches in the United Kingdom". Or say "t" is short for template, so I could type: <menu key>tInfobox a<cursor down><cursor down><enter/tab> to insert the template "Infobox album" and invoke the appropriate dialog. One could make such a feature discoverable by adding hints to the UI in appropriate places, e.g. if the most obvious invocation method is through a tabbed dialog, each dialog could have a small hint indicating how to quickly invoke it inline. == Inline markup completion in visual mode == Another option would be to just intelligently detect use of existing markup, e.g. to magically complete "[[Category:Churches in" or "{{Cite web" or "{{Infobox co" even when in visual mode. This is beneficial for people who already know wiki markup, but is arguably less efficient/user-friendly than a menu/command structure that's designed from scratch to be maximally efficient, discoverable and intuitive. It also would tie us permanently to wiki markup. What do you think? How can we make the visual editing surface maximally efficient for frequent use? All best, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

3 3

Parsoid expanding [[:en:Barack Obama]]
by Gabriel Wicke 03 May '12

03 May '12

Hello, template expansion performance in Parsoid has made great strides recently. [[:en:Barack Obama]] now expands in relatively reasonable time and memory: echo '{{:Barack Obama}}' | time node parse.js > obama.html 42.18user 2.04system 0:46.23elapsed 95%CPU (0avgtext+0avgdata 1528480maxresident)k 848inputs+0outputs (8major+691968minor)pagefaults 0swaps Sample output: http://dev.wikidev.net/gabriel/tmp/obama.html The time utility reports the maximum resident memory inflated by a factor of four (some bug in time afaik), so this works out to 382M resident max which matches with top. This is measured on my Intel i3 M370 laptop, and in the same ballpark as the PHP parser running on the cluster. There are a few tokenizer issues visible in the output. Some of them, such as the Navbox templates near the bottom, contain constructs like this: {{#if:foo|<tr><th><th style="foo;|<th style="}} bar;"> Supporting this would be very messy, so the template should be changed to use a saner nesting: {{#if:foo|<tr><th>|}}<th style="{{#if:foo|foo;|}} bar"> We'll have to analyze how common this kind of mis-nesting is, and if we can perhaps fix this up automatically. See also http://www.mediawiki.org/wiki/Parsoid/Todo#Limitations. Next bigger tasks I intend to tackle: * Add full round-trip information, and preserve it through transformations and DOM tree creation * Call back to action=parse to retrieve information we need from the wiki (link existence, image dimensions, many information-based parser functions and magic words, extensions). * Create a [ DOM -> token -> WikiText ] serializer chain based on the existing serializer in the Visual Editor Gabriel

1 0

offline export of wikitext to slide-like presentation format?
by Tom Roche 26 Apr '12

26 Apr '12

Is there a tool (or a chain) that would allow one to input wikitext and output either * something slidelike (ODP or PDF, suitably formatted) * something that easily converts to something slidelike (e.g., TeX beamer, HTML for Slidy) Why I ask: I have several long pages on a governmental MediaWiki that I used as rough drafts for a presentation, which (after favorable review) I'd like to turn into "real slides." Unfortunately the admins of that MW are notoriously savage, so my chances of getting something installed on the wiki instance, e.g. the mw-slidy extension http://www.mediawiki.org/wiki/Extension:Mw-slidy , are negligible (though I'll ask). Hence I probably need something that converts offline (i.e., not on a MediaWiki); I seek, e.g., a commandline tool such that I can do something like $ magic < input.mediawiki > output.pdf One option is Eclipse Mylyn's WikiText module http://wiki.eclipse.org/Mylyn/Incubator/WikiText but that seems rather heavyweight for this task, since I'm not currently using Eclipse for anything else. I'd prefer something like Deplate http://deplate.sourceforge.net/ but that only inputs the markups={rdoc, viki}, which both seem quite remote from (MediaWiki's) wikitext: i.e., creating a wikitext -> {rdoc, viki} converter seems like more work than writing HTML or TeX by hand. Am I missing something? Care to recommend a candidate app, or Something Completely Different? Your suggestions are appreciated, Tom Roche <Tom_Roche(a)pobox.com>

3 4

Mime-Type for wikitext
by Daniel Kinzler 25 Apr '12

25 Apr '12

Hi all! I just noticed that MediaWiki uses two different mime types for wikitext: * application/x-wiki is used by AjaxResponse, OutputPage and StreamFile. * text/x-wiki is used by RawAction.php (i.e. when you use action=raw) Is there a good reason for this, or is it just an oversight? I suggest to use the same mime type everywhere, and keep the old one for compatibility reasons - i.e. we should use application/x-wiki consistently, and RawAction could support text/x-wiki as an alias. That being said... the *correct* mime type would imho be application/x-mediawiki. But i don't insist on it :) -- daniel

7 9

Lua scripting update
by Sumana Harihareswara 19 Apr '12

19 Apr '12

Just a quick note on how that work is going: https://www.mediawiki.org/wiki/Lua_scripting#Status -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation

1 0

previous WYSIWYG editor: InlineEditor
by Sumana Harihareswara 18 Apr '12

18 Apr '12

I was made aware of work done on an "inline editor" -- see http://www.mediawiki.org/wiki/Extension:InlineEditor and code at http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/InlineEditor/ . This work was done by a team coordinated by GRNET (Greek Research Network), which developed a WYSIWYG editor that produces MediaWiki syntax. I presume that the Visual Editor team (Wikimedia Foundation and Wikia) already know about this work as a predecessor to their own, but just wanted to share it in case it's useful to anyone else while they wait for the Visual Editor. -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation

2 1

WRT previous WYSIWYG editor: InlineEditor
by Panos Louridas 18 Apr '12

18 Apr '12

Regarding the Inline Editor mentioned in today's post by Sumana: (http://www.mediawiki.org/wiki/Extension:InlineEditor http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/InlineEditor/) To give credit where credit is due, the editor was the brainchild of Jan Paul Posma, then a student at Groniger, now a graduate student at Oxford, who coordinated our contribution. GRNET worked together with Jan Paul to carry out improvements as well as an interesting usability study that we presented in last year's Wikimedia Conference in Berlin. We have since stopped working on the project since we were not sure that there was interest for it to be used. However, if there is a possibility that it may be useful in some way, we would be happy to see what could be done, discussing with Jan Paul. Best Regards, Panos Louridas GRNET

1 0

Userscripts for the VisualEditor?
by Jonas Brekle 16 Apr '12

16 Apr '12

Hi, I have not really looked into the code yet, but I just wanted to get your oppinions on the question: Will there be a possiblity to integrate userscripts or other extensions into the VisualEditor? Particulary i would be interested in reusing the Parsoid and retrieve something like "get parent heading from cursor"... I hope that makes sense :) Regards Jonas

2 2

Re: [Wikitext-l] Patch for parser
by Ori Livneh 03 Apr '12

03 Apr '12

Awesome -- thanks! I have a couple of questions to ask, too. These aren't urgent, so feel free to reply whenever you have the time. 1) Conformance vs. enhancement I'm not sure if you saw my comment in the diff, but some of the ISBN validation code I wrote is deliberately unreachable because it's stricter than the naive validation the Mediawiki currently performs. (I stupidly wrote it before checking to see what exactly the current parser does.) In general, is it ever desirable to try and improve on the old parsing grammar or is total conformance the overriding goal? 2) ECMAScript target Should I strive to write code that is compatible with older browsers? Thus far I've avoided ES 1.5 constructs like forEach, map, filter, etc. But if this is only going to run server-side under node for the foreseeable future, maybe that's an unnecessary handicap. 3) Intermediate representation vs. parser hacks The preliminary work I've done to parse behavior switches (__TOC__ & friends) has the parser directly toggle attributes on a configuration object. It does this rather than produce a token for some subsequent tree visitor to interpret. So the parsing is arguably somewhat lossy in this case, but possibly not: when serializing back wikitext, you could read all behaviors from the configuration object and encode them at the top; their position isn't significant, afaik.) So: did I make the right decision? PEG.js's support for arbitrary JavaScript code in the grammar makes this tempting to do sometimes, but perhaps it's wiser to insist that the parser not overreach the goal of building a tree. What is your take? I'm CCing wikitext-l, since your responses are likely to be useful to future contributors. Best, Ori On Mon, Apr 2, 2012 at 12:41 PM, Gabriel Wicke <gwicke(a)wikimedia.org> wrote: > Hi Ori, > > I committed your patch in https://gerrit.wikimedia.org/r/#change,4094. > Looks good, and lets 14 more tests pass ;) Thanks!! > > Gabriel > > > On Mon, Apr 2, 2012 at 9:59 AM, Ori Livneh <ori.livneh(a)gmail.com> wrote: > >> Hey Gabriel, >> >> Working on this on stolen time, as it were, but I do have some modest >> progress to report. The attached patch revises the handling of RFC >> auto-links and adds support for ISBNs, PMID links, and preliminary support >> for behavior switches (things like __TOC__). >> >> I applied for git access, so hopefully I'll have my own branch set up >> soon and we'll be able to do this in a slightly less haphazard way >> >> Hope you've had a nice trip, >> >> Ori >> > >

2 1

← Newer
1
...
7
8
9
10
11
12
13
...
24
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Wikitext-l