Re: [Wikitech-l] WYSIFTW status
On 17 January 2011 00:35, MZMcBride z...@mzmcbride.com wrote: Magnus Manske 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? As a one-man-show, I have to think about these things. It depends what your goal is. If your goal is to use this by default with core MediaWiki, it's going to have to support Internet Explorer 6 and Firefox 3, as well as a lot of other browsers. If your goal is to create another WikEd, it can support whichever browsers you choose to support. Given the widespread use of Firefox 3, I can't see any widespread adoption of this tool happening without support for it, even if Firefox 4 is on the horizon. FWIW: testing on a single example, I got 218 sec in FF 3.6.13 and 71 sec in FF 4.0b9 on the same system. FF 3.6 is really quite slow for these purposes. IE9 will be unusable. FF users seem to update pretty quickly once the new version is released and their favoured extensions have updated. Even IE users seem to update quickly once the new version is out. Except IE6 users, who are of course damned to perdition. Though obviously, optimisation before feature completion is evil. Before it goes anywhere serious or universal, it'll need some proper usability testing - to see if Magnus' full screen editing approach actually works for other people. Finally, there are, undoubtedly, a large number of bugs hidden in the code. I assume they will be weeded out, given enough eyeballs (testers and developers). Are you looking for testers and developers? Where would a tester submit a bug report? The page at http://meta.wikimedia.org/wiki/WYSIFTW doesn't seem to address this. The talk page is being used for this so far. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Cross-wiki user talk notification
2011/1/11 Ilmari Karonen nos...@vyznev.net: On 01/11/2011 11:59 AM, Jérémie Roquet wrote: And there's a handy property to determine if you have new messages: http://en.wikipedia.org/w/api.php?action=querymeta=userinfouiprop=hasmsg Unfortunately (or fortunately), userinfo cannot be retrived using jsonp [1]. [1] « callback - If specified, wraps the output into a given function call. For safety, all user-specific data will be restricted. » — Hmm, true. You might be able to emulate the functionality by using prop=info on the user's talk page (and perhaps storing the last time the user visited the page in a cookie). Hi again. Sorry for the late reply (as I read most of wikitech-l threads in batch, I missed that one after the subject change). Yes, that's a good idea and I think I'll do something like this. Thanks! (Ps. It strikes me that the simplest and most efficient way to implement cross-wiki user talk notifications would be as a MediaWiki extension. Why do we not have one already?) Sure. It would be both far more efficient and easier to set up. I guess I should really dive into MediaWiki development… Best regards, -- Jérémie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Image.php is deprecated need to replace with something else
On 12/01/11 09:03, Beebe, Mary J wrote: GetLinksTo() seems to be returning no results even though there are image pages with links to them. It seems to be a problem with the select statement within the File class. I looked at the query and if I run the query within mySQL it works if I remove the extra quotes. This should be fixed as of r80442. Are other people having trouble with this method? Nobody else uses that method. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] helping in WYSIWYG editor efforts
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. Best Regards, Panos Louridas GRNET ___ 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 Sun, Jan 16, 2011 at 7:34 PM, Lars Aronsson l...@aronsson.se wrote: Many articles are soo long, and have been edited so many times, that the history view is almost useless. If I want to find out when and how the sentence Overall, the city is relatively flatin the article [[en:Paris]] has changed over time, I can sit all day and analyze individual diffs. I think it would be very useful if I could highlight a sentence, paragraph or section of an article and get a reduced history view with only those edits that changed that part of the page. What sorts of indexes would be needed to facilitate such a search? Has anybody already implemented this as a separate tool? How would you define a particular sentence, paragraph or section of an article? The difficulty of the solution lies in answering that question. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] June 8th 2011, World IPv6 Day
Hoi, Do we have statistics of the IPv6 traffic ? Thanks, GerardM On 16 January 2011 13:13, Maarten Dammers maar...@mdammers.nl wrote: On 8 June, 2011, Google, Facebook, Yahoo!, Akamai and Limelight Networks will be amongst some of the major organisations that will offer their content over IPv6 for a 24-hour test drive. The goal of the Test Drive Day is to motivate organizations across the industry – Internet service providers, hardware makers, operating system vendors and web companies – to prepare their services for IPv6 to ensure a successful transition as IPv4 addresses run out. See http://isoc.org/wp/worldipv6day/ . Shouldn't Wikimedia participate in this event? What needs to be done to make this possible? Maarten ___ 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
[Wikitech-l] Category sorting and first letters
In r80443 I added a feature allowing categories to be sorted using the Unicode Collation Algorithm (UCA). I wanted to briefly talk about the potential user impact, the design choices and the caveats. Sorting was the easy part. The hard part was providing a first letter concept which would be reasonably sane. The idea I came up with was to compile a list of first letters, themselves sorted using the UCA. Then the first letter of a given string is the nearest letter in the list which sorts above the string. For instance if you have letters A, B, C, and a string Aardvark, if you sort them you get: A Aardvark B C So we know that A is the first letter of Aardvark because Aardvark sorts immediately below A. This algorithm gives us a number of nice properties: * It automatically drops accents, since accented letters sort the same as unaccented letters (at the primary level). Same with case differences, hiragana/katakana, etc. * You can work out the initial Jamo of a Hangul syllable character by just omitting the composed syllables from the first letter list. Previously this was done with a special-case hack in Language::firstChar(). * Vowel reordering in Thai and Lao is automatically supported. So แก sorts under heading ก and แข sorts under heading ข. * The collation can be expanded to support all sorts of other crazy features, and the first letter feature will keep working in a sane way. For instance, you could have an English collation which removed the from the start of a title. I compiled a list of 14,742 suitable header characters, identified by processing various Unicode data files. That list probably still needs lots of tweaks. There is a down side to this scheme. The default UCA table gives all characters with a similar logical function to the digits 0-9 the same primary sort order as the corresponding ASCII digits. So a page like [[१९२०]] on the Bihari Wikipedia will sort under a heading of 1 instead of १. There may be other instances of accidental cultural imperialism. However, this can be fixed by compiling language-dependent lists of header characters. The UCA default table is not meant to sort any language correctly, it's just a compromise collation. Support for language-specific collations can easily be added. Whether we get language-specific collations or not, I'd like to think about enabling this feature on Wikimedia. The most glaring omission from the UCA default tables is sensible sorting of the unified Han. In a Chinese context, there's an obvious way to sort characters, and that's by their order in the KangXi dictionary. The Unihan database gives such an ordering, and it's used within code blocks. But it's not used between code blocks. So if you sort by code point, all the Han characters that aren't in the U+4E00 to U+9FFF block will sort incorrectly. That's what the default UCA does, with a few minor exceptions. In a Japanese context, the way to sort ideographic characters is to convert them to phonetic hiragana and then to sort the resulting string. I don't know if there is any free software for doing this. On the Japanese Wikipedia, they achieve the same result by manually setting the sort key of every page to be the hiragana version of the title. There's lots of room here for other people to get involved, especially if you know a language other than English. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] WMDE Developer Meetup moved to May
Hi all after some discussion, Wikimedia Germany decided not to hold a developer's meet-up around the Chapter's conference in March. We just couldn't fit this in nicely with the venue and the overall organization. Don't despair though: This is what we will do instead: * There will be a hackathon hosted by Wikimedia Germany in (late) May, probably in Berlin, but that's not decided yet. This will mostly about hacking, with a strong focus on GLAM related stuff. There will be little in terms of presentations. * There will be the hacking days attached to Wikimania in Haifa, August 3./4. I'm in charge of setting up the program for that, and I'll try to make it a nice mix of discussing technology and actually hacking. I would also like to have a get-together with thechies and chapter folks at some point during Wikimania. I hope that this way, we can give the hacking events the attention they deserve. Let me know what you think. -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WYSIFTW status
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. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Toolserver-l] WMDE Developer Meetup moved to May
On 17.01.2011 17:14, Asaf Bartov wrote: Correction: Haifa Hacking Days are to be held August 2nd-3rd. Wikimania itself will be Aug 4th-6th. Gah! Thanks Asaf. There I went and looked it up, and then wrote the wrong thing into the email. Curses. -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] June 8th 2011, World IPv6 Day
On Sun, Jan 16, 2011 at 7:12 PM, Happy-melon happy-me...@live.com wrote: I don't entirely understand the point of this. The plan seems to be get a large enough fraction of 'the internet' to make a change which breaks for some people all at the same time, so that those people get angry with the ISPs that haven't got off their arses to fix said breakage, rather than angry with the broken sites, which is fair enough. No, the point is to test what happens if IPv6 is supported on a large scale. It's known from small-scale testing that this will break things for some small percentage of users, but no one's sure what the consequences are of switching this on fully for everyone. But AFAICT, the breakage won't occur if your connection can't 'do' IPv6, but only if your connection can't 'do' both IPv4 *and* IPv6 on the same site at the same time. Surely that's not actually the problem that we need to solve if we're to be able to migrate smoothly onto IPv6? When the IPv4 addresses run out, we need to be able to start setting up websites which are *only* v6, surely? There are many more clients in the world than servers, and servers have always been able to get dedicated IPv4 addresses much more easily than clients. A server Internet connection in America will typically come with as many IPv4 addresses as you need, while you usually can't get a dedicated residential IP address unless you pay extra. (And America has more IP addresses allocated per capita than anywhere else in the world, since it originally developed the Internet.) So as IPv4 addresses become scarcer, the pressure to use IPv6 only will fall mostly on residential users. Clients with only an IPv6 address will only be able to get direct connections to IPv6-enabled servers. The way servers are supposed to do this is serve both A and records for the same domain, so IPv4 clients use the A record and IPv6 clients use the record. Unfortunately, someone at some point decided that if the client supports both IPv4 and IPv6, and the server publishes both A and records, the client should connect via IPv6. In practice, almost no sites use IPv6, so the infrastructure is much less well-tested. Clients that think they have IPv6 connections might actually have the connection eaten by a middlebox, or just be slower or less reliable. So sites don't turn on the records in practice because it degrades service for clients with IPv6 connections, which means the servers aren't accessible to IPv6-only clients without workarounds. IPv6 day is an attempt to see what happens if major sites publish records for a while. Stuff will break, but hopefully not too horribly, and it will give both site operators and ISPs the chance to analyze what's wrong with their IPv6 support and what they can do to fix it. This is a step toward major sites publishing records all the time, which is necessary to support IPv6-only clients. Something like that, anyway. I'm hardly an expert on these things. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMDE Developer Meetup moved to May
On Mon, Jan 17, 2011 at 11:11 AM, Daniel Kinzler dan...@brightbyte.de wrote: * There will be a hackathon hosted by Wikimedia Germany in (late) May, probably in Berlin, but that's not decided yet. This will mostly about hacking, with a strong focus on GLAM related stuff. There will be little in terms of presentations. Late May? That's actually *really* awesome. Now I don't have to miss school to come :D -Chad ___ 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 Mon, Jan 17, 2011 at 5:55 AM, Alex Brollo alex.bro...@gmail.com wrote: Before I dig a little more into wiki mysteries, I was absolutely sure that wiki articles were stored into small pieces (paragraphs?) so that a small edit into a long long page would take exactly the same disk space than a small edit into a short page. But I discovered soon, that things are different. :-) Wikimedia stores diffs using delta compression, so actually this is basically what happens. The size of the edit is what determines the size of the stored diff, not the size of the page. (I don't know how this works in detail, though.) IIRC, default MediaWiki doesn't work this way. ___ 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 Mon, Jan 17, 2011 at 10:40 AM, Alex Brollo alex.bro...@gmail.com wrote: 2011/1/17 Bryan Tong Minh bryan.tongm...@gmail.com Difficult, but doable. Jan-Paul's sentence-level editing tool is able to make the distinction. It would perhaps be possible to use that as a framework for sentence-level diffs. Difficult, but diff between versions of a page does it. Looking at diff between pages, I simply thought firmly that only diff paragraphs were stored, so that the page was built as updated diff segments. I had no idea how this could be done, but all was magic! Paragraphs are much easier to recognize than sentences, as wikitext has a paragraph delimiter - a blank line. To truly recognize sentences, you basically have to engage in natural language processing, though you can probably get it right 90% of the time without too much effort. And to recognize what's going on when a sentence changes *and* is moved from one paragraph to another, requires an even greater level of natural language understanding. Again though, you can probably get it right most of the time without too much effort. Wikitext actually makes it easier for the most part, as you can use tricks such as the fact that the periods in [[I.M. Someone]] don't represent sentence delimiters, since they are contained in square brackets. But not all periods which occur in the middle of a sentence are contained in square brackets, and not all sentences end with a period. I'd say difficult but doable is quite accurate, although with the caveat that even the state of the art tools available today are probably going to make mistakes that would be obvious to a human. I'm sure there are tools for this, and there are probably some decent ones that are open source. But it's not as simple as just adding an index. ___ 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 Mon, Jan 17, 2011 at 12:41 PM, Anthony wikim...@inbox.org wrote: And to recognize what's going on when a sentence changes *and* is moved from one paragraph to another, requires an even greater level of natural language understanding. Again though, you can probably get it right most of the time without too much effort. Or at the paragraph level, when two paragraphs are combined into one (vs. one paragraph being deleted), or one paragraph is split into two (vs. one paragraph being added), or any of the various other, more complicated changes that take place. If you want a high level of accuracy when trying to determine who added a particular fact (such as Overall, the city is relatively flat, which may have started out as Paris, in general, contains very few changes in elevation), you really need to combine automated tools with human understanding. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikitech-l Digest, Vol 90, Issue 33
Huh??? www.englishfreeroam.co.cc On 17 Jan 2011, at 17:41, wikitech-l-requ...@lists.wikimedia.org wrote: Send Wikitech-l mailing list submissions to wikitech-l@lists.wikimedia.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.wikimedia.org/mailman/listinfo/wikitech-l or, via email, send a message with subject or body 'help' to wikitech-l-requ...@lists.wikimedia.org You can reach the person managing the list at wikitech-l-ow...@lists.wikimedia.org When replying, please edit your Subject line so it is more specific than Re: Contents of Wikitech-l digest... Today's Topics: 1. Category sorting and first letters (Tim Starling) 2. Re: From page history to sentence history (Bryan Tong Minh) 3. Re: From page history to sentence history (Alex Brollo) 4. WMDE Developer Meetup moved to May (Daniel Kinzler) 5. Re: WYSIFTW status (Aryeh Gregor) 6. Re: [Toolserver-l] WMDE Developer Meetup moved to May (Daniel Kinzler) 7. Re: June 8th 2011, World IPv6 Day (Aryeh Gregor) 8. Re: WMDE Developer Meetup moved to May (Chad) 9. Re: From page history to sentence history (Aryeh Gregor) 10. Re: From page history to sentence history (Anthony) -- Message: 1 Date: Tue, 18 Jan 2011 02:00:09 +1100 From: Tim Starling tstarl...@wikimedia.org Subject: [Wikitech-l] Category sorting and first letters To: wikitech-l@lists.wikimedia.org Message-ID: ih1lhs$pmn$1...@dough.gmane.org Content-Type: text/plain; charset=UTF-8 In r80443 I added a feature allowing categories to be sorted using the Unicode Collation Algorithm (UCA). I wanted to briefly talk about the potential user impact, the design choices and the caveats. Sorting was the easy part. The hard part was providing a first letter concept which would be reasonably sane. The idea I came up with was to compile a list of first letters, themselves sorted using the UCA. Then the first letter of a given string is the nearest letter in the list which sorts above the string. For instance if you have letters A, B, C, and a string Aardvark, if you sort them you get: A Aardvark B C So we know that A is the first letter of Aardvark because Aardvark sorts immediately below A. This algorithm gives us a number of nice properties: * It automatically drops accents, since accented letters sort the same as unaccented letters (at the primary level). Same with case differences, hiragana/katakana, etc. * You can work out the initial Jamo of a Hangul syllable character by just omitting the composed syllables from the first letter list. Previously this was done with a special-case hack in Language::firstChar(). * Vowel reordering in Thai and Lao is automatically supported. So ?? sorts under heading ? and ?? sorts under heading ?. * The collation can be expanded to support all sorts of other crazy features, and the first letter feature will keep working in a sane way. For instance, you could have an English collation which removed the from the start of a title. I compiled a list of 14,742 suitable header characters, identified by processing various Unicode data files. That list probably still needs lots of tweaks. There is a down side to this scheme. The default UCA table gives all characters with a similar logical function to the digits 0-9 the same primary sort order as the corresponding ASCII digits. So a page like [[]] on the Bihari Wikipedia will sort under a heading of 1 instead of ?. There may be other instances of accidental cultural imperialism. However, this can be fixed by compiling language-dependent lists of header characters. The UCA default table is not meant to sort any language correctly, it's just a compromise collation. Support for language-specific collations can easily be added. Whether we get language-specific collations or not, I'd like to think about enabling this feature on Wikimedia. The most glaring omission from the UCA default tables is sensible sorting of the unified Han. In a Chinese context, there's an obvious way to sort characters, and that's by their order in the KangXi dictionary. The Unihan database gives such an ordering, and it's used within code blocks. But it's not used between code blocks. So if you sort by code point, all the Han characters that aren't in the U+4E00 to U+9FFF block will sort incorrectly. That's what the default UCA does, with a few minor exceptions. In a Japanese context, the way to sort ideographic characters is to convert them to phonetic hiragana and then to sort the resulting string. I don't know if there is any free software for doing this. On the Japanese Wikipedia, they achieve the same result by manually setting the sort key of every page to be the hiragana version of the title. There's lots of room here for other people to get involved, especially if you know a language
Re: [Wikitech-l] WMDE Developer Meetup moved to May
On Mon, Jan 17, 2011 at 5:11 PM, Daniel Kinzler dan...@brightbyte.de wrote: * There will be a hackathon hosted by Wikimedia Germany in (late) May, probably in Berlin, but that's not decided yet. This will mostly about hacking, with a strong focus on GLAM related stuff. There will be little in terms of presentations. Hmm that would quite suck for me. Will it be during the weekend or during work days? 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
On Jan 17, 2011, at 4:13 PM, Daniel Friesen wrote: Making Wikia's RTE something you can easily install on a normal MediaWiki install would be a good start, and convincing them to try making the effort they said they planned to make to the RTE in a way that can be shared with and benefit from yours and the community's effort. As for improvement, I'm sure you could come up with some ideas from the plethora of complaints scattered around Wikia about issues with the RTE if you can organize them together. Thanks, this could be one bunch of our activities (we would be interested in more than one effort, that's why I listed three in my post). Concerning RTE in particular, When you say them, do you have in mind a specific endpoint that I could reach? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMDE Developer Meetup moved to May
On 17/01/11 17:11, Daniel Kinzler wrote: * There will be a hackathon hosted by Wikimedia Germany in (late) May, probably in Berlin, but that's not decided yet. This will mostly about hacking, with a strong focus on GLAM related stuff. There will be little in terms of presentations. I will be able to attend this event wherever it is. Would it be possible to set the date as early as possible so we can arrange days off with our employers and get cheap flights? Is there any blog / rss feeds I can add to make sure I do not miss any information? ;) I can not attend the august one. -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extending WikiEditor toolbar
2011/1/16 Alex mrzmanw...@gmail.com: I tried to integrate it as neatly as possible, though the lack of documentation hasn't helped. Everything works fine, except when using IE. In IE, it just inserts the ref in some random location on the page, sometimes *near* where the cursor/highlight is, but sometimes its not even close. It seems to work differently with different compatibility mode settings, but even that isn't consistent. I've looked at some of the WikiEditor code and can't figure out why it isn't working, when the other dialogs in the standard toolbar work just fine. Yeah IE has some nasty issues with selections. Have you tried calling .dialog( 'close' ) before doAction() instead of after? That's the only difference I can find between your code and the built-in dialogs. Roan Kattouw (Catrope) ___ 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
2011/1/17 Aryeh Gregor simetrical+wikil...@gmail.com: Wikimedia stores diffs using delta compression, so actually this is basically what happens. The size of the edit is what determines the size of the stored diff, not the size of the page. (I don't know how this works in detail, though.) IIRC, default MediaWiki doesn't work this way. Wikimedia doesn't technically use delta compression. It concatenates a couple dozen adjacent revisions of the same page and compresses that (with gzip?), achieving very good compression ratios because there is a huge amount of duplication in, say, 20 adjacent revisions of [[Barack Obama]] (small changes to a large page, probably a few identical versions to due vandalism reverts, etc.). However, decompressing it just gets you the raw text, so nothing in this storage system helps generation of diffs. Diff generation is still done by shelling out to wikidiff2 (a custom C++ diff implementation that generates diffs with HTML markup like ins/del) and caching the result in memcached. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Cross-wiki user talk notification
Jérémie Roquet á écrit: 2011/1/11 Ilmari Karonen nos...@vyznev.net: On 01/11/2011 11:59 AM, Jérémie Roquet wrote: And there's a handy property to determine if you have new messages: http://en.wikipedia.org/w/api.php?action=querymeta=userinfouiprop=hasmsg Unfortunately (or fortunately), userinfo cannot be retrived using jsonp [1]. [1] « callback - If specified, wraps the output into a given function call. For safety, all user-specific data will be restricted. » — Hmm, true. You might be able to emulate the functionality by using prop=info on the user's talk page (and perhaps storing the last time the user visited the page in a cookie). Hi again. Sorry for the late reply (as I read most of wikitech-l threads in batch, I missed that one after the subject change). Yes, that's a good idea and I think I'll do something like this. Thanks! (Ps. It strikes me that the simplest and most efficient way to implement cross-wiki user talk notifications would be as a MediaWiki extension. Why do we not have one already?) Sure. It would be both far more efficient and easier to set up. I guess I should really dive into MediaWiki development… Best regards, Feel free to send us patches. :) See my previous message about using CentralAuth for that. CentralAuth extension is not really an entry level extension, but you may have luck since you would just be adding hooks. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extending WikiEditor toolbar
On 1/17/2011 2:02 PM, Roan Kattouw wrote: 2011/1/16 Alex mrzmanw...@gmail.com: I tried to integrate it as neatly as possible, though the lack of documentation hasn't helped. Everything works fine, except when using IE. In IE, it just inserts the ref in some random location on the page, sometimes *near* where the cursor/highlight is, but sometimes its not even close. It seems to work differently with different compatibility mode settings, but even that isn't consistent. I've looked at some of the WikiEditor code and can't figure out why it isn't working, when the other dialogs in the standard toolbar work just fine. Yeah IE has some nasty issues with selections. Have you tried calling .dialog( 'close' ) before doAction() instead of after? That's the only difference I can find between your code and the built-in dialogs. No, that still didn't fix it. From some further testing, it looks like the regular dialogs are also broken in the current IE9 beta when using IE9 standards document mode. However, I found my dialogs do work in IE (except in IE9 standards mode) if some text is actually selected. It seems to forget the cursor position if nothing is selected and just places it randomly. -- Alex (wikipedia:en:User:Mr.Z-man) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Category sorting and first letters
2011/1/17 Tim Starling tstarl...@wikimedia.org: * It automatically drops accents, since accented letters sort the same as unaccented letters (at the primary level). How locale aware is it? For example, in Swedish accented letters come at the end of the alphabet and in Lithuanian I, Į and Y are collated together as if they were one letter. There are many quirks of this kind in other languages. And i don't know what to do when in the Lithuanian Wikipedia you sort names of places in the UK - should Islington come before or after York? (But hey, there's at least one Lithuanian MediaWiki developer, so i don't know whether my help is really needed here.) -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com We're living in pieces, I want to live in peace. - T. Moore ___ 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 01/17/2011 06:50 PM, Anthony wrote: If you want a high level of accuracy when trying to determine who added a particular fact (such as Overall, the city is relatively flat, which may have started out as Paris, in general, contains very few changes in elevation), you really need to combine automated tools with human understanding. Our current diff is not perfect, it often performs worse than the GNU wdiff (word diff) utility. But it is still useful. What I'm calling for is a way to filter out (or group together) some of the edits from the history view that had nothing at all to do with the specified sentence or paragraph. This shouldn't be impossible to do. It need not be perfect. The more irrelevant edits it can filter out, the better. I'm a Unix programmer from the days of RCS, which is functionally equivalent to the version control in MediaWiki. In RCS,tracing when, how and by whom a particular piece of code was altered (i.e., who introduced that bug) is as hard as it now is in MediaWiki.Do any of the newer systems (SVN, Git, ...) or commercial integrated development environments have better support for this? -- Lars Aronsson (l...@aronsson.se) Aronsson Datateknik - http://aronsson.se ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extending WikiEditor toolbar
On 1/17/2011 3:17 PM, Alex wrote:
On 1/17/2011 2:02 PM, Roan Kattouw wrote:
2011/1/16 Alex mrzmanw...@gmail.com:
I tried to integrate it as neatly as possible, though the lack of
documentation hasn't helped. Everything works fine, except when using
IE. In IE, it just inserts the ref in some random location on the page,
sometimes *near* where the cursor/highlight is, but sometimes its not
even close. It seems to work differently with different compatibility
mode settings, but even that isn't consistent. I've looked at some of
the WikiEditor code and can't figure out why it isn't working, when the
other dialogs in the standard toolbar work just fine.
Yeah IE has some nasty issues with selections.
Have you tried calling .dialog( 'close' ) before doAction() instead of
after? That's the only difference I can find between your code and the
built-in dialogs.
No, that still didn't fix it. From some further testing, it looks like
the regular dialogs are also broken in the current IE9 beta when using
IE9 standards document mode.
However, I found my dialogs do work in IE (except in IE9 standards mode)
if some text is actually selected. It seems to forget the cursor
position if nothing is selected and just places it randomly.
Based on this discovery, I tested a complete shot in the dark, and
managed to fix it (or at least work around it). Before inserting the
actual content, I have it insert a single space. Why it works I'm not
entirely sure, but it does. The code is now:
buttons: {
'cite-form-submit': function() {
$j.wikiEditor.modules.toolbar.fn.doAction( $j(this).data(
'context' ), {
type: 'encapsulate',
options: {
peri: ' '
}
}, $j(this) );
var ref = CiteTB.getRef(false, true);
$j(this).dialog( 'close' );
$j.wikiEditor.modules.toolbar.fn.doAction( $j(this).data(
'context' ), {
type: 'encapsulate',
options: {
pre: ref
}
}, $j(this) );
},
I've filed a bug for the IE9 standards mode issue that affects all the
dialogs (not just mine).
https://bugzilla.wikimedia.org/show_bug.cgi?id=26785
--
Alex (wikipedia:en:User:Mr.Z-man)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] From page history to sentence history
On 01/17/2011 03:49 PM, Anthony wrote: How would you define a particular sentence, paragraph or section of an article? The difficulty of the solution lies in answering that question. I think the definition could vary, and the functionality could still be useful. The API parameters could be the offset and length in the given article version, just like substr(). A user interface (depending on skin) could input the offset and length by point-and-click (region select) or by pointing at a word and finding the preceding and following blank line. Some user interface might care about sentence separators. The search could be simplified if each edit preserved some parameters of the diff, an edit index, e.g. inserted 7 characters at offset 4711. Then we know that this edit is irrelevant if the sought offset is nowhere near 4711 and as we go back in history, our offset needs to be reduced by 7 if it is larger than 4711. Doing such offset arithmetics for a thousand article edits should be a lot faster than calling diff over and over again. And then again, the diffs are necessary to build such an edit index. This could be done in a one-time conversion or on demand, using the edit index as a cache of such parameters. -- Lars Aronsson (l...@aronsson.se) Aronsson Datateknik - http://aronsson.se ___ 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 11-01-17 10:51 AM, Panos Louridas wrote: On Jan 17, 2011, at 4:13 PM, Daniel Friesen wrote: Making Wikia's RTE something you can easily install on a normal MediaWiki install would be a good start, and convincing them to try making the effort they said they planned to make to the RTE in a way that can be shared with and benefit from yours and the community's effort. As for improvement, I'm sure you could come up with some ideas from the plethora of complaints scattered around Wikia about issues with the RTE if you can organize them together. Thanks, this could be one bunch of our activities (we would be interested in more than one effort, that's why I listed three in my post). Concerning RTE in particular, When you say them, do you have in mind a specific endpoint that I could reach? Not really, just whatever you can find on their site. All the techs (besides Artur/crucially who is the sysadmin, not a MW dev) I've had contact with in the past have left Wikia. ~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] WYSIFTW status
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... Regards, Nux ___ 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
what is the reason and what it can bring to the community? masti On 01/17/2011 01:34 AM, Lars Aronsson wrote: I think it would be very useful if I could highlight a sentence, paragraph or section of an article and get a reduced history view with only those edits that changed that part of the page. What sorts of indexes would be needed to facilitate such a search? Has anybody already implemented this as a separate tool? ___ 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 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? -- Lars Aronsson (l...@aronsson.se) Aronsson Datateknik - http://aronsson.se ___ 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 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making my $wgHooks['SkinTemplateNavigation'] morefuture-proof
jida...@jidanni.org wrote in message news:87vd1p3891@jidanni.org... Maybe I should use isset()s every step of the way, lest users see embarrassing warnings one day when you fellows change something. Or perhaps no isset()s, that way users will notify me that something has changed in your structure, and I can adapt to get my function back working again. Isn't that what release notes are for? --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Cross-wiki user talk notification
Platonides platoni...@gmail.com wrote in message news:4d34a033.9080...@gmail.com... CentralAuth is not really an entry level extension, but you may have luck since you would just be adding hooks. Now there's the understatement of the week... :-D --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Cross-wiki user talk notification
On Mon, Jan 17, 2011 at 3:58 PM, Happy-melon happy-me...@live.com wrote: Platonides platoni...@gmail.com wrote in message news:4d34a033.9080...@gmail.com... CentralAuth is not really an entry level extension, but you may have luck since you would just be adding hooks. Now there's the understatement of the week... :-D --HM Glue! I need Glue! -- -george william herbert george.herb...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Cross-wiki user talk notification
On 11-01-17 04:09 PM, George Herbert wrote: On Mon, Jan 17, 2011 at 3:58 PM, Happy-melonhappy-me...@live.com wrote: Platonidesplatoni...@gmail.com wrote in message news:4d34a033.9080...@gmail.com... CentralAuth is not really an entry level extension, but you may have luck since you would just be adding hooks. Now there's the understatement of the week... :-D --HM Glue! I need Glue! Just use the duct tape. ~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
