Re: [Wikitech-l] Fwd: [ PRIVACY Forum ] French homeland intelligence threatens a volunteer sysop to delete a Wikipedia Article
On 8 April 2013 18:21, Chris Steipp cste...@wikimedia.org wrote: Technical measures to prevent this could be interesting though. Requiring that actions like delete be first nominated by another admin in a different jurisdiction could be an interesting feature, although probably totally impractical. If other people have ideas, I wouldn't mind hearing them. I think it is rare enough to just deal with on a case-by-case basis. It isn't hard to revert a deletion. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [ PRIVACY Forum ] French homeland intelligence threatens a volunteer sysop to delete a Wikipedia Article
On 8 April 2013 18:33, Tyler Romeo tylerro...@gmail.com wrote: Not that it's wikitech related, but please tell me the article was undeleted. Undeleted and then promptly translated into a dozen new languages! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Corrupt pages on English Wikipedia
I've just had a colleague send me links to a couple of English Wikipedia articles that were displaying as complete garbage - it looked like corrupt character encoding or something (there was no UI - just a page full of random characters and boxes). Running ?action=purge on them sorted it out, but if he hit upon two corrupted pages in a few minutes, there are probably more. Does anyone know anything about it? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Corrupt pages on English Wikipedia
On 20 February 2013 12:11, Andre Klapper aklap...@wikimedia.org wrote: On Wed, 2013-02-20 at 12:08 +, Thomas Dalton wrote: I've just had a colleague send me links to a couple of English Wikipedia articles that were displaying as complete garbage - it looked like corrupt character encoding or something (there was no UI - just a page full of random characters and boxes). Running ?action=purge on them sorted it out, but if he hit upon two corrupted pages in a few minutes, there are probably more. Does anyone know anything about it? Not without a testcase (URL) to start investigating. :) I've fixed the ones I know about, so I don't know if they'll be much help (which is why I didn't specify them before). If it does help, they were: http://en.wikipedia.org/wiki/Neil_Clark_Warren and http://en.wikipedia.org/wiki/Pepper_Schwartz (You can draw your own conclusions from my colleague's office reading habits!) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Corrupt pages on English Wikipedia
On 20 February 2013 12:43, Tim Starling tstarl...@wikimedia.org wrote: It's not a test case after you've run action=purge on it. Which is why I didn't bother including the URLs in the initial report. If you want to report things like this, it's best if you don't run action=purge, or even report it to anyone who might be inclined to do such a thing. Cache-related test cases are very fragile, so it takes some care to get them to a developer intact. My top priority was helping the person that reported it to read the page they wanted to read. A little gratitude to someone trying to help you fix a problem wouldn't go amiss... ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Corrupt pages on English Wikipedia
On 20 February 2013 16:32, bawolff bawolff...@gmail.com wrote: A little gratitude to someone trying to help you fix a problem wouldn't go amiss... We appreciate the bug report, we just can't do anything about it without more information. To give a (not entirely fair) comparison, imagine someone posted on your talk page that there was a spelling error on Wikipedia. I assume you would respond to such a report with where?, it wouldn't be because you're ungrateful that you respond like that, but simply that you cannot fix the issue without more information (Wikipedia is a big place). The situation here is somewhat similar. We're grateful for the report, but would need more information before we can do anything about it. My actual question was Does anyone know anything about it? - I was trying to determine if this was a known problem, which would help determine the next step. I think I supplied enough information for that purpose. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki
So, the new proposal: There would be a top level outline policy - a small number of browsers are supported (i.e., WMF will keep spending money until they work): * Desktop: Current and immediately-previous versions of Chrome, Firefox, MSIE and Safari * Tablet: Current versions of iOS/Safari; Current and immediately-previous ones of Android * Mobile: Current versions of iOS/Safari; Current and the five previous ones of Android[*] Anything not in this list may happen to work but WMF Engineering will not spend resources (read, developer time) on it. If a volunteer is willing to work like hell to make, say, the VisualEditor work in Opera we would try to support them by reviewing/accepting patches, but nothing more than that. It doesn't mean we would go out of our way to break previous browsers as they leave support, but we would not hold ourselves back from useful development solely because it might break browsers that we've actively decided not to support. Support is a very vague term. I think we need to recognise that, in reality, we will support different browsers to different degrees. There is a big difference between everything works exactly as intended and you can read articles with no noticeable problems, but some advanced features fail gracefully. Your list may be appropriate for the former, but we should support significantly more browsers (the 0.1% threshold, perhaps) at the latter level (which probably won't involve too much work, as long as you're happy to just blacklist things if they're not easy to fix). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] IPv6 usage on Wikimedia?
On 17 September 2012 11:25, David Gerard dger...@gmail.com wrote: Do we have any stats on IPv6 accesses and edits on Wikimedia sites? I see this page on stats, which suggests it's literally so small we can't even count it: http://stats.wikimedia.org/wikimedia/squids/SquidReportCountryData.htm Is that actually the case? 'Cos we do know IPv6 edits occur, therefore IPv6 page views occur. That's a split by country, why would it mention IPv6? Judging by the number of anonymous edits coming from IPv6 addresses, there might be fairly high usage. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] IPv6 usage on Wikimedia?
Are you sure about that number? There are a suspicious number of zeros in it! On Sep 17, 2012 6:51 PM, Diederik van Liere dvanli...@wikimedia.org wrote: On World IP6 day (June 6th 2012), we had about 5000 IP6 hits, however, for the first 17 days of September we had a total of 1,000,032,000 hits coming from IP6 addresses. This is based on the sampled squid log data. Best, Diederik On Mon, Sep 17, 2012 at 8:03 AM, David Gerard dger...@gmail.com wrote: On 17 September 2012 12:36, Thomas Dalton thomas.dal...@gmail.com wrote: On 17 September 2012 11:25, David Gerard dger...@gmail.com wrote: Do we have any stats on IPv6 accesses and edits on Wikimedia sites? I see this page on stats, which suggests it's literally so small we can't even count it: http://stats.wikimedia.org/wikimedia/squids/SquidReportCountryData.htm Is that actually the case? 'Cos we do know IPv6 edits occur, therefore IPv6 page views occur. That's a split by country, why would it mention IPv6? Judging by the number of anonymous edits coming from IPv6 addresses, there might be fairly high usage. Indeed. So where are the actual stats? - d. ___ 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 mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] scaled media (thumbs) as *temporary* files, not stored forever
On 3 September 2012 17:10, Isarra Yos zhoris...@gmail.com wrote: On 03/09/2012 05:33, Magnus Manske wrote: Illustrating the problem of manual right/left aligned thumbnails and elements by using slightly different CSS: http://toolserver.org/~magnus/redefined/?page=San%20Francisco Magnus That looks like as much a problem with the general design there as with the use of images on the page itself, though. I agree. The skin not wrapping text around the images isn't caused by users having a choice of what side of the page to put the image on. It's caused by the skin being badly designed... ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] scaled media (thumbs) as *temporary* files, not stored forever
On Aug 31, 2012 11:52 PM, Brion Vibber br...@pobox.com wrote: * Definitely don't have left right or center options. Can you elaborate on that? The positioning of images can make a big difference to how a page looks. Do you really think you can automate it in a way that makes pages always look good? It's also useful to be able to know where an image is going to be displayed so you can say thing like as can be seen in the image to the right. Getting images to work well on phones and tablets probably requires more user control, not less. It would be useful to be able to specify whether an image is vital to the article and should always be displayed or if it is just there to look nice and can be skipped if there isn't much screen space. (Sensible defaults are a must, of course.) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Can we make an acceptable behavior policy? (was: Re: Mailman archives broken?)
On 17 August 2012 02:42, Ryan Lane rlan...@gmail.com wrote: What is your plan to clean up the mess you made? I need to call you out on this MZ. This is an incredibly rude way to phrase this. I get that our community tends to accept this kind of behavior, but I think we should really put effort into coming up with some method of discouraging people from acting this way. It's a *slightly* rude way to phrase it. It's important not to overreact. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WikiMania?
There are probably 100 developers here! Go to some of the tech sessions and you'll meet them. On Jul 13, 2012 9:31 AM, Derric Atzrott datzr...@alizeepathology.com wrote: Out of curiosity, is there anyone else here at WikiMania from the mailing list? Thank you, Derric Atzrott Computer Specialist Alizee Pathology ___ 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] [Announcement] James Forrester joins WMF as Technical Product Analyst
James, you're emigrating? I never thought I'd see that... Congratulations, traitor! On 17 May 2012 17:52, Howie Fung hf...@wikimedia.org wrote: Everyone, It’s my pleasure to announce that James Forrester is joining our San Francisco office as a Technical Product Analyst, supporting the Visual Editor team. James started his work as a remote contractor yesterday and will be joining us in San Francisco later this year as a staff member. James will help prioritize the short term and long term work log on the Visual Editor, conduct user research, and incorporate community feedback into the development process. As many of you know, James is a long-time Wikimedian. He started contributing to English Wikipedia in October 2002, and was a founding member of their Arbitration Committee. He was also the movement’s volunteer Chief Research Officer, helping shepherd the predecessor of what is today the Research Committee, has for years been the “gopher-in-chief” at the Wikimania community conferences, and helped found Wikimedia UK in 2005. James joins us following a successful career in the UK government, where he implemented key open access and open government initiatives. Most recently, he was the acting Head of data.gov.uk, and then the Digital Engagement Policy Lead in the Government Digital Service, both at the Cabinet Office. James holds a Masters of Engineering in Computer Science from the University of Warwick. Beyond technology, James has strong interests in international politics, physics, communications, economics, law, the constitutional history of Britain, and education. Please join me in welcoming James! Howie ___ 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] Text browser users won't see your important site notice
On 20 January 2012 01:06, Ryan Lane rlan...@gmail.com wrote: No, there isn't a difference. A blackout where everyone sees a page with a particular message instead of the article they wanted is exactly the same as unscheduled downtime where everyone sees a page with a particular message instead of the article they wanted. If search engines and caches can survive one of them, they can survive both, since they are identical from an external perspective. I'm sorry. but this is silly. I have a hard time believing that you aren't simply trolling here. How is it silly? I'm not trolling, I just think the way the blackout was implemented looked really unprofessional and I can't see any good reason for not having done a better job. All we wanted was for anyone viewing any page on the site to see a particular static page rather than what they would usually see. That isn't difficult to do, as evidenced by the fact that it happens automatically whenever the site breaks. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Text browser users won't see your important site notice
On 19 January 2012 09:12, Platonides platoni...@gmail.com wrote: On 19/01/12 01:10, Thomas Dalton wrote: The sites have gone down accidentally on numerous occasions and any user trying to access them just got an error message. The world didn't seem to end on any of those occasions... There is a difference between accidentally breaking the site and pulling the plug on purpose. We had outages of several hours, but unless the blackout, the sysadmins were working on fixing it since they learned about it. Plus, I think you would need to go to the early days of Wikipedia to find an outage where it was unavailable for so long. No, there isn't a difference. A blackout where everyone sees a page with a particular message instead of the article they wanted is exactly the same as unscheduled downtime where everyone sees a page with a particular message instead of the article they wanted. If search engines and caches can survive one of them, they can survive both, since they are identical from an external perspective. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wednesday wikipedia shut down does not get through
On 19 January 2012 02:48, Daniel Friesen li...@nadir-seen-fire.com wrote: You do realize that going by what you are saying. If 503's weren't cached for that reason, then EVERY single request would be forwarded to the apaches. I'm talking about external caches, as I assumed everyone else was. The internal caches are entirely under the WMF's control so they can be made to do whatever the WMF wants them to do. There's no problem there. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Text browser users won't see your important site notice
On 18 January 2012 18:20, Dan Collins dcoll...@stevens.edu wrote: Michael, As was mentioned here, a 503 would be the most appropriate HTTP response code to serve. It would also prevent non-js users and text-only users from bypassing, it would avoid the flicker effect, and would cause search engines to correctly back off trying to index our pages. It would also correctly shut down all editing (if the site can not be read, why do you need emergency edit rights anyway?) I have no idea why this ineffective kludge was effected instead. I don't understand why it was done this way either... the consensus was for a full blackout, so why not just set all the squids to redirect to a page with the banner and explanation along with a 503 status code and be done with it? I was rather concerned by people thinking we need to allow emergency access - what kind of emergencies are going to mean people need Wikipedia? And is everyone having such an emergency going to have read the FAQ and know how to get around the blackout? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Text browser users won't see your important site notice
On 18 January 2012 19:32, Risker risker...@gmail.com wrote: On 18/01/2012, Thomas Dalton thomas.dal...@gmail.com wrote: snip I was rather concerned by people thinking we need to allow emergency access - what kind of emergencies are going to mean people need Wikipedia? And is everyone having such an emergency going to have read the FAQ and know how to get around the blackout? Speaking as one of the closers of the RFC, some of the things we were thinking of were a DMCA notice, Legal needing to get something taken down right now or some other OFFICE-type action, removal of an obvious copyright violation, information that needed to be suppressed, or just something that went wrong from the technical end of things and needed fixing right away. Remember this has sort of been put together with baling wire and sealing wax, and we wanted to make sure to leave a door open for unforeseen situations where it was possible to take immediate action if required. If the whole site is down, you don't really need to worry about takedown orders... Even if there was a need for an OFFICE action, people in the office are just a short walk away from the ops team that can do whatever needs doing. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Text browser users won't see your important site notice
On 18 January 2012 22:02, Risker risker...@gmail.com wrote: Actually, you do need to worry about takedown orders - the site is *not* shut down, it's accessible through Mobile and through very simple, easily discoverable methods. I know. That's what I'm saying I don't understand. If we're going to have a blackout, why not do it properly? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wednesday wikipedia shut down does not get through
On 18 January 2012 22:14, John Du Hart compwhi...@gmail.com wrote: Cache pollution. It would have to be a severely broken cache to be polluted by a 503. 503 is for temporary unavailability, you would be stupid to cache it. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Text browser users won't see your important site notice
On 18 January 2012 23:59, Ryan Lane rlan...@gmail.com wrote: So, this will be my last comment on this. In the time frame we had to implement this, it wasn't possible to do a 100% blackout that would have been completely impenetrable. There were a number of suggestions that could have blacked everything out completely, but very, very likely would have broken things in a way that would have lasted more than the blackout period. We have to consider: 1. Search engines 2. Our caches 3. Upstream caches 4. API users 5. Screen scrapers 6. Things we didn't have time to consider -- this is a big one The goal was to inform as many people as possible about the effects of the bills, and I think we were effective at doing so. The sites have gone down accidentally on numerous occasions and any user trying to access them just got an error message. The world didn't seem to end on any of those occasions... ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Email notification sender
On 3 January 2012 20:32, Strainu strain...@gmail.com wrote: I wouldn't be so fast in leaving only the sitename as sender name - a mail from Wikipedia would raise my (manual) spam alarms, just like emails from the Federal Bureau of Investigations or from [X] Bank. Why is Wikipedia more suspicious than Wikipedia mail? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Email notification sender
Why do email notifications from Wikipedia have the sender as MediaWiki Mail? Most Wikipedia users probably don't know what MediaWiki is. I suggest it be changed to Wikipedia or Wikipedia notifications or something like that. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Email notification sender
On 31 December 2011 18:24, Huib Laurens sterke...@gmail.com wrote: That we need to change in Wikimedia. Wikipedia is just a small part of the projects. Notifications from Wikipedia should say Wikipedia, notifications from Wikinews should say Wikinews, etc.. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Help us test the VisualEditor prototype
On Dec 14, 2011 3:16 PM, Daniel Barrett d...@vistaprint.com wrote: Thomas Dalton writes: The challenge is having pages that can be edited both by wysiwyg and in wikitext without the two tripping over each other. To address this, I think any visual editor project needs to decide which audience it's serving: - The average user - The average user AND power users If you're serving power users, the visual editor must perform powerful edits more quickly easily than typing wikitext directly. If you're serving only the average user, you don't have to worry about this, but complex wikitext (templates parser functions/tags) needs to be protected against breakage by the average user. The issue is that, even if power users don't use the new interface they still need to be able to use the old one to edit the same articles. If the wikitext created by the visual editor is unnecessarily complicated and unreadable (like the html produced by ms frontpage, for instance) then there is problem. Similarly, the visual editor needs to be able to parse even quite strangely written wikitext. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Help us test the VisualEditor prototype
On 14 December 2011 02:57, Neil Harris n...@tonal.clara.co.uk wrote: Once the wikitext parser (which is, of course, the hard part) is ready to be bolted in, that should give a big improvement in Wikipedia's accessibility for new editors -- almost everyone knows how to use a word processor. As you say, it's the wikitext bit that's hard. Without that, a wysiwyg editor is reasonably simple (we could have just used the one Wikia created, perhaps with a few modifications). The challenge is having pages that can be edited both by wysiwyg and in wikitext without the two tripping over each other. That's why I'm going to keep the cork firmly in the champagne bottle until we're asked to test that bit (I'll keep the bottle on ice, though, because this looks like a great start!). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Dropping the 'LATER' resolution in Bugzilla
On 29 November 2011 19:43, Daniel Friesen li...@nadir-seen-fire.com wrote: This - https://bugzilla.wikimedia.org/show_bug.cgi?id=18082 Is not really WONTFIX, nor FIXED, nor WORKSFORME... and do you really want it marked as an open bug when it won't be implemented at all for ages until browsers actually have feature support that would make it possible to implement? Sounds like a bad way to make our list of open bugs grow in a needless way and cloud up real bug reports we can and want to fix, with bug reports that won't be fixable for quite awhile due to external sources. The reason WONTFIX, FIXED and WORKSFORME don't make sense is because that isn't a bug, it's an enhancement request. Perhaps the solution is to not include enhancements in the list of bugs by default. It's natural that enhancement requests will sometimes sit around for ages before they get implemented, that doesn't mean we should mark them as resolved when they aren't. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Final mobile switch-over
On 23 November 2011 19:13, Philip Chang pch...@wikimedia.org wrote: We are suggesting that a home page customized for mobile viewing is perhaps more suitable, but I also understand the point you are making and will take that into consideration. I don't think anyone disagrees with that. The question is over whether no home page at all (just a search bar) is better than a home page that hasn't been customised for mobile users. I'm not sure that it is. Also, can you elaborate on what you said about country-specific home pages? Why would we want that? Wikipedias are for languages, not countries. All Wikipedias should have global reach, regardless of what language they are in. If individual language communities want to create different home pages for different countries, then I doubt the rest of the movement would step in to stop them, but it shouldn't be something initiated by the tech team. I suggest you find out if anyone wants such a feature before you implement it... ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Temporary password too short
On Oct 30, 2011 11:29 AM, William Allen Simpson william.allen.simp...@gmail.com wrote: On 10/26/11 9:13 AM, Neil Harris wrote: Assuming the seven-character password given, YH2MnDD, uses the character set [A-Za-z0-9], there should be 62^7 ~= 3.5 x 10^12 possible such passwords. I really wish folks would at least read a Wikipedia article before making such calculations. :-( No, you've listed the number of combinations, not the entropy. No, 40-bits of strength means 2**20 attempts on average. Same order of magnitude as WEP. You remember WEP, the security designed to be easily crackable? https://secure.wikimedia.org/wikipedia/en/wiki/Wired_Equivalent_Privacy In 2005, a group from the U.S. Federal Bureau of Investigation gave a demonstration where they cracked a WEP-protected network in 3 minutes using publicly available tools. Or, maybe, perhaps, you might trust that a well-known long-time security professional is telling you the generated password is too weak. ;-) If you are going to be so insulting, please at least try and be right... You could start by reading the articles you are telling other people to read. For a random sequence of characters, the entropy is just the base-2 log of the number of combinations, so there is nothing wrong with just calculating the number of combinations. Converting to entropy just makes it easier to compare two passwords drawn from different character sets. WEP is flawed because it encrypts different parts of the message using related keys, not because it is susceptible to a brute force attack on the password. It is completely irrelevant to our discussion. To get the average number of attempts, you half the number of combination, you don't square root it. With 40 bits, the average is 2^39 attempts, not 2^20. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Temporary password too short
On 30 October 2011 15:38, Neil Harris n...@tonal.clara.co.uk wrote: However, this is way, way, way lower risk than the current risk of brute-forcing low-hanging-fruit user passwords: for every user with a password generated by base64-encoding the output of /dev/random, there will be _thousands_ with passwords like secret99 and trustno1. A password from /dev/random is extremely insecure. It is highly susceptible to the find where they wrote it down because it's far too difficult to remember attack. Obligatory xkcd link: http://xkcd.com/936/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposed chat system
On 4 September 2011 13:44, Harry Burt jarry1...@gmail.com wrote: [Visual editor] Ian Baker http://www.mediawiki.org/wiki/User:Raindrift investigated and started to work on a chat system to be integrated to the concurrent editing interface, for collaboration and live help. There's a concurrent editing interface? Where is it (intended to be) used? It would never work for Wikipedia. The lack of a clear revision history and identifiable authors would be a big problem. It would also interfere with collaboration between people that aren't online at the same time (imagine three people are active on an article, two of which are online at the same time and so use the concurrent interface, how does the third person get involved?). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [RFC] Drop actions in favor of special pages and wiki pages
On 31 August 2011 15:32, Chad innocentkil...@gmail.com wrote: I *hate* action urls. They overly complicate Article and related classes, and date from a time before special pages existed. While on the one hand I think the cleanup recently to make Action classes and move the code out was a positive thing...I agree the better course of action is to kill them entirely. Of course, things like action=edit should work as back-compat for near eternity (supporting action=foobar redirects to Special:Foobar/Title would take very little code). We should probably be commenting on the wiki, but I'm at work at the moment and this is quicker. While it may well be true that special pages are better from a programming point of view, I much prefer action urls from a user point of view. I quite often get to pages by modifying urls rather than clicking links (why load an article before editing it when you can go straight to the edit page?) and I find it much easier to do that with action urls than special pages. If nothing else, it means the edit page and the article page are next to each other in the alphabetical list of recently viewed pages that appears when I start typing. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
On 2 May 2011 13:09, Roan Kattouw roan.katt...@gmail.com wrote: On Mon, May 2, 2011 at 1:41 PM, Maury Markowitz maury.markow...@gmail.com wrote: Editors do this all the time anyway. Typically using automated tools so they don't have to do any actual work. Surely someone here has had to wade through someone changing every REF to that bag of hammers CITE tag. Sure, but those aren't typically mixed with real changes in the same edit. That's what was hard: spotting the actual changes in the midst of all the normalization noise. The normalisation only really needs to happen once, though. There may be a few little bits where people have made wikitext edits since the last WYSIWYG edit, but the whole article will only need to be normalised the first time there is a WYSIWYG edit. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What is wrong with Wikia's WYSIWYG?
On 2 May 2011 15:31, David Gerard dger...@gmail.com wrote: On 2 May 2011 15:27, Thomas Dalton thomas.dal...@gmail.com wrote: The normalisation only really needs to happen once, though. There may be a few little bits where people have made wikitext edits since the last WYSIWYG edit, but the whole article will only need to be normalised the first time there is a WYSIWYG edit. Only if you immediately go all-WYSIWYG and no-one is ever allowed to directly edit wikitext ever again. This strikes me as likely to go over very badly indeed. No. I clearly said there would be small amounts of normalisation to deal with new wikitext edits, but that the whole article would only need to be normalised once. I was not assuming we would do away with wikitext editing entirely (and wouldn't support doing so). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: Reg. Research using Wikipedia
On 9 March 2011 16:00, Platonides platoni...@gmail.com wrote: Dear Members, I am Ramesh, pursuing my PhD in Monash University, Malaysia. My Research is on blog classification using Wikipedia Categories. As for my experiment, I use 12 main categories of Wikipedia. I want to identify which particular article belongs to which main 12 categories?. So I wrote a program to collect the subcategories of each article and classify based on 12 categories offline. I have downloaded already wiki-dump which consists of around 3 million article titles. My program takes this 3 million article titles and goes to online Wikipedia website and fetch the subcategories. Why do you need to access the live wikipedia for this? Using categorylinks.sql and page.sql you should be able to fetch the same data. Probably faster. I concur. Everything required for this project should be in the dumps. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] stop changing the whitespace in RELEASE-NOTES please
On 15 February 2011 22:43, K. Peachey p858sn...@yahoo.com.au wrote: Release Notes will be corrected and formatted to make it appropriate for release, nothing is going to change it. The standard is for 80 (or is it 72) characters wide and it will be corrected if theres errors. This is just something that will always happen. -Peachey Why are we imposing such an outdated rule? CLIs and text editors got the ability to automatically wrap text several decades ago. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] stop changing the whitespace in RELEASE-NOTES please
On 20 February 2011 19:06, Chad innocentkil...@gmail.com wrote: On Sun, Feb 20, 2011 at 2:01 PM, Thomas Dalton thomas.dal...@gmail.com wrote: On 15 February 2011 22:43, K. Peachey p858sn...@yahoo.com.au wrote: Release Notes will be corrected and formatted to make it appropriate for release, nothing is going to change it. The standard is for 80 (or is it 72) characters wide and it will be corrected if theres errors. This is just something that will always happen. -Peachey Why are we imposing such an outdated rule? CLIs and text editors got the ability to automatically wrap text several decades ago. Can we please stop this thread already? Starting a thread about whitespace was stupid, and continuing to discuss it is equally stupid. It seems to me that making commits to change whitespace that, from what I can tell, benefits no one (the fact that you didn't simply answer my question suggests you don't know any benefit either) and harms at least one person is the stupid thing. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] OT: Word-wrap
On 20 February 2011 19:09, Jay Ashworth j...@baylink.com wrote: Why are we imposing such an outdated rule? CLIs and text editors got the ability to automatically wrap text several decades ago. In fact, they *lost* the ability to automatically wrap text. They thought that was an acceptable tradeoff for gaining the ability to wrap *received* text if it was too long to fit. I've just proven why that's a bad tradeoff. I don't understand your proof and I also don't know any CLIs or text editors that don't automatically wrap text (if so configured). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] are you sure you want everything via HTTPS?
On 15 February 2011 21:09, jida...@jidanni.org wrote: Is that how Facebook™ or Google™ operate, sending every single component via HTTPS? No. Only the vital personal settings, password stuff is done that way. As for not letting people know what pages you are browsing, well, I don't now. Does Google™ offer a way to not let wiretapping people know what pages you are searching? Probably. We Geritol™ Generation users aren't exactly sure to tell you the truth. Ok, so offering HTTPS for everything isn't essential. What harm does it do, though? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Announce]: Mark Bergsma promotion to Operations Engineer Programs Manager
On 15 September 2010 16:41, Domas Mituzas midom.li...@gmail.com wrote: Hi! Erik gave an overview of how EPMs work a few days ago: http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/49532 What I learned is that most important information should be put under most obscure subject lines, so that only people who really really care would read that. It's not that obscure... it seems like a perfect subject line to me. It says precisely what the email is about... ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] relocating search servers
It's probably worth sending this kind of email more widely than just the tech list. On 12 August 2010 22:27, Robert Stojnic rainma...@gmail.com 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sentence-level editing
On 9 August 2010 23: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 It seems like a great idea, but your prototype doesn't appear to work. I can't see a way to save a modified sentence (the only options are preview and cancel, there is no submit option) and the publish button at the top of the page doesn't seem to do anything. Am I doing something wrong? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Reject button for Pending Changes
On 28 June 2010 12:19, Carl (CBM) cbm.wikipe...@gmail.com wrote: On Mon, Jun 28, 2010 at 12:46 AM, Rob Lanphier ro...@wikimedia.org wrote: Unaccept seems suitably rare that I think we should consider a confirmation screen which shows the effect of unaccepting (i.e. a diff between the latest accepted revision and the penultimate accepted revision). Does that seem like a reasonable enough failsafe to keep this from being used unintentionally? This seems beneficial even in the case where the reviewer knew they were hitting unaccept. I had the impression that unaccept does not add a new revision to the page, it simply removes the db entry that the revision in question was accepted. Is that wrong? That's correct, but from the point of view of someone only viewing accepted versions it will be like a revert. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Reject button for Pending Changes
On 28 June 2010 04:11, Rob Lanphier ro...@wikimedia.org wrote: I had forgotten that undo might possibly actually do something useful in this context. That said, let's recap what has happened so far. You start with accepted revision A1, and have pending revisions P1, P2, and P3. Once the user rejects P1, lets assume that that creates a new pending revision P4 that is the result of that undo. Now what? If they then review the diff between P1 and P2, they might mistakingly accept P2, even though it still contains the delta between A1 and P1. We could ask them to review the diff between P1 and P4, but that's now an aggregate of the P1P2 delta and the P2P3 delta, sans the A1P1 delta. I just don't think there's a clean way to reject an intermediate pending revision. Accepting? Sure, wonderful, that will work well. There's a reasonably strong argument for encouraging acceptance of intermediate revisions as part of the review process (so long as it always involves comparison to the latest accepted revision). But encouraging undo on intermediate revisions leaves things in a really weird place. Ah... you're right. I hadn't thought things through carefully enough. Ok, how about alternative D? D: 1) Display diff between A1 and P1. 2) P1 is rejected. Nothing happens to the database at this point, the rejection of P1 is just remembered somewhere. 3) Display a diff between A1 and P2 minus A1P1 delta (that can be created temporarily using the undo feature) 4a) If that diff is rejected, display a diff between A1 and P3 minus A1P2 delta (or equivalently, P3 minus A1P1 delta minus P1P2 delta). 4b) If that diff (in 3) is accepted, display a diff between P2 minus A1P1 delta and P3 minus A1P1 delta. 5) Continue in what I hope is the obvious fashion, because I'm thoroughly confused! 6) Create a revision equal to that latest accepted pseudo-revision and mark it as accepted. This will be a mess to program (and no, I'm not volunteering!), but it should be very intuitive for the reviewer. If at any time the undo feature can't create one of the pseudo-revisions (the ones in quotes), you just fail gracefully. What do you think? PS The aspirin is in the second drawer on the left! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Reject button for Pending Changes
On 27 June 2010 19:48, Rob Lanphier ro...@wikimedia.org wrote: For example, let's say that there are three pending revisions in the queue. That means there is the latest accepted revision (we'll call A1), and three pending revisions (P1, P2, and P3). P3 is the latest pending revision, while P1 and P2 are intermediate pending revisions. The specification says that when viewing the diff between A1 and P3, the reject button is enabled. A more conservative school of thought says that the reject button shouldn't be enabled, because its possible that P1 was a valid revision that was vandalized by P2, and the only way to tell is to look at the revision history. However, this should be reasonably rare, and the diff remains in the edit history to be rescued, and can be reapplied if need be. A competing problem is that disabling the reject button will result in the same confusion we're already seeing today. The guidance for reviewing multiple edits (http://en.wikipedia.org/wiki/Wikipedia:Reviewing#Step-by-step_.22how-to.22_for_reviewing_multiple_edits) says you have to go through them one-by-one (unless they are all by the same user), so I suggest eliminating the option of review multiple edits with a single click, unless they are all by the same user. The feature should be designed to fit in with the way it is used, after all. Once you've done that, the issue you raise goes away. However, I would suggest a rollback or undo button (which does that same as those buttons always do) rather than a reject button - don't introduce a new term when it does the same thing as an existing feature with its own name. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Broken validation statistics
What's broken about it? It seems very odd to me that the mean is an order of magnitude greater than the 95th percentile, but otherwise it all looks fine. I suspect there are a few invalid data points messing with the mean - perhaps pending changes is being turned off on articles while there are unreviewed edits and they are counting as being unreviewed for ages? (Or perhaps only if PC is turned back on again for that article and they are eventually reviewed days after being made.) If that is the problem, then I would suggest disallowing turning off PC on an article with revisions still pending. Alternatively, turning off PC could automatically approve any pending changes. On 27 June 2010 20:19, Gregory Maxwell gmaxw...@gmail.com wrote: Is anyone working on fixing the broken output from http://en.wikipedia.org/wiki/Special:ValidationStatistics ? I brought this up on IRC a week-ish ago and there was some speculation as to the cause but it wasn't clear to me if anyone was working on fixing it. ___ 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] Broken validation statistics
On 27 June 2010 20:34, Gregory Maxwell gmaxw...@gmail.com wrote: Reviewing the logs I am unable to find even a single article with a wait anywhere near that. Can you find one? I'm not sure which logs to review. The Advanced Review Log doesn't distinguish between edits by new registered users and edits by anons, and only the latter are included in the statistics (why is that, by the way?). There also isn't an easy way to see how long it took to review (you have to calculate it manually for every row). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Reject button for Pending Changes
On 27 June 2010 21:07, Rob Lanphier ro...@wikimedia.org wrote: The guidance for reviewing multiple edits ( http://en.wikipedia.org/wiki/Wikipedia:Reviewing#Step-by-step_.22how-to.22_for_reviewing_multiple_edits ) says you have to go through them one-by-one (unless they are all by the same user), so I suggest eliminating the option of review multiple edits with a single click, unless they are all by the same user. The feature should be designed to fit in with the way it is used, after all. Once you've done that, the issue you raise goes away. I think it actually gets worse. What should the reject button do in the case that the reviewer is looking at A1 and P1? It would function as undo. In the event that the edit cannot be undone, it fails gracefully. The software can't be expected to do everything successfully. However, I would suggest a rollback or undo button (which does that same as those buttons always do) rather than a reject button - don't introduce a new term when it does the same thing as an existing feature with its own name. The confirmation page that is shown when the user hits reject tells the reviewer that they are about to undo one or more revisions. We're not wedded to the word reject, but it's pretty clear that reviewers are going to look around to the counterpart to accept. There's already an undo link on these pages, but people still feel that some sort of reject or decline is necessary. I think if a button labelled rollback or undo were right next to the accept button they would recognise it as the counterpart to accept. If I saw a reject button I wouldn't know exactly what it's going to do. If I saw a rollback or undo button, I'd know exactly what to expect when I clicked it since I've been clicking button (well, links) with those names for years. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Reject button for Pending Changes
On 27 June 2010 23:16, Rob Lanphier ro...@robla.net wrote: If you're willing to write up an alternative proposal for how this should work, we'll take a look at it. It stands the best chance of getting implemented if you figure out a way of incremental implementation, since it sounds like you're a proponent of a go back to the drawing board approach to this. I've put a placeholder for Alternative B here: http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Reject_Pending_Revision Done. Please ask if anything isn't clear. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Updating strings for FlaggedRevs for the Flagged Protection/Pending Revisions/Double Check launch
On 23 May 2010 00:18, Rob Lanphier ro...@robla.net wrote: It seems what you're suggesting is the following: Step 1. Simply leave revreview-hist-basic as checked revision (or even go back to sighted revision) Step 2. Create a new revreview-hist-accepted, setting it to accepted revision Step 3. ? No, that's not the suggestion at all. As I understand it, your new version doesn't use the phrase checked revision at all, so there is no need to have a message saying it. The suggestion is that if accepted revision is used to mean two slightly different things (so might be translated in two different ways) in different places, there should be two messages both set to accepted revision with each message used for a particular meaning of the phrase. I can't think of an example and I'm not sure there are any for this particular feature, but it is a good general principle to keep in mind with any MediaWiki interface work. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Updating strings for FlaggedRevs for the Flagged Protection/Pending Revisions/Double Check launch
On 23 May 2010 01:17, Rob Lanphier ro...@robla.net wrote: The problem as I understand it is this. Other wikis (e.g. German, Polish) are using FlaggedRevs as originally designed, with many different flags corresponding to sighted, quality, accuracy and so on. The proposed implementation on English Wikipedia is binary: either an article is accepted or its not. Many strings in the English version were changed to correspond to this usage. As I understand it, the software has three dimensions (accuracy, depth and style) each with five levels. The fact that the enwiki implementation only uses one of those dimensions and only two of the levels shouldn't really change anything - the other 13 messages are just unused. In hindsight, the number of dimensions and number of levels shouldn't have been hard-coded at all. There just have just been a two dimensional array with the size and contents entirely customisable (either through the message system or a special configuration page). Unfortunately, it is too late for that kind of major change, so we'll just have to ignore the rest of the messages. That shouldn't have any impact on other projects, other than them not being able to rely on English as a default. The message system in this case isn't just being used to translate the interface, it is being used to customise it as well, so defaults are pretty useless anyway. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Auto Reply: Re: Auto Reply: Auto Reply: Transclude contemporary template states to page hisories?
On 21 March 2010 22:47, Tim Starling tstarl...@wikimedia.org wrote: So filtering is not as trivial as you might think. How about an anti-flood filter than stops emails that are identical to an email sent within the last hour? That ought to stop people auto-responding to themselves, at least. I think we can live with one auto-response per person (which is all most clients send, anyway, AFAIK - this really is a matter of a broken client, rather than a broken list). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Uploads on small wikis
On 14 March 2010 00:34, Aryeh Gregor simetrical+wikil...@gmail.com wrote: On Fri, Mar 12, 2010 at 5:42 PM, Thomas Dalton thomas.dal...@gmail.com wrote: If these are projects with active users, isn't this a decision to be made by those active users rather than wikitech-l? Wikimedia defaults are decided by wikitech-l/Wikimedia. Specific communities can choose to opt out of those defaults if they choose. Requiring all communities to explicitly opt in to any changes would make the defaults almost impossible to change. The change requiring autoconfirmed for upload wasn't approved by all the communities individually in any case, so it wouldn't make sense to require the change back to be so approved. I wouldn't count a change to just certain projects as being a change to the defaults. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] (no subject)
Do you have a reason for sending a blank email and then an email with a random address in it to wikitech-l? On 8 March 2010 22:12, William Nelson eyelikepi...@yahoo.com wrote: 3161 w.cheryl dr phoenix az ___ 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] modernizing mediawiki
On 2 March 2010 20:30, Chris Lewis yecheondigi...@yahoo.com wrote: Mediawiki makes millions more than Wordpress does too, why can't the money be put into making a modern product instead of in pockets of the people who run it? The Wikimedia Foundation makes millions more than Wordpress, but the Foundation is running a top 5 website. That they are able to do that on just a few million is amazing. The other top 5 sites are things like Google than spend billions. Maintaining and improving Mediawiki is just one of the things the Foundation does with its relatively small budget. The only money going into the pockets of the people that run the Foundation is their very reasonable salaries. The board get nothing (except their actual expenses, and some don't even claim those) and there are no shareholders getting profits (the WMF is a charity). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] hiphop! :)
On 27 February 2010 16:41, David Gerard dger...@gmail.com wrote: (I'm sure the complexity of templates will go up to compensate, unless Tim's parser functions reaper is set down to match, muwahaha.) Speeding up parsing will reveal a new bottleneck for the devs to fight the enwiki community over, don't worry about that. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikigalore
I'm CCing this to Mike Godwin (I'm not sure he's on this list). That site is full of our trademarks (names and logos) being used for commercial gain. Something probably should be done about it. On 26 February 2010 15:30, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, As far as leeches go, this takes the price as far as I am concerned. It sells scripts to leech any Wikimedia project and all this to have the rating of a website go up. Is this the kind of outfit that we act upon .. That is for you to decide.. Thanks, GerardM http://wikigalore.com/ ___ 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] Google phases out support for IE6
On 20 February 2010 10:48, Strainu strain...@gmail.com wrote: Hi guys, I'm reopening this discussion to bring up an Idea that Thomas had below: could we have an updated stat for browser market share? It would be nice to have for a migration we're considering on ro.wp. Also, purely for the sake of idle curiosity, I'd like to see what impact the Windows Browser Choice thing that is launching in Europe about now has. That means we need stats from before and after. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] confirm dfe03c58a0a....
On 10 February 2010 21:00, Conrad Irwin conrad.ir...@googlemail.com wrote: The point of the password is so you can prove to the web interface that you own the email address; so the fact that it is in your email box doesn't matter much. (If your email gets hacked this is the last thing you're likely to be worried about after all.) As it says on sign up do not use a valuable password. It doesn't require your email to be hacked, though. There is no security in the email system, they can be intercepted at any point. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Google phases out support for IE6
On 31 January 2010 20:49, John Vandenberg jay...@gmail.com wrote: If I'm reading that right, only 0.02% of users are using Mac OS classic (although I suppose there could be some more that have been grouped into Other, but that won't be many). That is still at least 1000 pageviews per month. If it does not degrade gracefully, we would be telling them to buy a new computer in order to view Wikipedia. How many contributors will be lost in the process? Only developers can tell us how many of those 1000 pageviews were logged in users. 1000 page views a month over the whole of Wikimedia is as close to nothing as makes no odds. That could be just a single user. Most IE5.2 users should have upgraded to iCab. Do we have good iCab support? IE to iCab isn't really an upgrade... it's a completely different browser, isn't it? iCab was a supported browser long after IE for Mac was dropped. Sure, but it's a completely different browser. Upgrade means to go to a later version of the same software, not a later version of completely different software. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Google phases out support for IE6
Google phases out support for IE6 http://news.bbc.co.uk/1/hi/technology/8488751.stm It's only a small step, but it is one more step towards the end of IE6 and the nightmare of supporting it! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Google phases out support for IE6
On 30 January 2010 14:42, Chad innocentkil...@gmail.com wrote: Whoops, haven't had any caffeine yet this morning, left the two links off here. They're: [1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/61083 Interestingly, the revision summary for that revision gives a link to general browser stats, rather than Wikimedia browser stats, which are obviously the relevant ones (although we have such high reach that there isn't a large difference). We have stats from Nov 2009 (http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm) - were those generated by a script that could be run again? Getting some trends could help us work out when to ditch IE6. The recent Google/China/IE story has received lots of coverage, including the authorities in France and Germany advising people to ditch IE entirely, so IE6 usage has probably shown a noticeable dip. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More advanced watchlists
2009/11/3 Lars Aronsson l...@aronsson.se: ==Watch a category of articles== 2010 is election year in Sweden, so I want to keep an eye on all articles in category:Swedish politicians, in recursive levels. [snip] Are there already any smarter tools to do this? You could make a list of all the politicians you are interested in as a subpage of your user page (or a wikiproject page) and then use the related changes feature on that page. It's not ideal, but it would work. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Off-topic: Anyone have a Google Wave invite?
I apologise for the slightly off-topic email, but does anyone have any Google Wave invites to hand out? If so, I would be very interested in getting one... ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Not allowing certain external link types?
2009/9/5 David Gerard dger...@gmail.com: See this talk page: http://en.wikipedia.org/wiki/User_talk:189.148.6.25 The poster purports to be a journalist experimenting with putting toxic links on Wikipedia to see who will follow them. Although his actions were IMO dickish, he has some point: is there any reason to allow .exe links on WMF sites? Is there a clean method to disable them? Is this a bad idea for any reason? What should default settings be in MediaWiki itself? etc., etc. The relevant edits have been oversighted so I can't tell what kind of URLs they were. If they were like www.foo.com/bar.exe then we can easily stop them by not parsing URLs that end .exe. There will be some false positives (eg. http://en.wikipedia.org/wiki/.exe although that is only a redirect, so no real harm), but it shouldn't involve more than a slight change to 1 or 2 lines of code, unless I'm missing something. Something more advanced that would actually block executables, rather than just things with an exe extension would require actually following the link, which is probably too slow to be practical (it would have to be done on rendering, rather than saving, otherwise you can just change what is at the other end of the link after saving the page). Is there any great risk here, though? Modern browsers won't run such an executable (at least not without big scary warnings which, of course, we never just blindly click through). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Links to Special:ListUsers/...
2009/8/30 Helder Geovane Gomes de Lima heldergeov...@gmail.com: Hello! Does anybody knows why the link http://en.wikipedia.org/wiki/Special:ListUsers/autoreviewer makes the target page to have the box on the right filled with Autoreviewers and shows only the users in that group, while using a translated name at pt.wikipedia, like http://pt.wikipedia.org/wiki/Especial:Lista_de_utilizadores/Robôshttp://pt.wikipedia.org/wiki/Especial:Lista_de_utilizadores/Rob%C3%B4s doesn't do the same thing? (in this example, we get a list of all users, starting from Robôs) Is it possible to use a translated name in the link for this kind of special page? (lists of users in a group) It seems you have to use the English name, which is presumably the name used in the code. It is probably possible to make it so aliases work - I suggest leaving a feature request on https://bugzilla.wikimedia.org/ . ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] On templates and programming languages
2009/6/30 Michael Daly michael.d...@kayakwiki.org:
Brion Vibber wrote:
Any thoughts? Does anybody happen to have a PHP implementation of a
Lua or JavaScript interpreter?
Rather than reinventing the wheel, why not look at fixing the existing
template syntax?
I would support that. We really don't need a Turing-complete template system.
As an aside - obliging template writers to declare variables used in the
template, say, as a definition of the input format at the top of the
template definition, would make parsing the variables out later a tad
easier. If it's declared, it's a variable; if not, it's not a variable
and is treated as plain text. Thus the first line of a template would
be the example of its use:
Template:foobar
--
{{Foobar|$var1|$var2|$andAnotherVar}}
...(implementation)...
--
How does that work with anonymous variables? Are all $[NUMBER] style
names count as auto-declared?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] On templates and programming languages
2009/6/30 Steve Sanbeg ssan...@ask.com: On Tue, 30 Jun 2009 21:38:07 +0100, Thomas Dalton wrote: 2009/6/30 Michael Daly michael.d...@kayakwiki.org: How does that work with anonymous variables? Are all $[NUMBER] style names count as auto-declared? They're not anonymous, they're just named sequentially. They are anonymous when you call the template, though. The names are determined by the order in the call rather than written explicitly. They do need to be considered separately. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] On templates and programming languages
2009/7/1 Brian brian.min...@colorado.edu:
On Tue, Jun 30, 2009 at 6:09 PM, Robert Rohderaro...@gmail.com wrote:
In other words, I assume things like {{fact}} and {{msg | foo is
bar }} will be be basically unchanged on the article side but
rewritten on the implementation side in Template: space. If that is
correct, it would be more useful to simply ask how large Template:
space is rather than counting all the template calls.
-Robert Rohde
Mixing the new language with existing wikicode? With a new language I
would like to see the old language go out the door. The end of double
braces.
What would you replace them with? The wikitext used by regular editors
should be as simple as possible, we don't want to require PHP or
Javascript to be used by anyone wanting to add an infobox to an
article.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] On templates and programming languages
2009/7/1 Michael Daly michael.d...@kayakwiki.org: Why not switch the template syntax for articles to match the syntax for tags (which in turn is based on XML or whatever syntax that comes from ultimately)? What is wrong with the current syntax for calling templates? At least, what is wrong with it that would be improved by that change? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Current events-related overloads
2009/6/26 Brion Vibber br...@wikimedia.org: Tim Starling wrote: It's quite a complex feature. If you have a server that deadlocks or is otherwise extremely slow, then it will block rendering for all other attempts, meaning that the article can not be viewed at all. That scenario could even lead to site-wide downtime, since threads waiting for the locks could consume all available apache threads, or all available DB connections. It's a reasonable idea, but implementing it would require a careful design, and possibly some other concepts like per-article thread count limits. *nod* We should definitely ponder the issue since it comes up intermittently but regularly with big news events like this. At the least if we can have some automatic threshold that temporarily disables or reduces hits on stampeded pages that'd be spiffy... Of course, the fact that everyone's first port of call after hearing such news is to check the Wikipedia page is a fantastic thing, so it would be really unfortunate if we have to stop people doing that. Would it be possible, perhaps, to direct all requests for a certain page through one server so the rest can continue to serve the rest of the site unaffected? Or perhaps excessively popular pages could be rendered (for anons) as part of the editing process, rather than the viewing process, since that would mean each version of the article is rendered only once (for anons) and would just slow down editing slightly (presumably by a fraction of a second), which we can live with. There must be something we can do that allows people to continue viewing the page wherever possible. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] We're not quite at Google's level
2009/5/22 Steve Bennett stevag...@gmail.com: On Sat, May 16, 2009 at 2:58 AM, The Cunctator cuncta...@gmail.com wrote: We should definitely highlight real downtime as a reason for funding, especially in a way that discusses practical steps that would be taken to reduce the problem and how much those steps would cost. Interesting point. Commercial organisations would never issue a press release highlighting poor performance, because they want people to think they're getting good value for money. A charity on the other hand...what does wikipedia have to lose from people thinking its servers are unreliable due to lack of funding? The thing that prompted me to start this thread was Google, a commercial organisation (although not one people pay for at the point of use), issuing just such a press release. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] We're not quite at Google's level
http://news.bbc.co.uk/1/hi/technology/8051262.stm Google has an hour of slow service and it's headline news. Imagine the donations we could get if our downtime (which, as David is fond of saying, is our most profitable product) got into the headlines! Perhaps we should take to issuing press releases following server problems. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] We're not quite at Google's level
2009/5/15 The Cunctator cuncta...@gmail.com: No, and it's stupid. It's not like this is a covert discussion. On Fri, May 15, 2009 at 11:45 AM, Bilal Abdul Kader bila...@gmail.comwrote: Is it ethical? How is it unethical? We take advantage of downtime to explain to our readers that we rely on donations to keep the site running, there is nothing dishonest about that. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] We're not quite at Google's level
2009/5/15 Bilal Abdul Kader bila...@gmail.com: Sorry I missed the point in a previous post then. The wordings looked like using the downtime as a strategy. Oh, no, I certainly wasn't proposing we fake downtime, that would be seriously unethical, I agree. We have plenty of natural downtime we can exploit. (The Google story was about their sites running slowly, so we probably don't even need anything to go down completely.) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Database Abstraction
2009/5/15 George Herbert george.herb...@gmail.com: Domas, I assume you're still on this list - can you give us some background why we're not on a closer to current release MySQL within the WMF environments? Upgrading for the sake of upgrading is always a bad idea. The question should also be why should we upgrade? not why shouldn't we upgrade?. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] This wiki has a problem error page lacks beg notice
2009/4/27 Brion Vibber br...@wikimedia.org: On 4/27/09 11:41 AM, David Gerard wrote: 2009/4/27 Brion Vibberbr...@wikimedia.org: On 4/27/09 8:25 AM, David Gerard wrote: What's missing? A donation beg notice! Downtime being, of course, our most profitable product ... At the moment, general downtime probably means the donation page is down too. :) We should probably plan for that, actually, and put up an automatic mirror not served from WMF machines ... The tricky part is having it survive the traffic. ;) If that message is for when MediaWiki breaks, presumably that means the squids are still up and running and, obviously, they can survive the traffic. Could the squids run a simplified version of the donation software themselves? It doesn't need to have all the interesting comments and statistics and stuff that we usually have. In fact, it doesn't need much more than a link to paypal. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia - openID provider?
2009/4/27 Chad innocentkil...@gmail.com: Is there some benefit with being a provider? Why not just accept id's for login? There's way too many providers as it is. It's too late. You need to make that kind of decision when you first start. Dealing with conflicts when we went over to global accounts within Wikimedia was hard enough, dealing with them if we went over to accepting OpenIDs would be a nightmare. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia - openID provider?
2009/4/27 Brion Vibber br...@wikimedia.org: On 4/27/09 1:54 PM, Thomas Dalton wrote: 2009/4/27 Chadinnocentkil...@gmail.com: Is there some benefit with being a provider? Why not just accept id's for login? There's way too many providers as it is. It's too late. You need to make that kind of decision when you first start. Dealing with conflicts when we went over to global accounts within Wikimedia was hard enough, dealing with them if we went over to accepting OpenIDs would be a nightmare. Not really, since they'd have their own freakish namespace. :) So everyone using OpenID would have to have a username with a certain prefix or something? That would be really annoying. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia - openID provider?
2009/4/27 MinuteElectron minuteelect...@googlemail.com: 2009/4/27 Thomas Dalton thomas.dal...@gmail.com: It's too late. You need to make that kind of decision when you first start. Dealing with conflicts when we went over to global accounts within Wikimedia was hard enough, dealing with them if we went over to accepting OpenIDs would be a nightmare. I think OpenIDs would (should?) be tied to accounts, not used as usernames. At the moment accounts and usernames are in a very fundamental 1:1 correspondence. It would be quite a major change to do away with that. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia - openID provider?
2009/4/27 MinuteElectron minuteelect...@googlemail.com: Hello, 2009/4/27 Thomas Dalton thomas.dal...@gmail.com: At the moment accounts and usernames are in a very fundamental 1:1 correspondence. It would be quite a major change to do away with that. I meant that when creating an account (or modifying an existing accounts preferences) you could use an OpenID instead of a password and use that to log-in and out. I thought the whole point of OpenID was that you didn't have to create an account on every site, you could just turn up and use your existing one. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New preferences system
2009/4/24 Jacopo Corbetta jacopo.corbe...@gmail.com: An existing example of us providing users with such an option however can be seen in the ability to turn various editing-related gadgets such as wikiEd. I think this shows that should a more visual editing interface become able to be deployed, we certainly would make it optional. Exactly. Each editor has its own incompatible setting which allows it to be turned on or off. Basically, each extension assumes it is going to be the one and only one editor for the wiki. If you install more than one, things will break. A unified preference might have been useful. Anyway, no big deal. I don't believe any WYSIWYG (or close to) editor that exists for MediaWiki is good enough that you can completely avoid editing the wikitext directly (in order to do complicated stuff), that means you can't use one and only one editor unless that editor is the default wikitext editor. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] tran-subst-antiation
2009/4/19 William Allen Simpson william.allen.simp...@gmail.com:
{{subst:TEMPLATE|P1|P2|subst=subst:}}
I've never seen that syntax before, what does the last bit do?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how much redundant text in Wikipedia?
2009/4/7 K. Peachey p858sn...@yahoo.com.au: Currently undos, so frequent on wikis, just blindly create a duplicate row instead of checking if the old one could be reused, https://bugzilla.wikimedia.org/show_bug.cgi?id=18333 . Maybe some hardware savings could even be achieved. From my understanding they have to be kept within the system to keep us within the GFDL licenseing terms. The text doesn't need to be stored twice, though, just a note that it is the same text. However, I believe the Wikipedia databases have the text compressed, so that is effectively what happens already. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Usermerge userright - prospects for unmerging?
2009/3/25 David Gerard dger...@gmail.com: 2009/3/25 Thomas Dalton thomas.dal...@gmail.com: An extra column in any table with a user id column for original user id (which would be identical to user id for the vast majority of rows) would be sufficient for most unmerges. There would still be a problem if an account was involved in more than one merge, though. I can see such being the case, e.g. prolific sockpuppeting vandals. However, preserving the original UID in all merges would likely suffice - I mean, a complete unmerging would be OK in all cases I can think of. True, you could completely unmerge and them just remerge the parts that should be merged. Rather cruel on the servers if the accounts have been prolific, but it would work. (I'm not sure why we would want to merge sockpuppeting vandals, though - just block them all individually.) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Usermerge userright - prospects for unmerging?
2009/3/26 Aryeh Gregor simetrical+wikil...@gmail.com: On Wed, Mar 25, 2009 at 9:03 PM, Platonides platoni...@gmail.com wrote: Changing the rev_user_text but not rev_user would work for most uses (but merging of anonymous users). Those columns are supposed to be *consistent*. Deliberately making them inconsistent would be a really bad idea. (Although Special:Import often already does . . .) I agree. If you were going to do that you would need to go through every line of code to find anywhere where someone had assumed they were consistent (which could be a lot of places - it's a safe assumption, so why not make it?) and thus written code that would now be broken. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] developer meet-up is out of room
2009/3/17 Lars Aronsson l...@aronsson.se: I sent in my registeration on March 9 and have still not received confirmation. After that I have recruited two more Swedish attendees, who also sent their registration. Our flights are already booked, so there is no way we can stay home. Of course we are coming to Berlin. You may well not be along in that situation. I guess no-one anticipated the meet-up would be so popular! Expanding it really would be the best option. (I'll be at the chapter meeting, so I'll see you around!) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Foundation-l] Proposed revised attribution language
2009/3/14 Magnus Manske magnusman...@googlemail.com: IIRC one reason to use wiki/ and w/ instead of direct URLs (en.wikipedia.org/Xenu) was to allow for non-article data at a later time (the other reason was to set noindex/nofollow rules). Looks like we will use that space after all :-) That may be one reason, but I think the main reason is to avoid problems with articles called things like index.php. /wiki/ is a dummy directory, there's nothing actually there to conflict with, the root directory has real files in it that need to accessible. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: Re: [Foundation-l] Report to the Board of Trustees: December 2008
2009/3/11 Brion Vibber br...@wikimedia.org: On 3/11/09 8:21 AM, Chad wrote: On Wed, Mar 11, 2009 at 9:25 AM, Lars Aronssonl...@aronsson.se wrote: Sue Gardner wrote: Report to the Wikimedia Foundation Board of Trustees [...] From December 9-15, Jimmy Wales and Sue Gardner visited India. It is great to read this report. But the archived version has been cut (by a software bug) at the line starting with From, http://lists.wikimedia.org/pipermail/foundation-l/2009-March/050792.html Since the report was distributed just fine, I think that Mailman is fine, but the bug hides somewhere in Pipermail 0.09. It is perhaps related to ^From being a message separator in the mbox format. Is there a fix for this bug? It was fixed several years ago, shouldn't happen on anything current. :P March 2009 seems pretty current to me... ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia is full
2009/3/11 Aude audeviv...@gmail.com: On Tue, Mar 10, 2009 at 9:54 AM, Tim Starling tstarl...@wikimedia.orgwrote: Please report urgent system administration issues to IRC, specifically #wikimedia-tech on irc.freenode.net. -- Tim Starling Certainly IRC is the best way to inform developers and sys admins of a problem with Wikipedia. As a user, I also like to know what's going on when there is a problem. But, I'm not regularly on IRC. If I'm at work where I sometimes look up things on Wikipedia (but don't edit), and see that Wikipedia is down, then I am curious what the problem is. However, IRC and other types of chat are forbidden at work. :( But, I am allowed to access gmail. So, I very much appreciate it when people send messages to the mailing list about such problems. The admin log on http://wikitech.wikimedia.org/view/Server_admin_log sometimes has some decent clues as to what is wrong and what is being done to fix it. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: Re: [Foundation-l] Report to the Board of Trustees: December 2008
2009/3/11 Brion Vibber br...@wikimedia.org: On 3/11/09 9:59 AM, Thomas Dalton wrote: 2009/3/11 Brion Vibberbr...@wikimedia.org: Is there a fix for this bug? It was fixed several years ago, shouldn't happen on anything current. :P March 2009 seems pretty current to me... Hence shouldn't and :P Hence I'll fix it, give me a minute!? (Or, more likely, I'll tell someone to fix it, give them a minute!) Comments from developers about bugs really should be about fixing them... Saying it shouldn't be happening doesn't help much. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki developer meeting is drawing close
2009/3/10 Daniel Kinzler dan...@brightbyte.de: Roan Kattouw schrieb: Daniel Kinzler schreef: The schedule[4] is slowly becomming clear now: On Friday, we'll start at noon with a who-is-who-and-does-what session The schedule you're linking to says it starts at 3 PM. Which time is the right one? Bah, naming times of day in english is awkward :) what do you call 1pm, afternnon? Anyway... 1pm is afternoon, but at noon is not at 3PM! So... doors open at noon, schedule starts at 3pm. Satisfied? That makes sense! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia is full
2009/3/10 K. Peachey p858sn...@yahoo.com.au: A bot that edits the sandbox every few minutes would work, would it? Possibly, but i would bump it up to like every two hours. Plus since the MySQL is spread between multipul systems you would have make sure it checks the same one all the time. If you're going to wait 2 hours, you might as well just wait for people to start complaining, that will be far quicker. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Flagged revs trial on en:wp?
2009/3/2 Brion Vibber br...@wikimedia.org: On 3/1/09 4:16 PM, David Gerard wrote: What's the holdup in the flagged revisions trial on en:wp? Last I heard, we're waiting for firm parameters on the test to be decided on by the community. If you accept the 59% result as sufficient consensus, then we have those parameters. The proposal was formulated in such a way that we can run various trials without needing developer input after the initial switch-on. I think someone linked to the relevant page earlier in the thread. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Autopromotion and revoking
2009/3/1 Techman224 techman...@yahoo.ca: Or it can be done like FlaggedRevs did with the Editor group. Which was? I didn't thing FlaggedRevs had anything to do with promotions, it just has a few permissions and you use the standard methods of granting them. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Autopromotion and revoking
2009/3/1 Andrew Garrett and...@werdn.us: On Mon, Mar 2, 2009 at 10:17 AM, Thomas Dalton thomas.dal...@gmail.com wrote: Which was? I didn't thing FlaggedRevs had anything to do with promotions, it just has a few permissions and you use the standard methods of granting them. FlaggedRevs, instead of improving the existing autopromote architecture, decided to create its own with the ability to revoke autopromoted groups. It would have been nice if, instead of implementing this in an extension which had nothing to do with autopromotion, the improvements in question were made to core. I stand corrected. Can the changes be ported upstream? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] http://en.wikipedia.org/ -- 301 Moved Permanently
2009/2/24 jida...@jidanni.org: Hello, say, when we are running our link checker programs and see HEAD http://en.wikipedia.org/ -- 301 Moved Permanently HEAD http://en.wikipedia.org/wiki/Main_Page -- 200 OK HEAD http://wikimania2007.wikimedia.org/ -- 301 Moved Permanently HEAD http://wikimania2007.wikimedia.org/wiki/Main_Page -- 200 OK HEAD http://radioscanningtw.jidanni.org/ -- 301 Moved Permanently HEAD http://radioscanningtw.jidanni.org/index.php?title=%E9%A6%96%E9%A0%81 -- 200 OK HEAD http://taizhongbus.jidanni.org/ -- 301 Moved Permanently HEAD http://taizhongbus.jidanni.org/index.php?title=%E9%A6%96%E9%A0%81 -- 200 OK HEAD http://transgender-taiwan.org/ -- 301 Moved Permanently HEAD http://transgender-taiwan.org/index.php?title=%E9%A6%96%E9%A0%81 -- 200 OK does that mean we should hardwire those extra long paths into our web pages instead of the less worrisome versions we are using now? I mean when I see a 301, I update my webpages, but momma said stay out of alleys... Unfortunately I don't think HTTP has a status code for move permanently but this redirect will always be here. 301 is probably the best option out of what there is. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Dump processes seem to be dead
2009/2/24 Robert Ullmann rlullm...@gmail.com: When a server is reported down (in this case hard; won't reply to ping) it should be physically looked at within minutes. Is there anyone within minutes of the servers at all times? Aren't they at a remote data centre? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Norwegian Websites Declare War on Internet Explorer 6
2009/2/20 Aryeh Gregor simetrical+wikil...@gmail.com: On Fri, Feb 20, 2009 at 4:02 AM, GerardM gerard.meijs...@gmail.com wrote: Hoi, Would this be a model to follow ? Thanks, GerardM Aan u verzonden door GerardM via Google Reader: Norwegian Websites Declare War on Internet Explorer 6 via Wired Top Stories door Michael Calore op 19-2-09 Several prominent websites in Norway are refusing to support the antiquated IE6 browser any longer, and have posted messages to IE6 users urging them to upgrade. The campaign has caught on, and is beginning to spread to other countries. No. Many users are forced to use IE6 because their workplace relies on it for intranet applications, for instance. These users will eventually be forced to upgrade as time moves on, but it's not appropriate for Wikipedia to go out of its way to make their lives any more difficult than they already are. IE6 support is not a major barrier to new features at this point that I'm aware of, so the gain to us would be marginal. There are different levels of support. We should certainly make sure things fail gracefully for IE6, but a new feature not working on IE6 shouldn't be a reason not to implement it for everyone else. (I believe that is pretty much the current policy already.) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
