Re: [Wikitech-l] From page history to sentence history
On Wed, Jan 19, 2011 at 3:59 AM, Anthony wikim...@inbox.org wrote: Why isn't this being used for the dumps? Well, the relevant code is totally unrelated, so the question is sort of a non sequitur. If you mean Why don't we have incremental dumps?, I guess Ariel is the person to ask. I'm assuming the answer is (as usual in software development) that there are higher-priority things to do right now. The concept of incremental dumps is pretty obvious, but that doesn't mean it wouldn't take some manpower to get them working. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] helping in WYSIWYG editor efforts
On Mon, Jan 17, 2011 at 1:47 PM, Panos Louridas louri...@grnet.gr wrote: Hi, At the Greek Research and Education Network (GRNET) we look at the possibility of contributing to the development of WYSIWYG editor support in Wikipedia. We understand that considerable work has already taken place in the area, e.g.: * http://www.mediawiki.org/wiki/WYSIFTW * https://svn.wikia-code.com/wikia/trunk/extensions/wikia/RTE/ * http://www.mediawiki.org/wiki/User:JanPaul123/Sentence-level_editing We therefore think that it will not be productive to reinvent the wheel over here. Our contribution can take the form of providing developers that will devote part (or all) of their time for some months in 2011. We welcome any comments and suggestions on how we could push this forward, and in particular: * Specific tasks / components that need to be designed, developed, optimized, etc., and estimates of effort and timeframe. Hi Panos, a very generous offer! One I would like to take you up on, for WYSIFTW as you no doubt have guessed :-) WYSIFTW is approaching feature completeness, as far as wiki markup parsing is concerned, and improves on usability as well. (just try the new floating context hover boxes, in lack of a better name, that I added last night, wich come up when you hover over a template or a references, for show/hide and rendered preview, and the new optional rendering for templates as a key-value-pair table) For support later this year, tasks would include * increase parsing performance (mostly post-parsing steps, focusing on DOM lookup and manipulation) * improve editing usability (cut/copy/paste, better specialised dialogs for images, table/row/cell properties etc.) * usability testing (I'm using up volunteers fast ;-) * creating a test suite (to make sure that changes don't accidentally break anything) * general compatibility testing (find pages that parse/unparse wrongly, and patch the code accordingly) I like the sentence-level editing function, but once I add section-level editing to WYSIFTW, these two will start to converge. I'm curious which of these will be more suited to small fixes and adding single sentences/references etc. As for RTE, I know little about. Apparently, it is not suitable for Wikipedia in its current form. From brief looks at CKeditor, it might be quite some work to make it behave nicely around parsed wikitext, as used on Wikipedia. Cheers, Magnus ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] MATH markup question
I am dipping my toe in MATH for the first time and finding the results somewhat curious. They key appears to be this statement: It generates either PNG images or simple HTML markup, depending on user preferences and the complexity of the expression. Consider the formulas here: http://en.wikipedia.org/wiki/Spherical_tokamak Is there any hope that the PNG and HTML versions of things might be made to look more similar? The characters don't even look the same in some cases (kappa for instance) and this leads to VERY confusing output. Maury ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FYI : Commons thumbnails slow
On Wed, Jan 19, 2011 at 2:17 AM, MZMcBride z...@mzmcbride.com wrote: Krinkle wrote: There's a bot in #wikimedia-toolserver reporting activity on [toolserver-l], I'll see if I can get a similar thing going for [wikitech-l]. In which channel would we want this though ? I assume #wikimedia-tech although, like Ryan said about dev/ops related, perhaps better in #wikimedia-dev (or both?) I run the bot you're talking about in #wikimedia-toolserver. Her name is Reba and she's a fine and mostly reliable lady. I don't imagine anyone wants a bot in #wikimedia-tech or #wikimedia-dev. It's noisy and largely pointless (spamming every reply to a thread about threatening to rewrite the parser to an IRC channel doesn't help anything or anyone). We need a better system for (power-)users to report site problems. Something that doesn't involve a mailing list, but something that likely has an IRC component (given that most of the ops idle there). A clean web UI -- IRC system could possibly work, but any system like that is open to abuse and misuse. As I wrote in my earlier mail, posting each new thread subject, that is, when a new thread gets started, on IRC. That would be, what, five new threads per day on average? The channel must be very quiet indeed, if that's considered spam :-) Cheers, Magnus ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MATH markup question
2011/1/19 Maury Markowitz maury.markow...@gmail.com I am dipping my toe in MATH for the first time and finding the results somewhat curious. They key appears to be this statement: It generates either PNG images or simple HTML markup, depending on user preferences and the complexity of the expression. Consider the formulas here: http://en.wikipedia.org/wiki/Spherical_tokamak Is there any hope that the PNG and HTML versions of things might be made to look more similar? The characters don't even look the same in some cases (kappa for instance) and this leads to VERY confusing output. You can force png rendering both by preferences and by code. But what's more interesting is the use of badly documented \scriptstyle TeX tag, which generates a much smaller and less invasive display of pngs: se this recent talk into en.source: http://en.wikisource.org/wiki/Wikisource:Scriptorium#Help.21_.28fractions_and_TeX_formatting.29 Alex brollo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MATH markup question
2011/1/19 Alex Brollo alex.bro...@gmail.com 2011/1/19 Maury Markowitz maury.markow...@gmail.com I am dipping my toe in MATH for the first time and finding the results somewhat curious. They key appears to be this statement: It generates either PNG images or simple HTML markup, depending on user preferences and the complexity of the expression. Consider the formulas here: http://en.wikipedia.org/wiki/Spherical_tokamak Is there any hope that the PNG and HTML versions of things might be made to look more similar? The characters don't even look the same in some cases (kappa for instance) and this leads to VERY confusing output. You can force png rendering both by preferences and by code. But what's more interesting is the use of badly documented \scriptstyle TeX tag, which generates a much smaller and less invasive display of pngs: se this recent talk into en.source: http://en.wikisource.org/wiki/Wikisource:Scriptorium#Help.21_.28fractions_and_TeX_formatting.29 Alex brollo I added some \scriptstyle tags into inline expressions, and I discovered that they force png too, while giving a smaller (better in my opinion) display of tha formulae. feel free to rollback! It's a test only. Alex brollo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] helping in WYSIWYG editor efforts
A very generous offer indeed! My own SLE and Magnus' WYSIFTW are indeed the most active projects, so that would be a good bet. Actually, for me the timing is just right, as I'll be working on a paper about this editor for a while, so it'd be cool to have someone(s) continue the project. If one of your researchers has a brilliant idea on how to do this right, that would obviously be really valuable too. A lot of things Magnus mentioned apply to my project too: * Improving detection algorithms, i.e. better sentence-level editing (perhaps using an external language recognition library), better detection of other elements. Keep in mind that the editor excludes anything it doesn't 'understand', so this is a nice fallback, you don't have to write a complex parser that detects a lot of stuff at once. * Cross-browser/platform/device compatibility (think mobile, touchscreens, etc.) * Usability testing (the more the merrier!) * Verifying detection coverage (Which % of the wikitext is editable) and quality (Wikitext - Adding markers - MediaWiki parser - Removing markings - Wikitext??) Checking this on a large number of pages. * Test suites (again, the more the merrier, but only for parts of the code and interface that are considered stable!) * Lots of implementation details: embedding the (current) editor toolbar in the textboxes, making sure (a fair percentage of) gadgets still work with this, and handling unusual cases like edit conflicts, etc. Perhaps it'd be good to have a (video or IRC?) conversation with you, your developers, people from the Foundation, and people from the specific projects you want to contribute to. Again, really awesome that you guys want to work on this! :-) Best regards, Jan Paul On 19-Jan-2011, at 9:55, Magnus Manske wrote: On Mon, Jan 17, 2011 at 1:47 PM, Panos Louridas louri...@grnet.gr wrote: Hi, At the Greek Research and Education Network (GRNET) we look at the possibility of contributing to the development of WYSIWYG editor support in Wikipedia. We understand that considerable work has already taken place in the area, e.g.: * http://www.mediawiki.org/wiki/WYSIFTW * https://svn.wikia-code.com/wikia/trunk/extensions/wikia/RTE/ * http://www.mediawiki.org/wiki/User:JanPaul123/Sentence-level_editing We therefore think that it will not be productive to reinvent the wheel over here. Our contribution can take the form of providing developers that will devote part (or all) of their time for some months in 2011. We welcome any comments and suggestions on how we could push this forward, and in particular: * Specific tasks / components that need to be designed, developed, optimized, etc., and estimates of effort and timeframe. Hi Panos, a very generous offer! One I would like to take you up on, for WYSIFTW as you no doubt have guessed :-) WYSIFTW is approaching feature completeness, as far as wiki markup parsing is concerned, and improves on usability as well. (just try the new floating context hover boxes, in lack of a better name, that I added last night, wich come up when you hover over a template or a references, for show/hide and rendered preview, and the new optional rendering for templates as a key-value-pair table) For support later this year, tasks would include * increase parsing performance (mostly post-parsing steps, focusing on DOM lookup and manipulation) * improve editing usability (cut/copy/paste, better specialised dialogs for images, table/row/cell properties etc.) * usability testing (I'm using up volunteers fast ;-) * creating a test suite (to make sure that changes don't accidentally break anything) * general compatibility testing (find pages that parse/unparse wrongly, and patch the code accordingly) I like the sentence-level editing function, but once I add section-level editing to WYSIFTW, these two will start to converge. I'm curious which of these will be more suited to small fixes and adding single sentences/references etc. As for RTE, I know little about. Apparently, it is not suitable for Wikipedia in its current form. From brief looks at CKeditor, it might be quite some work to make it behave nicely around parsed wikitext, as used on Wikipedia. Cheers, Magnus ___ 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] From page history to sentence history
On Wed, Jan 19, 2011 at 3:33 AM, Aryeh Gregor simetrical+wikil...@gmail.com wrote: On Wed, Jan 19, 2011 at 3:59 AM, Anthony wikim...@inbox.org wrote: Why isn't this being used for the dumps? Well, the relevant code is totally unrelated, so the question is sort of a non sequitur. No, the question is why the relevant code is totally unrelated. Specifically, I'm talking about the full history dumps. If you mean Why don't we have incremental dumps? No, that's not the question. The question is why are you uncompressing and undiffing (from DiffHistoryBlobs) only to recompress (to bz2) and then uncompress and recompress (to 7z) when you can get roughly the same compression by just extracting the blobs and removing any non-public data. Or, if it's easier, continue to uncompress (in gz) and undiff then rediff and recompress (in gz), as that will be much much faster than compressing in bz2. You'll also wind up with a full history dump which is *much* easier to work with. Yes, you'll break backward compatibility, but considering that the English full history dump never finishes, even if you just implemented it for that one it'd be better than the present, which is to have nothing. I'm assuming the answer is (as usual in software development) that there are higher-priority things to do right now. And there are lots of lower-priority things that are being done. And lots of dollars sitting on the sidelines doing nothing. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FYI : Commons thumbnails slow
Magnus Manske wrote: As I wrote in my earlier mail, posting each new thread subject, that is, when a new thread gets started, on IRC. That would be, what, five new threads per day on average? The channel must be very quiet indeed, if that's considered spam :-) It'd likely be a lot more than five if it were the encouraged form of error reporting. There are the (pre-existing) users of this mailing list to consider as well. When you add a bunch of noise (site down, site down 2, re: site down 2 [it was just my connection lol]), you drown out the signal. Obviously when _you_ report an issue, it holds a lot more weight than if anyone who can figure out how a mailing list works reports an issue. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WYSIFTW status
On Mon, Jan 17, 2011 at 10:18 PM, Maciej Jaros e...@wp.pl wrote: Aryeh Gregor (2011-01-17 17:31): On Sun, Jan 16, 2011 at 7:16 PM, Magnus Manske magnusman...@googlemail.com wrote: There is the question of what browsers/versions to test for. Should I invest large amounts of time optimising performance in Firefox 3, when FF4 will probably be released before WYSIFTW, and everyone and their cousin upgrades? Design for only the fastest browsers. Other browsers could always just be dropped back to the old-fashioned editor. +1 IMHO on some later stage (after optimizing and testing) you should think about quickly dropping to either simple version of the editor (e.g. only folding ref) or to the plain textarea version. Also old versions of browser might benefit a lot by not using jQuery too much (IIRC Google JS engine was the first to be optimized for frameworks like jQuery and that is why it behaves better). Maybe also some hint for users might be given that their browser/machine is too slow for more advanced editor on whole page and that they might want to edit a single section... Thanks. Most options (bold/italics, links, HTML/references, images, tables) can already be configured separately before parsing. This can be linked to browser sniffing to reduce parse time in older browsers at the expense of nice layout. It could also be a user option. OTOH, it might not be necessary: I just added section editing (including intro section 0). The section can be edited in place, and cancel will show the original HTML without having to reload the page. On my usual test article [[Paris]], the slowest section (History) parses in ~5 sec (Firefox 3.6.13, MacBook Pro). Chrome 10 takes 2 seconds. I believe these will already be acceptable to average users; optimisation should improve that further. Cheers, Magnus ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FYI : Commons thumbnails slow
On Wed, Jan 19, 2011 at 12:06 AM, Magnus Manske magnusman...@googlemail.com wrote: (here I am again, throwing tech solutions at social problems...) The non-technical solution would be for wikitech-l/#wikimedia-tech regulars to start poking people at IRC when error reports come in on the mailing list. The nice thing about this is that people are pretty good at noise filtering. Bryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] helping in WYSIWYG editor efforts
Thanks to both Jean Paul and Magnus for taking up the offer! Based on your input I will look into our developer tool for people with expertise in the following: * Advanced JS, preferably with experience in optimisation issues etc. * UI design, usability testing, etc. * Text processing (of sorts) for the needs of SLE (if you believe I am missing something, say so) I expect to have the people in place in February, I will let you know. I will be following the list. Jean Paul indicated that we might talk in more detail. I do not follow IRC because of my tight schedule; I do use Skype, however (ID: louridas). Please Jean Paul, Magnus, and others, let me know if that suits you. As I am located in Athens, my waking hours are around East European Time. Cheers, Panos. On Jan 19, 2011, at 3:54 PM, Jan Paul Posma wrote: A very generous offer indeed! My own SLE and Magnus' WYSIFTW are indeed the most active projects, so that would be a good bet. Actually, for me the timing is just right, as I'll be working on a paper about this editor for a while, so it'd be cool to have someone(s) continue the project. If one of your researchers has a brilliant idea on how to do this right, that would obviously be really valuable too. A lot of things Magnus mentioned apply to my project too: * Improving detection algorithms, i.e. better sentence-level editing (perhaps using an external language recognition library), better detection of other elements. Keep in mind that the editor excludes anything it doesn't 'understand', so this is a nice fallback, you don't have to write a complex parser that detects a lot of stuff at once. * Cross-browser/platform/device compatibility (think mobile, touchscreens, etc.) * Usability testing (the more the merrier!) * Verifying detection coverage (Which % of the wikitext is editable) and quality (Wikitext - Adding markers - MediaWiki parser - Removing markings - Wikitext??) Checking this on a large number of pages. * Test suites (again, the more the merrier, but only for parts of the code and interface that are considered stable!) * Lots of implementation details: embedding the (current) editor toolbar in the textboxes, making sure (a fair percentage of) gadgets still work with this, and handling unusual cases like edit conflicts, etc. Perhaps it'd be good to have a (video or IRC?) conversation with you, your developers, people from the Foundation, and people from the specific projects you want to contribute to. Again, really awesome that you guys want to work on this! :-) Best regards, Jan Paul On 19-Jan-2011, at 9:55, Magnus Manske wrote: On Mon, Jan 17, 2011 at 1:47 PM, Panos Louridas louri...@grnet.gr wrote: Hi, At the Greek Research and Education Network (GRNET) we look at the possibility of contributing to the development of WYSIWYG editor support in Wikipedia. We understand that considerable work has already taken place in the area, e.g.: * http://www.mediawiki.org/wiki/WYSIFTW * https://svn.wikia-code.com/wikia/trunk/extensions/wikia/RTE/ * http://www.mediawiki.org/wiki/User:JanPaul123/Sentence-level_editing We therefore think that it will not be productive to reinvent the wheel over here. Our contribution can take the form of providing developers that will devote part (or all) of their time for some months in 2011. We welcome any comments and suggestions on how we could push this forward, and in particular: * Specific tasks / components that need to be designed, developed, optimized, etc., and estimates of effort and timeframe. Hi Panos, a very generous offer! One I would like to take you up on, for WYSIFTW as you no doubt have guessed :-) WYSIFTW is approaching feature completeness, as far as wiki markup parsing is concerned, and improves on usability as well. (just try the new floating context hover boxes, in lack of a better name, that I added last night, wich come up when you hover over a template or a references, for show/hide and rendered preview, and the new optional rendering for templates as a key-value-pair table) For support later this year, tasks would include * increase parsing performance (mostly post-parsing steps, focusing on DOM lookup and manipulation) * improve editing usability (cut/copy/paste, better specialised dialogs for images, table/row/cell properties etc.) * usability testing (I'm using up volunteers fast ;-) * creating a test suite (to make sure that changes don't accidentally break anything) * general compatibility testing (find pages that parse/unparse wrongly, and patch the code accordingly) I like the sentence-level editing function, but once I add section-level editing to WYSIFTW, these two will start to converge. I'm curious which of these will be more suited to small fixes and adding single sentences/references etc. As for RTE, I know little about. Apparently, it is not suitable for Wikipedia in its current
Re: [Wikitech-l] From page history to sentence history
masti wrote: On 01/18/2011 12:30 AM, Lars Aronsson wrote: On 01/17/2011 11:36 PM, masti wrote: what is the reason and what it can bring to the community? I tried to describe this. The task of finding out the history of a part of an article is very time consuming for long articles with a long history, where you have to manually look through lots of revisions that aren't related to the part of the article you are interested in. I took as the example the part of the flat geography of the city of Paris. Was this part controversial? Who edited it? Has it changed? When and by whom? Most edits to the article Paris are probably related to new elections, new buildings, new institutions. Most edits have nothing to do with the flat geography. So could the history view of maybe 5000 edits be quickly reduced down to 50 edits or even 5? In this rare situation it could be beneficial, but does it really make sense in general? Workload and complication of interface, in my opinion, is not worth it. masti I think it makes sense, but more as an external tool which selected them for you. There are tools like http://wikipedia.ramselehof.de/wikiblame.php which aim to do these things, but although I don't think they are so good, they may be a good place to start. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WYSIFTW status
Magnus Manske wrote: On my usual test article [[Paris]], the slowest section (History) parses in ~5 sec (Firefox 3.6.13, MacBook Pro). Chrome 10 takes 2 seconds. I believe these will already be acceptable to average users; optimisation should improve that further. Cheers, Magnus What about long tables? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] helping in WYSIWYG editor efforts
Skype sounds great! Also, I heard you work with Ariel, which is great because that way you have a more local person to contact with MediaWiki questions. Perhaps we can get off-list with those interested to schedule an introductory meeting? (You, me, Magnus, Ariel, others?) I am located in the Netherlands, so our hours will be similar. Cheers, Jan Paul On 19-Jan-2011, at 19:47, Panos Louridas wrote: Thanks to both Jean Paul and Magnus for taking up the offer! Based on your input I will look into our developer tool for people with expertise in the following: * Advanced JS, preferably with experience in optimisation issues etc. * UI design, usability testing, etc. * Text processing (of sorts) for the needs of SLE (if you believe I am missing something, say so) I expect to have the people in place in February, I will let you know. I will be following the list. Jean Paul indicated that we might talk in more detail. I do not follow IRC because of my tight schedule; I do use Skype, however (ID: louridas). Please Jean Paul, Magnus, and others, let me know if that suits you. As I am located in Athens, my waking hours are around East European Time. Cheers, Panos. On Jan 19, 2011, at 3:54 PM, Jan Paul Posma wrote: A very generous offer indeed! My own SLE and Magnus' WYSIFTW are indeed the most active projects, so that would be a good bet. Actually, for me the timing is just right, as I'll be working on a paper about this editor for a while, so it'd be cool to have someone(s) continue the project. If one of your researchers has a brilliant idea on how to do this right, that would obviously be really valuable too. A lot of things Magnus mentioned apply to my project too: * Improving detection algorithms, i.e. better sentence-level editing (perhaps using an external language recognition library), better detection of other elements. Keep in mind that the editor excludes anything it doesn't 'understand', so this is a nice fallback, you don't have to write a complex parser that detects a lot of stuff at once. * Cross-browser/platform/device compatibility (think mobile, touchscreens, etc.) * Usability testing (the more the merrier!) * Verifying detection coverage (Which % of the wikitext is editable) and quality (Wikitext - Adding markers - MediaWiki parser - Removing markings - Wikitext??) Checking this on a large number of pages. * Test suites (again, the more the merrier, but only for parts of the code and interface that are considered stable!) * Lots of implementation details: embedding the (current) editor toolbar in the textboxes, making sure (a fair percentage of) gadgets still work with this, and handling unusual cases like edit conflicts, etc. Perhaps it'd be good to have a (video or IRC?) conversation with you, your developers, people from the Foundation, and people from the specific projects you want to contribute to. Again, really awesome that you guys want to work on this! :-) Best regards, Jan Paul On 19-Jan-2011, at 9:55, Magnus Manske wrote: On Mon, Jan 17, 2011 at 1:47 PM, Panos Louridas louri...@grnet.gr wrote: Hi, At the Greek Research and Education Network (GRNET) we look at the possibility of contributing to the development of WYSIWYG editor support in Wikipedia. We understand that considerable work has already taken place in the area, e.g.: * http://www.mediawiki.org/wiki/WYSIFTW * https://svn.wikia-code.com/wikia/trunk/extensions/wikia/RTE/ * http://www.mediawiki.org/wiki/User:JanPaul123/Sentence-level_editing We therefore think that it will not be productive to reinvent the wheel over here. Our contribution can take the form of providing developers that will devote part (or all) of their time for some months in 2011. We welcome any comments and suggestions on how we could push this forward, and in particular: * Specific tasks / components that need to be designed, developed, optimized, etc., and estimates of effort and timeframe. Hi Panos, a very generous offer! One I would like to take you up on, for WYSIFTW as you no doubt have guessed :-) WYSIFTW is approaching feature completeness, as far as wiki markup parsing is concerned, and improves on usability as well. (just try the new floating context hover boxes, in lack of a better name, that I added last night, wich come up when you hover over a template or a references, for show/hide and rendered preview, and the new optional rendering for templates as a key-value-pair table) For support later this year, tasks would include * increase parsing performance (mostly post-parsing steps, focusing on DOM lookup and manipulation) * improve editing usability (cut/copy/paste, better specialised dialogs for images, table/row/cell properties etc.) * usability testing (I'm using up volunteers fast ;-) * creating a test suite (to make sure that changes don't accidentally break anything) *
Re: [Wikitech-l] MATH markup question
On Wed, Jan 19, 2011 at 8:54 AM, Alex Brollo alex.bro...@gmail.com wrote:
You can force png rendering both by preferences and by code. But what's
more interesting is the use of badly documented \scriptstyle TeX tag, which
generates a much smaller and less invasive display of pngs:
The use of scriptstyle to control font size is an ugly hack that makes
many formulas less readable. For example, math2^{A_C}\,/math and
math2^{A}C\,/math become much harder to distinguish in
scriptstyle.
In a custom installation, you can tweak the font size in images by
changing the value of the -D parameter in line 8 of render.ml and
recompiling texvc.
The ideal solution for Wikipedia would be to move to a system in which
users with relatively modern browsers don't see images at all. There
is already a candidate for that system: MathJax. This has extensive
browser compatibility [1] and is actively maintained, with some
big-name sponsors behind it [2]. The main difficulties enabling it on
WIkipedia would be configuration and checking for any inconsistencies
with texvc (so the main limitation is developer interest). On a
custom install without a huge base of existing text, you could
probably just use Extension:MathJax, although I haven't tried it.
- Carl
1: http://www.mathjax.org/resources/browser-compatibility/
2: http://www.mathjax.org/sponsors/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MATH markup question
Wow, thanks for the pointer Carl, MathJax is impressive. Alex, your work is appreciated, but I'm not sure exactly what I'm seeing. Can you point me in the right direction to read up a bit more? Maury ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] helping in WYSIWYG editor efforts
I have added Panos to Skype; yes, we should probably exchange Skype handles off-list. I am in Cambridge (London time), so that should work. Cheers, Magnus On Wed, Jan 19, 2011 at 8:34 PM, Jan Paul Posma jp.po...@gmail.com wrote: Skype sounds great! Also, I heard you work with Ariel, which is great because that way you have a more local person to contact with MediaWiki questions. Perhaps we can get off-list with those interested to schedule an introductory meeting? (You, me, Magnus, Ariel, others?) I am located in the Netherlands, so our hours will be similar. Cheers, Jan Paul On 19-Jan-2011, at 19:47, Panos Louridas wrote: Thanks to both Jean Paul and Magnus for taking up the offer! Based on your input I will look into our developer tool for people with expertise in the following: * Advanced JS, preferably with experience in optimisation issues etc. * UI design, usability testing, etc. * Text processing (of sorts) for the needs of SLE (if you believe I am missing something, say so) I expect to have the people in place in February, I will let you know. I will be following the list. Jean Paul indicated that we might talk in more detail. I do not follow IRC because of my tight schedule; I do use Skype, however (ID: louridas). Please Jean Paul, Magnus, and others, let me know if that suits you. As I am located in Athens, my waking hours are around East European Time. Cheers, Panos. On Jan 19, 2011, at 3:54 PM, Jan Paul Posma wrote: A very generous offer indeed! My own SLE and Magnus' WYSIFTW are indeed the most active projects, so that would be a good bet. Actually, for me the timing is just right, as I'll be working on a paper about this editor for a while, so it'd be cool to have someone(s) continue the project. If one of your researchers has a brilliant idea on how to do this right, that would obviously be really valuable too. A lot of things Magnus mentioned apply to my project too: * Improving detection algorithms, i.e. better sentence-level editing (perhaps using an external language recognition library), better detection of other elements. Keep in mind that the editor excludes anything it doesn't 'understand', so this is a nice fallback, you don't have to write a complex parser that detects a lot of stuff at once. * Cross-browser/platform/device compatibility (think mobile, touchscreens, etc.) * Usability testing (the more the merrier!) * Verifying detection coverage (Which % of the wikitext is editable) and quality (Wikitext - Adding markers - MediaWiki parser - Removing markings - Wikitext??) Checking this on a large number of pages. * Test suites (again, the more the merrier, but only for parts of the code and interface that are considered stable!) * Lots of implementation details: embedding the (current) editor toolbar in the textboxes, making sure (a fair percentage of) gadgets still work with this, and handling unusual cases like edit conflicts, etc. Perhaps it'd be good to have a (video or IRC?) conversation with you, your developers, people from the Foundation, and people from the specific projects you want to contribute to. Again, really awesome that you guys want to work on this! :-) Best regards, Jan Paul On 19-Jan-2011, at 9:55, Magnus Manske wrote: On Mon, Jan 17, 2011 at 1:47 PM, Panos Louridas louri...@grnet.gr wrote: Hi, At the Greek Research and Education Network (GRNET) we look at the possibility of contributing to the development of WYSIWYG editor support in Wikipedia. We understand that considerable work has already taken place in the area, e.g.: * http://www.mediawiki.org/wiki/WYSIFTW * https://svn.wikia-code.com/wikia/trunk/extensions/wikia/RTE/ * http://www.mediawiki.org/wiki/User:JanPaul123/Sentence-level_editing We therefore think that it will not be productive to reinvent the wheel over here. Our contribution can take the form of providing developers that will devote part (or all) of their time for some months in 2011. We welcome any comments and suggestions on how we could push this forward, and in particular: * Specific tasks / components that need to be designed, developed, optimized, etc., and estimates of effort and timeframe. Hi Panos, a very generous offer! One I would like to take you up on, for WYSIFTW as you no doubt have guessed :-) WYSIFTW is approaching feature completeness, as far as wiki markup parsing is concerned, and improves on usability as well. (just try the new floating context hover boxes, in lack of a better name, that I added last night, wich come up when you hover over a template or a references, for show/hide and rendered preview, and the new optional rendering for templates as a key-value-pair table) For support later this year, tasks would include * increase parsing performance (mostly post-parsing steps, focusing on DOM lookup and manipulation) * improve editing usability (cut/copy/paste, better
Re: [Wikitech-l] From page history to sentence history
Anthony wikim...@inbox.org wrote in message news:AANLkTi=uk+uf3y_b+zld57wcfuef_7rf-bt8tnvtg...@mail.gmail.com... No, that's not the question. The question is why are you uncompressing and undiffing (from DiffHistoryBlobs) only to recompress (to bz2) and then uncompress and recompress (to 7z) when you can get roughly the same compression by just extracting the blobs and removing any non-public data. That's probably not nearly as straightforward as it sounds. RevDel'd and suppressed revisions are not removed from the text storage; even Oversighted revisions are left there, only the entry in the revision table is removed or altered. I don't know OTTOMH how regularly the DiffHistoryBlob system stores a 'key frame', and how easy it would be to break diff chains in order to snip out non-public data from them, but I'd guess a) not very, and b) that the current code doesn't give any consideration to doing so because there's no reason for it to do so. So refactoring it to incorporate that, while not impossible, is a non-trivial amount of work. And there are lots of lower-priority things that are being done. And lots of dollars sitting on the sidelines doing nothing. Low-priority interesting things tend to get done when you have volunteers doing them. While the value of some of the Foundation's expenditure is commonly debated, I think you'd struggle to argue that many of the WMF's dollars are not doing *anything*. --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Best way to track RELEASE-NOTES changes each svn update?
C On Sun, Jan 16, 2011 at 7:16 PM, Happy-melon happy-me...@live.com wrote: Isn't that what release notes are for? Say, how do you pros see what changed? Here is my extra stupid way. I do it every few weeks. cp RELEASE-NOTES /tmp svn update diff --ignore-space-change -U0 /tmp RELEASE-NOTES Often old lines are shown again, because somebody tidied their formatting. A svn diff wouldn't be any better. The worst thing is each 1.17 to 1.18, 1.18 to 1.19 change, when the whole file changes. So how do you folks track RELEASE-NOTES level changes (not source code level changes, too many), coinciding with your SVN updates? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] From page history to sentence history
On Wed, Jan 19, 2011 at 7:49 PM, Happy-melon happy-me...@live.com wrote: Anthony wikim...@inbox.org wrote in message news:AANLkTi=uk+uf3y_b+zld57wcfuef_7rf-bt8tnvtg...@mail.gmail.com... No, that's not the question. The question is why are you uncompressing and undiffing (from DiffHistoryBlobs) only to recompress (to bz2) and then uncompress and recompress (to 7z) when you can get roughly the same compression by just extracting the blobs and removing any non-public data. That's probably not nearly as straightforward as it sounds. I have no idea how straightforward it sounds, so I won't argue with that. RevDel'd and suppressed revisions are not removed from the text storage; even Oversighted revisions are left there, only the entry in the revision table is removed or altered. I don't know OTTOMH how regularly the DiffHistoryBlob system stores a 'key frame', and how easy it would be to break diff chains in order to snip out non-public data from them, but I'd guess a) not very, and b) that the current code doesn't give any consideration to doing so because there's no reason for it to do so. So refactoring it to incorporate that, while not impossible, is a non-trivial amount of work. It wouldn't be trivial, but it wouldn't be particularly hard either. Most of the work is already being done. It's just being done inefficiently. On Wed, Jan 19, 2011 at 7:49 PM, Happy-melon happy-me...@live.com wrote: And there are lots of lower-priority things that are being done. And lots of dollars sitting on the sidelines doing nothing. Low-priority interesting things tend to get done when you have volunteers doing them. While the value of some of the Foundation's expenditure is commonly debated, I think you'd struggle to argue that many of the WMF's dollars are not doing *anything*. Last I checked there were millions of them sitting in the bank. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Best way to track RELEASE-NOTES changes each svn update?
On Wed, Jan 19, 2011 at 8:55 PM, jida...@jidanni.org wrote: So how do you folks track RELEASE-NOTES level changes (not source code level changes, too many), coinciding with your SVN updates? I don't follow release notes, I'm subscribed to mediawiki-cvs. It's way more informative. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MATH markup question
2011/1/19 Maury Markowitz maury.markow...@gmail.com Wow, thanks for the pointer Carl, MathJax is impressive. Alex, your work is appreciated, but I'm not sure exactly what I'm seeing. Can you point me in the right direction to read up a bit more? Don't care, throw away my suggestions and ask Carl. Ubi major minor cessat! :-) Alex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
