Re: [Wikitech-l] MediaWiki RFC reporter bot
You have not provided enough detail. What wikis should such tool target, and what are relevant links to categories. On Tue, 10 Dec 2013, at 14:09, MZMcBride wrote: Hi. I filed https://bugzilla.wikimedia.org/show_bug.cgi?id=58250 if you or someone you know feels like writing a small script that can report new and status changes to MediaWiki requests for comments on a weekly basis to this mailing list. I think such a script would directly improve participation in RFCs. 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] Re-evaluating MediaWiki ResourceLoader's debug mode
On 12/09/2013 11:30 PM, MZMcBride wrote: Matthew Flaschen wrote: On 12/09/2013 09:29 PM, MZMcBride wrote: * You can specify debug=true. ** Specifying the URL parameter can damage reproducibility. ** URL parameter is non-obvious to just about everyone. I can't think of a more straight-forward name. It's also clearly documented. Clearly documented where? The detailed explanation is on the ResourceLoader features page (https://www.mediawiki.org/wiki/ResourceLoader/Features#Debug_mode), which is linked from the main documentation for developers using ResourceLoader (https://www.mediawiki.org/wiki/ResourceLoader/Developing_with_ResourceLoader). I just made a tweak to make it more prominent on the developing page. I see that you've filed two bugs regarding source maps: https://bugzilla.wikimedia.org/45514 and https://bugzilla.wikimedia.org/53510. Thanks for these. Source maps are another good approach to consider. Yes, I'd like to see this. It's a standard approach, somewhat analogous to how C, etc. debugging works. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Patrolling on english wikipedia
I was recently suggested by someone (and requested by someone else) to use patrolling on good edits in huggle, however after executing the patrol api query I receive this error: ?xml version=1.0?api servedby=mw1130error code=patroldisabled info=Patrolling is disabled on this wiki //api Is it true? Is patrolling really disabled on English wikipedia? It sounds to me very unlike, so is this a bug and different error message should have been displayed? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Patrolling on english wikipedia
On the English Wikipedia, only new *pages* are patrolled. This is the case on most Wikimedia wikis, actually. See [1] [1] http://meta.wikimedia.org/wiki/Help:Patrolled_edit#Patrolled_pages On Tue, Dec 10, 2013 at 7:40 AM, Petr Bena benap...@gmail.com wrote: I was recently suggested by someone (and requested by someone else) to use patrolling on good edits in huggle, however after executing the patrol api query I receive this error: ?xml version=1.0?api servedby=mw1130error code=patroldisabled info=Patrolling is disabled on this wiki //api Is it true? Is patrolling really disabled on English wikipedia? It sounds to me very unlike, so is this a bug and different error message should have been displayed? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- *Theo (User:Theopolisme on Wikipedia)http://enwp.org/wiki/User:Theopolisme http://en.wikipedia.org/wiki/User:Theopolisme* ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Patrolling on english wikipedia
OK, so the original suggestion I got from Nemo (http://lists.wikimedia.org/pipermail/wikitech-l/2013-September/072047.html) to use patrolling as solution for suspicious edits queue (which I proposed here http://lists.wikimedia.org/pipermail/wikitech-l/2013-September/072038.html ) was actually not possible, because the feature is disabled anyway... On Tue, Dec 10, 2013 at 3:05 PM, Theopolisme theopolismew...@gmail.com wrote: On the English Wikipedia, only new *pages* are patrolled. This is the case on most Wikimedia wikis, actually. See [1] [1] http://meta.wikimedia.org/wiki/Help:Patrolled_edit#Patrolled_pages On Tue, Dec 10, 2013 at 7:40 AM, Petr Bena benap...@gmail.com wrote: I was recently suggested by someone (and requested by someone else) to use patrolling on good edits in huggle, however after executing the patrol api query I receive this error: ?xml version=1.0?api servedby=mw1130error code=patroldisabled info=Patrolling is disabled on this wiki //api Is it true? Is patrolling really disabled on English wikipedia? It sounds to me very unlike, so is this a bug and different error message should have been displayed? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- *Theo (User:Theopolisme on Wikipedia)http://enwp.org/wiki/User:Theopolisme http://en.wikipedia.org/wiki/User:Theopolisme* ___ 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] MediaWiki RFC reporter bot
Gryllida wrote: You have not provided enough detail. What wikis should such tool target, and what are relevant links to categories. Nemo helpfully responded here: https://bugzilla.wikimedia.org/58250#c1. This idea is strictly related to https://www.mediawiki.org/wiki/RFC; apologies for any confusion. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Patrolling on english wikipedia
Currently, but you could always get consensus to get it enabled. RC patrolling was switched off in 2005 - https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28news%29diff=9146943oldid=9146404 NP patrolling was turned on in 2007 - https://en.wikipedia.org/w/index.php?title=Wikipedia:New_pages_patrol/patrolled_pagesoldid=171938297 And the API didn't support patrolling until 2008 - https://www.mediawiki.org/wiki/Special:Code/MediaWiki/40435 So obviously things have changed a lot and you may have an actual use case for it now. That said, I'm not sure patrolled edits is really the best option. It sounds like you want a queue that you can add things to for later review. But with patrolled edits, you can only remove things. So if *every* unpatrolled edit goes through huggle and is either reverted, patrolled, or left for later review, it would work. But if it doesn't look at every edit, then your queue is going to be a mix of suspicious edits and things that were never looked at in the first place. Only admins, bots, and people in the autopatrol group would have their edits patrolled automatically, which means you'd have to patrol the edits of a large fraction of regular users. -- Alex On 12/10/2013 9:24 AM, Petr Bena wrote: OK, so the original suggestion I got from Nemo (http://lists.wikimedia.org/pipermail/wikitech-l/2013-September/072047.html) to use patrolling as solution for suspicious edits queue (which I proposed here http://lists.wikimedia.org/pipermail/wikitech-l/2013-September/072038.html ) was actually not possible, because the feature is disabled anyway... On Tue, Dec 10, 2013 at 3:05 PM, Theopolisme theopolismew...@gmail.com wrote: On the English Wikipedia, only new *pages* are patrolled. This is the case on most Wikimedia wikis, actually. See [1] [1] http://meta.wikimedia.org/wiki/Help:Patrolled_edit#Patrolled_pages On Tue, Dec 10, 2013 at 7:40 AM, Petr Bena benap...@gmail.com wrote: I was recently suggested by someone (and requested by someone else) to use patrolling on good edits in huggle, however after executing the patrol api query I receive this error: ?xml version=1.0?api servedby=mw1130error code=patroldisabled info=Patrolling is disabled on this wiki //api Is it true? Is patrolling really disabled on English wikipedia? It sounds to me very unlike, so is this a bug and different error message should have been displayed? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- *Theo (User:Theopolisme on Wikipedia)http://enwp.org/wiki/User:Theopolisme http://en.wikipedia.org/wiki/User:Theopolisme* ___ 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] Patrolling on english wikipedia
From my own experience it would be faster and less painful to implement my own patrolled edits feature / queue using some own interface on labs for example, than getting anything passed through RFC on enwp :P But if anyone is in a mood to commit suicide, you can of course start a RFC on english wikipedia On Tue, Dec 10, 2013 at 4:48 PM, Alex mrzmanw...@gmail.com wrote: Currently, but you could always get consensus to get it enabled. RC patrolling was switched off in 2005 - https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28news%29diff=9146943oldid=9146404 NP patrolling was turned on in 2007 - https://en.wikipedia.org/w/index.php?title=Wikipedia:New_pages_patrol/patrolled_pagesoldid=171938297 And the API didn't support patrolling until 2008 - https://www.mediawiki.org/wiki/Special:Code/MediaWiki/40435 So obviously things have changed a lot and you may have an actual use case for it now. That said, I'm not sure patrolled edits is really the best option. It sounds like you want a queue that you can add things to for later review. But with patrolled edits, you can only remove things. So if *every* unpatrolled edit goes through huggle and is either reverted, patrolled, or left for later review, it would work. But if it doesn't look at every edit, then your queue is going to be a mix of suspicious edits and things that were never looked at in the first place. Only admins, bots, and people in the autopatrol group would have their edits patrolled automatically, which means you'd have to patrol the edits of a large fraction of regular users. -- Alex On 12/10/2013 9:24 AM, Petr Bena wrote: OK, so the original suggestion I got from Nemo (http://lists.wikimedia.org/pipermail/wikitech-l/2013-September/072047.html) to use patrolling as solution for suspicious edits queue (which I proposed here http://lists.wikimedia.org/pipermail/wikitech-l/2013-September/072038.html ) was actually not possible, because the feature is disabled anyway... On Tue, Dec 10, 2013 at 3:05 PM, Theopolisme theopolismew...@gmail.com wrote: On the English Wikipedia, only new *pages* are patrolled. This is the case on most Wikimedia wikis, actually. See [1] [1] http://meta.wikimedia.org/wiki/Help:Patrolled_edit#Patrolled_pages On Tue, Dec 10, 2013 at 7:40 AM, Petr Bena benap...@gmail.com wrote: I was recently suggested by someone (and requested by someone else) to use patrolling on good edits in huggle, however after executing the patrol api query I receive this error: ?xml version=1.0?api servedby=mw1130error code=patroldisabled info=Patrolling is disabled on this wiki //api Is it true? Is patrolling really disabled on English wikipedia? It sounds to me very unlike, so is this a bug and different error message should have been displayed? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- *Theo (User:Theopolisme on Wikipedia)http://enwp.org/wiki/User:Theopolisme http://en.wikipedia.org/wiki/User:Theopolisme* ___ 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] MacOS (OSX) developers / tech people with mac needed for huggle packaging
Hi, Huggle 3 is slowly getting near to first release, and I have yet set up some built environment for early beta versions. 1 for windows on one of my own windows boxens (using NSIS and MinGW) which I use to release beta version packages on sourceforge, and other one for linux using launchpad. So that both Windows and Linux users can easily get and install huggle packages with no need to understand how compiling works or any need to resolve any dependencies themselves. [1] Unfortunately, we have no such thing for MacOS, not just because neither me or any other current huggle dev owns a Mac, but also because there is no free launchpad like service for mac's I know of. So, if someone of you has enough experience with packaging software for Macs and wants to help with huggle packaging for MacOS, let us know so that we can setup some build process for MacOS users as well. 1 - More information on how to get huggle packages is at https://en.wikipedia.org/wiki/Wikipedia:Huggle/Huggle3_Beta#Prebuilt_packages ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
Hoi, A blanket ban like this is an extremely bad idea. The notion that you should think twice before you make something a default option does have merit. Gadgets, java script all provide functionality that is sometimes / often experimental. Without the benefit of experiments we will get into a rut, We will have moved away from the credo of be bold. Thanks, GerardM On 9 December 2013 22:02, K. Peachey p858sn...@gmail.com wrote: For wider discussion --- From: bugzilla-daemon at wikimedia.org Subject: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites http://news.gmane.org/find-root.php?message_id=%3cbug%2d58236%2d3%40https.bugzilla.wikimedia.org%2f%3e Newsgroups: gmane.org.wikimedia.mediawiki.bugs http://news.gmane.org/gmane.org.wikimedia.mediawiki.bugs Date: 2013-12-09 20:41:41 GMT (19 minutes ago) https://bugzilla.wikimedia.org/show_bug.cgi?id=58236 Web browser: --- Bug ID: 58236 Summary: No longer allow gadgets to be turned on by default for all users on Wikimedia sites Product: Wikimedia Version: wmf-deployment Hardware: All OS: All Status: NEW Severity: normal Priority: Unprioritized Component: Site requests Assignee: wikibugs-l at lists.wikimedia.org Reporter: jared.zimmerman at wikimedia.org CC: benapetr at gmail.com, bugzilla+org.wikimedia at tuxmachine.com, dereckson at espace-win.org, greg at wikimedia.org , tomasz at twkozlowski.net, wikimedia.bugs at snowolf.eu Classification: Unclassified Mobile Platform: --- Gadgets being turned on for all site users (including readers) can cause a confusing users experience, especially when there is some disagreement and defaults change without notice (readers are rarely if ever part of these discussions) Move to model where gadgets are per user rather than part of a default experience for users -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l at lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/wikibugs-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] MacOS (OSX) developers / tech people with mac needed for huggle packaging
On Tue, Dec 10, 2013 at 8:14 AM, Petr Bena benap...@gmail.com wrote: Hi, Huggle 3 is slowly getting near to first release, and I have yet set up some built environment for early beta versions. 1 for windows on one of my own windows boxens (using NSIS and MinGW) which I use to release beta version packages on sourceforge, and other one for linux using launchpad. So that both Windows and Linux users can easily get and install huggle packages with no need to understand how compiling works or any need to resolve any dependencies themselves. [1] Unfortunately, we have no such thing for MacOS, not just because neither me or any other current huggle dev owns a Mac, but also because there is no free launchpad like service for mac's I know of. So, if someone of you has enough experience with packaging software for Macs and wants to help with huggle packaging for MacOS, let us know so that we can setup some build process for MacOS users as well. I hacked together a Homebrew formula: https://gist.github.com/atdt/7894375 But: brew install --HEAD huggle3 Warning: Your Xcode (4.6.3) is outdated Please update to Xcode 5.0.1. Xcode can be updated from the App Store. == Cloning https://github.com/huggle/huggle3-qt-lx.git Updating /Library/Caches/Homebrew/huggle3--git == ./configure --disable-silent-rules --prefix=/usr/local/Cellar/huggle3/HEAD == make exception.cpp: In instantiation of ‘std::basic_ostream_CharT, _Traits std::operator(std::basic_ostream_CharT, _Traits, const std::basic_string_CharT, _Traits, _Alloc) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar]’: exception.cpp:17: instantiated from here exception.cpp:17: error: explicit instantiation of ‘std::basic_ostream_CharT, _Traits std::operator(std::basic_ostream_CharT, _Traits, const std::basic_string_CharT, _Traits, _Alloc) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar]’ but no definition available make: *** [exception.o] Error 1 make: *** Waiting for unfinished jobs ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
I think the bug is sufficiently killed at this point, so I wanted to add my $.02 here instead of there. As hoo mentioned on the bug, there have been some gadgets that have opened up some serious security and performance issues, so I can sympathize with Jared wishing they didn't exist at times. But without them, we would get even worse stuff hacked into Common.js. So I think we need to focus on the desired process so useful gadgets can safely be set as default. Do any of the communities have formal policies on how code should be formalized into a gadget, and a process for setting that gadget as a default? There seems to be some inferred policy from Wikipedia:Gadget, but I'm not finding a specific policy on it. On Tue, Dec 10, 2013 at 9:01 AM, Gerard Meijssen gerard.meijs...@gmail.comwrote: Hoi, A blanket ban like this is an extremely bad idea. The notion that you should think twice before you make something a default option does have merit. Gadgets, java script all provide functionality that is sometimes / often experimental. Without the benefit of experiments we will get into a rut, We will have moved away from the credo of be bold. Thanks, GerardM On 9 December 2013 22:02, K. Peachey p858sn...@gmail.com wrote: For wider discussion --- From: bugzilla-daemon at wikimedia.org Subject: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites http://news.gmane.org/find-root.php?message_id=%3cbug%2d58236%2d3%40https.bugzilla.wikimedia.org%2f%3e Newsgroups: gmane.org.wikimedia.mediawiki.bugs http://news.gmane.org/gmane.org.wikimedia.mediawiki.bugs Date: 2013-12-09 20:41:41 GMT (19 minutes ago) https://bugzilla.wikimedia.org/show_bug.cgi?id=58236 Web browser: --- Bug ID: 58236 Summary: No longer allow gadgets to be turned on by default for all users on Wikimedia sites Product: Wikimedia Version: wmf-deployment Hardware: All OS: All Status: NEW Severity: normal Priority: Unprioritized Component: Site requests Assignee: wikibugs-l at lists.wikimedia.org Reporter: jared.zimmerman at wikimedia.org CC: benapetr at gmail.com, bugzilla+org.wikimedia at tuxmachine.com, dereckson at espace-win.org, greg at wikimedia.org , tomasz at twkozlowski.net, wikimedia.bugs at snowolf.eu Classification: Unclassified Mobile Platform: --- Gadgets being turned on for all site users (including readers) can cause a confusing users experience, especially when there is some disagreement and defaults change without notice (readers are rarely if ever part of these discussions) Move to model where gadgets are per user rather than part of a default experience for users -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l at lists.wikimedia.orghttps:// lists.wikimedia.org/mailman/listinfo/wikibugs-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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
In the Hebrew Wikipedia it's pretty straightforward: A proposal is made at the Village Pump-like page, people bring up arguments for and against, and if there are no strong arguments against, an administrator makes the gadget default after a few days. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore 2013/12/10 Chris Steipp cste...@wikimedia.org I think the bug is sufficiently killed at this point, so I wanted to add my $.02 here instead of there. As hoo mentioned on the bug, there have been some gadgets that have opened up some serious security and performance issues, so I can sympathize with Jared wishing they didn't exist at times. But without them, we would get even worse stuff hacked into Common.js. So I think we need to focus on the desired process so useful gadgets can safely be set as default. Do any of the communities have formal policies on how code should be formalized into a gadget, and a process for setting that gadget as a default? There seems to be some inferred policy from Wikipedia:Gadget, but I'm not finding a specific policy on it. On Tue, Dec 10, 2013 at 9:01 AM, Gerard Meijssen gerard.meijs...@gmail.comwrote: Hoi, A blanket ban like this is an extremely bad idea. The notion that you should think twice before you make something a default option does have merit. Gadgets, java script all provide functionality that is sometimes / often experimental. Without the benefit of experiments we will get into a rut, We will have moved away from the credo of be bold. Thanks, GerardM On 9 December 2013 22:02, K. Peachey p858sn...@gmail.com wrote: For wider discussion --- From: bugzilla-daemon at wikimedia.org Subject: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites http://news.gmane.org/find-root.php?message_id=%3cbug%2d58236%2d3%40https.bugzilla.wikimedia.org%2f%3e Newsgroups: gmane.org.wikimedia.mediawiki.bugs http://news.gmane.org/gmane.org.wikimedia.mediawiki.bugs Date: 2013-12-09 20:41:41 GMT (19 minutes ago) https://bugzilla.wikimedia.org/show_bug.cgi?id=58236 Web browser: --- Bug ID: 58236 Summary: No longer allow gadgets to be turned on by default for all users on Wikimedia sites Product: Wikimedia Version: wmf-deployment Hardware: All OS: All Status: NEW Severity: normal Priority: Unprioritized Component: Site requests Assignee: wikibugs-l at lists.wikimedia.org Reporter: jared.zimmerman at wikimedia.org CC: benapetr at gmail.com, bugzilla+org.wikimedia at tuxmachine.com, dereckson at espace-win.org, greg at wikimedia.org , tomasz at twkozlowski.net, wikimedia.bugs at snowolf.eu Classification: Unclassified Mobile Platform: --- Gadgets being turned on for all site users (including readers) can cause a confusing users experience, especially when there is some disagreement and defaults change without notice (readers are rarely if ever part of these discussions) Move to model where gadgets are per user rather than part of a default experience for users -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l at lists.wikimedia.orghttps:// lists.wikimedia.org/mailman/listinfo/wikibugs-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 ___ 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] Patrolling on english wikipedia
On 10/12/13 13:40, Petr Bena wrote: I was recently suggested by someone (and requested by someone else) to use patrolling on good edits in huggle, however after executing the patrol api query I receive this error: ?xml version=1.0?api servedby=mw1130error code=patroldisabled info=Patrolling is disabled on this wiki //api Is it true? Is patrolling really disabled on English wikipedia? It sounds to me very unlike, so is this a bug and different error message should have been displayed? What about using the thank feature for good edits? -L ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Patrolling on english wikipedia
On 2013-12-10 11:05 AM, Isarra Yos zhoris...@gmail.com wrote: On 10/12/13 13:40, Petr Bena wrote: I was recently suggested by someone (and requested by someone else) to use patrolling on good edits in huggle, however after executing the patrol api query I receive this error: ?xml version=1.0?api servedby=mw1130error code=patroldisabled info=Patrolling is disabled on this wiki //api Is it true? Is patrolling really disabled on English wikipedia? It sounds to me very unlike, so is this a bug and different error message should have been displayed? What about using the thank feature for good edits? -L ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Really this seems the ideal use case for edit tags (the obvious problem is currently you can't set them by the api afaik) -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki to Latex Converter
Sure, I'd love to look at your code. Hopefully we can avoid reinventing the wheel *too* many times. Is it available some where? Or a written report? --scott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Patrolling on english wikipedia
On 12/10/2013 01:05 PM, Isarra Yos wrote: What about using the thank feature for good edits? Thanking is for when someone does something special. Not barnstar worthy (that's even more special), but more than just a trivial fix. There are a lot of good edits that probably aren't thanks-worthy. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On 12/10/2013 01:04 PM, Amir E. Aharoni wrote: In the Hebrew Wikipedia it's pretty straightforward: A proposal is made at the Village Pump-like page, people bring up arguments for and against, and if there are no strong arguments against, an administrator makes the gadget default after a few days. I know more about how it becomes a gadget, rather than how it becomes default. It's done at https://en.wikipedia.org/wiki/Wikipedia:Gadget/proposals . It's not very formal currently. Basically, there is a proposal, then if no one objects after a few days (or there is consensus despite the objection), an admin can make it a gadget. It looks like people may also propose making them default at the same page, but I'm not sure. People may want to get wider input at Village Pump (technical) in such cases. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki to Latex Converter
On Mon, Nov 25, 2013 at 10:49 PM, Santhosh Thottingal santhosh.thottin...@gmail.com wrote: To support complex scriptshttps://en.wikipedia.org/wiki/Complex_text_layout we need to use a tex system that can support Unicode and complex script rendering system. Xetex https://en.wikipedia.org/wiki/XeTeX works very well with these scripts.I tried the MediaWiki to Latex converter with Malayalam script, and the result is buggy. Could you take a look at the attached PDF, generated from https://ml.wikipedia.org/wiki/%E0%B4%AE%E0%B4%B2%E0%B4%AF%E0%B4%BE%E0%B4%B3%E0%B4%82 with our not-yet-deployed new software? Any Malayam-specific feedback you could provide would be very useful. --scott ps. the images in the pdf are deliberately very low resolution to keep the overall size of the PDF small. -- (http://cscott.net) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Hackathon 2014 - Save the Date! May 9th - 11th 2014
Dear all, just a short note from Wikimedia CH that we are currently preparing the 2014 Hackathon in Zürich. Contracts are about to be signed and we want to let you know that you can count on us to create you an unique experience in Switzerland. Date: May 9th - 11th Location: Youth Hostel Zürich A preliminary page can be found on MediaWiki.org More to come soon! Feel free to contact us in case of questions! Charles and Manuel -- Manuel Schneider - Chief Information Officer Wikimedia CH - Verein zur Förderung Freien Wissens Lausanne, +41 (21) 340 66 22 - www.wikimedia.ch ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Do we have MediaWiki activities at 30C3 (Chaos Communication Congress) Hamburg 27.-30.12.2013 ?
https://events.ccc.de/congress/2013/wiki/Main_Page The 30th Chaos Communication Congress (30C3) is an annual four-day conference on technology, society and utopia. Hello, I justed wanted to know if someone plans to travel to Hamburg, and whether there are any planned MediaWiki-related activities. Preliminary conference schedule: https://events.ccc.de/congress/2013/Fahrplan/ . Just remember our first MediaWiki meeting at the 21C3 (December 2004) in Berlin: https://www.mediawiki.org/wiki/File:20041229_First_MediaWiki_Developer_Conference_Poster_with-signatures_21C3_Berlin.jpg Kind regards, Tom signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Do we have MediaWiki activities at 30C3 (Chaos Communication Congress) Hamburg 27.-30.12.2013 ?
Hey, At least half a dozen people from WMDE will be there. Unlike last year, we will not have a stand. MediaWiki as a whole does seem out of scope for the congress, if one considers the topics covered there. I did hear some thing about the FOSDEM wiki dev room needing more input and participation :) Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Do we have MediaWiki activities at 30C3 (Chaos Communication Congress) Hamburg 27.-30.12.2013 ?
Am 10.12.2013 21:30, schrieb Jeroen De Dauw: At least half a dozen people from WMDE will be there. Unlike last year, we will not have a stand. MediaWiki as a whole does seem out of scope for the congress, if one considers the topics covered there. I did hear some thing about the FOSDEM wiki dev room needing more input and participation :) Cheers -- Thanks. I'll attend, perhaps we can meet there. Additional info: The conference ticket pre-sale closes in about 2 hours from now, see https://events.ccc.de/2013/12/08/online-ticket-sale-closing-soon/ ***The ticket shop will not accept any new orders after December 10th, 23:59:59 CET. * ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Help needed with ParserCache::getKey() and ParserCache::getOptionsKey()
(re-sending from the right account for this list) Hi. I (rather urgently) need some input from someone who understands how parser caching works. (Rob: please forward as appropriate). tl;dr: what is the intention behind the current implementation of ParserCache::getOptionsKey()? It's based on the page ID only, not taking into account any options. This seems to imply that all users share the same parser cache key, ignoring all options that may impact cached content. Is that correct/intended? If so, why all the trouble with ParserOutput::recordOption, etc? Background: We just tried to enable the use of the parser cache for wikidata, and it failed, resulting in page content being shown in random languages. I tried to split the parser cache by user language using ParserOutput:.recordOption to include userlang in the cache key. When tested locally, and also on our test system, that seemed to work fine (which seems strange now, looking at the code of getOptionsKey()). On the life site however, it failed. Judging by its name, getOptionsKey should generate a key that includes all options relevant to caching page content in the parser cache. But it seems it forces the same parser cache entry for all users. Is this intended? Possible fix: ParserCache::getOptionsKey could delegate to ContentHandler::getOptionsKey, which could then be used to override the default behavior. Would that be a sensible approach? And if so, would it be feasible to push out such a change before the holidays? Thanks, Daniel -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Help needed with ParserCache::getKey() and ParserCache::getOptionsKey()
On Tue, Dec 10, 2013 at 4:22 PM, Daniel Kinzler dan...@brightbyte.de wrote: what is the intention behind the current implementation of ParserCache::getOptionsKey()? It's based on the page ID only, not taking into account any options. Looking at the code, ParserCache::getOptionsKey() is used to get the memc key which has a list of parser option names actually used when parsing the page. So for example, if a page uses only math and thumbsize while being parsed, the value would be array( 'math', 'thumbsize' ). Then ParserOptions::optionsHash is used to construct a key corresponding to the actual ParserOptions object, for storing the actual parser output for that page+ParserOptions combination. In the example above, it would only use the 'math' and 'thumbsize' options to vary the key; users having the same 'math' and 'thumbsize' would get the same cached parser output even if they have different options for stubthreshold, dateformat, numberheadings, userlang, editsection, an so on. This reduces cache fragmentation. I doubt that the ContentHandler is really going to need to override getOptionsKey; the ParserOptions options used to parse the page really shouldn't vary depending on user language or other stuff like that. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikidata-tech] Help needed with ParserCache::getKey() and ParserCache::getOptionsKey()
Hi, I'm almost asleep, so this might be terrible wrong, but who knows: This is all based on the presumption that $this-mMemc-get( $this-getOptionsKey( $article ) ); (in ParserCache) returned false on Wikidata because the cache has been disable before or whatever. Then the problem is as follows: One calls ParserCache::get() with $useOutdated=false (default value). ParserCache::get calls out to ParserCache::getKey (with $useOutdated still false). That one then does: $this-mMemc-get( $this-getOptionsKey( $article ) ). If that returns false and $useOutdated is false also: $usedOptions = ParserOptions::legacyOptions(); (line 152) will be called which then nukes all our ParserOptions. Cheers, Marius On Tue, 2013-12-10 at 21:45 +0100, Daniel Kinzler wrote: Hi. I (rather urgently) need some input from someone who understands how parser caching works. (Rob: please forward as appropriate). tl;dr: what is the intention behind the current implementation of ParserCache::getOptionsKey()? It's based on the page ID only, not taking into account any options. This seems to imply that all users share the same parser cache key, ignoring all options that may impact cached content. Is that correct/intended? If so, why all the trouble with ParserOutput::recordOption, etc? Background: We just tried to enable the use of the parser cache for wikidata, and it failed, resulting in page content being shown in random languages. I tried to split the parser cache by user language using ParserOutput:.recordOption to include userlang in the cache key. When tested locally, and also on our test system, that seemed to work fine (which seems strange now, looking at the code of getOptionsKey()). On the life site however, it failed. Judging by its name, getOptionsKey should generate a key that includes all options relevant to caching page content in the parser cache. But it seems it forces the same parser cache entry for all users. Is this intended? Possible fix: ParserCache::getOptionsKey could delegate to ContentHandler::getOptionsKey, which could then be used to override the default behavior. Would that be a sensible approach? And if so, would it be feasible to push out such a change before the holidays? Thanks, Daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki to Latex Converter
On Tue, Dec 10, 2013 at 3:06 PM, C. Scott Ananian canan...@wikimedia.org wrote: Could you take a look at the attached PDF, generated from https://ml.wikipedia.org/wiki/%E0%B4%AE%E0%B4%B2%E0%B4%AF%E0%B4%BE%E0%B4%B3%E0%B4%82 with our not-yet-deployed new software? Any Malayam-specific feedback you could provide would be very useful. It was brought to my attention that this mailing list strips attachments. I've uploaded the PDF to http://cscott.net/wmf/malayalam.pdf --scott -- (http://cscott.net) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Tech Talk: MediaWiki Upgrades and Extension Dependencies
Please join our next Tech Talk via video streaming: MediaWiki Upgrades and Extension Dependencies – Ideas for Improvement Friday, December 13, 2013, 19:00 UTC http://www.timeanddate.com/worldclock/fixedtime.html?iso=20131213T19p1=1440 Facilitators: Mark Hershberger and Markus Glaser. Watch https://www.mediawiki.org/wiki/Meetings/2013-12-13 or #wikimedia-dev IRC for URL details. Upgrading MediaWiki is easy, upgrading a MediaWiki site using extensions is not. Versioning extensions and aligning them with MediaWiki versions is not done consistently. And how would you know which extension version works for your slightly older MediaWiki, e.g. because you are using a LTS version? The talk explores the various possiblities of remedy for this issue. It'll cover: * the current situation * the question of how we version extensions * the question of how we manage dependencies * an idea of using our users' power to know what's working * of course, a discussion Technically, we'll touch issues of LTS versions, git tagging and branching, Composer support, WikiApiary, usage statistics and crowd certification. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] OAuth Devlopment Training
Hi all, For any developers who have been thinking about connecting their application to MediaWiki, but haven't gotten around to diving in, I'm going to have a short training/workshop session next week. I'll give a brief intro to using the version of OAuth that we're running, and walk through some quick demos in php and go. After that, I'm happy to walk any developer through getting their app connected, if anyone is struggling with a particular issue. It will be Wed, Dec 18th at 11am PST (1900 UTC). Please let me know if you're interested. We'll probably use a hangout for the session, but if that's not an option for anyone we can use a voice call and etherpad. Either way I'll probably send out invites individually. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Help needed with ParserCache::getKey() and ParserCache::getOptionsKey()
On 11/12/13 08:22, Daniel Kinzler wrote: what is the intention behind the current implementation of ParserCache::getOptionsKey()? It's based on the page ID only, not taking into account any options. This seems to imply that all users share the same parser cache key, ignoring all options that may impact cached content. Is that correct/intended? No, the set of options which fragment the cache is the same for all users. So if the user language is included in that set of options, then users with different languages will get different parser cache objects. That is to say, the options key stores the list of options which vary the cache. ParserOptions::optionsHash() uses this list to form a parser output key (as in ParserCache:getParserOutputKey()) which is specific to the actual options requested. If the parser output varies by language for some users, and not others, then you may possibly have a problem, but it doesn't sound like that is what you are doing. We just tried to enable the use of the parser cache for wikidata, and it failed, resulting in page content being shown in random languages. That's probably because you incorrectly used $wgLang or RequestContext::getLanguage(). The user language for the parser is the one you get from ParserOptions::getUserLangObj(). During page save, a default ParserOptions is used, with the default user language, for the purposes of link table construction. The ParserOutput thus generated will be saved into the ParserCache. So it's not correct to use the context user language during parse, this will cause pollution of the parser cache. I tried to split the parser cache by user language using ParserOutput:.recordOption to include userlang in the cache key. When tested locally, and also on our test system, that seemed to work fine (which seems strange now, looking at the code of getOptionsKey()). It's not necessary to call ParserOutput::recordOption(). ParserOptions::getUserLangObj() will call it for you (via onAccessCallback). ParserCache::getOptionsKey could delegate to ContentHandler::getOptionsKey, which could then be used to override the default behavior. Would that be a sensible approach? No. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] OAuth Devlopment Training
I'm bummed that I won't be able to join in since this overlaps substantially with the Analytics Research Data showcase that starts @ 11:30 AM PST. Would you be interested in recording the presentation for those of us who cannot attend? -Aaron On Tue, Dec 10, 2013 at 6:47 PM, Chris Steipp cste...@wikimedia.org wrote: Hi all, For any developers who have been thinking about connecting their application to MediaWiki, but haven't gotten around to diving in, I'm going to have a short training/workshop session next week. I'll give a brief intro to using the version of OAuth that we're running, and walk through some quick demos in php and go. After that, I'm happy to walk any developer through getting their app connected, if anyone is struggling with a particular issue. It will be Wed, Dec 18th at 11am PST (1900 UTC). Please let me know if you're interested. We'll probably use a hangout for the session, but if that's not an option for anyone we can use a voice call and etherpad. Either way I'll probably send out invites individually. ___ 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
