On Thu, Jun 9, 2011 at 7:19 AM, Mihály Héder <span dir="ltr">&lt;<a href="mailto:hedermisi@gmail.com" target="_blank">hedermisi@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Dear Wikitext experts,<br>
<br>
please, check out Sztakipedia, a new Wiki RTE at:<br>
<a href="http://pedia.sztaki.hu/" target="_blank">http://pedia.sztaki.hu/</a> (please check the video first, and then the tool itself)<br></blockquote><div>[snip]<br><br>That&#39;s
 really cool! The analysis &amp; interactive suggestion tools are 
especially interesting; some of those can be the sorts of tools that 
could really aid in certain kinds of article editing, as well as for 
other uses like doing research or more educational-focused work where 
pulling information from other parts of the wiki resources would be 
useful.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
Our plan right now is to create an API for our recommendation services<br>
and helpers and a MediaWiki js plugin to get its results to the<br>
current wiki editor. This way I hope the results of this research -<br>
which started out as a rather theoretical one - will be used in a real<br>
world scenario by at least a few people. I hope we will be able to<br>
extend the your planned new RTE the same way in the future.<br></blockquote><div><br>Awesome!
 I would definitely love to see that happen; while we&#39;re still in early 
phases on the parser itself we&#39;re also starting to work on the editor 
integration API, so somewhere down the road we should have a standardish
 way to plug some of that in.<br>
<br><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br>
Please, share with me your thoughs/comments/doubts about Sztakipedia.<br>
<br>
Also I wanted to ask some things:<br>
-Which is the most wanted helper feature according to you:<br>
infobox/category/link recommendation? External data import from the<br>
Linked Open Data? (Like our Book Recommender right now which has<br>
millions of book records in it?) Field _value_ recommendation for<br>
infoboxes from the text? Other?<br></blockquote><div><br>We&#39;ll need to collect a little more reactions from users probably, but offhand I can definitely see real use for:<br>*
 helper tool for making references/citations (those book records sound 
like they could really help in looking up info &amp; formatting a book 
or periodical reference!)<br>
* suggestion of which infobox-style templates and categories to apply to
 a page based on content &amp; already-found related pages -- we have 
such a *huge* array of templates and categories on the big Wikipedias, 
and it&#39;s easy to not know where to look. Having something that suggests 
&#39;infobox-city&#39; to you when you&#39;re pretty clearly writing about a city 
could be a lot more useful than a simple typeahead list... it could even
 suggest it before the user knows to look for it!<br>
<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
-How do you measure the performance of a parser? I saw hints to some<br>
300 parser test cases somewhere...<br></blockquote><div><br>We have 
parser regression test cases in tests/parser/parserTests.txt (in 
maintenance/ on older released versions), but for performance testing 
you&#39;d want to use some real-world articles.<br>
<br>Roughly speaking, you want to get some idea of both _average cases_ 
and _worst cases_. Overall server load is ruled by the average case, but
 it&#39;s the worst cases -- the slowest pages to render -- that have the 
most impact on user experience.<br>
<br>* grab a few dozen or hundred articles as a general subset (possibly weighted by popularity?)<br>* grab several of the largest, most complex articles from english wikipedia<br><br>There
 tends to be at least some overlap here. ;) Large numbers of template 
invocations, large numbers of images, and large numbers of parser 
functions &amp; tag extensions are usually the worst cases. Individual 
templates can also hide a lot of complexity that&#39;s not obvious from 
looking at the source of the base page.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
-Which is the best way to mash up external services to support the Wiki editor<br>
interface (because if you call an external REST service from JS in mediawiki, it<br>
will be cross-site scripting I&#39;m afraid)?<br></blockquote><br>If 
the JS can call via JSONP (executing via &lt;script&gt; and using a 
callback to pass data back to the caller), that should be fine. It&#39;s 
also possible to use cross-origin permission headers eg <a href="http://www.w3.org/TR/cors/" target="_blank">http://www.w3.org/TR/cors/</a><br>
<br>-- brion