Re: [Wikitech-l] Announcement: Kunal Mehta joins Wikimedia as Features Contractor
On 12/12/2013 08:08 PM, Terry Chay wrote: Hello everyone, It’s with great pleasure that I’m announcing that Kunal Mehta[1] has joined the Wikimedia Foundation as contractor in Features Engineering. Welcome aboard! :) It's been great working with already, and I look forward to continuing to do so. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] chrome new version alway tips event.returnValue
On 11 Dec 2013, at 18:40, Bryan Davis wrote: > On Wed, Dec 11, 2013 at 9:59 AM, Sen wrote: >> when i open the chrome console,i always can get: >>> event.returnValue is deprecated. Please use the standard >>> event.preventDefault() instead. >> >> >> is any plan to fix this? > > I don't know if there is currently a plan to fix it, but the warning > is from jQuery and should be fixed by version 1.11 or greater [0]. As > noted on the upstream bug this is just a warning and should have no > effect on functionality. > > [0]: http://bugs.jquery.com/ticket/14282 > In addition to merely being deprecated (and us using a dated version of jQuery), it is also harmless if support were to be removed entirely by Chrome. As far as I know, no version of jQuery ever relied on event.returnValue. It just did the fallback from the standard event.preventDefault in an odd way causing it to trigger a property access, which then (now, years later) got triggered by Chrome’s deprecation system. Simplified: * They were using (jQuery v1.9.1): e.defaultPrevented || e.returnValue === false Which means if the browser supports standard e.defaultPrevented, but is genuinely set to false (it is a boolean property after all) it would look at e.returnValue. * They are now using (jQuery v1.11.0-pre, latest upstream master): e.defaultPrevented ( … ) e.defaultPrevented === undefined && e.returnValue === false -- Krinkle ___ 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
I love how this thread evolved, +1 on pretty much all previous replies. A few more thoughts though. On 10 Dec 2013, at 03:29, MZMcBride wrote: > Ori Livneh wrote: >> On Mon, Dec 9, 2013 at 2:58 PM, Ryan Kaldari >> wrote: >>> I am somewhat concerned about the implications for JS debugging here. >>> Debugging JS problems with the live sites is already pretty complicated: >>> 1. debug=true won't reproduce some bugs (usually race condition related) >> >> Yeah, debug mode sucks. I think we need to think it over. > Indeed, there are various improvements to be made to debug mode. As well as various bug fixes, such as the execution scope. In debug mode we currently load javascript without closures, thus resulting in differences when there are scope bugs. This should make no difference for “good” code (and for this definition of good, anything passing jshint is good enough), but we still have extensions with largely unreviewed javascript, and of course gadgets, site scripts and user scripts which can contain anything imaginable. On 10 Dec 2013, at 03:29, MZMcBride wrote: > Currently it goes something like this, as I understand it: by default, all > CSS and JavaScript is concatenated and minified as much as practically > possible. If you pass a "debug=true" URL parameter to index.php, you can > disable this concatenation and minification of CSS and JavaScript (which > largely, if not exclusively, come through via load.php/ResourceLoader). > Yep, baring a few oversimplified details, this is correct. A more detailed description: https://www.mediawiki.org/wiki/ResourceLoader/Features On 10 Dec 2013, at 03:29, MZMcBride wrote: > * Minification reduces bandwidth usage. > ** At the cost of making debugging more difficult. > > * You can specify debug=true. > ** Specifying the URL parameter can damage reproducibility. > ** URL parameter is non-obvious to just about everyone. > *** Could add an HTML comment at least pointing people in this direction. > > * Minification is a form of obfuscation and it harms the open Web. > > I'm not sure what the right answer is here. The damage to reproducibility > and the open Web hurts a lot. The performance hit may hurt more. > Don’t forget that concatenation is also an important factor in reducing bandwidth. Firstly because gzip is far more effective when applied to a larger package. Secondly, because the number of http requests can sometimes be a more significant cause of slow-down than file size, especially on mobile where both matter very mcuh. I disagree it makes debugging more difficult. It certainly adds a level of abstraction, but I don’t think this level is affecting difficultly. Especially considering the tools that browsers ship nowadays for debugging. These have improved a lot over the years. For one, Chromium-based browsers have had for several years now (Chrome, Opera, ..) and WebKit releases recently (Safari 6) all have a “Pretty print” or “Original formatting” feature that will expand minified code on-the-fly without reloading, reparsing, or reproducing anything. That is enough to allow a developer who is reproducing a bug to understand context and step-through code execution. It might not give an exact file and line number, but that’s inevitable short of banning converters (e.g. js closure wrapping, and CSSMin @embed) or compiling (LESS) completely. What matters is the context of the error and what module it originates from. And in most cases you don’t even need pretty-print in order to know context. Variable and function names in the stack trace usually provide more than enough information when provided by a bug reporter for developers to know where to look. On the subject, there are other things I think we should focus on to improve debugging in modern browsers: Source maps[1]. Having source maps will actually provide the one thing we can’t provide right now: Getting original file names and line numbers without sacrificing compilation or conversion. In fact, we could drop debug mode entirely (short of its effect on debug-modules being loaded, it wouldn’t affect the way modules are packages anymore). As example, when working on VisualEditor I never ever use debug=true (not locally, not in production). It is completely unnecessary and would be rather slow to request near 600 raw js and css files from a server (used to be more before we switched to using a compiled version of OOjs UI). For me it hasn’t been a trade-off due to the slowness in debug=true, it simply didn’t provide anything I already had. — Krinkle [1] http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] OAuth Devlopment Training
Just a reminder that I'll be running a training tomorrow for any developers interested in OAuth at 11am PST / 19:00 UTC. If you're still interested, let me know and I'll add you to the hangout invite list. For everyone who already responded, I'll send you the link in a bit. Several people asked if we would record it, so I'm planning to do that. I'll send out the link afterward. On Tue, Dec 10, 2013 at 4:47 PM, Chris Steipp 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] Fwd: [Wikimedia-l] [Wikimedia Announcements] IEG 2013 Round 2 Grantees Announced
3 technical projects out of 7 Wikimedia Individual Engagement Grants. Good! Original Message Subject: [Wikimedia-l] [Wikimedia Announcements] IEG 2013 Round 2 Grantees Announced Date: Tue, 17 Dec 2013 01:37:52 -0430 From: Harold Hidalgo Reply-To: wikimedi...@lists.wikimedia.org CC: wikimediaannounc...@lists.wikimedia.org Today were announcing the second round of Individual Engagement Grantees. [1] These grants from the Wikimedia Foundation support individuals and small teams of Wikimedians to experiment with new ideas aimed at having online impact on Wikimedia projects. Weve learned a lot from the first round of IEG grantees over the past 6 months, and look forward to seeing what this next group will accomplish.[2] Seven projects have been recommended by the *Individual Engagement Grants Committee*, a group of volunteers from across the Wikimedia movement who reviewed a set of more than twenty proposals, and approved by the Wikimedia Foundation for this round.[3][4] These selections represent a broad range of projects focusing on activities from outreach to tool-building and are all aimed at connecting and supporting our community. Grantees are trying out new ways of engaging with women and young Wikipedians, fostering participation in Africa, and supporting cartographers, researchers and developers to better engage with projects like Wikimedia Commons, Wikidata, and Wikipedia. The seven selected projects are: *Wikimaps Atlas* Led by Arun Ganesh and Hugo Lopez, funded at $12,500.[5] Hugo and Arun will be building a system to automate the creation of maps in standardized cartographic style using the latest open geographic data. With new workflows and scripts, they aim to make it easier for Wikimedias cartographers to generate and update maps for use in Commons, Wikipedia, and beyond. *Mbazzi Village writes Wikipedia* Led by Paul Kikuba with collaboration from Dan Frendin, funded at $2880.[6] This project is a collaboration between Mbazzi villagers, Wikimedia Sweden, and the Wikimedia Foundation to build a Wikipedia center in Uganda where volunteers can to contribute to Luganda Wikipedia, particularly focusing on articles related to sustainable development. *What is about - C'est quoi. A series of communication tools about Wikipedia in Cameroon* Led by Marilyn Douala Bell and Iolanda Pensa with collaboration from Michael Epacka, funded at 15,000.[7] The team in Douala, Cameroon will engage local artists to create comics, video, and other materials to raise awareness about Wikipedia and free knowledge. *Visual editor gadgets compatibility* Led by Eran Roz and Ravid Ziv, funded at $4500.[8] The team aims to map, organize, and surface lists of gadgets used in different language versions of Wikipedia to improve sharing of gadgets across language communities. Theyll also be piloting and documenting an approach for adapting the most-used gadgets for Visual Editor compatibility. *Wikidata Toolkit* Led by Markus Krötzsch with collaboration from students and researchers at Dresden University of Technology, funded at $30,000.[9] Markus team will develop a demonstrator toolkit for loading, querying, and analysing data from Wikidata. The project experiments with ways to give developers, researchers, and Wikimedians easier access to use Wikidata in applications, research, and other projects. *Women Scientists Workshop Development* Led by Emily Temple-Wood, funded at $9480.[10] Emily is piloting a model of regular, incentivized editing workshops aimed at college-aged women to encourage them to become regular contributors to Wikimedia projects and combat systemic bias with quality content. If the approach is successful, shell use lessons learned in order to develop a scalable kit for other groups to use. Finally, weve provisionally approved a seventh project: *Generation Wikipedia* Led by Emily Temple-Wood and Jake Orlowitz, funded at $20,000 - provided that legal dependencies can be satisfied.[11] This project would pilot a week-long summer conference for young Wikipedians and Wikimedians from around the globe to connect, share skills and build leadership and community capacity among our newest generation of editors. The ten grantees from Cameroon, Uganda, India, Israel, France, Italy, Germany and the United States will begin their projects in the new year; most will run from January through June 2014. Theyll be regularly sharing their progress, experience and lessons learned from their experiments throughout this period, so please feel free to visit their respective pages on Meta for project information and updates in the coming months.[4] Thanks to everyone who boldly created a project idea or shared feedback and suggestions in this round! The next round of IEG proposals opens on 1 March 2014. We look forward to seeing more of your ideas and engagement in 2014.[12][13] Sincerely, Harold A. Hidalgo On behalf of the *Individual Engagement Grants Committee*.
Re: [Wikitech-l] SkinTemplateOutputPageBeforeExec hook and documenting skin template variables
On Sat, Dec 7, 2013 at 1:44 AM, Jon Robson wrote: > I created a bug around killing this hook in favour of more specific > clearer hooks - https://bugzilla.wikimedia.org/show_bug.cgi?id=58137 - > I don't think we should be tinkering with template variables > personally under any circumstances and if we are making changes we > should be doing them higher up the stack. I would be interested in > your thoughts and inevitable screams about how I'm proposing terrible > things ;-) > I have a core patch that adds a hook for adding stuff at the end of portlets, separate from stuff like the language links list. https://gerrit.wikimedia.org/r/#/c/101895/ This will allow Wikibase to add the "edit / add links" link in a cleaner way. Feedback would be great on this approach or if anyone has a better suggestion. :) Cheers, Katie > > > On Fri, Dec 6, 2013 at 10:37 AM, Jon Robson wrote: > > The mobile skin has traditionally used the template variable > > 'language_urls' in SkinTemplate to access the list of alternative > > languages of an article. We are now seeing a lot of friction and bugs > > as we try to move our codebase closer to core. > > > > Question 1: > > What does 'language_urls' mean - is it acceptable for anything other > > than a real language to be in that list? > > > > Over the course of 3 weeks however we have had 3 bugs that have added > > things that are not languages to this list. This has caused various > > noticeable problems with how languages works on mobile. > > > > Question 2: > > Why do developers abuse it in this way - is there not a better more > > semantic way to do this? > > > > Currently we have an issue live on all wikipedias which makes a > > language button show up on all pages - even those without articles. > > x > > > https://en.m.wikipedia.org/w/index.php?title=Diggers_%26_Dealers&title=Diggers_%26_Dealers > > When the language button at the bottom of the screen is clicked it > > says "This page is available in 1 language: Edit links (Edit > > interlanguage links) > > > > As a result I've now proposed a change for our skin to override this > > [1] so that we can control the list contents and override the effects > > of the hook. > > > > This however is rather frustrating - especially given none of our > > template variables are documented and open to this kind of > > interpretation > > > > Question 3: > > Should we document these template variables? If so where and how? > > > > Thanks for your opinions on this matter. > > > > [1] https://gerrit.wikimedia.org/r/99693 > > > > -- > > Jon Robson > > http://jonrobson.me.uk > > @rakugojon > > > > -- > Jon Robson > http://jonrobson.me.uk > @rakugojon > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- @wikimediadc / @wikidata ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] FOSS OPW Round 7 Featured Project - Uploadwizard:OSM embedding, updates
Hi everyone, Myself Anu G Enchackal ,GNOME Outreach Program for Women Round 7 Intern,working on UploadWizard : OSM embedding mentored by Gergő Tisza. This project is about enhancing the image upload process for Wikimedia Commons.The main goal of the OpenStreetMap map embedding project would be to provide map interface & the integration with external databases to the UploadWizard.The secondary goal is to integrate with some databases of locations and use that in various ways. One way would be checking if there are locations with requested images nearby (that is, someone put out a note that Commons needs good images about a certain place and doesn't currently have any), and warn the uploader about them. Week 1 ( Dec 10 --- Dec 16 ) This week was spent mostly by navigating through the existing structure and working on a link introduction within UploadWizard. The present plan is to introduce a link next to coordinate fields within UploadWizard , which can initialize the map widget onclick. Patch sets [1] which replaces the existing 'Show on Map' with a link having the same functionality are already uploaded to gerrit. Expecting valuable comments from everyone Anu G Enchackal OPW Round 7 Intern [1] https://gerrit.wikimedia.org/r/#/c/101029/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Lowering limitation of the score extension
On 12/17/13, Mathieu Stumpf wrote:
> Hello,
>
> I would like to use the score extension to generate guitar chords
> diagrams, but writing something like
>
> \fret-diagram #"s:0.75;6-x;5-x;4-o;3-2;2-3;1-2;"
>
>
> I get this message error:
> Processing `.../file.ly'
> Parsing...
> .../file.ly:12:0: error: unknown escaped string: `\fret'
>
> \fret-diagram #"s:0.75;6-x;5-x;4-o;3-2;2-3;1-2;"
> .../file.ly:12:0: error: syntax error, unexpected STRING
>
> \fret-diagram #"s:0.75;6-x;5-x;4-o;3-2;2-3;1-2;"
> .../file.ly:21:24: error: syntax error, unexpected '}'
>
> }error: failed files: ".../file.ly"
>
> exited with status: 1
>
> The code works just fine when I compile it with my local lilypond. That
> functionality would be really interesting, since with a little scribunto
> module, it would allow to generate chords diagram on the fly, and even a
> chord book.
>
> Also I would like to make even more with colored diagrams showing a set
> of interval on the neck. It would be fine if the mediawiki environnement
> would allow this.
>
> kind regards
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I'm not very familiar with lilypond, so there is probably a better
way, but I was able to generate that fret board with code like:
\markup {\fret-diagram #"s:0.75;6-x;5-x;4-o;3-2;2-3;1-2;"}
\score {
\new Score { c1 }
\midi { }
}
\header { tagline = ##f}
See https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&oldid=586519066
--bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Jenkins interruption
Le 17/12/13 17:57, Antoine Musso a écrit : > Hello, > > For some nasty reason the Wikimedia Jenkins had to be restarted a few > minutes ago. It is currently busy reloading the configuration and > restarting, should be fully back up around 5:20pm UTC. > > Meanwhile, jenkins-bot will whine in Gerrit that jobs have been LOST. > This is because it cant reach Jenkins to build the jobs and consider > they are not existent (ie lost). > > Whenever Jenkins is back up, the jobs will have to be retriggered by > submitting a new patchset (for example fixing a typo in the commit > summaries of changes affected). > > Sorry for the inconvenience. And Jenkins is already back up. Still have to retrigger affected jobs though. -- Antoine "hashar" Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Jenkins interruption
Hello, For some nasty reason the Wikimedia Jenkins had to be restarted a few minutes ago. It is currently busy reloading the configuration and restarting, should be fully back up around 5:20pm UTC. Meanwhile, jenkins-bot will whine in Gerrit that jobs have been LOST. This is because it cant reach Jenkins to build the jobs and consider they are not existent (ie lost). Whenever Jenkins is back up, the jobs will have to be retriggered by submitting a new patchset (for example fixing a typo in the commit summaries of changes affected). Sorry for the inconvenience. -- Antoine "hashar" Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Lowering limitation of the score extension
Hello, I would like to use the score extension to generate guitar chords diagrams, but writing something like \fret-diagram #"s:0.75;6-x;5-x;4-o;3-2;2-3;1-2;" I get this message error: Processing `.../file.ly' Parsing... .../file.ly:12:0: error: unknown escaped string: `\fret' \fret-diagram #"s:0.75;6-x;5-x;4-o;3-2;2-3;1-2;" .../file.ly:12:0: error: syntax error, unexpected STRING \fret-diagram #"s:0.75;6-x;5-x;4-o;3-2;2-3;1-2;" .../file.ly:21:24: error: syntax error, unexpected '}' }error: failed files: ".../file.ly" exited with status: 1 The code works just fine when I compile it with my local lilypond. That functionality would be really interesting, since with a little scribunto module, it would allow to generate chords diagram on the fly, and even a chord book. Also I would like to make even more with colored diagrams showing a set of interval on the neck. It would be fine if the mediawiki environnement would allow this. kind regards ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Homepage Redesign
Le 16/12/13 21:53, Brena Monteiro a écrit : > Yes! That's the idea. Identify what content is fundamental to put on the > homepage. Some people agreed that the contents of the homepage needs to be > directed to new users. And I wonder: > > Which content will do new users love MediaWiki? Or what will arouse > interest in using and contribute immediately? Hello, Whenever I hunt for a new software I expect the following on the main page: - software prerequisites (in our case PHP / Mysql) - screenshots - a list of the most important features - a download link - dates of last releases - step-by-step tutorial to install Additional useful links: - bug utility - support forum / mailing list / IRC channel - online demo cheers, -- Antoine "hashar" Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
