Wikitech-l July 2015

wikitech-l@lists.wikimedia.org

97 participants
74 discussions

How to make commits from mirrored Wikimedia repos show up on your GitHub profile
by Bartosz Dziewoński 27 Jun '24

27 Jun '24

I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here. tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.) (Is there a place on mw.org to put this tidbit on?) ------- Forwarded message ------- From: "Brian Levine" <support(a)github.com> (GitHub Staff) To: matma.rex(a)gmail.com Cc: Subject: Re: Commits in mirrored repositories not showing up on my profile Date: Tue, 09 Jul 2013 06:47:19 +0200 Hi Bartosz In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit. The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits. Cheers Brian -- Matma Rex

3 3

XML dumps
by Lars Aronsson 11 Jan '16

11 Jan '16

The XML database dumps are missing all through May, apparently because of a memory leak that is being worked on, as described here, https://phabricator.wikimedia.org/T98585 However, that information doesn't reach the person who wants to download a fresh dump and looks here, http://dumps.wikimedia.org/backup-index.html I think it should be possible to make a regular schedule for when these dumps should be produced, e.g. once each month or once every second month, and treat any delay as a bug. The process to produce them has been halted by errors many times in the past, and even when it runs as intended the interval is unpredictable. Now when there is a bug, all dumps are halted, i.e. much delayed. For a user of the dumps, this is extremely frustrating. With proper release management, it should be possible to run the old version of the process until the new version has been tested, first on some smaller wikis, and gradually on the larger ones. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

7 7

Re: [Wikitech-l] VisualEditor support for table copy-and-paste from Word
by Koerner, Chris L 23 Dec '15

23 Dec '15

This drag and drop from a CSV and other mentions of VE neatness would make a great blog post. I would love see a post about being productive in VisualEditor. Tips and tricks as it were. -Chris K. This electronic mail and any attached documents are intended solely for the named addressee(s) and contain confidential information. If you are not an addressee, or responsible for delivering this email to an addressee, you have received this email in error and are notified that reading, copying, or disclosing this email is prohibited. If you received this email in error, immediately reply to the sender and delete the message completely from your computer system.

2 1

2015-07-01 Scrum of Scrums notes
by Grace Gellerman 15 Nov '15

15 Nov '15

https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-07-01

13 18

MW support for Composer equivalent for JavaScript packages
by Daniel Werner 06 Nov '15

06 Nov '15

