Wikitech-l October 2013

wikitech-l@lists.wikimedia.org

148 participants
148 discussions

Re: [Wikitech-l] [Design] Are external link icons useful
by Brion Vibber 31 Oct '13

31 Oct '13

A few background notes: * The generic external link icon is applied by virtual of existence of the 'external' class, which is a nice simple implementation. I kinda like it. :) * In contrast, the CSS rules used to mark certain external links with the PDF, IRC, SSL, etc "specific" icon types are relatively ugly and hard to maintain. These use inefficient client-side attribute value matching. There is a desire to clean these up in the style sheets, which would of course be easiest if they're simply removed. * If it's useful to keep those subtypes, it may be more desirable to implement them differently (for instance by having the parser apply the matching rules and output a class). This would simplify the CSS rules for maintenance, since they would be able to just use the classes. * Note that some of the rules such as PDF detection can misidentify resource types (for instance the rules would mark a File:Blah.pdf file *page* on Commons as "PDF" even though it's not actually a PDF download, but an HTML web page). This would not necessarily change under the above proposal to change implementation, as the basic problem is that you can't really reliably determine a file type from a "file extension" on a URL (the only real way to check is to try fetching the resource, or at least its HTTP headers, and report back what type was received). -- brion On Tue, Oct 29, 2013 at 1:11 PM, Quiddity <pandiculation(a)gmail.com> wrote: > As Bartosz says, and I think most of the communities would agree if asked > on their respective village pumps - we value the external link icon in > particular, and most of the other icons in general (with the possible > exception of the https padlock). We think they are useful for both editors > and readers. > > Re: Gadget - This isn't a particular workflow - this is: > "I'm reading a random article, and I notice an external link icon, so, as > a wikignome, I either: (if spam) remove it, (if citation) fix it, (if > [subjective decision about its relevance/worth and adherence to [[WP:EL]] > guideline) move it into the External links section." > A gadget would not be a good replacement. > > By all means clean up the CSS, but do not consider removing the icons > without seeking much much wider input. > > > > On 13-10-29 11:57 AM, Jared Zimmerman wrote: > >> Nick, good points, for the particular use case sounds like a gadget for >> showing external links called out for workflows around fixing them would >> be a good idea. After hearing everyone's thought i'm leaning toward no >> icons for the average user. >> >> * >> * >> * >> * >> *Jared Zimmerman *\\Director of User Experience \\Wikimedia Foundation >> M : +1 415 609 4043 | : @JaredZimmerman <https://twitter.com/** >> JaredZimmerman <https://twitter.com/JaredZimmerman>> >> >> >> >> >> On Tue, Oct 29, 2013 at 11:41 AM, quiddity <pandiculation(a)gmail.com >> <mailto:pandiculation@gmail.**com <pandiculation(a)gmail.com>>> wrote: >> >> +1 for more discussion, and onwiki discussion to find out why >> we/they've each kept them in the individual CSS payloads for so many >> years... >> >> >> On 10/24/2013 02:48 PM, Jared Zimmerman wrote: >> >>> Its definitely a less heavy handed way of doing >>> the thing many (annoying) sites do when they warn >>> you that you're leaving their site. I just wonder >>> is the signal to noise it worth it. I don't know >>> that modern web users have any expectations that >>> link within a site always point to local site urls. >>> >>> >> Wikis are special, in relation to most sites, because of the density >> of internal links (many per paragraph), and the expectation that >> most links are internal and will lead to a similar quality/style of >> information. That applies from Wikisource, to Wookiepedia. >> >> In wikis that don't mix external links in the main content (eg most >> Wikipedias), the icons are also useful /for editors/ as they can >> >> easily notice that something needs to be moved/fixed. >> >> See https://en.wikipedia.org/wiki/**Help:External_link_icons<https://en.wikipedia.org/wiki/Help:External_link_icons>for a >> good list of what the English Wikipedia has. >> >> See also recent discussion at >> https://bugzilla.wikimedia.**org/show_bug.cgi?id=54604<https://bugzilla.wikimedia.org/show_bug.cgi?id=54604>("Ridiculous >> amount of CSS rules for external links") >> >> >> The only icon that seems (afaik) completely unnecessary, and >> bright/distracting, is the https padlock, which possibly >> could/should be replaced with the standard external link icon. >> (Unless there's a rationale for it that I'm forgetting/unaware of.) >> >> See this 2009 discussion where Davidgothberg created a blue (less >> distracting) replacement, if we need to keep a padlock for some >> reason. >> https://en.wikipedia.org/wiki/**MediaWiki_talk:Common.css/** >> Archive_11#Secure_links_**padlock<https://en.wikipedia.org/wiki/MediaWiki_talk:Common.css/Archive_11#Secure_l…> >> https://www.mediawiki.org/**wiki/Special:Code/MediaWiki/**60320<https://www.mediawiki.org/wiki/Special:Code/MediaWiki/60320> >> >> HTH. Quiddity >> >> ______________________________**_________________ >> Design mailing list >> Design(a)lists.wikimedia.org <mailto:Design@lists.**wikimedia.org<Design(a)lists.wikimedia.org> >> > >> https://lists.wikimedia.org/**mailman/listinfo/design<https://lists.wikimedia.org/mailman/listinfo/design> >> >> >> >> >> >> ______________________________**_________________ >> Design mailing list >> Design(a)lists.wikimedia.org >> https://lists.wikimedia.org/**mailman/listinfo/design<https://lists.wikimedia.org/mailman/listinfo/design> >> >> > > ______________________________**_________________ > Design mailing list > Design(a)lists.wikimedia.org > https://lists.wikimedia.org/**mailman/listinfo/design<https://lists.wikimedia.org/mailman/listinfo/design> >

2 1

Re: [Wikitech-l] Deployment postmortem
by Greg Grossmeier 31 Oct '13

31 Oct '13

First: Thanks for responding to this and writing it up. <quote name="Yuri Astrakhan" date="2013-10-31" time="04:53:44 +0400"> > == Recomendations == > * Allow a bit more time between deployments and observe fatalmonitor before > and after Agreed. I put a ton of blame on myself for not slowing down the cadence of LD slots when a bunch of people are trying to get in on the same day. For future LDs I am going to explicitly ask everyone to do what Yuri suggests (monitor fatals after your deploy) before saying that you're done. 5 minutes post-deploy of watching the fatalmonitor isn't unreasonable, I don't think. Relatedly, I think we should reassess the Lightning Deploys :) Not necessarily to get rid of them (probably not), but: 1) how many deploys can go in one LD? How many do we *want* to go? 2) from 1, is the length of the LD long enough/too long? 3) LD management is still pretty high-communication ("Alright, who's in line? Who's up next? Are you done yet?") There are basic tools that can help with this (Etsy has an IRC "pushbot" that manages the queue mostly automatically, for instance); I'll look into those/test them. 4) probably more, aka: your thoughts? Greg PS: graph of the fatals attached, just for completenesses sake. -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

First round of loggable javascript deprecations
by Krinkle 30 Oct '13

30 Oct '13

TL;DR: We're starting to remove long-deprecated methods. First, they'll be wrapped in mw.log.deprecate (possibly replaced with dummy values) which will produce a stacktrace to the console when used. Example: http://cl.ly/image/3W0o131K0D3j Pre-amble: * As of MediaWiki 1.17 we started actively developing new javascript features. * Any code from before that point has been tagged "legacy" and deprecated as of v1.17.0 back in 2011. Problems: * There is no easy way to see whether a page is using any of these deprecated interfaces. * We still haven't removed any of the legacy code. * Though we've added new things (jQuery, jQuery UI, mw.Title, mw.Uri etc.). We've been reluctant to iterate further on these "new" things and haven't been able to really refactor or improve them. We've upgraded jQuery and jQuery UI a few times. But only because there were no major changes in backwards compatibility. This changed in 1.9 and that's why we're still on 1.8. It would seem we're in a fixed position – unable to move up, only sideways. On the server-side of MediaWiki, deprecation has been a natural process enforced socially (plugins not maintained for several release cycles will simply have to be disabled). We introduce the new, we migrate uses of the old, we deprecate the old, we support both for uses for a while to allow others to migrate their stuff, then we remove the old. In the front-end we never completed such a cycle. But, we're getting close to the completion of our first first cycle now. The legacy scripts deprecated as of v1.17.0 have all been removed or wrapped in mw.log.deprecate. Please go to your favourite wiki in debug=true mode with a modern browser (recent Chrome, Firefox or Opera) and look at the console. Look for any uncaught exceptions, deprecation notices or other messages and try to address them soon (or report it to the maintainers of the gadgets triggering them). -- Krinkle [1] https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.log-method-dep…

1 0

Fwd: Participation in an Aaron Swartz Hackathon event
by Quim Gil 30 Oct '13

30 Oct '13

There is a plan for a worldwide round of Aaron Hackathons, on the upcoming Nov 8-10 weekend. http://aaronswartzhackathon.org/ Coordination: https://www.noisebridge.net/wiki/Worldwide_Aaron_Swartz_Memorial_Hackathon_… We have been invited to run a hackathon. Can we organize it? We would need to find a project and a critical mass of contributors willing to document and coordinate the hackathon. One possibility could be to kick-off the hackathon on Friday 8 Nov in a physical location (San Francisco), and focus initially on the distribution of tasks. Then remote participants could also participate taking tasks, participating with the rest of the group on some IRC channel and occasional videoconferences. About the project, I personally think that it should have a link with the motivation of the hackathon: "We were part of an inchoate, ad-hoc community of collaborators who helped each other learn how to code. No, not how to write code ‒ how to write code for the purpose of changing the world." - Zooko, on memories of Aaron See also https://en.wikipedia.org/wiki/Aaron_Swartz#Life_and_works On Sat, 5 Oct 2013, Noah Swartz wrote: > Hey assorted Wikimedia people, > As I may have mentioned to some of you previously, we're running another > round of Aaron Hackathons, on the upcoming Nov 8-10 weekend. I was > wondering if WMF would be interested in providing a project for people to > work on. For each event we're hoping to have one well structured project > that people - both technical and non - can work on that can have some > support from people who have worked on it or related projects previously, > so that participants can jump right in. > Would you be willing to structure something for people to work on? If not > are there other WMF related things that people can do? Maybe go through a > list of open bugs or feature requests? Or maybe just writing documents, or > doing outreach, any project is welcome. > Currently we have two tentative events in SF and ~5 more confirmed > locations elsewhere around the world. We have a very basic landing page up > at http://aaronswartzhackathon.org/ which might give you more of a sense of > what's going on. I assume that SF is the location that works best for you > but let me know if you think somewhere else would be good. I'd really love > to see you all participate so let me know if there's anything I can do to > help. > As always feel free to pass this along to anyone else who you think might > be interested, and I'm happy to answer any and all questions you have. > Looking forward to hearing back soon! > Noah >

5 6

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?
by Quim Gil 30 Oct '13

30 Oct '13

On 10/29/2013 03:30 PM, S Page wrote: > Quim: > > And if we want to specify any fonts in our works, they should be free. > > Uh, why? Mac users actually have Helvetica Neue, the nicest-looking > font, Windows users have Georgia. The presence of these names in our CSS > does nothing to hinder the cause of free fonts. Yes, it does hinder the cause of free fonts. We won't help scratching the itch because in practice we will rely on a proprietary solution for our UX work targeting the majority of users. While not forcing anybody to use free fonts, our mockups, tests, reviews, screenshots and what not will all assume the happy coincidence that Helvetica Neue ("the most ubiquitous in advertising copy and logos") and Georgia (Microsoft Corporation) are everywhere. Now compare with this hypothetical scenario: we actually bet on a set of optional free fonts, because we care about typography as much as we care about freedom. We use them as default in our mockups, tests, reviews, screenshots and what not. We serve them as web fonts, we bundle them in our apps and offline versions, we promote them to the users missing them in their systems. We take note of our own itches and user feedback, and we file bugs and enhancement requests upstream, or send/commission improvements. This way we contribute spreading free typography, just like we contribute spreading other areas of free knowledge, free culture and free software. > Removing them would be detrimental for most of our users. Detrimental... they would still be able to access all our content and functionality without losing a single readable character, right? A lot less "detrimental" than not serving them conveniently mp3, mpeg, flash, Facebook/Twitter/Google login, and other proprietary options already installed in your average Mac / Windows desktop that we decided not to support. If the above scenario to improve the MediaWiki/Wikimedia UX by improving free fonts is not exciting, or a priority, then at least we could be neutral and not promote actively any proprietary font either. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

4 3

Google Code-in: are you in?
by Quim Gil 30 Oct '13

30 Oct '13

Google Code-in has been announced: http://www.google-melange.com/gci/homepage/google/gci2013 This is about 13-17 year old students performing tasks that can be isolated and a skilled contributor would complete in a couple of hours. The tasks mjust have a mentor and can be related to code, documentation, outreach, QA or UX. Participants get one point for each task completed and they can complete as many as they can between 18 November and 6 January. Wikimedia can apply thanks to our participation on GSoC 2013. The deadline is 28 October. Only 10 organizations will be accepted. I think we should apply. Main reasons: * The definition of a Code-in task fits very well with our ideal definition of an annoying little bug: https://www.mediawiki.org/wiki/Annoying_little_bugs * The typical Code-in participant needs what most potential new contributor also need from us: an insightful landing page, straight connections to first tasks and friendly community support. * Just like GSoC / OPW, it is a good chance for non-primetime projects to raise their hands, get some help and hopefully some new contributors. * Good exercise for first-time mentors, practicing for more co plex internship projects. * Good exercise for any open source project, meaning just any MediaWiki / Wikimedia tech project. But of course this will only work if many projects want to step in with a task and a mentor for it. So what do you think? -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

10 17

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?
by Matthew Flaschen 30 Oct '13

30 Oct '13

On 10/29/2013 06:30 PM, S Page wrote: > This seems right. I repeat, there is no benefit to putting the free > names first, unless designers think they look better. One important benefit is that we encourage use of free fonts, even when both free and proprietary fonts are installed. This fits with our support for free software throughout the movement. I completely agree we should choose great free fonts that fit our intended design. > Most popular Linux variants specify an equivalent FOSS font for > "Helvetica" that ships with the OS for exactly this scenario, ensuring > that users get a decent approximation of the proprietary font's > appearance by some FOSS font. For the record (and I think similar to what you said), this may be the case for Helvetica, but not necessarily Helvetica Neue. On my machine, fc-match gives 'Helvetica' => "Nimbus Sans L" "Regular"' 'Helvetica Neue' => "DejaVu Sans" "Book" 'Made-up font name' => "DejaVu Sans" "Book" Nimbus Sans L is indeed based on Helvetica (https://en.wikipedia.org/wiki/Nimbus_Sans_L). I think the other two are just last-ditch fallbacks (hence why it's the same for 'Made-up font name'). I set up http://jsfiddle.net/UPBUH/ as a quick testing ground. When I check the Fonts tab of Firefox's Web Console (not Firebug), it shows "Nimbus Sans L Bold system". Used as: "Nimbus Sans L". I think that means fc is looking through the whole stack and picking Nimbus Sans L as the best match. I think corroborates what you said earlier ("fontconfig will use the first font in the font stack that has a positive match.") S, can I ask what you see for that fiddle on the same console tab? > A few brave users customize the matching behavior because they prefer something else, or they read some how-to > article. If we put the free names first, we just frustrate those > efforts, and the experience of 90% of our users doesn't change. If we put the free font first, we're saying we want to use that free font (because it's a free, and fits our intended design well). The extremely few users who manually customize their font-matching can still override e.g. what "Nimbus Sans L" points to on their machine. > A font stack is inherently undefined behavior :) > Yes we get somewhat unspecified behavior for a small subset of our > users, but on balance it's better and more freedom-y to let them evolve > a better FOSS version of the notion of "Helvetica" than nailing them to > 2012's fallback "Nimbus Sans L". Who says we have to nail anything down? We can choose Nimbus Sans L initially and then put a similar but better free font first later. Matt Flaschen

3 4

Welcome, Rummana Yasmeen
by Rob Lanphier 29 Oct '13

29 Oct '13

Hi everyone, I'd like to introduce Rummana Yasmeen, a new Software Test Engineer in our QA team through April in our San Francisco office. Rummana is going to be working with our Visual Editor team primarily on manual testing, finding bugs so you don't have to. Depending on how things go in the next few months, she may venture out into other areas (e.g. automation). Rummana earned a Bachelors of Science in Computer Science, from North South University in Dhaka, Bangladesh, and recently earned a Graduate Certificate in IT management from Golden Gate University. You'll find her on our IRC channels as "rummana", and her email is ryasmeen(a)wikimedia.org. Welcome, Rummana! Rob p.s. important pronunciation guide, since things are about to get confusing for many of us who work with her in-person/on phone, etc. Rummana pronounces her name with the accent on the second syllable ("ru-MAH-nuh"), as opposed to Sumana who pronounces her name with the accent on the first ("SU-mah-nuh")

4 3

Localizing site names displayed RelatedSites extension
by Eugene Zelenko 29 Oct '13

29 Oct '13

Hi! How site names displayed by RelatedSites extension could be localized? For example, such links are heavily used in Wikivoyage, but only section header in toolbox is localized and English project names are used for links. Eugene.

1 0

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?
by Steven Walling 29 Oct '13

29 Oct '13

On Tue, Oct 29, 2013 at 12:51 PM, Jared Zimmerman < jared.zimmerman(a)wikimedia.org> wrote: > We have an action item to change the order from the free fonts that are > visually similar to the specified non-free fonts, I don't think* that this > will change the experience for user without those fonts but we'd have to do > some testing, it really comes down to if we specify Helvetica Neue, and a > particular system thinks that should match a different free font than the > one we thought was a best match. > Just to confirm: I did a quick test, and it appears that on OSX (10.9) Chrome and Firefox interpret font family settings the same using the order Tim suggested. So the output is still Georgia headings and Helvetica Neue body. One question... it seems like specifying Helvetica regular and Neue is slightly redundant. Is there are reason we don't cut Helvetica regular from the list? -- Steven Walling, Product Manager https://wikimediafoundation.org/

3 2

← Newer
1
2
3
4
5
6
7
...
15
Older →

Jump to page:

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 October 2013