[MediaWiki-CodeReview] [MediaWiki r85110]: New comment added
User IAlex posted a comment on MediaWiki.r85110. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85110#c15589 Comment: Do not pass a parsed string to Xml::element(); either use Html::rawElement() or Message::text() (but not both). ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85110]: New comment added
User Purodha posted a comment on MediaWiki.r85110. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85110#c15591 Comment: Done with r85114. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85114]: New comment added, and revision status changed
User IAlex changed the status of MediaWiki.r85114. Old Status: new New Status: fixme User IAlex also posted a comment on MediaWiki.r85114. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85114#c15592 Comment: Read my previous comment once more, I didn't write Xml::rawElement(), but Html::rawElement(). Now I get ''Fatal error: Call to undefined method Xml::rawElement() in includes/specials/SpecialUserrights.php on line 540''. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] GSoC 2011 proposal
On 01.04.2011, 2:00 Sumana wrote: Since very few people can see the formal proposal, there is a copy to view at: http://www.mediawiki.org/wiki/User:Zhenya I'm not registered as a mentor or anything, but I can see his proposal nevertheless. -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85114]: New comment added
User Purodha posted a comment on MediaWiki.r85114. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85114#c15593 Comment: Fixed in r85115 now. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84825]: New comment added
User Duplicatebug posted a comment on MediaWiki.r84825. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84825#c15594 Comment: But the user does not get a (import) token, because prop=infointoken=import does not check for user right importupload. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85062]: New comment added
User Duplicatebug posted a comment on MediaWiki.r85062. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85062#c15595 Comment: You can add qqq-messages also on translatewiki.net direct, it get exported the next time, with all the other messages. Now the message does [[translatewiki:MediaWiki:Blocklist-target/qqq|not exist]] and so not shown inside the interface, when editing other languages of that message (maybe that is a bug/feature in Extension:Translate). ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r64853]: Revision status changed
User ^demon changed the status of MediaWiki.r64853. Old Status: ok New Status: reverted Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/64853#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85130]: Revision status changed
User Krinkle changed the status of MediaWiki.r85130. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85130#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85127]: Revision status changed
User MaxSem changed the status of MediaWiki.r85127. Old Status: new New Status: deferred Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85127#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85128]: New comment added
User Platonides posted a comment on MediaWiki.r85128. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85128#c15596 Comment: This was in core?? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85131]: New comment added, and revision status changed
User Nikerabbit changed the status of MediaWiki.r85131. Old Status: new New Status: fixme User Nikerabbit also posted a comment on MediaWiki.r85131. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85131#c15597 Comment: That looks awfully slow. For each and every message it executes 2x in_array(), after which it calls wfMessage multiple times, transforms the message texts and uses == for comparison. Besides, using wfMessage() will fail once we no longer user mediawiki-namespace for mediawiki translations. I don't think this is the right approach. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r67684]: New comment added
User Duplicatebug posted a comment on MediaWiki.r67684. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/67684#c15599 Comment: Please have a look at bug 28277. Transwiki import is broken for some interlanguage sources, when the source is on another sister project, like en.wikipedia for pt.wikibooks, because code$followRedirects/code defaults to codefalse/code ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85131]: New comment added
User Nikerabbit posted a comment on MediaWiki.r85131. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85131#c15600 Comment: we = twn and as soon as I have time to look at it. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84985]: New comment added
User Trevor Parscal posted a comment on MediaWiki.r84985. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84985#c15602 Comment: Excellent catch - I followed up in r85140 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84985]: Revision status changed
User Trevor Parscal changed the status of MediaWiki.r84985. Old Status: fixme New Status: new Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84985#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85080]: New comment added
User Solitarius posted a comment on MediaWiki.r85080. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85080#c15603 Comment: This patch cause the following error message: Parse error: syntax error, unexpected T_ELSE in /var/www/w/includes/MessageCache.php on line 613. Also check r78179. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85080]: New comment added
User Reedy posted a comment on MediaWiki.r85080. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85080#c15604 Comment: Fixed in r85141, thanks ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85140]: Revision status changed
User Krinkle changed the status of MediaWiki.r85140. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85140#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84985]: Revision status changed
User Krinkle changed the status of MediaWiki.r84985. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84985#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84627]: Revision status changed
User Trevor Parscal changed the status of MediaWiki.r84627. Old Status: fixme New Status: new Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84627#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] svn: Failed to add directory 'config': an unversioned directory of the same name already exists
Dear fellow SVN users, if you encounter $ svn update ... svn: Failed to add directory 'config': an unversioned directory of the same name already exists Then you had better move that directory and all its contents elsewhere, and do svn update again, to avoid a half updated wiki. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
Can you possibly get any more hyperbolic? For your information, I've been trying to clean up the Javascript of en.wiktionary.org this past week, which is a total nightmare (and it's a sister project!). If you'd like to help, feel free to join the discussions: http://en.wiktionary.org/wiki/MediaWiki_talk:Common.js http://en.wiktionary.org/wiki/Wiktionary_talk:Per-browser_preferences#Proposal_to_migrate_into_a_user_scripts_library Ryan Kaldari On 4/1/11 4:51 PM, MZMcBride wrote: Ryan Kaldari wrote: Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing clean-up on a few wikis, but I usually just get chewed out by the local admins for not discussing every change in detail (which obviously doesn't scale for fixing 200+ wikis). I would love to hear ideas for how to address this problem. This caught my eye as Wikimedia has far more than 200 wikis. There seems to be a shift happening within the Wikimedia Foundation. The sister projects have routinely been ignored in the past, but things seem to be going further lately Personally, I'm in favor of disbanding all of the projects that Wikimedia has no intention of actively supporting in the near-future or even mid-range future. I think the current situation in which certain sister projects are supported in name only is unacceptable to the users and to the public. MZMcBride ___ 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] Focus on sister projects
Good idea. After the 1.17 deployment, I've been trying to go through and clean-up some of the Javascript cruft that has built up on the various wikis over the years. One of the main goals of 1.17 was improving page loading speeds by optimizing Javascript delivery. Of course if all the wikis are serving lots of old redundant Javascript, the optimization doesn't accomplish that much. On wiktionary specifically, the importScript and importExternalScript functions are redundant, and the Wiktionary:PREFS system should be retired now that Gadgets are available. I admit I was much too gung-ho in my clean-up regarding Wiktionary, and I intend to let the admins there handle it from here. As long as we're on the subject of wiktionary, I notice that there's a lot of custom Javascript there for handling specialized editing tasks like editing glosses, managing translations, etc. It seems like some of this functionality could be improved further and developed into full-fledged extensions (making it easy for other wiktionaries to use as well). Would you have any interest in working up a couple Wiktionary project proposals for the upcoming Hackathon in Berlin? Ryan Kaldari On 4/1/11 5:53 PM, Conrad Irwin wrote: Ryan — what is your goal with the cleanup? Part of the reason I think you're getting nowhere on Wiktionary is that as far as anyone there can tell you're just changing stuff for the fun of changing stuff (and breaking it in the process...). If you can tell us what you're trying to achieve, then (given that we wrote the code, and have a reasonably good idea of how it's used), we can probably help you. Conrad On Fri, Apr 1, 2011 at 5:11 PM, Ryan Kaldarirkald...@wikimedia.org wrote: Can you possibly get any more hyperbolic? For your information, I've been trying to clean up the Javascript of en.wiktionary.org this past week, which is a total nightmare (and it's a sister project!). If you'd like to help, feel free to join the discussions: http://en.wiktionary.org/wiki/MediaWiki_talk:Common.js http://en.wiktionary.org/wiki/Wiktionary_talk:Per-browser_preferences#Proposal_to_migrate_into_a_user_scripts_library Ryan Kaldari On 4/1/11 4:51 PM, MZMcBride wrote: Ryan Kaldari wrote: Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing clean-up on a few wikis, but I usually just get chewed out by the local admins for not discussing every change in detail (which obviously doesn't scale for fixing 200+ wikis). I would love to hear ideas for how to address this problem. This caught my eye as Wikimedia has far more than 200 wikis. There seems to be a shift happening within the Wikimedia Foundation. The sister projects have routinely been ignored in the past, but things seem to be going further lately Personally, I'm in favor of disbanding all of the projects that Wikimedia has no intention of actively supporting in the near-future or even mid-range future. I think the current situation in which certain sister projects are supported in name only is unacceptable to the users and to the public. MZMcBride ___ 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] Focus on sister projects
Ok — yes loading speeds are definitely something worth improving. WT:PREFS to become gadgets has been discussed ever since gadgets was released, it will happen one day :). Luckily that code is only loaded for people who are using WT:PREFS, so it should have minimal impact. I'd be pretty interested to — do you have a guideline as to the expected format. In particular I think the core of the editor, which provides a framework for javascript to load, edit, undo, redo, and save the page (with edit summaries) would be pretty useful everywhere. It's documented in the first half of http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_docs and there's a tutorial at http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_tutorial.js — but it could do with new-ification (in particular some jQuery would be nice, and there's probably a better javascript API wrapper than JsMwApi :). Conrad On Fri, Apr 1, 2011 at 6:40 PM, Ryan Kaldari rkald...@wikimedia.org wrote: Good idea. After the 1.17 deployment, I've been trying to go through and clean-up some of the Javascript cruft that has built up on the various wikis over the years. One of the main goals of 1.17 was improving page loading speeds by optimizing Javascript delivery. Of course if all the wikis are serving lots of old redundant Javascript, the optimization doesn't accomplish that much. On wiktionary specifically, the importScript and importExternalScript functions are redundant, and the Wiktionary:PREFS system should be retired now that Gadgets are available. I admit I was much too gung-ho in my clean-up regarding Wiktionary, and I intend to let the admins there handle it from here. As long as we're on the subject of wiktionary, I notice that there's a lot of custom Javascript there for handling specialized editing tasks like editing glosses, managing translations, etc. It seems like some of this functionality could be improved further and developed into full-fledged extensions (making it easy for other wiktionaries to use as well). Would you have any interest in working up a couple Wiktionary project proposals for the upcoming Hackathon in Berlin? Ryan Kaldari On 4/1/11 5:53 PM, Conrad Irwin wrote: Ryan — what is your goal with the cleanup? Part of the reason I think you're getting nowhere on Wiktionary is that as far as anyone there can tell you're just changing stuff for the fun of changing stuff (and breaking it in the process...). If you can tell us what you're trying to achieve, then (given that we wrote the code, and have a reasonably good idea of how it's used), we can probably help you. Conrad On Fri, Apr 1, 2011 at 5:11 PM, Ryan Kaldarirkald...@wikimedia.org wrote: Can you possibly get any more hyperbolic? For your information, I've been trying to clean up the Javascript of en.wiktionary.org this past week, which is a total nightmare (and it's a sister project!). If you'd like to help, feel free to join the discussions: http://en.wiktionary.org/wiki/MediaWiki_talk:Common.js http://en.wiktionary.org/wiki/Wiktionary_talk:Per-browser_preferences#Proposal_to_migrate_into_a_user_scripts_library Ryan Kaldari On 4/1/11 4:51 PM, MZMcBride wrote: Ryan Kaldari wrote: Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing clean-up on a few wikis, but I usually just get chewed out by the local admins for not discussing every change in detail (which obviously doesn't scale for fixing 200+ wikis). I would love to hear ideas for how to address this problem. This caught my eye as Wikimedia has far more than 200 wikis. There seems to be a shift happening within the Wikimedia Foundation. The sister projects have routinely been ignored in the past, but things seem to be going further lately Personally, I'm in favor of disbanding all of the projects that Wikimedia has no intention of actively supporting in the near-future or even mid-range future. I think the current situation in which certain sister projects are supported in name only is unacceptable to the users and to the public. MZMcBride ___ 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] Focus on sister projects
Happy-melon wrote: I would be very interested to hear what criterion you would use to separate out a group of 200 (or any number other than zero, one or all [1]) wikis which are maintained from the rest which are unmaintained; where the distinction in quality of service, the ratio of Foundation resources to userbase or readership, or any other meaningful statistic, showed any obvious jump across the boundary. You would need to be able to show such a thing in order to make anyone believe that there is any intention (or lack thereof) for the Foundation to do anything with the sister projects. I'm not really sure what you're saying here. Are you trying to argue that the other projects get anywhere near as much attention as Wikipedia? It's one thing to argue that more of the Foundation's resources should be directed to particular projects; that's a perfectly reasonable discussion, but for foundation-l, not here. It's quite another to argue that an arbitrary number (don't forget that Ryan is referring to the number of wikis with broken JavaScript which are unable to fix it themselves, not any attempt to count every wiki in the cluster) represents some freudian slip into some diabolical scheme or even into a subconscious mindset. Even if that is what you want to claim, that belongs in foundation-l as well. Our shell request workflow could use work is a time-honoured topic which comes and goes and seems to be in a relatively successful era at the moment. Anything more political than that has nothing to do with, and no place on, wikitech-l. I considered the venue before posting. But the reality is that the tech side (or specifically MediaWiki) is currently at the core of every Wikimedia wiki. Its development, its features, its architecture, etc. all have a fundamental impact on what any Wikimedia site is. The focus of MediaWiki should mirror the focus of the Wikimedia Foundation. Currently MediaWiki tries to do too much, tries to fill too many niches, and ends up not doing very much particularly well. I'd like to see that change. I'd like to see it focused, as I think it would benefit both MediaWiki and the Wikimedia Foundation to a huge extent. If you think that's a topic for foundation-l, I suppose we'll have to agree to disagree. Personally, I think it's a tech topic, given that nearly every change seems to at least begin with code development. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
Ryan, My thoughts (from a sister project side) It is useful to go through a few bits to manage expectations. * General introductory information around the scope, expected outcomes, summary of what wikis can do and general dates and for this to be placed at the Techblog. This allows local wikis to know and prepare. As the importance rises, I think that a general sitenotice for a week is appropriate. Is it possible to do a site notice for admins only? As that would be most useful. [This lets those who are alert into the playpen and involved] * A place where the detail of the project and outcomes, and how to participate, and where to advise (aka complain) where and when things stop working, or help is needed. If you are planning to go through series of wikis, then if there is a timetable to which people can prepare, or even be available to help, and how they can help. [This empowers people and puts the emphasis on them to get themselves organised for your timetable, your time being the limited factor] * Where you are planning on doing work, having generic information at your local talk page about who you are and that points them to the information pages (general and detail), to the fact that they had been told it was going to happen and to where they should bitch and complain. [Akin to TALK TO THE HAND] While admins will always be protective of their patch, especially if something breaks universally, none of us wishes to impede progress and we want to know how we can help. - Make us do our homework - Give us time to marshal resources, and - Have expectations that we should be organised to help. If we cannot do that, then it is somewhat upon our heads if you have to do what you have to do. Expectations and activities need to be reasonable and practical to both parties. Regards, Andrew - CSS clueless beyond the basics On 1 Apr 2011 at 17:11, Ryan Kaldari wrote: Can you possibly get any more hyperbolic? For your information, I've been trying to clean up the Javascript of en.wiktionary.org this past week, which is a total nightmare (and it's a sister project!). If you'd like to help, feel free to join the discussions: http://en.wiktionary.org/wiki/MediaWiki_talk:Common.js http://en.wiktionary.org/wiki/Wiktionary_talk:Per-browser_preferences#Proposal_to_migrate_into_a_user_scripts_library Ryan Kaldari On 4/1/11 4:51 PM, MZMcBride wrote: Ryan Kaldari wrote: Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing clean-up on a few wikis, but I usually just get chewed out by the local admins for not discussing every change in detail (which obviously doesn't scale for fixing 200+ wikis). I would love to hear ideas for how to address this problem. This caught my eye as Wikimedia has far more than 200 wikis. There seems to be a shift happening within the Wikimedia Foundation. The sister projects have routinely been ignored in the past, but things seem to be going further lately Personally, I'm in favor of disbanding all of the projects that Wikimedia has no intention of actively supporting in the near-future or even mid-range future. I think the current situation in which certain sister projects are supported in name only is unacceptable to the users and to the public. MZMcBride ___ 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
