Wikitech-l May 2016

wikitech-l@lists.wikimedia.org

113 participants
123 discussions

Database dumps
by Byrial Jensen 17 Apr '25

17 Apr '25

Until some weeks ago http://dumps.wikimedia.org/backup-index.html used to show 4 dumps in progress at the same time. That meant that new database dumps normally was available within about 3 weeks for all databases except for enwiki and maybe dewiki where the dump process due to size took longer time. However the 4 dumps processes at one time become 3 some weeks ago. And after massive failures at June 4, only one dump has been in progress at the same time. So at the current speed it will take several months to come thru all dumps. Is it possible to speed up the process again using several dump processes at the same time? Thank you, Byrial

3 2

User-Agent:
by Domas Mituzas 17 Apr '25

17 Apr '25

Hi! from now on specific per-bot/per-software/per-client User-Agent header is mandatory for contacting Wikimedia sites. Domas

19 61

EBNF grammar project status?
by Steve Bennett 01 Apr '25

01 Apr '25

What's the status of the project to create a grammar for Wikitext in EBNF? There are two pages: http://meta.wikimedia.org/wiki/Wikitext_Metasyntax http://www.mediawiki.org/wiki/Markup_spec Nothing seems to have happened since January this year. Also the comments on the latter page seem to indicate a lack of clear goal: is this just a fun project, is it to improve the existing parser, or is it to facilititate a new parser? It's obviously a lot of work, so it needs to be of clear benefit. Brion requested the grammar IIRC (and there's a comment to that effect at http://bugzilla.wikimedia.org/show_bug.cgi?id=7 ), so I'm wondering what became of it. Is there still a goal of replacing the parser? Or is there some alternative plan? Steve

26 217

Missing Section Headings
by Marc Riddell 13 Sep '24

13 Sep '24

Hello, I have been a WP editor since 2006. I hope you can help me. For some reason I no longer have Section Heading titles showing in the Articles. This is true of all Headings including the one that carries the Article subject's name. When there is a Table of Contents, it appears fine and, when I click on a particular Section, it goes to that Section, but all that is there is a straight line separating the Sections. There is also no button to edit a Section. If I edit the page and remove the "== ==" markers from the Section Titles, the Title then shows up, but not as a Section Heading. Also, I don't have any Date separators on my Want List. This started 2 days ago. Any thoughts? Thanks, Marc Riddell [[User:Michael David]]

10 11

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

bluejeans
by Jeremy Baron 22 Feb '23

22 Feb '23

Hi, On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote: > We will be holding this brownbag in 25 minutes. The Bluejeans link has > changed: > > https://bluejeans.com/396234560 I'm not familiar with bluejeans and maybe have missed a transition because I wasn't paying enough attention. is this some kind of experiment? have all meetings transitioned to this service? anyway, my immediate question at the moment is how do you join without sharing your microphone and camera? am I correct thinking that this is an entirely proprietary stack that's neither gratis nor libre and has no on-premise (not cloud) hosting option? are we paying for this? -Jeremy

9 16

productivity of mediawiki developers
by rupert THURNER 29 May '17

29 May '17

hi, is there a statistics about mediawiki developer productivity? i just fell over a couple of pages and i am quite impressed i must say: * gabriel, https://github.com/gwicke, 2'300 commits last year * jeroen, https://github.com/JeroenDeDauw, 3'700 commits a year * ori, https://github.com/atdt, 1'700 * james, https://github.com/jdforrester, 1'200 * yuri, https://github.com/nyurik, 900 * matt: https://github.com/mattflaschen, 400 commits rupert

11 14

Deploying the UrlShortener extension to Wikimedia wikis
by Legoktm 12 Nov '16

12 Nov '16

Hi, YuviPanda, prtksxna, and myself (with help from Tim and Aaron) have been working the UrlShortener extension, which is designed to implement the URL shortener RfC[1] (specifically Tim's implementation suggestion). I've filed T108557[2] to deploy the extension to Wikimedia wikis. We'd like to use the "w.wiki" short domain, which the WMF is already in control of. A test wiki has been set up mimicking what Wikimedia's configuration would be like: http://urlshortener.wmflabs.org/, and has an accompanying "short" domain at us.wmflabs.org (e.g. http://us.wmflabs.org/3). Please play with it and report any bugs you might find :) [1] https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener [2] https://phabricator.wikimedia.org/T108557 Thanks, -- Legoktm

3 5

Phab blogs
by Amir E. Aharoni 19 Sep '16

19 Sep '16

Hi, I only now noticed that Phabricator has blogs: https://phabricator.wikimedia.org/phame/blog/ I couldn't find a way to subscribe to them in RSS. Is it possible? -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

6 6

Crediting the work of our community members
by Jon Robson 06 Jul '16

06 Jul '16

"I came across a patch from a user who was keen to move himself from "Patch contributors" to "Developers" in the MediaWiki CREDITS file [1]. It had been sitting there for over a year. He doesn't seem to have been active since. I don't know what to do with it. It made me think. Do we have it documented anywhere how we use this credits file and why we feel the need to distinguish between Developers and Patch Contributors? It seems like a recipe for disaster in my opinion as it can only lead to hurt feelings due to contributors feeling unfairly treated. https://www.mediawiki.org/wiki/Special:Version/Credits leads with 'We would like to recognize the following persons for their contribution to MediaWiki." - if someone is not in that list are they not as important? If we keep these files we should probably explain the rules to what adding names looks like within these files and what the process to adding your name is (can I add myself? Is there a process like getting +2?) To take another extreme, we might consider abandoning such a file in favour of something automatically generated. Things like https://github.com/wikimedia/mediawiki/graphs/contributors do a far better job at allowing people to see who contributed to a tool and making people feel like their work is rewarded. On a slightly related note, can we abandon the practice of putting names inside files themselves? I see this practice in JavaScript and PHP files throughout core (grep for @author). As Team Geek [2] (great read btw) says "unlike other collaborative pieces of creative work... software keeps changing even after it's "done". So while listing contributors credits at the end of a movie is a safe and static thing, attempting to add and remove names from a source file is a never-ending exercise in insanity". For similar reasons this practice gives an impression of ownership of a file/code review responsibilities (which are not always true) and risks hurt feelings. [1] https://github.com/wikimedia/mediawiki/blob/master/CREDITS [2] http://www.amazon.com/gp/search?index=books&linkCode=qs&keywords=9781449302…

9 10

Recent authentication session instability (was Re: Update from the Wikimedia Performance Team)
by Bryan Davis 19 Jun '16

19 Jun '16

On Thu, Feb 4, 2016 at 8:20 AM, MZMcBride <z(a)mzmcbride.com> wrote: > Federico Leva (Nemo) wrote: >>Login pretty much never does what I expect nowadays, but I'm not sure my >>expectations are correct so I can't identify actual bugs. > > There are various open tasks in Phabricator about user sessions currently, > such as <https://phabricator.wikimedia.org/T124440>. Being unexpectedly > logged out lately has been a bit annoying, though I don't know if it's > related to the Performance team or some other team. The origin of the unexpected logouts falls on the AuthManager project and specifically the SessionManager component that rolled out in 1.27.0-wmf.11 [0]. We had various issues related to the session handling changes including a bug that was overloading the storage capacity of the Redis servers that store session data [1] and two other issues which required rolling the wikis back to 1.27.0-wmf.10 [2][3]. Both rollbacks were accompanied by a run of the "resetGlobalUserTokens.php" maintenance script which updates each user's CentralAuth records in such a way that their authentication session will be considered invalid the next time it is used on a wiki. This was done from an abundance of caution point of view concerning possible issues with sessions that had been issued by the SessionManager software. The reset script is not fast [4], so session invalidation has slowly worked its way across the CentralAuth user table. Part of the enhancements that are being applied in order to bring SessionManager back to production with 1.27.0-wmf.13 is a new config setting that can be used to give us a nearly instant switch to throw to invalidate all active sessions. This setting is actually included in 1.27.0-wmf.12, but the configuration on the Wikimedia cluster has not been changed to make use of it yet. Invalidating all user sessions is not something we plan to do for fun certainly, but there have been in the past (and likely will be in the future) software and configuration issues that necessitate the use of that heavy hammer approach. [0]: https://phabricator.wikimedia.org/T123451 [1]: https://phabricator.wikimedia.org/T125267 [2]: https://wikitech.wikimedia.org/wiki/Incident_documentation/20160123-Session… [3]: https://tools.wmflabs.org/sal/log/AVKZtfQXW8txF7J0uNE2 [4]: https://phabricator.wikimedia.org/T124861 Bryan -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855

7 13

New mirror of 'other' datasets
by Ariel Glenn WMF 17 Jun '16

17 Jun '16

I'm happy to announce a new mirror for datasets other than the XML dumps. This mirror comes to us courtesy of the Center for Research Computing, University of Notre Dame, and covers everything "other" [1] which includes such goodies as Wikidata entity dumps, pageview counts, titles of all files on each wiki (daily), titles of all articles of each wiki (daily), and the so-called "adds-changes" dumps, among other things. You can access it at http://wikimedia.crc.nd.edu/other/ so please do! Ariel [1] https://dumps.wikimedia.org/other/

2 2

Should we switch the default category collation to uca-default?
by Ryan Kaldari 03 Jun '16

03 Jun '16

There are currently 94 WMF wikis using UCA category collation rather than the default "uppercase" collation. The Unicode Collation Algorithm (UCA) is the official standard for how to sort Unicode characters, and generally follows how a human would typically alphabetize strings. For example, uppercase collation sorts Aztec, Ärsenik, Zoo, Aardvark as "Aardvark, Aztec, Zoo, Ärsenik", but uca-default collation sorts them as "Aardvark, Ärsenik, Aztec, Zoo". UCA collation also (optionally) supports natural numeric sorting so that 100, 1, 99 sorts as "1, 99, 100" rather than "1, 100, 99". The WMF Community Tech team has recently posted proposals on English Wikipedia and several Wiktionaries asking if these communities would support switching to UCA collation. The proposal on English Wikipedia has received unanimous support so far.[1] We thought that Wiktionaries would be more skeptical of the change, but so far we have received only positive responses.[2] Since it seems that most wikis are receptive to switching to UCA, maybe we should just make it the default rather than waiting on all the wikis to request it separately. Of the large Wikipedias, French, Dutch, Polish, Portuguese, and Russian are already using UCA, and German is in the process of switching.[3] For non-Latin scripts, my understanding is that UCA will be a big improvement, especially if we switch them to language-specific implementations, like uca-ja, uca-zh, uca-ar, etc. Three questions: 1. Does switching the default collation from "uppercase" to "uca-default" sound like a good idea? 2. Should this be proposed on meta or is it too technical? 3. Are there any wikis that would need to opt out of this for some reason? (I know there are issues with Kurdish,[4] but that's the only one I know about.) 1. https://en.wikipedia.org/wiki/Wikipedia_talk:Categorization#OK_to_switch_En… 2. https://phabricator.wikimedia.org/T128502 3. https://phabricator.wikimedia.org/T128806 4. https://phabricator.wikimedia.org/T48235

8 9

Campaigns extension / ServerSideAccountCreation log - does anyone still use it?
by Brad Jorsch (Anomie) 02 Jun '16

02 Jun '16

Question 1: Would anyone care if we kill the "loginCTA" campaign, which tracks when people use the link at the bottom of Special:UserLogin to get to the account creation page? Question 2: Would anyone care if we remove the extension entirely from Wikimedia wikis? Wikiapiary seems to show only one user outside of Wikimedia. Background: The extension needs a rewrite for AuthManager, and in particular the "loginCTA" campaign will be a bit of a pain to keep working. If someone is making use of the extension that's fine, but if not we may as well not continue to spend development resources on it. -- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation

4 7

Community Wishlist Survey: Status report #2
by Johan Jönsson 01 Jun '16

01 Jun '16

Hi everyone, The important part of this email is this link: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Status_repor… This is the second Community Wishlist Survey status report. In November and December, active contributors to Wikimedia projects proposed, discussed and voted on the features and fixes that they most want to see. The Wikimedia Foundation Community Tech team has been tasked with working on these. Additionally, Wikimedia Deutschland's Technical Wishes team has been working on wishes from the German-speaking community. There's overlap between the two wishlists, and the teams are collaborating on various wishes, so this report includes progress made by both teams as well as great work being done by volunteer developers and other WMF staff. So far, we (in the broad sense) have added support for: *) Migrating dead external links to archives (but there's more work to be done!) *) Pageview stats *) Global notifications *) A category watchlist We're currently working on: *) Improving the plagiarism detection bot *) Improving the diff compare screen *) Numerical sorting in categories *) The possibility to add an expiry date to watchlist items *) A revision slider to help editors navigate through diff pages For more information on these projects as well as upcoming tasks, see the full status report on Meta: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Status_repor… We're looking forward to talking and working with you as we go along. Thanks, //Johan Jönsson User:Johan (WMF) --

