Re: [Wikitech-l] RFC meeting this week
Summary and meeting logs of these RfC s discussed last week: RfC: Extension management with Composer https://phabricator.wikimedia.org/T467#7 RfC: CentralNotice backend improvements https://phabricator.wikimedia.org/T468#7 PS: Phabricator registration is still disabled, but if you want todiscuss or work on Architecture tasks, you can request an exception -- see https://phabricator.wikimedia.org/tag/architecture/board/ and https://www.mediawiki.org/wiki/Phabricator#Access_to_phabricator.wikimedia.org On Mon, Sep 29, 2014 at 3:30 AM, Tim Starling tstarl...@wikimedia.org wrote: The next RFC meeting will discuss the following RFC: * API roadmap (Brad Jorsch, Yuri Astrakhan) https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap The API roadmap was last discussed at the Architecture Summit in January. The meeting will be on the IRC channel #wikimedia-office on irc.freenode.org at the following time: * UTC: Wednesday 21:00 * US PDT: Wednesday 14:00 * Europe CEST: Wednesday 23:00 * Australia AEST: Thursday 07:00 -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Quim Gil Engineering Community Manager @ 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] State of the DumpHTML extension
The DumpHTML extension looks like it's in a pretty bad state, it doesn't work at all in the current version of MediaWiki. This seems to be an unfortunate symptom of how it's used and how it's treated by core developers. DumpHTML is most useful when someone is shutting down and archiving their wiki, so it doesn't get tested regularly. The act of creating a version of wiki pages suitable for offline use from static files is something which inherently requires different behaviour from things deep within core. Because DumpHTML has been segregated into an extension and core doesn't support an offline/dump mode internally DumpHTML has to use a bunch of hacks to make core behave properly during the dump. Then, because they are completely unaware of DumpHTML's needs, core developers make improvements to core that then break DumpHTML without providing it an alternative interface to get what it needs out of core. For one DumpHTML needs to proxy and mess with file repo behaviours. To do that it messed with properties like thumbScriptUrl, but then those properties were protected leaving DumpHTML unsupported. This was reported as a bug a month ago, which has gone relatively unnoticed: https://bugzilla.wikimedia.org/show_bug.cgi?id=69824 It also subclassed RepoGroup and since it proxied existing repo instances instead of working with repo info it had to bypass the __constructor. But then a $repoGroup-cache was added to the __constructor in core, breaking DumpHTML in another way. There are probably more issues that I haven't found yet while trying to workaround the other issues. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] IRC bots for phab
On Mon, Sep 29, 2014 at 12:13 AM, K. Peachey p858sn...@gmail.com wrote: I have no idea where that is coming from, specifically since there was no mention of creating accounts and the Login page clearly mentions using LDAP credentials to log in. Petan attended part of the phab meeting last Wednesday and raised the same issue at that point. I gave him a link to https://phabricator.wikimedia.org/T457 at that time and other issues blocking wider login were discussed. I had the impression that he was deliberately raising the issue again even though he already raised exactly that error message during the meeting. (and without linking to relevant phab tasks or giving any indication that he knew that what he was reporting was already a known issue. or that part of the issue was that registration was intentionally limited) Maybe I was wrong. But I didn't just imagine the earlier context. Some things about the current phab deployment could be better (e.g. instead of just having a warning about the limited user registration on https://phabricator.wikimedia.org/ , also have some warning at https://phabricator.wikimedia.org/auth/start/ ). Perhaps you need to be a bit more civil and less bitey, perhaps! After all you did link to the relevant discussion about it on Phab, it's not hard to expect people to want to log-in and be involved... Sure, I expect people to want to be able to join discussions like that where they are already happening. (vs. e.g. starting a thread about a phab task because you can't comment directly). In the future I'll try to remember to give the same link that Andre did on this thread. -Jeremy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Security and Maintenance Releases: 1.19.19, 1.22.11 and 1.23.4
Adding the space to includes/XmlTypeCheck.php before applying the patch worked. Thank you! On 26 September 2014 19:23, Grunny mwgru...@gmail.com wrote: It's because there's a leading space before the tab in front of the comment here: https://git.wikimedia.org/blob/mediawiki%2Fcore.git/REL1_19/includes%2FXmlTypeCheck.php#L22 That leading space exists in the patch for 1.19.19, so applies fine when you're applying it to a fresh copy of the 1.19.18 branch. But, as it was introduced in the 1.19.10 release ( https://git.wikimedia.org/commitdiff/mediawiki%2Fcore.git/926b9e6) and the patch for the 1.19.10 release didn't include the space, if you used the patches for all releases since, it won't be there and the new 1.19.19 patch will fail to apply the first changes to that file without fixing that space first. Cheers, grunny ___ 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] MediaWiki Language Extension Bundle 2014.09 release
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2014.09. This bundle is compatible with MediaWiki 1.23.x and
MediaWiki 1.22.x releases.
* Download:
https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2014.09.tar.bz2
* sha256sum: 9cfdc7d4fc87b4cd6f8d1d2e1593b8cd064b7a9a2773c1a6a554304949a609ec
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://bugzilla.wikimedia.org
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Babel and CleanChanges ==
* Only localisation updates.
== CLDR ==
=== Noteworthy changes ===
* Update to CLDR 26 (Upstream: http://cldr.unicode.org/index/downloads/cldr-26)
Changes
* Removed entries from LocalNamesEn.php when identical to CLDR. Right
now, 13 local names are differing from CLDR's, as well as the other
languages, are left to follow-ups.
== LocalisationUpdate ==
=== Noteworthy changes ===
* Bug 68781: New hook LocalisationCacheRecacheFallback in MediaWiki
1.24 and above allows to not use the wrong message when a language
itself doesn't have a change but one of its fallbacks does.
== Translate ==
=== Noteworthy changes ===
* Regression fixed: Translate's compatibility with MediaWiki 1.22 has
been restored.
* Regression fixed: Fix translation ratios in translatable page
language selector.
* Special:MyLanguage is now in core. For backwards compatibility,
translations of Special:MyLanguage aliases were moved to a separate
file (Bug 69461).
* Bug 67778: Added UserMerge support.
* $wgTranslatePageTranslationULS now works as intended on all
translation pages by removing the language code from the page name.
== UniversalLanguageSelector ==
=== Noteworthy changes ===
* Update ULS data with latest supplementalData.xml from CLDR.
--
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Damon Sicore joins WMF as Vice President of Engineering
Dear all, We are excited to announce that the Wikimedia Foundation now has a Vice President of Engineering. Damon Sicore will be filling this vital role. Please join us in welcoming him to the team. The VPE role will be crucial to further developing and maintaining the technology that supports the very core of the Wikimedia movement, and ensuring the development, scale, and stability of the MediaWiki architecture. Damon joins us as part of planned growth of our product and engineering teams, first announced in November 2012. As we have grown, we need dedicated focus on product and engineering as separate departments, to ensure development of best practices like performance engineering, continuous delivery, A/B testing, software re-architecture, UI/UX work, and user research. Erik Moeller, who filled the role of VP for both product and engineering since 2011, led in the creation of this new role and was essential to the search process. From today onward, Erik will focus on his role as VP of Product and Strategy and Deputy Director of the WMF, while Damon will take over leadership of the Engineering team; both will report to me as part of the c-level team. Damon has a unique track record of managing large platform rollouts using distributed teams like ours, while understanding the essential role of community contributions and working in a transparent, open source environment. These skills and experiences will be invaluable in his work here at the Foundation. It’s unusual to find someone who understands us so well, and so I want to thank the many people from across the organization, especially in the engineering, product, and human resources teams, who have been involved in making this search successful. We are very happy to have Damon on board. His proven track record of managing large platform rollouts using distributed teams like ours, while understanding the essential role of community contributions and working in a transparent, open source environment, is unique and invaluable as part of our movement. We’ll be sending around a copy of the press release shortly. You’ll also be be able to meet Damon, and ask him questions, this Thursday at our monthly Metrics Meeting https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings. Please join us there! Please join me in welcoming Damon. Lila ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removal of Scribunto's Allow saving code with errors option
On 28 September 2014 20:17, Jackmcbarn jackmcb...@gmail.com wrote: Scribunto has an option to allow code to be saved even if it contains syntax errors that prevent it from ever working. The original reason for this feature was to make it more convenient to save incomplete code. However, in practice, this has never been used for its intended purpose, and users who don't know any Lua are breaking otherwise-functional modules with it. Because of this, and because it's easy enough to save incomplete code by simply wrapping it all in a multiline comment, I plan to remove the option unless objections are raised. This seems totally reasonable; we already do this with JSON, and I believe it's also planned for JS and CSS content types as well. Go for it. J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removal of Scribunto's Allow saving code with errors option
Just for info the gerrit change: https://gerrit.wikimedia.org/r/#/c/160367/ Freundliche Grüße / Kind regards Florian -Ursprüngliche Nachricht- Von: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von James Forrester Gesendet: Montag, 29. September 2014 19:38 An: Wikimedia developers Betreff: Re: [Wikitech-l] Removal of Scribunto's Allow saving code with errors option On 28 September 2014 20:17, Jackmcbarn jackmcb...@gmail.com wrote: Scribunto has an option to allow code to be saved even if it contains syntax errors that prevent it from ever working. The original reason for this feature was to make it more convenient to save incomplete code. However, in practice, this has never been used for its intended purpose, and users who don't know any Lua are breaking otherwise-functional modules with it. Because of this, and because it's easy enough to save incomplete code by simply wrapping it all in a multiline comment, I plan to remove the option unless objections are raised. This seems totally reasonable; we already do this with JSON, and I believe it's also planned for JS and CSS content types as well. Go for it. J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ 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] [Wikimedia-l] Damon Sicore joins WMF as Vice President of Engineering
On 29 September 2014 13:38, Lila Tretikov l...@wikimedia.org wrote: We are excited to announce that the Wikimedia Foundation now has a Vice President of Engineering. Damon Sicore will be filling this vital role. Please join us in welcoming him to the team. Welcome, Damon. Looking forward to working with you. J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bug day: Book tool/Collection/PDF, 2014-10-08, 14–22 UTC
Hello, Please join us on the next Wikimedia bug day: **2014-10-08, 14:00–22:00 UTC** [1] in #wikimedia-tech on Freenode IRC.[2] We will be triaging bug reports for the Collection extension (Book tool) in general and PDF export in particular, which were just switched to a new backend (OCG).[3] We have two immediate goals: 1) recover 100 % of the relevant reports from the defunct PediaPress tracker;[4] 2) get a clean list of known PDF issues that the new backend didn't fix. Everyone is welcome to join any time these weeks, and no technical knowledge is needed! It's an easy way to get involved or to give something back. We encourage you to record your activity on the etherpad [4]. This information and more can be found here: https://www.mediawiki.org/wiki/Bug_management/Triage/201410 For more information on triaging in general, check out https://www.mediawiki.org/wiki/Bug_management/Triage I look forward to seeing you there. Please distribute further by email, talk pages etc. (Collection is used on almost 2 thousands wikis!) Sorry for the crossposting, Nemo [1] Timezone converter: http://everytimezone.com/#2014-10-08,120,5x1 [2] See http://meta.wikimedia.org/wiki/IRC for more info on IRC chat [3] http://lists.wikimedia.org/pipermail/wikitech-l/2014-July/077867.html [4] https://etherpad.wikimedia.org/BugTriage-Collection ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removal of Scribunto's Allow saving code with errors option
So how much broken Lua is out there in the wild on WMF wikis? On 29 September 2014 01:17, Jackmcbarn jackmcb...@gmail.com wrote: Scribunto has an option to allow code to be saved even if it contains syntax errors that prevent it from ever working. The original reason for this feature was to make it more convenient to save incomplete code. However, in practice, this has never been used for its intended purpose, and users who don't know any Lua are breaking otherwise-functional modules with it. Because of this, and because it's easy enough to save incomplete code by simply wrapping it all in a multiline comment, I plan to remove the option unless objections are raised. Jackmcbarn ___ 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] Individual Engagement Grant funding available
En español: A todos, Este es un recordatorio de que solicitudes serán aceptados hasta el 30 de septiembre. In English: All, This is a reminder that applications will be accepted until September 30. Other announcement translations may be found by clicking the links below: বাংলা https://meta.wikimedia.org/wiki/Grants:IEG/IEG_Round_Two_-_2014/bn • Deutsch https://meta.wikimedia.org/wiki/Grants:IEG/IEG_Round_Two_-_2014/de • italiano https://meta.wikimedia.org/wiki/Grants:IEG/IEG_Round_Two_-_2014/it • 日本語 https://meta.wikimedia.org/wiki/Grants:IEG/IEG_Round_Two_-_2014/ja • русский https://meta.wikimedia.org/wiki/Grants:IEG/IEG_Round_Two_-_2014/ru Pine On Tue, Sep 2, 2014 at 12:16 PM, Pine W wiki.p...@gmail.com wrote: Forwarding from Siko Bouterse: Greetings! The Wikimedia Foundation Individual Engagement Grants program is accepting proposals for funding new experiments from September 1st to 30th. https://meta.wikimedia.org/wiki/Grants:IEG Your idea can improve Wikimedia projects by building a new tool or gadget, organizing a better process on your wiki, conducting research on an important issue, or providing other support for community-building. Whether you need $200 or $30,000 USD, Individual Engagement Grants can cover your own project development time in addition to funding for a team to help you. The program has a flexible schedule and reporting structure, and Grantmaking staff are there to support you through all stages of the process. Do you have have a good idea, but you are worried that it isn’t developed enough for a grant? Put it into the IdeaLab, where volunteers and staff can give you advice and guidance on how to bring it to life. https://meta.wikimedia.org/wiki/Grants:IdeaLab Also, IEG will be hosting three Hangout Sessions for real-time discussions to help you make your proposal better - the first will happen on September 16th. https://meta.wikimedia.org/wiki/Grants:IdeaLab/Events#Upcoming_events For inspiration, you can read more about past projects https://blog.wikimedia.org/tag/individual-engagement-grants/ that received funding or review open proposals https://meta.wikimedia.org/wiki/Grants:IEG#ieg-reviewing. We are excited to see some of the new ways your grant ideas can support our community and make an impact on the future of Wikimedia projects. Submit your proposal in September! https://meta.wikimedia.org/wiki/Grants:IEG#ieg-apply ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Damon Sicore joins WMF as Vice President of Engineering
Good news! Damon, a warm welcome to Wikimedia and to these lists. Sam On Mon, Sep 29, 2014 at 1:38 PM, Lila Tretikov l...@wikimedia.org wrote: Dear all, We are excited to announce that the Wikimedia Foundation now has a Vice President of Engineering. Damon Sicore will be filling this vital role. Please join us in welcoming him to the team. The VPE role will be crucial to further developing and maintaining the technology that supports the very core of the Wikimedia movement, and ensuring the development, scale, and stability of the MediaWiki architecture. Damon joins us as part of planned growth of our product and engineering teams, first announced in November 2012. As we have grown, we need dedicated focus on product and engineering as separate departments, to ensure development of best practices like performance engineering, continuous delivery, A/B testing, software re-architecture, UI/UX work, and user research. Erik Moeller, who filled the role of VP for both product and engineering since 2011, led in the creation of this new role and was essential to the search process. From today onward, Erik will focus on his role as VP of Product and Strategy and Deputy Director of the WMF, while Damon will take over leadership of the Engineering team; both will report to me as part of the c-level team. Damon has a unique track record of managing large platform rollouts using distributed teams like ours, while understanding the essential role of community contributions and working in a transparent, open source environment. These skills and experiences will be invaluable in his work here at the Foundation. It’s unusual to find someone who understands us so well, and so I want to thank the many people from across the organization, especially in the engineering, product, and human resources teams, who have been involved in making this search successful. We are very happy to have Damon on board. His proven track record of managing large platform rollouts using distributed teams like ours, while understanding the essential role of community contributions and working in a transparent, open source environment, is unique and invaluable as part of our movement. We’ll be sending around a copy of the press release shortly. You’ll also be be able to meet Damon, and ask him questions, this Thursday at our monthly Metrics Meeting https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings. Please join us there! Please join me in welcoming Damon. Lila ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe -- Samuel Klein @metasj w:user:sj +1 617 529 4266 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Outreach Program for Women/Round 9
Hello, My name is Roxana and I am an engineering student at the Polytechnic University of Bucharest, Romania. I would like to be part of MediaWiki open-source community and participate in the Outreach Program for Women round 9. The project that interests me is Wikipedia article translation metrics https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_9#Wikipedia_article_translation_metrics But before diving into the code and do the suggested micro-task, I first wanted to fix some annoying little bugs, starting with bug #25163 https://bugzilla.wikimedia.org/show_bug.cgi?id=25163. So far everything is working fine in my local development environment, but I am still trying to familiarize myself with the code review / patching part. So, to wrap things up, my question is if I am heading towards the right direction, and if not, what advice do you have. Thank you, Roxana. https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_9#Wikipedia_article_translation_metrics ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: Outreach Program for Women/Round 9
Hi Roxana, I am forwarding your email to Quim, who helps to organizw our OPW program. Pine -- Forwarded message -- From: Roxana Necula necula.roxan...@gmail.com Date: Mon, Sep 29, 2014 at 2:39 PM Subject: [Wikitech-l] Outreach Program for Women/Round 9 To: wikitech-l@lists.wikimedia.org Hello, My name is Roxana and I am an engineering student at the Polytechnic University of Bucharest, Romania. I would like to be part of MediaWiki open-source community and participate in the Outreach Program for Women round 9. The project that interests me is Wikipedia article translation metrics https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_9#Wikipedia_article_translation_metrics But before diving into the code and do the suggested micro-task, I first wanted to fix some annoying little bugs, starting with bug #25163 https://bugzilla.wikimedia.org/show_bug.cgi?id=25163. So far everything is working fine in my local development environment, but I am still trying to familiarize myself with the code review / patching part. So, to wrap things up, my question is if I am heading towards the right direction, and if not, what advice do you have. Thank you, Roxana. https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_9#Wikipedia_article_translation_metrics ___ 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] Outreach Program for Women/Round 9
On 9/29/14, Roxana Necula necula.roxan...@gmail.com wrote: Hello, My name is Roxana and I am an engineering student at the Polytechnic University of Bucharest, Romania. I would like to be part of MediaWiki open-source community and participate in the Outreach Program for Women round 9. The project that interests me is Wikipedia article translation metrics https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_9#Wikipedia_article_translation_metrics But before diving into the code and do the suggested micro-task, I first wanted to fix some annoying little bugs, starting with bug #25163 https://bugzilla.wikimedia.org/show_bug.cgi?id=25163. So far everything is working fine in my local development environment, but I am still trying to familiarize myself with the code review / patching part. So, to wrap things up, my question is if I am heading towards the right direction, and if not, what advice do you have. Thank you, Roxana. https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_9#Wikipedia_article_translation_metrics ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Hi Roxana, thanks for your interest. It does sound like you're heading in the right direction. Being able to fix a small bug (any bug), is one of the most important steps for GSOC/OPW potentials, as it demonstrates your interest in MediaWiki. Submitting to code review (and gerrit in general) can be a little confusing at first. Don't worry too much if you're not 100% sure if you're submitting something correctly, everything is undo-able, so if you accidentally submit something incorrectly, its very easy to fix. The general process for submitting something (via git) is: git checkout master git pull git checkout -b topicOfPatch edit various files here git commit -a git show # This just shows what your patch looks like so you can check it git review There's pages on mediawiki.org that explain this in much more detail. If you run into any trouble (Or if you just want to talk to MediaWiki people) you can always get help with submitting patches in #mediawiki or #wikimedia-dev irc channels on irc.freenode.net. I strongly encourage you to try out irc, as it can really help to have real time communication when learning things. I also would encourage you to discuss the project you want to do with the people offering to mentor it (For the one you linked to, that would be Amir, who uses the nickname aharoni on irc) --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removal of Scribunto's Allow saving code with errors option
Very little. Currently, enwiki has one broken module [ https://en.wikipedia.org/wiki/Category:Scribunto_modules_with_errors] and dewiki has none [ https://de.wikipedia.org/wiki/Kategorie:Wikipedia:Modul_mit_Syntaxfehler]. On Mon, Sep 29, 2014 at 2:16 PM, David Gerard dger...@gmail.com wrote: So how much broken Lua is out there in the wild on WMF wikis? On 29 September 2014 01:17, Jackmcbarn jackmcb...@gmail.com wrote: Scribunto has an option to allow code to be saved even if it contains syntax errors that prevent it from ever working. The original reason for this feature was to make it more convenient to save incomplete code. However, in practice, this has never been used for its intended purpose, and users who don't know any Lua are breaking otherwise-functional modules with it. Because of this, and because it's easy enough to save incomplete code by simply wrapping it all in a multiline comment, I plan to remove the option unless objections are raised. Jackmcbarn ___ 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] Removal of Scribunto's Allow saving code with errors option
Jackmcbarn wrote: Scribunto has an option to allow code to be saved even if it contains syntax errors that prevent it from ever working. The original reason for this feature was to make it more convenient to save incomplete code. However, in practice, this has never been used for its intended purpose, and users who don't know any Lua are breaking otherwise-functional modules with it. Because of this, and because it's easy enough to save incomplete code by simply wrapping it all in a multiline comment, I plan to remove the option unless objections are raised. As long as false positives are low, this is probably fine. It'd be nice to get rid of the checkbox as it's user interface clutter. That said, a hard block is still pretty potent... I wonder whether simply warning the user and auto-categorizing the pages as likely broken on page save would be adequate. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removal of Scribunto's Allow saving code with errors option
There are no false positives at all, since it tests it by actually loading it into Lua. I think a total disallow is warranted because letting the page be saved with such an error means that the entire module is 100% useless (and will break every page that uses it) until someone fixes it. Jackmcbarn On Mon, Sep 29, 2014 at 9:53 PM, MZMcBride z...@mzmcbride.com wrote: Jackmcbarn wrote: Scribunto has an option to allow code to be saved even if it contains syntax errors that prevent it from ever working. The original reason for this feature was to make it more convenient to save incomplete code. However, in practice, this has never been used for its intended purpose, and users who don't know any Lua are breaking otherwise-functional modules with it. Because of this, and because it's easy enough to save incomplete code by simply wrapping it all in a multiline comment, I plan to remove the option unless objections are raised. As long as false positives are low, this is probably fine. It'd be nice to get rid of the checkbox as it's user interface clutter. That said, a hard block is still pretty potent... I wonder whether simply warning the user and auto-categorizing the pages as likely broken on page save would be adequate. 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] Removal of Scribunto's Allow saving code with errors option
Jackmcbarn wrote:
There are no false positives at all, since it tests it by actually loading
it into Lua.
Does the checkbox currently only allow overriding the type of error that
would completely prevent execution of a module? I encounter a lot of code
linters and syntax highlighters that mess up or get confused. It's
difficult for me to understand what exactly with errors means here.
I don't know Lua well enough to use it as an example, but as James
mentioned CSS, using the example of .foo { -moz-colour: red;, to me
there's probably a distinction to be made between the invalid
-moz-colour property and the lack of a }. Though perhaps certain
clients wouldn't mind either, which brings us back to the meaning of error.
I think a total disallow is warranted because letting the page be saved
with such an error means that the entire module is 100% useless (and will
break every page that uses it) until someone fixes it.
This kind of assumes a bad scenario (breaking pages), which doesn't really
apply to making a new module or improving an existing module in a sandbox
page. For me, it doesn't seem very difficult to envision a scenario in
which not being able to save currently broken code would be annoying,
though it's quite possible my concern about this is simply overblown.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Removal of Scribunto's Allow saving code with errors option
+1 On Sep 29, 2014, at 19:38 , James Forrester jforres...@wikimedia.org wrote: On 28 September 2014 20:17, Jackmcbarn jackmcb...@gmail.com wrote: Scribunto has an option to allow code to be saved even if it contains syntax errors that prevent it from ever working. The original reason for this feature was to make it more convenient to save incomplete code. However, in practice, this has never been used for its intended purpose, and users who don't know any Lua are breaking otherwise-functional modules with it. Because of this, and because it's easy enough to save incomplete code by simply wrapping it all in a multiline comment, I plan to remove the option unless objections are raised. This seems totally reasonable; we already do this with JSON, and I believe it's also planned for JS and CSS content types as well. Go for it. J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ 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
