Re: [Wikitech-l] wikipedia is one of the slower sites on the web
Hi! I.e., only about a quarter of users have been ported to user_properties. Why wasn't a conversion script run here? In theory if all properties are at defaults, user shouldn't be there. The actual check should be against the blob field. Domas ___ 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 Mon, Aug 2, 2010 at 5:35 PM, Domas Mituzas midom.li...@gmail.com wrote: Hi! I.e., only about a quarter of users have been ported to user_properties. Why wasn't a conversion script run here? In theory if all properties are at defaults, user shouldn't be there. The actual check should be against the blob field. That's what he did. Read the query. -- Andrew Garrett http://werdn.us/ ___ 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
That's what he did. Read the query. ;-) thats what happens when email gets ahead of coffee. Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki version statistics
Hoi, The big problem with upgrading MediaWiki is the upgrading of extensions. It is not documented anywhere if extensions will work with a specific release of MediaWiki. Being able to install extensions is a great thing when you know upfront that the extensions you are interested in will actually work and not crash your installation. Thanks, GerardM On 2 August 2010 02:14, Jeroen De Dauw jeroended...@gmail.com wrote: A quick glance at the WP site docs didn't answer the question of how (or if) they secure this process. Asking would probably be good (whoever's doing the updater work). I've been looking at how WP works here and concluded this is basically not documented at all (from a developers perspective). On the WP IRC nobody seems to know anything about it, and my looking through the code itself has gotten me few insights into how updates and installation is secured. If anyone know more about this (esp what's up with the WP deployment repository), please contact me, this would be of great help for my GSoC project. -- Jeroen De Dauw * http://blog.bn2vs.com * http://wiki.bn2vs.com Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Question about oldest Wikipedia dump available for different Wikipedias
Yep, thanks to your email, I realized a mini dump extracted randomly is enough for my purposes. Thanks Ilmari! P. On Tue, Jul 20, 2010 at 1:25 PM, Ilmari Karonen nos...@vyznev.net wrote: On 07/20/2010 09:51 AM, paolo massa wrote: Thanks Gregor and yes, you are right. I didn't think about your suggestion before, sorry. The fact is that I wrote a script running on the pages-meta-current.xml because it is much smaller and manageable but, you are right: I can use the revision of the page I'm interested that is in pages-meta-history.xml If you're only interested in a small number of pages, you can get an up-to-date mini dump through Special:Export. See http://meta.wikimedia.org/wiki/Help:Export and http://www.mediawiki.org/wiki/Export for details. Alternatively, you can also fetch page histories through the API: http://www.mediawiki.org/wiki/API:Query_-_Properties#revisions_.2F_rv -- Ilmari Karonen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- -- Paolo Massa Email: paolo AT gnuband DOT org Blog: http://gnuband.org ___ 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 28 July 2010 21:13, jida...@jidanni.org wrote: Seems to me playing the role of the average dumb user, that en.wikipedia.org is one of the rather slow websites of the many websites I browse. No matter what browser, it takes more seconds from the time I click on a link to the time when the first bytes of the HTTP response start flowing back to me. Seems facebook is more zippy. It seems fast here: 130ms. The first load of the homepage can be slow: http://zerror.com/unorganized/wika/lader1.png http://en.wikipedia.org/wiki/Main_Page (I need a bigger monitor, the escalator don't fit on my screen) -- -- ℱin del ℳensaje. ___ 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 2 August 2010 12:13, Oldak Quill oldakqu...@gmail.com wrote: On 28 July 2010 20:13, jida...@jidanni.org wrote: Seems to me playing the role of the average dumb user, that en.wikipedia.org is one of the rather slow websites of the many websites I browse. No matter what browser, it takes more seconds from the time I click on a link to the time when the first bytes of the HTTP response start flowing back to me. Seems facebook is more zippy. Maybe Mediawiki is not optimized. For what it's worth, Alexa.com lists the average load time of the websites they catalogue. I'm not sure what the metrics they use are, and I would guess they hit the squid cache and are in the United States. Alexa.com list the following average load times as of now: wikipedia.org: Fast (1.016 Seconds), 74% of sites are slower. facebook.com: Average (1.663 Seconds), 50% of sites are slower. An addendum to the above message: According to the Alexa.com help page Average Load Times: Speed Statistics (http://www.alexa.com/help/viewtopic.php?f=6t=1042): The Average Load Time ... [is] based on load times experienced by Alexa users, and measured by the Alexa Toolbar, during their regular web browsing. So although US browsers might be overrepresented in this sample (I'm just guessing, I have no figures to support this statement), the Alexa sample should include many non-US browsers, assuming that the figure reported by Alexa.com is reflective of its userbase. -- Oldak Quill (oldakqu...@gmail.com) ___ 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
2010/8/2 Tei oscar.vi...@gmail.com: Maybe a theme can get the individual icons that the theme use, and combine it all in a single png file. This technique is called spriting, and the single combined image file is called a sprite. We've done this with e.g. the enhanced toolbar buttons, but it doesn't work in all cases. Maybe the idea than resource=file must die in 2011 internet :-/ The resourceloader branch contains work in progress on aggressively combining and minifying JavaScript and CSS. The mapping of one resource = one file will be preserved, but the mapping of one resource = one REQUEST will die: it'll be possible, and encouraged, to obtain multiple resources in one request. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki version statistics
We branch and tag extensions along with versions of MediaWiki, so the code found at http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_15_5/extensions/ is supposed to work with MW 1.15.5. However, this assumes that the trunk version of each extension worked with the trunk version of MW at the time of the branch point, which is not always the case and is the responsibility of the extension maintainer. Versioned releases can also be downloaded through ExtensionDistributor at mediawiki.org, although ED breaks all the time and we've been getting lots of questions in #mediawiki from people whose wiki broke because they installed the trunk version of ParserFunctions (downloaded through ED) with MediaWiki 1.15. Though branches, tags, and the extension distributor exist, in reality none of them come even close to solving the problem. The issue is, none of these things allow an extension author to properly match a version of an extension to a version of MediaWiki. The solution I take is to always have my extension useable in the trunk version, and backwards compatible to as many versions of MediaWiki as possible. This is a problem we need to solve. This is one of the things that makes upgrading MediaWiki a crap shoot. V/r, Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki version statistics
I've been looking at how WP works here and concluded this is basically not documented at all (from a developers perspective). On the WP IRC nobody seems to know anything about it, and my looking through the code itself has gotten me few insights into how updates and installation is secured. If anyone know more about this (esp what's up with the WP deployment repository), please contact me, this would be of great help for my GSoC project. Would it not be enough to hash all extensions on the distributor side, and to check the hash sum on the client side using https for the connection? Respectfully, Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki version statistics
On Fri, Jul 30, 2010 at 06:35, Tim Starling tstarl...@wikimedia.org wrote: However, the statistics presented by Qualys show that an alarming number of people are running versions of MediaWiki older than 1.14.1, which was the most recent fix for an XSS vulnerability exploitable without special privileges. There is certainly room for us to do better. I haven't read all the documents, but have these researchers taken into account backported fixes? My gut feeling is that the preference for 1.12 is simply due to its inclusion in Debian stable [1]. The maintainer seems to be actively backporting security fixes [2], so while I agree that these versions may enjoy less community support, they should not be considered broken on the basis of the version number alone. This, of course, unless it is certain that some vulnerabilities are still present in the Debian version. If you are aware of the existence of such a problem, I would recommend you contact secur...@debian.org. Otherwise, the situation might not be as dangerous as it seems. On the topic of facilitating upgrades: perhaps we should emphasize the option to install and upgrade using SVN, which is probably very convenient for users that are comfortable with the command line. Moodle has this in the official documentation and I find it very useful [3]. SVN could also be handy as the backend for a user-friendly upgrade procedure, as it already deals with local modifications and such. [1] http://packages.debian.org/search?keywords=mediawiki [2] http://packages.debian.org/changelogs/pool/main/m/mediawiki/mediawiki_1.12.0-2lenny5/changelog [3] http://docs.moodle.org/en/Upgrading#Using_CVS ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is exactly needed for setting up a new language edition of WM project?
(CCing Rob and Jens who've traditionally been the major wiki creators and also Roan, who helps out a lot. :-)) On Mon, Aug 2, 2010 at 9:45 AM, Milos Rancic mill...@gmail.com wrote: Please, tell me which data you need for setting up a project? According to my information, data are: * language I don't think they need the language name (either in English or in the local language). If the project is approved, then it must have the interface translated, which would mean that it's already defined in Names.php. * language code * type of project (Wikipedia, Wikinews etc.) * logo * the name of project in local language * the name of the project namespace * the name of the project talk namespace It looks like from bug 14252 comment 7 https://bugzilla.wikimedia.org/show_bug.cgi?id=14252#c7 that we don't actually need the project talk namespace, if everything is properly defined in Messages*.php. Anything else needed? ...and anything else wanted in a perfect world? (For example, a logo isn't technically *needed* but it's easier to have them setup and get everything working right away, in the initial bug request, than to try to track someone down later.) -- Casey Brown Cbrown1023 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki version statistics
On 02.08.2010, 18:01 Jacopo wrote: My gut feeling is that the preference for 1.12 is simply due to its inclusion in Debian stable [1]. The maintainer seems to be actively backporting security fixes [2], so while I agree that these versions may enjoy less community support, they should not be considered broken on the basis of the version number alone. This, of course, unless it is certain that some vulnerabilities are still present in the Debian version. If you are aware of the existence of such a problem, I would recommend you contact secur...@debian.org. Otherwise, the situation might not be as dangerous as it seems. They haven't backported security fixes from 1.15.4 and 1.15.5 yet, which are seveal months old (OMG disclosure!) And who knows what other problems (including security flaws) may still be there, as stabe versions usually get much less attention and testing. -- Best regards, Max Semenik ([[User:MaxSem]]) ___ 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 Mon, Aug 2, 2010 at 11:24 PM, Roan Kattouw roan.katt...@gmail.com wrote: The resourceloader branch contains work in progress on aggressively combining and minifying JavaScript and CSS. The mapping of one resource = one file will be preserved, but the mapping of one resource = one REQUEST will die: it'll be possible, and encouraged, to obtain multiple resources in one request. Does that approach gain much over HTTP pipelining? -- John Vandenberg ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is exactly needed for setting up a new language edition of WM project?
On Mon, Aug 2, 2010 at 11:45 PM, Milos Rancic mill...@gmail.com wrote: Please, tell me which data you need for setting up a project? According to my information, data are: * language * language code * type of project (Wikipedia, Wikinews etc.) * logo * the name of project in local language * the name of the project namespace * the name of the project talk namespace Anything else needed? I think Wikisource is now at the stage that any new projects should be using the Proofread Page extension. This extension has two namespaces, 'Index' and 'Page', and they are in the messages, so translations for them (and the talk namespaces) are necessary. http://translatewiki.net/w/i.php?title=Special%3ATranslatetask=viewgroup=ext-proofreadpagelanguage=frlimit=100 -- John Vandenberg ___ 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 2 August 2010 15:24, Roan Kattouw roan.katt...@gmail.com wrote: ... Maybe the idea than resource=file must die in 2011 internet :-/ The resourceloader branch contains work in progress on aggressively combining and minifying JavaScript and CSS. The mapping of one resource = one file will be preserved, but the mapping of one resource = one REQUEST will die: it'll be possible, and encouraged, to obtain multiple resources in one request. :-O That is awesome solution, considering the complex of the real world problems. Elegant, and probably as side effect may remove some bloat. -- -- ℱin del ℳensaje. ___ 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 Mon, Aug 2, 2010 at 10:50 AM, John Vandenberg jay...@gmail.com wrote: Does that approach gain much over HTTP pipelining? Yes, because browsers don't HTTP pipeline in practice, because transparent proxies at ISPs cause sites to break if they do that, and there's no reliable way to detect them. Opera does pipelining and blacklists bad ISPs or something, I think. See: https://bugzilla.mozilla.org/show_bug.cgi?id=264354 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki version statistics
Would it not be enough to hash all extensions on the distributor side, and to check the hash sum on the client side using https for the connection? I guess this would suffice for ensuring integrity, but what about the other distribution meta-data? Where to get it from, how to manipulate it, and how to format it? Since WP and PEAR have systems that do (now) well at that, it makes a lot more sense to just copy what they do instead of trying to re-invent the wheel and make all the same mistakes they did. -- Jeroen De Dauw * http://blog.bn2vs.com * http://wiki.bn2vs.com Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Developing true WISIWYG editor for media wiki
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. So we decided to write to this list. Any feedback/suggestion will be very helpful. P.S. Screen cast demonstrating our experimental client for Trac wiki http://www.screencast.com/t/MDkzYzM4 Regards, Pavel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is exactly needed for setting up a new language edition of WM project?
Casey, thanks for pointing to the previous bug request! John, thanks for the info for Wikisource! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki version statistics
Jeroen De Dauw wrote: Would it not be enough to hash all extensions on the distributor side, and to check the hash sum on the client side using https for the connection? I guess this would suffice for ensuring integrity, but what about the other distribution meta-data? Where to get it from, how to manipulate it, and how to format it? Since WP and PEAR have systems that do (now) well at that, it makes a lot more sense to just copy what they do instead of trying to re-invent the wheel and make all the same mistakes they did. I would make the system based on our repository. So the MediaWiki update subsystem would have a base url like http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_16/ Then it would fetch a file called http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_14/VERSIONS containing all the extensions, their version and an optional url. If the version is newer than the installed one, it needs updating. The presence of a special tag on the file for a url would send it to a new major version: http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_15/VERSIONS which would be recursed to the latest mediawiki branch so it can offer the really latest one for download (but note that it shouldn't use extensions from a newer branch without updating mediawiki). If an extension doens't provide a url, treat it as extensions/extension name with a fallback to eg. extensions/archive/extensions/extension name.php (so we can safely redirect old extensions to new ones, etc.) The VERSIONS file can be easily generated by an script reading their $wgExtensionCredits. Releasing a new extension would be increasing its version and recreating the VERSIONS file. Whereas if you the version isn't changed, new uploads would still get the improvements (yes, this scheme would also work for trunk). To get an extension there, third party extension creators could request subversion access and place their extension there (the best option imho, since then they can be noticed when doing changes in core), get a developer to list their external url, or instruct the users to add their own repository to the repo list. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Showing bytes added/removed in each edit in View history and User contributions
On Wed, Jul 28, 2010 at 2:37 AM, church.of.emacs.ml church.of.emacs...@googlemail.com wrote: On 07/28/2010 04:57 AM, Jason Spiro wrote: I think it would be nice for both View history[1] and User contributions to show bytes added/removed. This would make it easier to distinguish between small contributions from big ones: between multiple-sentence additions and small typo fixes. I'm not sure we should even show byte counts by default. It must be very confusing for newbies (especially if they don't know what a byte is). And it clutters up the UI. Perhaps make it optional and disable by default? It's mostly targeted at experienced users anyway. If we'd make it optional, I don't think your proposal would be any problem (and as a Wikipedian I'd love to have that feature!). -- Tobias (User:Church of emacs) Newbies know what characters are, and the byte counts are really just character counts. If someone wants to see page history, then they probably also would benefit from knowing which edits are text additions and which are text removals, no? Has anyone ever done usability studies of newbies -- new Internet users, experienced Internet users who are non-editors, or new editors? Have the study conductors watched how they play with the history tools? Maybe you and I should each ask our moms to try the history tools and see how they react to seeing the history screens and the byte counts on those screens. By the way, why does page history say 12,345 bytes and not 12,345 characters? -- Jason Spiro: software/web developer, packager, trainer, IT consultant. I support Linux, UNIX, Windows, and more. Contact me to discuss your needs. +1 (416) 992-3445 / www.jspiro.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Showing bytes added/removed in each edit in View history and User contributions
On Mon, Aug 2, 2010 at 4:59 PM, Jason A. Spiro jasonspi...@gmail.com wrote: Has anyone ever done usability studies of newbies -- new Internet users, experienced Internet users who are non-editors, or new editors? Yep, that's what the Usability Initiative does. Have the study conductors watched how they play with the history tools? That I don't know. I don't know if descriptions of the Usability Initiative's studies are all public, or what. Maybe one of them could fill us in. My personal guess is that the best usability for newbies would be to hide as many things as possible to make it less intimidating. By the way, why does page history say 12,345 bytes and not 12,345 characters? Because it's 12,345 bytes, not 12,345 characters. :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Showing bytes added/removed in each edit in View history and User contributions
On Mon, Aug 2, 2010 at 5:18 PM, Aryeh Gregor simetrical+wikil...@gmail.com wrote: On Mon, Aug 2, 2010 at 4:59 PM, Jason A. Spiro jasonspi...@gmail.com wrote: Has anyone ever done usability studies of newbies -- new Internet users, experienced Internet users who are non-editors, or new editors? Yep, that's what the Usability Initiative does. Ah, I just took a look at their website now: http://usability.wikimedia.org/wiki/Main_Page Have the study conductors watched how they play with the history tools? That I don't know. I don't know if descriptions of the Usability Initiative's studies are all public, or what. Maybe one of them could fill us in. My personal guess is that the best usability for newbies would be to hide as many things as possible to make it less intimidating. By the way, why does page history say 12,345 bytes and not 12,345 characters? Because it's 12,345 bytes, not 12,345 characters. :) Does the difference really matter so much that we must really use the more-obscure and more-technical term bytes? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Showing bytes added/removed in each edit in View history and User contributions
On Mon, Aug 2, 2010 at 5:28 PM, Jason A. Spiro jasonspi...@gmail.com wrote: Does the difference really matter so much that we must really use the more-obscure and more-technical term bytes? In English, maybe not. In a lot of languages, they'll differ by a somewhat unpredictable factor that can be as high as three. The sane thing would be to just make the counts be in characters rather than bytes to begin with, of course -- it's hardly difficult. I imagine Chinese people are puzzled when RC reports +3 and there was only one character added. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Showing bytes added/removed in each edit in View history and User contributions
Στις 02-08-2010, ημέρα Δευ, και ώρα 17:36 -0400, ο/η Aryeh Gregor έγραψε: On Mon, Aug 2, 2010 at 5:28 PM, Jason A. Spiro jasonspi...@gmail.com wrote: Does the difference really matter so much that we must really use the more-obscure and more-technical term bytes? In English, maybe not. In a lot of languages, they'll differ by a somewhat unpredictable factor that can be as high as three. The sane thing would be to just make the counts be in characters rather than bytes to begin with, of course -- it's hardly difficult. I imagine Chinese people are puzzled when RC reports +3 and there was only one character added. I would love it if the indicator was in characters instead of bytes. That's more meaningful for almost every project. Readers are looking at text after all, not at raw strings. Ariel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Showing bytes added/removed in each edit in View history and User contributions
On 08/03/2010 01:48 AM, Ariel T. Glenn wrote: I would love it if the indicator was in characters instead of bytes. That's more meaningful for almost every project. Readers are looking at text after all, not at raw strings. Ariel That would require introduction of another field to revision table, since byte count is not convertible to characher count in UTF-8. --vvv ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Showing bytes added/removed in each edit in View history and User contributions
2010/8/2 Aryeh Gregor simetrical+wikil...@gmail.com: That I don't know. I don't know if descriptions of the Usability Initiative's studies are all public, or what. Maybe one of them could fill us in. There are videos around, yes, but I'm not sure we have reports. Digging around on usabilitywiki should turn stuff up, or maybe someone closer to these tests (both geographically and in terms of expertise) can provide more exact links. The tests were specifically focused on editing and general navigation, and did not test the history view AFAIK. 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
Павел Петроченко 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. So we decided to write to this list. Any feedback/suggestion will be very helpful. P.S. Screen cast demonstrating our experimental client for Trac wiki http://www.screencast.com/t/MDkzYzM4 Regards, Pavel 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. 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 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 :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Showing bytes added/removed in each edit in View history and User contributions
On Mon, Aug 2, 2010 at 6:45 PM, Victor Vasiliev vasi...@gmail.com wrote: That would require introduction of another field to revision table, since byte count is not convertible to characher count in UTF-8. No, we'd just have to repurpose rev_len to mean characters instead of bytes, and update all the old rows. We don't actually need the byte count for anything, do we? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] About moving (was: Showing bytes added/removed in each edit in View history and User contributions)
Roan Kattouw wrote: 2010/8/2 Aryeh Gregor: That I don't know. I don't know if descriptions of the Usability Initiative's studies are all public, or what. Maybe one of them could fill us in. There are videos around, yes, but I'm not sure we have reports. Digging around on usabilitywiki should turn stuff up, or maybe someone closer to these tests (both geographically and in terms of expertise) can provide more exact links. The tests were specifically focused on editing and general navigation, and did not test the history view AFAIK. Roan Kattouw (Catrope) Were they asked to Make this page appear under this different name? I think that's something whose usability *decreased* with vector. Maybe a tab is not the best interface, but even having it on the sidebar would have been preferable. https://bugzilla.wikimedia.org/show_bug.cgi?id=24481 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On Mon, Aug 2, 2010 at 10:16 AM, Lane, Ryan ryan.l...@ocean.navo.navy.mil wrote: Please Debian, keep your version of MediaWiki up to date at least to the oldest stable release, and please send your fixes upstream when you find unfixed bugs. I am not a Debian developer, and I agree that sending fixes upstream is good. But surely you're aware that the whole point of Debian stable is that it does ***not*** change to newer versions of programs after release, apart from security fixes? Debian is well known for taking the word stable seriously (e.g. [1]) and it's a reason people choose them. - Carl [1]: http://www.debian.org/doc/manuals/debian-faq/ch-getting.en.html#s-updatestable ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
Excerpts from Carl (CBM)'s message of Mon Aug 02 19:06:42 -0400 2010: I am not a Debian developer, and I agree that sending fixes upstream is good. But surely you're aware that the whole point of Debian stable is that it does ***not*** change to newer versions of programs after release, apart from security fixes? Debian is well known for taking the word stable seriously (e.g. [1]) and it's a reason people choose them. Ryan's complaint is: 1. Distributors frequently get backported patches wrong (usually due to a lack of expertise or manpower), and 2. Distributors roll patches without telling upstream developers who would happily accept them into the mainline. However, upstream developers are often guilty of ignoring a distribution's needs, so it goes both ways. Cheers, Edward ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
I am not a Debian developer, and I agree that sending fixes upstream is good. But surely you're aware that the whole point of Debian stable is that it does ***not*** change to newer versions of programs after release, apart from security fixes? Debian is well known for taking the word stable seriously (e.g. [1]) and it's a reason people choose them. Are they also backporting security fixes for all extensions as well? If not, then they are doing a serious disservice to their users. Some extensions have had some *really* serious vulnerabilities. We generally mark these as such when we find them, but the warnings go away when the vulnerabilities are fixed. Unfortunately for those using old versions of MediaWiki, they may never know the extension was vulnerable for the version they are downloading. Maybe we should be more vigilant about how we mark things, but it is difficult to manage this for all extensions, especially since they aren't all code reviewed. If Debian doesn't feel they should keep supported versions in their repos, maybe they shouldn't distribute MediaWiki. Respectfully, Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About moving (was: Showing bytes added/removed in each edit in View history and User contributions)
2010/8/3 Platonides platoni...@gmail.com: Were they asked to Make this page appear under this different name? No, they were not. As I said, the focus was editing and general site navigation, not viewing history, moving pages or a zillion other things that, while they may appear elementary to us, are rather advanced actions from a new user's perspective. I don't doubt that the usability of all those things could be improved, but then looking for features needing usability improvement in MediaWiki is about as hard as looking for guns at an NRA rally, a Starbucks in central London, things named after Robert C. Byrd in West Virginia or islands you never knew existed in the South Pacific: they're everywhere you look. The usability initiative had to limit its scope. I can't really offer an informed opinion on where the move link belongs usability-wise, I'll leave that to the people that actually know stuff about user experience and user interface design. What I can do is point out that the studies were limited to asking people to find a page (both in terms of navigation and search) and edit it (both in terms of finding the edit button and doing various things on the edit page). If an action doesn't take place on the edit page and isn't one that is commonly used to get to an edit page, it probably wasn't tested. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On Mon, Aug 2, 2010 at 7:35 PM, Ryan Lane rlan...@gmail.com wrote: Are they also backporting security fixes for all extensions as well? I would assume that Debian, ideally, applies security patches for extensions they distribute themselves. Programs a user has installed outside the Debian system are always going to be the responsibility of the user. Of course, if Debian upgraded their stable version of Mediawiki to the newest version, and my production server was running a custom extension that only worked with the previous version of Mediawiki that Debian called stable, I'd be pissed. If Debian doesn't feel they should keep supported versions in their repos, maybe they shouldn't distribute MediaWiki. That is, seriously, an absurd attitude for a Mediawiki Developer to have. It reflects a fundamental misunderstanding of the meaning of Debian's stable version system. Note that Debian stood up to Mozilla corp. when Mozilla attempted to stop Debian uploading security patches to stable versions [1]. Surely Mediawiki would have much less persuasive power telling them to stop. I'm exiting of this discussion at this point. I've made the point I wanted to make, compelling or not, and I'm afraid I'm drifting off topic. - Carl [1]: http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
If Debian doesn't feel they should keep supported versions in their repos, maybe they shouldn't distribute MediaWiki. That is, seriously, an absurd attitude for a Mediawiki Developer to have. It reflects a fundamental misunderstanding of the meaning of Debian's stable version system. Note that Debian stood up to Mozilla corp. when Mozilla attempted to stop Debian uploading security patches to stable versions [1]. Surely Mediawiki would have much less persuasive power telling them to stop. I'm exiting of this discussion at this point. I've made the point I wanted to make, compelling or not, and I'm afraid I'm drifting off topic. I'm not saying we should tell them to stop. They can distribute whatever they want. I'm simply saying their stable version is likely doing more harm than good, and that just because they can distribute something in their somewhat insane way, doesn't mean they should. Respectfully, Ryan Lane ___ 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 08/01/2010 10:55 PM, Aryeh Gregor wrote: One easy hack to reduce this problem is just to only provide a few options for stub threshold, as we do with thumbnail size. Although this is only useful if we cache pages with nonzero stub threshold . . . why don't we do that? Too much fragmentation due to the excessive range of options? Couldn't you just tag every internal link with a separate class for the length of the target article, and then use different personal CSS to set the threshold? The generated page would be the same for all users: a href=My_Article class=134_byte_articleMy Article/a -- 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] Showing bytes added/removed in each edit in View history and User contributions
On Mon, Aug 2, 2010 at 5:36 PM, Aryeh Gregor simetrical+wikil...@gmail.com wrote: On Mon, Aug 2, 2010 at 5:28 PM, Jason A. Spiro jasonspi...@gmail.com wrote: Does the difference really matter so much that we must really use the more-obscure and more-technical term bytes? In English, maybe not. In a lot of languages, they'll differ by a somewhat unpredictable factor that can be as high as three. The sane thing would be to just make the counts be in characters rather than bytes to begin with, of course -- it's hardly difficult. I imagine Chinese people are puzzled when RC reports +3 and there was only one character added. A question for the non-English wiki contributors out there: Do you honestly care that MediaWiki shows byte counts and not character counts? If so, why do you care? Best regards, -Jason ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Showing bytes added/removed in each edit in View history and User contributions
On Tue, Aug 3, 2010 at 2:53 PM, Jason A. Spiro jasonspi...@gmail.com wrote: A question for the non-English wiki contributors out there: Do you honestly care that MediaWiki shows byte counts and not character counts? If so, why do you care? If the count itself is useful (I don't think it is), then it is probably way more useful when it's remotely accurate. Of course, if the inaccuracy doesn't matter, then perhaps we could just display random numbers next to the changes. That might be just as helpful, and will save us a lot of trouble. -- Andrew Garrett http://werdn.us/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] chanfing main page articles from drop down. help required
Hi, i've installed mediawiki for a wiki project. now we have 4 sections on main page . like there are on wikipedia main page. Now as its done in wikipedia these 4 boxes are tables and update on date criteria. Now i want to do is to give some kind a navigation bar like drop down or paging. so when user selects page from drop down the all 4 pages are updated with relevant articles. to clear more. how the for parts of table can be updated . and how to put combo box ( which is already filled with page numbers / article topics) and which user selects any page from drop down all the 4 table rows are updated. any body help me . im new to media wiki searched alot. but didnot get any thing. or material or example. if i ve to made my extension then how ill write . means what is will the flow. how it will be pluged in the mediawiki and runs smoothly any article example. e-book from where i can read step by step. wating Noman ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: changing main page articles from drop down. help required
-- Forwarded message -- From: Noman nom...@gmail.com Date: Tue, Aug 3, 2010 at 10:04 AM Subject: chanfing main page articles from drop down. help required To: wikitech-l@lists.wikimedia.org how ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Showing bytes added/removed in each edit in View history and User contributions
On 8/3/10, Aryeh Gregor simetrical+wikil...@gmail.com wrote: No, we'd just have to repurpose rev_len to mean characters instead of bytes, and update all the old rows. We don't actually need the byte count for anything, do we? Byte count is used. For example in Chinese Wikipedia, one of the criteria of Did you know articles is = 3000 bytes. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