3 2

2016-05-25 Scrum of Scrums meeting notes
by Grace Gellerman 01 Jun '16

01 Jun '16

https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-05-25 = 2016-05-25 = == Technology == === Analytics === - Trying to puppetize druid, harder than it looks - Working on scaling on pageview API and cassandra, doing perf testing on new nodes - Trying to add throttling to pageview API - Working on harvesting edit data from db/dumps into hadoop, WIP , main goal this quarter - Deployed visualization of Unique Devices: https://vital-signs.wmflabs.org/#projects=ptwiki/metrics=UniqueDevices - === Services === * RESTBase ** rate limiting in prod, log-only *** Analytics, we need to discuss pageview limits * Cassandra ** expanding from 2 to 3 instances per node in prod ** upgrade to 2.2.6 next * Change prop ** handling updates for summary and mobile-sections* endpoints ** will move purging to it soon * Math ** MathML by default on all wikibooks, early next week all projects * heads up: Services team on Wikimania, then off-site at the end of June === Release Engineering === * '''Blocking''': ??? * '''Blocked''': none * '''Updates''': ** wmf.3 is rolling forward this week ** rc.0 of 1.27 should be out this week === Technical Operations === * '''Blocking''': ** none * '''Blocked''': ** none * Updates: ** misc varnish cluster on route for being upgrade to varnish 4 again ** getting rid of tech debt on the database front (m1 cluster to be reimaged) ** helping releng with scap3 ** Getting finally a redundant link esams-eqiad ** libicu upgrade. See email from Giuseppe on wikitech-l === Security === * Two-factor authentication has been deployed to CentralAuth wikis with permission enabled for staff * Abbey and Daisy are assisting in usability surveying of two-factor * Darian and Chris are working on knowledge transfer prior to Chris' last day on Friday, May 27th * Darian is working on onboarding documentation in anticipation of Security Team hires in the near-ish future * Security review schedule remains on track ( https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Schedule ) and Brian Wolff will be assisting == Product == === Reading === ==== Web ==== * Getting ready for Hovercards A/B test (finialising bug fixes) ** Fundraising tech eng can have a look at JS variable for Popups enabled/disabled ==== Android ==== * released Beta with Reading Lists ==== iOS ==== ==== Mobile Content Service ==== * Working on feed endpoints ==== Reading Infrastructure === * AuthManager: please read email from Brad on wikitech-l * https://gerrit.wikimedia.org/r/#/c/290269 (testing gem) pending review as of 24-May-2016 === Community Tech === * No blockers * Numerical sorting in categories ** New indexes are in place thanks to JCrespo ( https://phabricator.wikimedia.org/T130692 ) ** Will be proposing on Wikitech-l that we switch to "uca-default" as the default page collation, rather than "uppercase" ( https://phabricator.wikimedia.org/T136113 ) * Launched MassViews interface for pageview stats ( http://tools.wmflabs.org/massviews/ ) * Working on new CopyPatrol tool for detecting plagiarism ( http://tools.wmflabs.org/plagiabot ) === Editing === ==== Parsing ==== (Subbu won't be there, updates only) * Work ongoing to migrate Parsoid to use service-runner after a bunch of fixes were pushed to service-runner - hoping to push this past the finish line by next week before attempting a migration of Parsoid cluster to jessie / node v4 (Follow along on https://phabricator.wikimedia.org/T135176 and blocking tasks). Conversation ongoing with services team to resolve details. * Tidy replacement work proceeding well. After last round of fixes and visual diff testing, ~88% of test pages render with pixel-perfect accuracy and ~97% pages with < 1% pixel diffs with HTML5depurate. Additional CSS fixes since then and new round of visual diff testing in progress. Tim working to make some fixes to doBlockLevels in core parser to iron out some kinks there which leads to different behavior in HTML5depurate compared to Tidy (similar effects in Parsoid). * Kunal's linker rewrite patch merged. Follow up work in progress to use the new linker code. * VE / CX: Please start thinking about how your code needs to change to use split data-mw format. The data-mw split code is probably 2-3 weeks away in terms of being ready for deployment, but you can start testing it with Parsoid master which can provide you the split data-mw (ping arlolra on IRC for details). ==== Language ==== * Blocked: ** Preference section "Internationalisation" balloons after clicking "More language settings" https://phabricator.wikimedia.org/T133114(Frontend/Style libs) ** Can't load In Progress or Published translation list https://phabricator.wikimedia.org/T135743 (For: Collobration/Roan) * Updates: ** Compact Language Links (as a non-beta feature) deployed in Beta/testwikis; work on it continue along with ULS === Fundraising tech === * (force) merged security patches to fr branch, deployed ** got tests passing again Monday * CentralNotice: api for a/b testing * More work to get off ActiveMQ, remove SPOF (just bit us again last week) * Prepping for fundraising in Israel, Japan and Ukraine ** Trying to mess with language fallbacks on payments cluster so we never show Russian messages to those whose preferred language is Ukrainian * Enhancing fraud & dos mitigation measures === Discovery === * '''Blocking''': none * '''Blocked''': none * Team offsite last week, got plans for next Q and year * Upgrade to ElasticSearch 2.3 is coming on Thursday ( https://phabricator.wikimedia.org/T133124) * Portal team added descriptive texts to project links on portal after A/B test showed (small) positive impact * Survey results for portal visitors: https://commons.wikimedia.org/wiki/File:Wikipedia_Portal_Survey_-_May_2016.… * Maps in Wikivoyage now support external layers: https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#Maps_with_extra… == Wikidata == * Blockers: none. * Deleting files on Commons that are used in Wikidata statements was not possible due to a bug. https://phabricator.wikimedia.org/T135485 * First prototype for structured data on Commons is close, finally. https://phabricator.wikimedia.org/T125822 * QUnit tests timed out on Jenkins more often this week. Anybody knows why? https://phabricator.wikimedia.org/T136303

