Re: [Wikitech-l] relocating search servers
Hi all, The relocation process took more than we anticipated, so it now looks like the situation is going to continue throughout the day today. Towards the afternoon/evening various wikis are going to be gradually restored to normal. Cheers, Robert On 12/08/10 22:27, Robert Stojnic wrote: Hi all, We are currently relocating some servers internally in the datacenter. As a consequence, search snippets, did you mean... and interwiki search are going to be turned off during this time, and only bare results shown. This will affect all WMF wikis. I expect, if everything goes well, that in around 4-5h things are going to go back to normal. Cheers, Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikisource books and web 1.0 pages (was: pas de sujet)
On 13 August 2010 10:27, Lars Aronsson l...@aronsson.se wrote: ... If we applied this web 2.0 principle to Wikibooks and Wikisource, we wouldn't need to have pages with previous/next links. We could just have smooth, continuous scrolling in one long sequence. Readers could still arrive at a given coordinate (chapter or page), but continue from there in any direction. Examples of such user interfaces for books are Google Books and the Internet Archive online reader. You can link to page 14 like this: http://books.google.com/books?id=Z_ZLMAAJpg=PA14 and then scroll up (to page 13) or down (to page 15). The whole book is never in your browser. New pages are AJAX loaded as they are needed. You are not thinking web here. The web way to solve a problem like easy access to next page or different chapters is to have a next page link or have all the chapters as tabs, or something like that. Make the wiki aware of the structure of a book, and make it render these nextpage link / chapters tabs. Web 2.0 is obsolete now, the future is Web 3.5 ( CSS3, HTML5) (-: -- -- ℱin del ℳensaje. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikisource books and web 1.0 pages
Interesting. You might want to have a look at Microsoft's Seadragon technology : http://www.dailymotion.com/video/x2738e_sea-dragon-and-photosynth-demo_tech (check at 1min20s if you don't want to watch the whole video) Now, getting back to your proposal : A javascript interface similar to the ones at IA or Google Books, that downloads only the few scans that need to be shown to the user, would be fairly easy to write using the API. We could even do it for text, as long as it is rendered as well-separated physical pages. However, it would be more complicated to apply the same principle if text is to be rendered without page separations, and preserving its logical structure. We would need to either pre-parse the whole document and develop an API that lets us download small bits of it, or to parse the current page together with previous and next pages. I am not sure if it is really worth the effort ; the bandwidth saving would be less significant than for scans. Thomas Lars Aronsson a écrit : On 08/11/2010 09:46 PM, Aryeh Gregor wrote: This seems like a very weird way to do things. Why is the book being split up by page to begin with? For optimal reading, you should put a lot more than one book-page's worth of content on each web page. ThomasV will give the introduction to ProofreadPage and its purpose. I will take a step back. A book is typically 40-400 pages, because that is how much you can comfortably bind in one volume (one spine) and sell as a commercial product. A web 1.0 (plain HTML + HTTP) page is typically a smaller chunk of information, say 1-100 kbytes. To match (either in Wikisource or Wikibooks) the idea of a book with web technology, the book needs to split up, either according to physical book pages (Wikisource with the ProofreadPage extension) or chapters (Wikisource without ProofreadPage or Wikibooks). In either case, the indiviual pages have a sequential relationship. If you print the pages, you can glue them together and the sequence makes sense, which is not the case with Wikipedia. Such pages have links to the previous and next page in sequence (which Wikipedia articles don't have). Wikipedia, Wikibooks and Wikisource mostly use web 1.0 technology. A very different approach to web browsing was taken when Google Maps was launched in 2005, the poster project for the web 2.0. You arrive at the map site with a coordinate. From there, you can pan in any direction and new parts of the map (called tiles) are downloaded by advanced JavaScript and XML (AJAX) calls as you go. Your browser will never hold the entire map. It doesn't matter how big the entire map is, just like it doesn't matter how big the entire Wikipedia website is. The unit of information to fetch is the tile, just like the web 1.0 unit was the HTML page. If we applied this web 2.0 principle to Wikibooks and Wikisource, we wouldn't need to have pages with previous/next links. We could just have smooth, continuous scrolling in one long sequence. Readers could still arrive at a given coordinate (chapter or page), but continue from there in any direction. Examples of such user interfaces for books are Google Books and the Internet Archive online reader. You can link to page 14 like this: http://books.google.com/books?id=Z_ZLMAAJpg=PA14 and then scroll up (to page 13) or down (to page 15). The whole book is never in your browser. New pages are AJAX loaded as they are needed. It's like Google maps except that you can only pan in two directions (one dimensions), not in the four cardinal directions. And the zoom is more primitive here. After you have scrolled to page 19, you need to use the Link tool to know the new URL to link to. At the Internet Archive, the user interface is similar, but the URL in your browser is updated as you scroll (for better or worse), http://www.archive.org/stream/devisesetembleme00lafeu#page/58/mode/1up If we only have scanned images of book pages, this is simple enough, because each scanned image is like a tile in Google maps. But in Wikisource, we have also run OCR software to extract a text layer for each page, and we have proofread that text to make it searchable. I still have not learned JavaScript, but I guess you could make AJAX calls for a chunk of text and add that to the scrollable web page, just like you can add tiled images. Google has not done this, however. If you switch to plain text viewing mode, http://books.google.com/books?pg=PA14id=Z_ZLMAAJoutput=text you get traditional web 1.0 pages with links to the previous and next web page. (Each of Google's text pages contains text from 5 book pages, e.g. page 11-15, only to make things more confusing.) But the real challenge comes when you want to wiki edit one such chunk of scrollable text. I think it could work similar to our section editing of a long Wikipedia article. But to be really elegant, I should be able, when editing a section, to scroll up
Re: [Wikitech-l] wikipedia is one of the slower sites on the web
On 12 August 2010 00:01, Domas Mituzas midom.li...@gmail.com wrote: ... I'm sorry to disappoint you but none of the issues you wrote down here are any new. If after reading any books or posts you think we have deficiencies, mostly it is because of one of two reasons, either because we're lazy and didn't implement, or because it is something we need to maintain wiki model. I am not dissapointed. The wiki model make it hard, because everything can be modified, because the whole thing is giganteous and have a innertia, and the need to support a giganteous list of languages that will make the United Nations looks like timid. And I know you guys are a awesome bunch. And lots of eyes has ben put on the problems. This make mediawiki a ideal scenario to think about tecniques to make the web faster. Heres a cookie, a really nice plugin for firebug to check speed. http://code.google.com/p/page-speed/ -- -- ℱin del ℳensaje. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sentence-level editing
I suppose I just go on and build it as an extension then. ^_^ Again, if you have suggestions or want to join in development or anything else, feel free to mail. Best regards, Jan Paul ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sentence-level editing
2010/8/13 Jan Paul Posma jp.po...@gmail.com: I suppose I just go on and build it as an extension then. ^_^ Again, if you have suggestions or want to join in development or anything else, feel free to mail. You've already applied for commit access right? Did you apply for extension access or core access? If and when you get commit access for extensions, you're encouraged to develop your extension in our SVN repo. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Developing true WISIWYG editor for media wiki
Hi, I sent a mail several months ago on this list to 'advertise' for a wysiwyg editor for wikipedia. It is still hosted on a server, for instance if you attempt to edit the page Open_innovation you get that : http://www.myrilion.com:8080/wysiwyg?article=Open_innovation The point with this editor that it is fully client based: the wiki markup is transformed in html on client side, edited as html through a javascript editor and then transformed back to mediawiki markup on client side as well. The code of the translation engine is written in OCaml (www.ocaml.org) and compiled to javascript. If anyone here is interested I'll be happy to clean the sources and to release it as an opensource project. All the best, William 2010/8/13 Павел Петроченко pa...@onpositive.com: Hi, glad to present our first demo on editing media wiki articles: http://www.screencast.com/t/NmMzMjVkNjUt Regards, Pavel 2010/8/3 Павел Петроченко pa...@onpositive.com Hi, Yes, of course we are interested on it. Specifically, the ideal WISIWYG MediaWiki editor would allow easy WISIWYG editing to newbies, while still allowing to use the full wikisyntax to power users, without inserting crappy markup when using it, or reordering everything to its liking when WISIWYG was used to do a little change. Thanks for the note, it may be an important issue. From the screencast, it seems your technology is based in a local application instead of web. That's is a little inconvenience for the users, but an acceptable one IMHO. You could plug your app as an external editor, see: http://www.mediawiki.org/wiki/Manual:External_editors Yep according to my understanding this is major problem, but unfortunately we are rich client developers, so going web is only in our future plans. (Actually we are thinking about moving to it, but waiting for a first customer to help with transition) On other side being a rich client app may add some benefits for advanced users, which are still hard to do in web apps (according to my poor desktop developer understanding). custom groupings, personal inbox, local for work flow/validation rules and review. (just as initial examples) The problem that makes this really hard is that MediaWiki syntax is not nice. So I'm a bit skeptical about that fast quality editor. You can find in the list archives many discussions about it, and also in wikitext-l. Things like providing a ribbon is a completely esthetical choice, it can't really help on the result of its editing. Maybe your backend is powerful enough to handle this without problems. Please, show me wrong :) Yep - already meet some crap in dealing with it(much more complex than, Trac wiki one). But still hope to over helm most of problems, in a couple of month I don't have an issue with there being a closed source Windows app that edits wikitext well, but then there is going to be a bit of a difficult transition from reading to editing and back again. Yes, this is one of pote And just FYI, generally our community is more interested in free and cross-platform software than proprietary, single platform software. Actually we are going to be open source and cross platform (we are Eclipse RCP based) That was very interesting. Any chance the rest of us can try it for ourselves? Our media wiki support is at very early stage now. Actually we are still not sure how much we are going to be committed into it, If there will be enough interest (at least couple of volunteer beta testers), we will start publishing builds somewhere. Regards, Pavel OnPositive Technologies. 2010/8/3 Neil Kandalgaonkar ne...@wikimedia.org On 8/2/10 9:29 AM, Павел Петроченко wrote: Hi guys, At the moment we are discussing an opportunity to create full scale true WYSIWYG client for media wiki. To the moment we have a technology which should allow us to implement with a good quality and quite fast. Unfortunately we are not sure if there is a real need/interest for having such kind of client at the media wiki world, as well as what are actual needs of media wiki users. Definitely interested. As for what the needs of MediaWiki users are, you can check out everything on http://usability.wikimedia.org/ . We are just beginning to address usability concerns. This study might be interesting to you: http://usability.wikimedia.org/wiki/Usability_and_Experience_Study P.S. Screen cast demonstrating our experimental client for Trac wiki http://www.screencast.com/t/MDkzYzM4 That was very interesting. Any chance the rest of us can try it for ourselves? I personally like the idea of a ribbon. I think we can assume that most wiki editors are always going to be novice editors, so taking up tremendous amounts of space by default to explain things is warranted. Experts should be able to drop into raw wikitext, or otherwise minimize the interface. I don't have an issue with there being a closed source Windows app that
Re: [Wikitech-l] Sentence-level editing
On 10 August 2010 00:55, Jan Paul Posma jp.po...@gmail.com wrote: ... The last few weeks I've worked on some prototypes to illustrate this idea. You can find the most advanced prototype here: http://janpaulposma.nl/sle/prototype/prototype3.html The full project proposal and prototypes can be found here: http://www.mediawiki.org/wiki/User:JanPaul123/Sentence-level_editing This is the best thing I have see the whole week. But suppose I want to be always in this mode, I can't click on links. Also maybe the user don't really need to see the lines highlighted, ... here in firefox wen I double-click on a word, the whole phrase is highlited... is like the user is already acustomed for how line-selections works on double click. But IANUE.Also, there need to be stronger options, commit changes, cancel or something, maybe theres a better way to do this. May pay to ask some real usability experts about this, if have some positive feedback to give, before continue. -- -- ℱin del ℳensaje. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikisource books and web 1.0 pages (was: pas de sujet)
On Fri, Aug 13, 2010 at 4:27 AM, Lars Aronsson l...@aronsson.se wrote: Wikipedia, Wikibooks and Wikisource mostly use web 1.0 technology. A very different approach to web browsing was taken when Google Maps was launched in 2005, the poster project for the web 2.0. You arrive at the map site with a coordinate. From there, you can pan in any direction and new parts of the map (called tiles) are downloaded by advanced JavaScript and XML (AJAX) calls as you go. Your browser will never hold the entire map. It doesn't matter how big the entire map is, just like it doesn't matter how big the entire Wikipedia website is. The unit of information to fetch is the tile, just like the web 1.0 unit was the HTML page. I have doubts about whether this is the right approach for books. Offering the book as plain HTML pages, one for each chapter and also one for the whole book (for printing and searching), seems more useful. Browsers can cope with such long pages just fine, and it preserves all the functionality people are used to: links work as expected, back and forward work as expected, all without extra work on our part. This isn't an option for Google Maps, because 1) They're dealing with way more data. They can't possibly send you a map of the whole world in full detail on every page load. It would be many megabytes even compressed. 2) The page model doesn't fit their needs. Even if they served the whole map, they'd need complicated JavaScript to have it scroll and zoom and so forth as the user expects. This isn't needed for transcribed text, and trying to reimplement all the scrolling/bookmarking/navigation/search/etc. functionality that users are used to for regular web pages would be counterproductive. Traditional web pages are designed to present formatted text, possibly with some interspersed images, without particular layout precision. Anything in that format is probably best distributed as plain HTML, not some fancy web app thing. Not to mention, the latter is a lot more work to implement. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] wikipedia is one of the slower sites on the web
On Fri, Aug 13, 2010 at 6:55 AM, Tei oscar.vi...@gmail.com wrote: I am not dissapointed. The wiki model make it hard, because everything can be modified, because the whole thing is giganteous and have a innertia, and the need to support a giganteous list of languages that will make the United Nations looks like timid. Actually, wikis are much easier to optimize than most other classes of apps. The pages only change rarely compared to something like Facebook or Google, which really has to regenerate every single page customized to the view. That's why we get by with so little money compared to real organizations. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia logging infrastructure
On Fri, Aug 13, 2010 at 8:55 AM, Magnus Manske magnusman...@googlemail.com wrote: Disk dump thread: * Get mutex for list start pointer * Copy list start pointer * Reset list start pointer = NULL * Release mutex * Write list to disk * Release memory If you allocate memory per list item, the freed ones should nicely fit the next ones, so malloc would not be too slow, I imagine (just use char[] of fixed size). While we're having fun speculating on possible designs without actually volunteering to write the code ;): wouldn't a circular buffer make more sense than a linked list? You could have one buffer per thread, to avoid locking for the end pointer, and then the thread that writes the logs to disk can just go around all the buffers in turn, grabbing the requests from the start, ordering them by timestamp, and writing them out in the correct order. I don't think this would need any locking at all, and if you make the buffer large enough that you don't have to worry about the dump thread not being able to keep up, you wouldn't even have any cache bouncing. You could also avoid malloc()/free() issues by just preallocating all the buffers, with only the dump thread doing malloc()/free() during operation. If you keep enough buffer space for 100k requests total, and each request takes 1 KB, that's only 100 MB. Now I want Domas to shoot holes in my idea too! :) Just curious: is the million wakeups an actual number, or a figure of speech? How many views/sec are there? Current #wikimedia-tech topic says that peak load is about 100k req/s. Assuming a million per second is a reasonable idea for future-proofing. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Developing true WISIWYG editor for media wiki
This looks very interesting. 1. Have you been checking the cleanliness of your diffs? 2. It seems like some of the links which link to a different word than the label text are being rendered incorrectly. Examples include parents and joint ventures in the second paragraph. 3. This page uses an enormous amount of JavaScript code... Even after combining all 161 JavaScript files, minifying them with JSMin, and compressing them with GZip, we're looking at 209KB, which is miraculous when you consider it started out as 2.4MB, but still, yes, trimming would help. Here's the stats for the files in various stages. -- 2408505 bytes (2.4 MB) wysiwyg.combined.js -- 1136034 bytes (1.1 MB) wysiwyg.combined.min.js -- 208361 bytes (209 KB) wysiwyg.combined.min.js.gz 4. What's browsers does this work in? 5. What's the performance like in less-modern browsers (if it supports them) such as any Internet Explorer browser, especially IE 6 and 7 which have some of the slowest JavaScript interpreters among the more common browsers. 6. What is your Wikitext HTML / HTML wikitext system using to parse and how much of the document does it understand as opposed to passively transform? Regex? BNF? Anything particularly cool or new? Just a port of the existing MediaWiki parser? Let me also say, thank you for your work in this field, it's a very important area for research and development to be taking place, both at the foundation but most importantly in the community. - Trevor On 8/13/10 8:27 AM, William Le Ferrand wrote: Hi, I sent a mail several months ago on this list to 'advertise' for a wysiwyg editor for wikipedia. It is still hosted on a server, for instance if you attempt to edit the page Open_innovation you get that : http://www.myrilion.com:8080/wysiwyg?article=Open_innovation The point with this editor that it is fully client based: the wiki markup is transformed in html on client side, edited as html through a javascript editor and then transformed back to mediawiki markup on client side as well. The code of the translation engine is written in OCaml (www.ocaml.org) and compiled to javascript. If anyone here is interested I'll be happy to clean the sources and to release it as an opensource project. All the best, William 2010/8/13 Павел Петроченкоpa...@onpositive.com: Hi, glad to present our first demo on editing media wiki articles: http://www.screencast.com/t/NmMzMjVkNjUt Regards, Pavel 2010/8/3 Павел Петроченкоpa...@onpositive.com Hi, Yes, of course we are interested on it. Specifically, the ideal WISIWYG MediaWiki editor would allow easy WISIWYG editing to newbies, while still allowing to use the full wikisyntax to power users, without inserting crappy markup when using it, or reordering everything to its liking when WISIWYG was used to do a little change. Thanks for the note, it may be an important issue. From the screencast, it seems your technology is based in a local application instead of web. That's is a little inconvenience for the users, but an acceptable one IMHO. You could plug your app as an external editor, see: http://www.mediawiki.org/wiki/Manual:External_editors Yep according to my understanding this is major problem, but unfortunately we are rich client developers, so going web is only in our future plans. (Actually we are thinking about moving to it, but waiting for a first customer to help with transition) On other side being a rich client app may add some benefits for advanced users, which are still hard to do in web apps (according to my poor desktop developer understanding). custom groupings, personal inbox, local for work flow/validation rules and review. (just as initial examples) The problem that makes this really hard is that MediaWiki syntax is not nice. So I'm a bit skeptical about that fast quality editor. You can find in the list archives many discussions about it, and also in wikitext-l. Things like providing a ribbon is a completely esthetical choice, it can't really help on the result of its editing. Maybe your backend is powerful enough to handle this without problems. Please, show me wrong :) Yep - already meet some crap in dealing with it(much more complex than, Trac wiki one). But still hope to over helm most of problems, in a couple of month I don't have an issue with there being a closed source Windows app that edits wikitext well, but then there is going to be a bit of a difficult transition from reading to editing and back again. Yes, this is one of pote And just FYI, generally our community is more interested in free and cross-platform software than proprietary, single platform software. Actually we are going to be open source and cross platform (we are Eclipse RCP based) That was very interesting. Any chance the rest of us can try it for ourselves? Our media wiki
Re: [Wikitech-l] Getting back to more regular site software updates
On Thu, Aug 12, 2010 at 8:49 PM, Danese Cooper dcoo...@wikimedia.org wrote: I think you may be hallucinating. We are just now hiring our second code-reviewer, who is also thinking about ways to make the code review process more transparent. Is this someone with a lot of MediaWiki experience? If not, how are they supposed to review code? I'd think it would be much more sound to ask a couple of existing employees to pitch in instead, spending part of their time reviewing and part of it coding. I can think of a couple of people who are qualified enough. It doesn't make a lot of sense to have someone who only reviews and doesn't code, unless they've already done so much coding that they're very familiar with the codebase and coding conventions anyway. I also wonder how the review process could be more transparent, since it's already completely public and open for anyone to join in (and plenty of random non-developers do join in). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikisource books and web 1.0 pages
Why not make a demo? I think this idea has come up a couple of times here in the last year. People find it easy to argue about mere proposals but an actual demo gives people a vision of what you are going for. Just look at what's happened with WYSIWYG just in the last week. OpenLayers seems like a good place to start although it's obviously more designed for maps. http://wiki.openstreetmap.org/wiki/OpenLayers On 8/13/10 11:36 AM, Lars Aronsson wrote: On 08/13/2010 07:36 PM, Aryeh Gregor wrote: I have doubts about whether this is the right approach for books. Offering the book as plain HTML pages, one for each chapter and also one for the whole book (for printing and searching), seems more useful. Browsers can cope with such long pages just fine, One web page per chapter, yes, but not for whole books, especially not for the thicker and larger books. Web pages beyond 100 kbytes still load slowly, especially when you're on a wireless network in a crowded conference room. The problem is, after you scan a book you only know where the physical pages begin and end. The chapter boundaries can only be detected by manual proofreading and markup. The sequence from beginning to end of the book is the same for both pages and chapters (except for complicated cases with footnotes, as discussed recently). A smooth web 2.0, map-style scrolling through that sequence can be a way to overcome the delay between fast mechanical scanning and slow manual proofreading. -- Neil Kandalgaonkar ) ne...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Developing true WISIWYG editor for media wiki
Hi Trevor, Thanks for the reply! Actually I wrote this code for fun a few months ago; the core is done but there is still a lot of room for improvements ;) I'm using a functional language called OCaml (www.ocaml.org). Have you ever heard of it? It comes with several fancy tools; I used ocamllex to generate the lexer; and a custom parser to cope with the grammar. I didn't reused any line of the mediawiki parser, it is entirely written from scratch in pure ocaml. The ocaml code is compiled to javascript to get the js code you can see on the website. Using those tools, I've been able to set up a rather complicated program in js that I couldn't have written in a non typed language. (but perhaps because I'm a bad js programmer..) About your questions: 1) No, I haven't check that. It is a very important issue, but if the current result is not correct it should be a matter of fixing a few bugs here and there, not a global design issue. 2) Yes, this case is not correctly handled. One more time, I didn't spent too much time on this, even if I'd love to ! 3) Ah, perhaps, yes. This js is autogenerated. A friend of mine released a new ocaml-js compiler ( available from www.ocsigen.org ), perhaps his compiler will produce more compact code. 4,5) I only tested on safari and chrome where the preformance is actually quite good. Of course, the computations that were originally handled by the server have to be done by the browser, so it is slower; but with this method there is less load on the server (at least I believe so), the load is distributed to the users; it is a nice scheme for a community project isn't it ;)? 5) Well, the best should probably that you have a look to the source code. I can put it on github if you want; would you be interested? Is there an ocaml developer on the list that could give his opinion about the global process ? Thanks ! William 2010/8/13 Trevor Parscal tpars...@wikimedia.org: This looks very interesting. 1. Have you been checking the cleanliness of your diffs? 2. It seems like some of the links which link to a different word than the label text are being rendered incorrectly. Examples include parents and joint ventures in the second paragraph. 3. This page uses an enormous amount of JavaScript code... Even after combining all 161 JavaScript files, minifying them with JSMin, and compressing them with GZip, we're looking at 209KB, which is miraculous when you consider it started out as 2.4MB, but still, yes, trimming would help. Here's the stats for the files in various stages. -- 2408505 bytes (2.4 MB) wysiwyg.combined.js -- 1136034 bytes (1.1 MB) wysiwyg.combined.min.js -- 208361 bytes (209 KB) wysiwyg.combined.min.js.gz 4. What's browsers does this work in? 5. What's the performance like in less-modern browsers (if it supports them) such as any Internet Explorer browser, especially IE 6 and 7 which have some of the slowest JavaScript interpreters among the more common browsers. 6. What is your Wikitext HTML / HTML wikitext system using to parse and how much of the document does it understand as opposed to passively transform? Regex? BNF? Anything particularly cool or new? Just a port of the existing MediaWiki parser? Let me also say, thank you for your work in this field, it's a very important area for research and development to be taking place, both at the foundation but most importantly in the community. - Trevor On 8/13/10 8:27 AM, William Le Ferrand wrote: Hi, I sent a mail several months ago on this list to 'advertise' for a wysiwyg editor for wikipedia. It is still hosted on a server, for instance if you attempt to edit the page Open_innovation you get that : http://www.myrilion.com:8080/wysiwyg?article=Open_innovation The point with this editor that it is fully client based: the wiki markup is transformed in html on client side, edited as html through a javascript editor and then transformed back to mediawiki markup on client side as well. The code of the translation engine is written in OCaml (www.ocaml.org) and compiled to javascript. If anyone here is interested I'll be happy to clean the sources and to release it as an opensource project. All the best, William 2010/8/13 Павел Петроченкоpa...@onpositive.com: Hi, glad to present our first demo on editing media wiki articles: http://www.screencast.com/t/NmMzMjVkNjUt Regards, Pavel 2010/8/3 Павел Петроченкоpa...@onpositive.com Hi, Yes, of course we are interested on it. Specifically, the ideal WISIWYG MediaWiki editor would allow easy WISIWYG editing to newbies, while still allowing to use the full wikisyntax to power users, without inserting crappy markup when using it, or reordering everything to its liking when WISIWYG was used to do a little change. Thanks for the note, it may be an important issue. From the screencast, it seems your
Re: [Wikitech-l] Developing true WISIWYG editor for media wiki
2010/8/13 William Le Ferrand will...@corefarm.com: I'm using a functional language called OCaml (www.ocaml.org). Have you ever heard of it? Our math extensions for displaying TeX use it. In fact, they've been languishing for a lack of OCaml programmers ... - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Developing true WISIWYG editor for media wiki
Very exciting work, thanks for the quality responses. I'm not an OCaml programmer, so I'd likely be useless in giving input - but open-sourcing it and putting the code in a repository is always a good way to find people who are and to get them involved. - Trevor On 8/13/10 12:19 PM, William Le Ferrand wrote: Hi Trevor, Thanks for the reply! Actually I wrote this code for fun a few months ago; the core is done but there is still a lot of room for improvements ;) I'm using a functional language called OCaml (www.ocaml.org). Have you ever heard of it? It comes with several fancy tools; I used ocamllex to generate the lexer; and a custom parser to cope with the grammar. I didn't reused any line of the mediawiki parser, it is entirely written from scratch in pure ocaml. The ocaml code is compiled to javascript to get the js code you can see on the website. Using those tools, I've been able to set up a rather complicated program in js that I couldn't have written in a non typed language. (but perhaps because I'm a bad js programmer..) About your questions: 1) No, I haven't check that. It is a very important issue, but if the current result is not correct it should be a matter of fixing a few bugs here and there, not a global design issue. 2) Yes, this case is not correctly handled. One more time, I didn't spent too much time on this, even if I'd love to ! 3) Ah, perhaps, yes. This js is autogenerated. A friend of mine released a new ocaml-js compiler ( available from www.ocsigen.org ), perhaps his compiler will produce more compact code. 4,5) I only tested on safari and chrome where the preformance is actually quite good. Of course, the computations that were originally handled by the server have to be done by the browser, so it is slower; but with this method there is less load on the server (at least I believe so), the load is distributed to the users; it is a nice scheme for a community project isn't it ;)? 5) Well, the best should probably that you have a look to the source code. I can put it on github if you want; would you be interested? Is there an ocaml developer on the list that could give his opinion about the global process ? Thanks ! William 2010/8/13 Trevor Parscaltpars...@wikimedia.org: This looks very interesting. 1. Have you been checking the cleanliness of your diffs? 2. It seems like some of the links which link to a different word than the label text are being rendered incorrectly. Examples include parents and joint ventures in the second paragraph. 3. This page uses an enormous amount of JavaScript code... Even after combining all 161 JavaScript files, minifying them with JSMin, and compressing them with GZip, we're looking at 209KB, which is miraculous when you consider it started out as 2.4MB, but still, yes, trimming would help. Here's the stats for the files in various stages. -- 2408505 bytes (2.4 MB) wysiwyg.combined.js -- 1136034 bytes (1.1 MB) wysiwyg.combined.min.js -- 208361 bytes (209 KB) wysiwyg.combined.min.js.gz 4. What's browsers does this work in? 5. What's the performance like in less-modern browsers (if it supports them) such as any Internet Explorer browser, especially IE 6 and 7 which have some of the slowest JavaScript interpreters among the more common browsers. 6. What is your Wikitext HTML / HTML wikitext system using to parse and how much of the document does it understand as opposed to passively transform? Regex? BNF? Anything particularly cool or new? Just a port of the existing MediaWiki parser? Let me also say, thank you for your work in this field, it's a very important area for research and development to be taking place, both at the foundation but most importantly in the community. - Trevor On 8/13/10 8:27 AM, William Le Ferrand wrote: Hi, I sent a mail several months ago on this list to 'advertise' for a wysiwyg editor for wikipedia. It is still hosted on a server, for instance if you attempt to edit the page Open_innovation you get that : http://www.myrilion.com:8080/wysiwyg?article=Open_innovation The point with this editor that it is fully client based: the wiki markup is transformed in html on client side, edited as html through a javascript editor and then transformed back to mediawiki markup on client side as well. The code of the translation engine is written in OCaml (www.ocaml.org) and compiled to javascript. If anyone here is interested I'll be happy to clean the sources and to release it as an opensource project. All the best, William 2010/8/13 Павел Петроченкоpa...@onpositive.com: Hi, glad to present our first demo on editing media wiki articles: http://www.screencast.com/t/NmMzMjVkNjUt Regards, Pavel 2010/8/3 Павел Петроченкоpa...@onpositive.com Hi, Yes, of course we are interested on it. Specifically,
Re: [Wikitech-l] Getting back to more regular site software updates
Danese Cooper wrote: I think you may be hallucinating. We are just now hiring our second code-reviewer, who is also thinking about ways to make the code review process more transparent. The area of contractors and Wikimedia hires has to be one of the most opaque parts of Wikimedia. Unless someone is fully certified as a member of the staff and is listed at wmf:Staff,[1] there is almost no way to figure out who's working for Wikimedia, in what capacity, and for what duration. The only real recourse available to contributors is to directly ask each individual person whether or not they're staff, and sometimes they'll answer.[2] For an organization that prides itself on openness and transparency, I don't see how it's acceptable to intentionally keep the list of people Wikimedia is hiring that are doing code development work a complete secret. I've personally asked Erik to have people listed on some sort of page on the WMFwiki, but apparently the overhead for a simple ordered list is too high. Without being able to know who's working on what or when or why, it makes it so much harder for people not hired by Wikimedia (the ones who do the majority of the code development) to collaborate with the ones who have been hired (or partially hired). I can say that the majority of code development work I've been seeing lately from people working for Wikimedia is Usability-related or fundraising-related. If there are code reviewers being hired to do general code review, mind pointing me to a reliable source saying so? MZMcBride [1] http://wikimediafoundation.org/wiki/Staff [2] http://en.wikipedia.org/?oldid=364616662#Are_you_Wikimedia_staff.3F ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Getting back to more regular site software updates
2010/8/13 Aryeh Gregor simetrical+wikil...@gmail.com: they supposed to review code? I'd think it would be much more sound to ask a couple of existing employees to pitch in instead, spending part of their time reviewing and part of it coding. I can think of a couple of people who are qualified enough. It doesn't make a lot of sense to have someone who only reviews and doesn't code, unless they've already done so much coding that they're very familiar with the codebase and coding conventions anyway. I second this. The only way to become good at reviewing MediaWiki code is to write MediaWiki code for at least a year. I had been a dev for 3 years by the time I felt comfortable reviewing code, but then I hadn't been doing it full time. Someone working full time and being coached by experienced reviewers should be able to get up to speed in less than a year, IMO. This would still be quite a long time, though, so hiring people specifically for code review should be understood in that context. However, the fact that it takes so long to get a good grip on reviewing code suggests that reviewing code is just something that senior developers do, and that newly hired developers will be able to review code a few years from now. If we have our existing senior developers do more code review, educate all of our developers about code review better, and just hire more developers to initially cover the void of senior devs doing less coding and more review and later to join the reviewers, I believe we'll have a much more sustainable and sane setup than we would get by hiring people specifically for review and having them focus on review from day 1. I also wonder how the review process could be more transparent, since it's already completely public and open for anyone to join in (and plenty of random non-developers do join in). I would also like to hear specific suggestions here. I think there are things that could be done to improve our code review process in terms of making sure code gets reviewed in a timely fashion and by the right person. (I have some ideas about that just occurred to me today, so I'll take the time to think about them and hash them out more while I'm on vacation, and maybe post them next week.) However, it's not clear to me how transparency could be improved. All the data is already made available, all that could be improved AFAICT is making it easier to obtain. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sentence-level editing
Jan Paul Posma wrote: Interesting. I find the switch to 3row textarea from content a little jarring. A further developed version could make use of contentEditable to provide the same editing ability but without the negative side effects of the textarea. Actually, showing the original wikitext is one of the goals of this user-interface. The goal of this project is to lower the barriers for novice users, and providing a better way for them to learn the wikitext syntax. Hiding the wikitext completely would defeat this purpose. In the best cases novice users would first edit some sentences, while noticing the wikitext syntax, but only some links and perhaps bold/italics. This is much less scary than a big textarea with lots of code. Then they may experiment with references, images, templates (once these are implemented), so they can slowly learn more. Eventually they can either be advanced users of this editor, or try the editor we have now, which will always be more powerful. The editor I'm proposing *isn't* a total replacement for the current editor, just an addition. Best regards, Jan Paul Aye, I had one suggestion later on in the message which could apply there. Or converting the simple content back to WikiText and showing the syntax ([[, '', etc...) inline, with a floating cancel and preview button just using contentEditable as a textarea replacement that doesn't disrupt the page flow as much. contentEditable is more than simply WYSIWYG, it can also be used to build custom inputs that fuse html and text to provide a text area enhanced by extra ui inline with the content. ~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] Getting back to more regular site software updates
2010/8/13 MZMcBride z...@mzmcbride.com: The area of contractors and Wikimedia hires has to be one of the most opaque parts of Wikimedia. Unless someone is fully certified as a member of the staff and is listed at wmf:Staff,[1] there is almost no way to figure out who's working for Wikimedia, in what capacity, and for what duration. The only real recourse available to contributors is to directly ask each individual person whether or not they're staff, and sometimes they'll answer.[2] For an organization that prides itself on openness and transparency, I don't see how it's acceptable to intentionally keep the list of people Wikimedia is hiring that are doing code development work a complete secret. I've personally asked Erik to have people listed on some sort of page on the WMFwiki, but apparently the overhead for a simple ordered list is too high. Yes, this is bad. The problem is that currently, we simply do not have such a list, not even internally. It desperately needs to be compiled and made public. At one point, Tim started a page on officewiki trying to list all dev contractors because he was taken by complete surprise when someone told him he'd been contracting for usability for a few months already. I think I know almost all developers we contract and what they do, but that's only because I proactively stay on top of things by e.g. asking new people who they are and what they do when they appear in the staff channel. Even then, some contractors manage to elude me and I find out about them long after they've been hired. Without being able to know who's working on what or when or why, it makes it so much harder for people not hired by Wikimedia (the ones who do the majority of the code development) to collaborate with the ones who have been hired (or partially hired). People who do work for WMF also have this problem: they are generally more up to speed, but they don't have complete knowledge either. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Getting back to more regular site software updates
On Fri, Aug 13, 2010 at 4:10 PM, Roan Kattouw roan.katt...@gmail.com wrote: However, the fact that it takes so long to get a good grip on reviewing code suggests that reviewing code is just something that senior developers do, and that newly hired developers will be able to review code a few years from now. If we have our existing senior developers do more code review, educate all of our developers about code review better, and just hire more developers to initially cover the void of senior devs doing less coding and more review and later to join the reviewers, I believe we'll have a much more sustainable and sane setup than we would get by hiring people specifically for review and having them focus on review from day 1. Yep. And we could do this immediately. So why aren't we? Slow code review, and consequent slow deployment and release, has been probably the biggest problem with MediaWiki development for at least a year. On Fri, Aug 13, 2010 at 4:33 PM, Roan Kattouw roan.katt...@gmail.com wrote: I think I know almost all developers we contract and what they do, but that's only because I proactively stay on top of things by e.g. asking new people who they are and what they do when they appear in the staff channel. Apparently this isn't a reliable strategy, since I'm technically a Wikimedia contractor right now, but no one invited me to any special channels. (I say technically because I did a few hours of work and got to the point where I couldn't do much more without review, which I've been waiting for for more than two weeks.) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] So, Java.
So what's our escape plan from Java? http://blogs.computerworld.com/16736/oracle_vs_google_over_java_in_android_is_only_the_start (I work in a Java shop. I'd already recommended to my boss and boss's boss that we get the hell off Solaris ASAP. Today we had a lot of Java developers rather concerned for their careers.) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] proposal to extend the ref tag syntax
On 13 August 2010 19:10, Aryeh Gregor simetrical+wikil...@gmail.com wrote: This is pretty convincing, but not totally. Maybe the reason that people are so adamant about keeping content on the same page is just b ecause they have to click links back and forth to view the other pages, which is disruptive. If they could more easily see the next and previous page, and maybe a few pages beyond that if necessary, don't you think it would be much more attractive to not split things up? Evidently not, as you are ignoring that text fidelity and preserving pages are considered important. (Most obnoxious possible responses to a bug report: Oh, what you want is just stupid, you don't *really* want that, you want this other thing instead which is nothing like what you asked for.) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] So, Java.
So what's our escape plan from Java? Where are we with Java so that we need to escape from Java? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] So, Java.
On Fri, Aug 13, 2010 at 4:57 PM, Daniel Schwen li...@schwen.de wrote: So what's our escape plan from Java? Where are we with Java so that we need to escape from Java? Lucene. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] So, Java.
On 13 August 2010 21:57, Daniel Schwen li...@schwen.de wrote: So what's our escape plan from Java? Where are we with Java so that we need to escape from Java? Search, for one. Java is not free software in practice if Oracle is spewing lawsuits all over the place. (My escape plan at work was to move to OpenJDK 7. This may not allow escape from Oracle's gibbering insanity either.) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] So, Java.
Search, for one. Java is not free software in practice if Oracle is spewing lawsuits all over the place. Right, lucene slipped my mind. I suppose there are good reasons not to use CLucene? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] So, Java.
On Fri, Aug 13, 2010 at 4:55 PM, David Gerard dger...@gmail.com wrote: So what's our escape plan from Java? http://blogs.computerworld.com/16736/oracle_vs_google_over_java_in_android_is_only_the_start (I work in a Java shop. I'd already recommended to my boss and boss's boss that we get the hell off Solaris ASAP. Today we had a lot of Java developers rather concerned for their careers.) Oracle is only suing Google because Google is redistributing Java without paying them, and because they're using a modified version (so technically they're not covered by the patent grants), and because Google has deep pockets. It's pretty implausible that they'll sue users and developers directly. If they do, Wikimedia has little enough money to be extremely low on their list. I don't think we need to worry about this one way or the other at this point. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Developing true WISIWYG editor for media wiki
2010/8/13 William Le Ferrand will...@corefarm.com: 1) No, I haven't check that. It is a very important issue, but if the current result is not correct it should be a matter of fixing a few bugs here and there, not a global design issue. There is a very fundamental issue with converting wikitext to HTML, then back, which is that there are multiple wikitext alternatives that produce the same HTML: [[Foo]] and [[Foo|Foo]] for instance. Earlier versions of FCKeditor used to 'normalize' all links looking like [[Foo]] to [[Foo|Foo]], which resulted absolutely hideous diffs that were nigh impossible to review because the actual changes got buried in lots of link 'normalizations'. This is what Trevor is talking about when he asks about the cleanliness of your diffs. I believe this particular bug was fixed, but the general point stands: you need to somehow remember things about the wikitext that went in in order to have a chance to get it back relatively unscathed. I personally believe that the round-trip approach is fundamentally flawed and that you should have some internal representation (not HTML) closely connected to the wikitext in which you track changes, but that's just my personal conviction and I'm not aware of any successful editors built this way. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] So, Java.
On 13 August 2010 22:05, Aryeh Gregor simetrical+wikil...@gmail.com wrote: Oracle is only suing Google because Google is redistributing Java without paying them, and because they're using a modified version (so technically they're not covered by the patent grants), and because Google has deep pockets. It's pretty implausible that they'll sue users and developers directly. If they do, Wikimedia has little enough money to be extremely low on their list. I don't think we need to worry about this one way or the other at this point. I wasn't aware of if we can probably get away with it in the WMF guidelines regarding free software. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] So, Java.
On Fri, Aug 13, 2010 at 5:09 PM, David Gerard dger...@gmail.com wrote: I wasn't aware of if we can probably get away with it in the WMF guidelines regarding free software. If software is non-free just because someone files patent suits against those who use it, then Linux is non-free also. Microsoft has claimed for years to have patents that make it illegal to redistribute Linux without its permission, and it has sued one company (TomTom) on those grounds. Likewise, Apple recently sued HTC on a theory that boils down to the claim that probably all web browsers infringe its patents, IIRC. How is this different from Oracle suing Google? Almost all software might theoretically be covered by someone's patents, but practically speaking, that doesn't make it non-free. It's still free as long as modified versions can be widely disseminated in practice, and that's still the case for Java up until Oracle starts collecting royalties as a matter of course. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Getting back to more regular site software updates
2010/8/13 Roan Kattouw roan.katt...@gmail.com: Yes, this is bad. The problem is that currently, we simply do not have such a list, not even internally. It desperately needs to be compiled and made public. At one point, Tim started a page on officewiki trying to list all dev contractors because he was taken by complete surprise when someone told him he'd been contracting for usability for a few months already. I think I know almost all developers we contract and what they do, but that's only because I proactively stay on top of things by e.g. asking new people who they are and what they do when they appear in the staff channel. Even then, some contractors manage to elude me and I find out about them long after they've been hired. All contracts go through HR (which currently is only one person, Daniel Phelps). MZMcBride asked me a while ago whether we'd maintain an up-to-date list of comings and goings of all contractors, which I don't think makes sense, simply because many contracts are intentionally short-term engagements without any meaningful community implications (e.g. administrative and in-office support contracts). However, we can certainly do better in keeping folks in the loop on contracts that have community implications, which includes most tech contracts and of course community dept. contracts. Whether this is through blog updates, a public log page, or by another method, is up to Daniel to figure out, and I know he's working on it, along with a very long list of other things. -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Image redirects - has the behavior changed?
Hi, I remember last year image redirects used to work flawlessly. Tonight I can't seem to get one working. Has the behavior of MediaWiki changed or am I doing something wrong? Thanks, Strainu ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] So, Java.
On 13 August 2010 22:25, Aryeh Gregor simetrical+wikil...@gmail.com wrote: Almost all software might theoretically be covered by someone's patents, but practically speaking, that doesn't make it non-free. It's still free as long as modified versions can be widely disseminated in practice, and that's still the case for Java up until Oracle starts collecting royalties as a matter of course. OK. Nevertheless, I would really strongly suggest planning a firm escape route as soon as possible. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] So, Java.
David Gerard wrote: On 13 August 2010 22:05, Aryeh Gregor simetrical+wikil...@gmail.com wrote: Oracle is only suing Google because Google is redistributing Java without paying them, and because they're using a modified version (so technically they're not covered by the patent grants), and because Google has deep pockets. It's pretty implausible that they'll sue users and developers directly. If they do, Wikimedia has little enough money to be extremely low on their list. I don't think we need to worry about this one way or the other at this point. I wasn't aware of if we can probably get away with it in the WMF guidelines regarding free software. But the first half of Aryeh's first sentence (Oracle is only suing... not covered by the patent grants) stands alone. Unless we're afraid that Oracle is going to start going after anyone who uses Java in any way, we shouldn't have to worry. (We're not redistributing JDK's, let alone modifying them.) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] So, Java.
If software is non-free just because someone files patent suits against those who use it, then Linux is non-free also. Microsoft has claimed for years to have patents that make it illegal to redistribute Linux without its permission, and it has sued one company (TomTom) on those grounds. Likewise, Apple recently sued HTC on a theory that boils down to the claim that probably all web browsers infringe its patents, IIRC. How is this different from Oracle suing Google? Almost all software might theoretically be covered by someone's patents, but practically speaking, that doesn't make it non-free. It's still free as long as modified versions can be widely disseminated in practice, and that's still the case for Java up until Oracle starts collecting royalties as a matter of course. Exactly. We better start planning our route away from PHP, it may have technology patented in Java, and we all know how Oracle loves to sue. -- Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] So, Java.
OK. Nevertheless, I would really strongly suggest planning a firm escape route as soon as possible. Why? The Java we use is GPL licensed. As long as we use a JDK/VM that is open, we are good. -- Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sentence-level editing
You've already applied for commit access right? Did you apply for extension access or core access? Actually, I didn't say it explicitly, but I mentioned Sentence-level editing, so that would be an extension. If and when you get commit access for extensions, you're encouraged to develop your extension in our SVN repo. Sure! But suppose I want to be always in this mode, I can't click on links. Also maybe the user don't really need to see the lines highlighted, ... here in firefox wen I double-click on a word, the whole phrase is highlited... is like the user is already acustomed for how line-selections works on double click. But IANUE. You can't follow links, no. This is an editing mode and not a viewing mode. Perhaps there should be another Edit mode option Preview or something, to show the page as it would be. But I don't think it's that much of a problem, as you can in fact see if the links you entered are correct depending on the color. This hasn't been implemented in this prototype, obviously, but it should be there in the final version. Also, there need to be stronger options, commit changes, cancel or something, maybe theres a better way to do this. What exactly do you mean? There is a Publish button now to save the page, and cancel buttons when you edit individual sentences. May pay to ask some real usability experts about this, if have some positive feedback to give, before continue. If WMF or someone else wants to do this, then sure, but I'm not going to pay for it! ;-) Do note, by the way, that I have two supervisors from my university monitoring the project, one of whom is specialized in usability. Aye, I had one suggestion later on in the message which could apply there. Or converting the simple content back to WikiText and showing the syntax ([[, '', etc...) inline, with a floating cancel and preview button just using contentEditable as a textarea replacement that doesn't disrupt the page flow as much. contentEditable is more than simply WYSIWYG, it can also be used to build custom inputs that fuse html and text to provide a text area enhanced by extra ui inline with the content. I understand your point. If done right, this could look very good, while still embracing the concept of showing the wikitext. For now I personally cannot invest much time in this, as the coding of the extension will take a lot of time. If you like to take a shot at it, the source can be found at http://github.com/janpaul123/sle-prototype. If it looks and works good, I will include it in the extension for sure! Again, thanks for all the responses. I'm quite confident that this is the way to go, judging by your comments. Right now I'm trying to implement a nice way of plugging in these different edit modes, and building the first editor, the basic sentence-level editor. This, by the way, is not that easy, as there are quite some ambiguities on where a sentence ends. Finding a good algorithm is still a topic of research called Sentence boundary disambiguation. (http://en.wikipedia.org/wiki/Sentence_boundary_disambiguation) If you have any ideas on how to do this right, please share it! Best regards, Jan Paul ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikisource books and web 1.0 pages
There you go then: http://toolserver.org/~magnus/book2scroll/index.html Just one demo book for the moment, but it'll be easy to allow all wikisource books tomorrow, when I have had some sleep... (page jumping is broken too, but scrolling works just fine...) Cheers, Magnus On Fri, Aug 13, 2010 at 7:59 PM, Neil Kandalgaonkar ne...@wikimedia.org wrote: Why not make a demo? I think this idea has come up a couple of times here in the last year. People find it easy to argue about mere proposals but an actual demo gives people a vision of what you are going for. Just look at what's happened with WYSIWYG just in the last week. OpenLayers seems like a good place to start although it's obviously more designed for maps. http://wiki.openstreetmap.org/wiki/OpenLayers On 8/13/10 11:36 AM, Lars Aronsson wrote: On 08/13/2010 07:36 PM, Aryeh Gregor wrote: I have doubts about whether this is the right approach for books. Offering the book as plain HTML pages, one for each chapter and also one for the whole book (for printing and searching), seems more useful. Browsers can cope with such long pages just fine, One web page per chapter, yes, but not for whole books, especially not for the thicker and larger books. Web pages beyond 100 kbytes still load slowly, especially when you're on a wireless network in a crowded conference room. The problem is, after you scan a book you only know where the physical pages begin and end. The chapter boundaries can only be detected by manual proofreading and markup. The sequence from beginning to end of the book is the same for both pages and chapters (except for complicated cases with footnotes, as discussed recently). A smooth web 2.0, map-style scrolling through that sequence can be a way to overcome the delay between fast mechanical scanning and slow manual proofreading. -- Neil Kandalgaonkar ) ne...@wikimedia.org ___ 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