Hey, I just wanted to check in about the status of enabling JavaScript package management usage in MediaWiki. I am basically talking about an equivalent for JS to what we have with Composer for PHP. Real-world example: The "data-values/value-view" package[0] is defining "jquery.event.special.eachchange.js": ValueView/lib/jquery.event/jquery.event.special.eachchange.js Now, recently I needed the same functionality in one of my extensions, so I just copied it over. [1] I know that this is the worst way one could do this, but as far as I can see we don't have that much of a choice right now. Here are the alternative options I can see: Moving "jquery.event.special.eachchange.js" out of the "data-values/value-view" package into its own "WMDE/jquery-eachchange" package... 1. ... and using it in my extension via composer. + pro: two or more extensions or other packages requiring this package will still result in having only one MW-wide installation.. - con: requires MW specific code which is actually not related to the MW-independent package to feed the resource loader. - con: using Composer to manage pure JavaScript packages! Uuuh, ugly! 2. ... and having a build step in other packages using the package, pulling the "WMDE/jquery-eachchange" somewhere into the file structure of the packages/extensions using it. + pro: don't need to abuse composer, we can use "npm", "Bower" or any other arbitrary JS package manager here. - con: got to tell resource loader somehow... (didn't think so much about that yet) - con: if more than one extensions or other packages require this package we still end up with the same code twice or more often in one MW installation. 3. Combining 1 and 2: Start with 2, using a JS package manager. Then going to 1, creating a composer package and pulling the "WMDE/jquery-eachchange" package in via some build script. + pro: The two pros from 1 + 2 + pro: ^^ - con: still got to tell resource loader somehow... - con: Overhead; We now create two packages where the Composer one is just a bridge to the MW-world, still polluting packagist.org. Still kind of ugly and more effort for publishing a package and therefore potentially scaring programmers away from doing so since they've got better things to do than doing work that could be automated. I have not seen Approach 2 and 3 yet. Though I could imagine that the VisualEditor team has used something like that. Approach 1 is the way the "data-values/value-view" package itself is being handled. And that package should actually be a MW independent pure JS package but right now it contains MW specific code and uses composer for distribution! There is still another option but that had to be properly implemented: 4. Choose one native JS package manager for now and go with it (add support for others later perhaps). Integrate it properly with MW (resource loader to begin with), document how to use it and finally distribute JS code coming from the MW world but useful for other projects in a way where it can actually be used in a non-MW context. This has already been bugging me when working on Wikidata. Now I'd like to reuse some of the code I have written there without spending hours and hours with option 3 because there should be support for option 4 rather sooner or later. So I am wondering; Does anyone have any thoughts, any alternatives perhaps or is there any roadmap on anything like the option 4 that I have shown? Cheers, Daniel [0]: https://packagist.org/packages/data-values/value-view [1]: https://github.com/DanweDE/mediawiki-ext-UserBitcoinAddresses/blob/master/r…

7 9

New RFC: better JS minification
by Max Semenik 01 Nov '15

01 Nov '15

Hi, I'd like to present a new RFC for your consideration: https://www.mediawiki.org/wiki/Requests_for_comment/Minifier It is about how we can shave 10-15% off the size if JavaScript delivered to users. Your comments are highly welcome!:) -- Best regards, Max Semenik ([[User:MaxSem]])

9 12

Getting mediawiki core to pass codesniffer standard
by Vivek Ghaisas 26 Sep '15

26 Sep '15

Hello, wikitech-l, tl;dr trying to make mw-core pass mw-codesniffer, expect large patches on Gerrit, and please help A lot of work has been done on MediaWiki codesniffer <https://phabricator.wikimedia.org/tag/mediawiki-codesniffer/> (the PHP_CodeSniffer standard for MediaWiki) over the last few months and this might be a good time to get core to pass our coding conventions <https://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP>. Work on this has already started at T102609 <https://phabricator.wikimedia.org/T102609>. There were two primary reasons to send this email: 1. This is a pretty big task and any help would be very welcome! If we can get phpcs to run against core's master, it would make every patch contributors' work a little easier. 2. Work is being organized as subtasks of T102609, and has been divided on the basis of sniffs. Because of this, every patch is going to change a lot of unrelated files and a lot of reviewers are going to get added on Gerrit. Let's make this happen! Vivek Ghaisas (polybuildr)

5 4

RFC meeting this week
by Tim Starling 19 Sep '15

19 Sep '15

In the next RFC meeting, we will discuss the following RFC: * Improving extension management <https://www.mediawiki.org/wiki/Requests_for_comment/Improving_extension_man…> The meeting will be on the IRC channel #wikimedia-office on chat.freenode.net 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

5 6

I love Parsoid but it doesn't want me
by Ricordisamoa 18 Sep '15

18 Sep '15

Are there any stable APIs for an application to get a parse tree in machine-readable format, manipulate it and send the result back without touching HTML? I'm sorry if this question doesn't make any sense.

8 29

MediaWiki, as seen on TV
by Steven Walling 13 Sep '15

13 Sep '15

There's a pretty hilarious American police procedural TV show in 2015 called "CSI: Cyber", featuring mostly cybercrime. Obviously they have to dredge up snippets of code from places for screenshots on the show. Episode 4 happened to include a tidbit from MediaWiki 1.25/wmf3. Supposedly the code was a hack to make your printer blow up. Original lulz and screenshots via http://moviecode.tumblr.com/post/114815574587/this-is-from-csi-cyber-s01e04…

6 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l July 2015