2 2

RFC: Add Content-Security-Policy header to MediaWiki
by Brian Wolff 31 May '16

31 May '16

So the RFC process page says I should email wikitech-l to propose an RFC, thus: Content-Security-Policy (CSP) header is a header that disables certain javascript features that are commonly used to exploit XSS attacks, in order to mitigate the risks of XSS. I think we could massively benefit from using this technology - XSS attacks probably being the most common security issue in MediaWiki. The downside is that it would break compatibility with older user scripts. Please see the full text of my proposal at https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy The associated phabricator ticket is: https://phabricator.wikimedia.org/T135963 I'd appreciate any comments anyone might have. Thanks, Brian

4 5

The Revision Scoring weekly update
by Aaron Halfaker 31 May '16

31 May '16

Hi folks, This is the 6th weekly update for the revision scoring team that we have sent to this mailing list. *New developments:* - We set up a system for expiring labeling tasks after they have not been completed [3] - We set up the ORES service in the Beta cluster [8] *Maintenance and robustness:* - We brought ores-beta (in the beta cluster) back online [1] - We solved a problem with ORES being able to score multiple revisions in batch [2] - We addressed some database connection issues in Wiki labels [4] - We brought Wikilabels back online after some deployment issues [5] and wrote up a post-mortem [6] - We addressed some puppet issues with ORES' staging environment [7] 1. https://phabricator.wikimedia.org/T135677 2. https://phabricator.wikimedia.org/T136278 3. https://phabricator.wikimedia.org/T135400 4. https://phabricator.wikimedia.org/T136502 5. https://phabricator.wikimedia.org/T136520 6. https://phabricator.wikimedia.org/T136523 7. https://phabricator.wikimedia.org/T136488 8. https://phabricator.wikimedia.org/T130404 Stay tuned! -Aaron

1 0

Tech Talk: Integrating user behavior to design better products: May 31
by Rachel Farrand 31 May '16

31 May '16

Please join for the following tech talk: *Tech Talk**:* Integrating user behavior to design better products *Presenter:* Pau Giner *Date:* May 31, 2016 *Time: *19:00 UTC <http://www.timeanddate.com/worldclock/fixedtime.html?msg=Tech+Talk%3A+Integ…> *Length:* 30 minutes Link to live YouTube stream <http://www.youtube.com/watch?v=mLeTABdcdR4> *IRC channel for questions/discussion:* #wikimedia-office *Summary: *The design process helps us to find solutions that respond to the user needs. However, this process needs to rely on actual user behavior to make sure we are addressing the right problems with the best possible solutions. Wikimedia projects are developed in the open and they reach millions of users in very different contexts. This makes it challenging to integrate the different observed behaviors, measured actions, opinions and other forms of feedback. After applying the design process on different Wikimedia projects, I want to share some good practices and lessons learnt when integrating user behavior to inform product decisions, and how you (in whichever role you are playing) can help designers to better support this process. *Feel free to forward this email to any other relevant wikimedia lists.*

1 1

File handler options & InstantCommons (was Re: Update from the Perf Team)
by Brion Vibber 31 May '16

31 May '16

On Sun, May 29, 2016 at 11:22 AM, Gergo Tisza <gtisza(a)wikimedia.org> wrote: > On Sun, May 29, 2016 at 7:08 PM, Brion Vibber <bvibber(a)wikimedia.org> > wrote: > > We could change all that if there was a stable enough URL/linking > > API... Can probably fake it for common cases and supported handlers by > > generating a URL like we would for a local 404-handler repo; my main > > concern is for future expansion where we add more fancy types on Commons > > where the local site may not have an extension installed locally. > > > Not sure if trying to use an unhandled file type via InstantCommons makes > sense; the image parameters in the wikitext and the image parameters in the > URL (or imageinfo API or hypothetical linking API) don't necessarily use > the same syntax; what would transform that? (Granted, you get similar > problems when parameter transformation is handled by the local extension > and there is a version mismatch between the local and remote installation.) > Yep, it all comes back to T66214 <https://phabricator.wikimedia.org/T66214> doesn't it. :D > > (Iframe embedding as a fallback for unknown handlers sounds possible, > > could expose > > a frame URL in the imageinfo data.) > > > > In general that would be a nice idea (see T27854 > <https://phabricator.wikimedia.org/T27854>). Specifically for embedding > unknown file types in MediaWiki though, we would probably have to introduce > some standard key-value syntax for image parameters first, instead of the > current mess where it's parsed by an arbitrary set of regexes defined by > the media handlers and generated in a similarly flexible way. And then you > still have the problem of handling unknown media types in VisualEditor > which would need some kind of parameter metadata at least. > Indeed. iframe embedding of video might be a good place to start for unknown types; since we already have an iframe embedding system for video in TimedMediaHandler, it should be easy to adapt it as a provider so that sites can use videos from Commons without installing TimedMediaHandler locally. Key issues for options: * separate the layout parameters from the file rendering parameters (eg things like 'thumb' or 'frame' affect the layout, but the file handler/renderer only cares about the resulting size) * define standardish keys for file options already in use * if extra file options are needed, have a standard option for extended options! * define that extra options will not be localizable or have magical regexes; they should just be key-value pairs with fixed, predictable key names * define a standard way to pass file options to the iframe Existing file options: * 'width' and 'height' are implied through thumb/frame/upright/default size, or explicitly via /\d+px/ or /\d+x\d+px' etc regexes defined in core. * SvgHandler uses 'lang'; regex defined in core. * PdfHandler and PagedTiffHandler use 'page'; regex defined in core. * PagedTiffHandler uses 'lossy' switch to allow overriding the default thumbnail type (JPG vs PNG); regex defined in extension * TimedMediaHandler adds 'start', 'end', and 'thumbtime'; regex defined in extension There might be a couple more floating around out there, but that should cover those already in use in Wikimedia content. For compatibility we'd need to keep the core regexes, and might or might not want to move the 'lossy' and 'start/end/thumbtime' ones to core. I can imagine some extended attributes I'd like for video: * 'loop' * 'mute' * 'autoplay' (only allowed with 'loop' and 'mute', for GIF-like display) for zoomable panoramic images (flat or spherical): * 'zoom' - initial zoom level * 'center' - coordinates of initial centering (what coord system? separate x/y params or just one? should spherical use lat/lon? etc) for viewing a 3d model: * 'zoom' - just like panoramas * 'distance' - viewer distance from origin point; this is different from zoom! * 'center' - origin point/center of view, extended to 3 dimensions (for instance to concentrate on a portion of a larger model) Let's imagine a file type that uses everything! An animated 3d model that's localizable, and has multiple selectable "pages" of which we show one: [[File:Cool file type.mytype|  thumb |alt=A bouncing ball changes colors while a calendar in background counts off seasons in French.  |640x480px  |lang=fr |page=3  |start=25 |thumbtime=27.5 |end=35 |lossy=1  |zoom=1.5 |center-x=0.5 |center-y=0.667 |center-z=0.25 |distance=0.75 |loop=1 |muted=1 |autoplay=1  |Check out this an awesome [[3d model]] that's [[animation|animated]]! ]] There is some ambiguity with accepting any unknown key followed by '='... is [[File:Equation.mytype|E=mc^2]] using "E=mc^2" as a caption or passing a parameter "E" with value "mc^2"? We could add a 'caption=' magic option and use it explicitly: [[File:Equation.mytype|caption=E=mc^2]] Or just adding a stub <nowiki> ought to do it as a workaround, since it should break the regex check for the generic key followed by "=": [[File:Equation.mytype|<nowiki></nowiki>E=mc^2]] For the media dialog in VE there's a few things we can do... For locally-installed extensions, easy peasy! Extension registers the options it needs along with localized labels and whatever necessaries for validation/input. I'll have to take a look at how it works currently... For remote files... probably we'd want to have an API method for the remote site to expose a given file's option keys, localized labels, and some metadata about the fields (just like a local extension might supply, but without the ability to inject some JS or a custom widget). Another possibility is for the remote site to expose a layout option editor "preview" in its own iframe using a postMessage interface to bump data values in/out of the dialog. This might be good for, say, specifying the start/end/thumb times of a video, or the initial zoom/position of a panorama, by scrubbing/dragging/zooming on the actual media instead of manually typing in numbers. (Could use the exact same iframe interface for local handlers to avoid having multiple code paths, or could remove the intermediary frame for that case and have a common JS API for both methods.) Back to implementation of the viewer: basically we'd take the final file options in normalized key form (width & height and any other regex'd or extended keys) and pass them as query string parameters to an iframe. So when we look up info about the file itself, 'imageinfo' can return an 'iframe' key with, say, https://commons.wikimedia.org/wiki/File:Curiosity%27s_Seven_Minutes_of_Terr… we can take that iframe URL from the imageinfo and append our other options, so an invocation like: [[File:Curiosity's_Seven_Minutes_of_Terror.ogv| 640px|start=3:02|end=3:52|thumbtime=3:14]] would yield something like <iframe src="...?embedplayer=yes&width=640&height=360&start=3:02&end=3:52&thumbtime=3:14" width="640" height="360" frameborder="0" allowFullScreen ></iframe> Now this also brings up questions like did you want to play the video inline vs show a thumbnail that brings up the video in a popup, which may be something where we have to work out in general as well... this would allow using a *standard* popup on the wiki side (say, MultimediaViewer?) to load a remote media item. If using an iframe to embed something with "plain" thumbnail behavior where click means "link" or "zoom", we have to work out issues like passing click events from the iframe to the parent (or else do some clickjacking ;) -- brion

1 0

Participate in the Inspire Campaign on Addressing Harassment
by Chris "Jethro" Schilling 31 May '16

31 May '16

I am pleased to announce the launch of the third Inspire Campaign for IdeaLab, focused on addressing harassment of Wikimedia project contributors: <https://meta.wikimedia.org/wiki/Grants:IdeaLab/Inspire> Harassment diminishes the experience of contributing and participation for a substantial number of individuals, even those who simply witness it. Current methods of dealing with harassment are considered unacceptable as they often do not lead to productive outcomes.[1] During the month-long campaign, you are invited to submit & review ideas on how to better address harassment. Consider joining a team to help make an idea happen. Ideas can be submitted in any language, and focus on research, building tools or software, outreach efforts, or something completely new. Grants are available from the Wikimedia Foundation to fund projects that are eligible for financial support.[2] Ideas focused on changes to community policies and guidelines are also welcome. Google Hangout sessions are also scheduled in June if you’d like to discuss your idea or have questions about WMF grants.[3] Questions about the campaign can be directed at the Inspire talk page.[4] An FAQ page about the campaign is also available.[5] If you want to help make your projects safer for everyone to participate in, I encourage you to participate in this Inspire Campaign. I believe we can work together to address this difficult and important issue. With thanks, Chris "Jethro" Schilling I JethroBT (WMF) <https://meta.wikimedia.org/wiki/User:I_JethroBT_(WMF)> Community Organizer, Wikimedia Foundation <https://wikimediafoundation.org/wiki/Home> [1] < https://commons.wikimedia.org/wiki/File:Harassment_Survey_2015_-_Results_Re… > [2] <https://meta.wikimedia.org/wiki/Grants:Start> [3] <https://meta.wikimedia.org/wiki/Grants:IdeaLab/Events> [4] <https://meta.wikimedia.org/wiki/Grants_talk:IdeaLab/Inspire> [5] <https://meta.wikimedia.org/wiki/Grants:IdeaLab/Inspire/FAQ>

1 0

Voting reusable
by rupert THURNER 31 May '16

31 May '16

>From time to time mails like below pass by where I wish that voting should be generalized on a technical level. So that any organization participating in the wikiverse would be able to conduct votes and reuse voting rights. Would this be something of broader value? Best Rupert ---------- Forwarded message ---------- From: "Sandister Tei" <sandistertei(a)gmail.com> Date: May 31, 2016 16:33 Subject: Re: [Wikimedia-GH] Help us choose volunteers to serve you To: "Sadat" <masssly(a)ymail.com> Cc: "Planning Wikimedia Ghana Chapter" <wikimedia-gh(a)lists.wikimedia.org> And if they vote with another account? Regards, Sandister Tei www.sandistertei.com Via mobile On 31 May 2016 2:28 p.m., "Mohammed S. Abdulai" <masssly(a)ymail.com> wrote: > You can just restrict multiple entries, I believe you're familiar with > that process. > > Cheers > > -Masssly > > Sent from my Samsung Galaxy smartphone. > -------- Original message -------- > From: Sandister Tei <sandistertei(a)gmail.com> > Date: 05/31/2016 10:38 (GMT+00:00) > To: Sadat <masssly(a)ymail.com> > Cc: Planning Wikimedia Ghana Chapter <wikimedia-gh(a)lists.wikimedia.org> > Subject: RE: [Wikimedia-GH] Help us choose volunteers to serve you > > You can suggest another means to check double voting. > > Regards, > Sandister Tei > > www.sandistertei.com > > Via mobile > On 31 May 2016 10:07 a.m., "Mohammed S. Abdulai" <masssly(a)ymail.com> > wrote: > >> For best practices we shouldn't REQUIRE prospective respondents to enter >> their names. >> >> I would like to see that relaxed. >> >> Thanks >> >> -Masssly >> >> >> Sent from my Samsung Galaxy smartphone. >> -------- Original message -------- >> From: Sandister Tei <sandistertei(a)gmail.com> >> Date: 05/31/2016 08:00 (GMT+00:00) >> To: Planning Wikimedia Ghana Chapter <wikimedia-gh(a)lists.wikimedia.org> >> Subject: [Wikimedia-GH] Help us choose volunteers to serve you >> >> Hello all. >> >> Help us choose volunteers to serve you. >> Please take this survey <http://goo.gl/forms/NQSLDL0CRGwwy3hi2>. It's >> just two questions. >> >> >> *Regards, * >> *Sandister Tei * >> >> *www.sandistertei.com <http://www.sandistertei.com>* >> > _______________________________________________ Wikimedia-GH mailing list Wikimedia-GH(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-gh

1 0

Discovery Weekly Update for the week starting 2016-05-23
by Chris Koerner 31 May '16

31 May '16

Howdy, Here is this week's (belated) update from the Discovery department. * Updated Wikipedia.org Portal stats [1] for articles by languages * Updated Portal page [2] for things done to date * Last week, the Search Team met offsite in Washington, D.C. to build our quarterly goals based on the annual plan. The goals pages on mediawiki.org will be updated soon with the new provisional goals. * Elasticsearch 2.3.3 upgrade in progress, beta is running the new version. Production clusters will be upgraded next week, see the upgrade plan [3] for more details. * Released a report [4] on analyzing the relationship between query features and zero results rate. [1] https://phabricator.wikimedia.org/T128546 [2] https://www.mediawiki.org/wiki/Wikipedia.org_Portal [3] https://phabricator.wikimedia.org/T133124 [4] https://www.mediawiki.org/wiki/File:From_Zero_to_Hero_-_Anticipating_Zero_R… ---- Feedback and suggestions on this weekly update are welcome! The full update, and archive of past updates, can be found on Mediawiki.org: https://www.mediawiki.org/wiki/Discovery/Status_updates -- Yours, Chris Koerner Community Liaison - Discovery Wikimedia Foundation

1 0

Testing of Lua-script
by John Erling Blad 31 May '16

31 May '16

Hi all, wrote an application for an IEG-grant on creating a testing environment for Lua-scripts.[1] Perhaps it is interesting for you. It is mainly a tool for on-wiki testing of scripts, and I'm not sure if it is that interesting for use for off-wiki testing. When I wrote the application I said it was about BDD-style testing, but it would probably be better to describe it as testing with spec-statements.[2] It is somewhat similar to the library "Busted",[3] but it use expect instead of assert. No changes to the Lua core is necessary to run this kinds of tests, it is mostly to get proper localization of messages and a bit more stability and reputability. Likewise i sketched an alternate future grant application for ATDD-style testing. This is testing with step-statements. The BDD-lib will only do spec-type testing. Add yourself to endorsement if you think this is a good idea! :) [1] https://meta.wikimedia.org/wiki/Grants:IEG/Lua_libs_for_behavior-driven_dev… [2] https://en.wikipedia.org/wiki/Behavior-driven_development [3] http://olivinelabs.com/busted/

1 1

Technical Collaboration goals for July - September 2016
by Quim Gil 31 May '16

31 May '16

Hi, the Wikimedia Foundation Technical Collaboration team (Community Liaisons + Developer Relations) is defining individual and team goals for the next quarter, July - September 2016. We welcome your feedback. Which tasks should we prioritize? Please share your suggestions, preferably at https://phabricator.wikimedia.org/T131915 More: https://meta.wikimedia.org/wiki/Technical_Collaboration/Goals -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

2026

2025

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 May 2016