Wikitech-l October 2013

wikitech-l@lists.wikimedia.org

148 participants
152 discussions

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 30 Oct '13

30 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

RC for Mediawiki 1.22: 1.22.0rc0
by Mark A. Hershberger 29 Oct '13

29 Oct '13

We've put together an RC for 1.22.0. Please test the tarball and report any bugs you find on Bugzilla: http://bugzilla.wikimedia.org/ Full release notes: https://git.wikimedia.org/blob/mediawiki%2Fcore.git/tags/1.22.0rc0/RELEASE-… https://www.mediawiki.org/wiki/Release_notes/1.22 ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.22/mediawiki-1.22.0rc0.tar.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.22/mediawiki-core-1.22.0rc0.tar.g… http://download.wikimedia.org/mediawiki/1.22/mediawiki-1.22.0rc0.tar.gz.sig Public keys: https://www.mediawiki.org/keys/keys.html

2 1

Filtering out bugs that wait for a response
by Petr Bena 29 Oct '13

29 Oct '13

Hi, is there any possible technical way to make a filter in bugzilla that filter out bugs that are waiting for a response from bug opener (OP)? I suppose there could be either a keyword or something like WAITING-FOR-RESPONSE but in that case it would need to be removed by hand when OP respond. Or there could be a condition that filter out bugs where OP doesn't have last comment? Or probably it would be best to combine both, keyword and check if OP has last comment. But not really sure if that is even possible. Any ideas? It would help to simplify some of my bug lists which are typically full of bugs where I am just waiting for someone to respond to a question but which I can't close now.

3 2

What's the prefered way to contribute patches to Pediapress' mwlib?
by Strainu 29 Oct '13

29 Oct '13

Hi, I have some patches for Extension:Collection, which actually apply to mwlib. While the php code seems to reside on the wikimedia servers, mwlib is on github. Should I attach them to a corresponding bug on bugzilla.wikimedia.org, or should I open a pull request on github? Thanks, Strainu

2 1

OPW project: redesigning mediawiki.org homepage?
by Quim Gil 29 Oct '13

29 Oct '13

I'm thinking of proposing the redesign of the mediawiki.org homepage as a FOSS Outreach Program for Women [1] project. I could act as co-mentor with the help of someone else. The RFC process held so far [2] would serve as a source of feedback, but the project would imply basically a restart. The progress of the project would be public and anybody could chip in and have their say. If there is agreement overall, we would aim to substitute the current homepage or implement changes progressively. If there is a strong lack of consensus that no OPW intern will fix, we would continue the exercise as a prototype, and at the end of the internship the mentors would take the responsibility to drive the project until its implementation. What do you think? Any volunteers to co-mentor? Please reply here or at the RFC Talk page. Thank you! [1] https://www.mediawiki.org/wiki/Outreach_Program_for_Women/Round_7 [2] https://www.mediawiki.org/wiki/Requests_for_comment/MediaWiki.org_Main_Page… -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

More TLS Problems
by Tyler Romeo 29 Oct '13

29 Oct '13

About time another issue with TLS popped up. Thought I'd share it here: http://bit-player.org/2013/the-keys-to-the-keydom *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science

2 3

Visualising CSS debt - cleaning up our messy codebase
by Jon Robson 28 Oct '13

28 Oct '13

I think we are all in agreement that the CSS in MediaWiki is a mess but it's not clear how to solve the mess. I think I've created a useful bit of JS to visualise this mess and make a path to solving it clearer. If you visit: http://jonrobson.me.uk/lsg/ You will see in the dropdown mediawiki vector styles. This is a CSS file I created by manually concatenating all CSS files loaded by default on desktop. When visualised you see a lot of interesting things: 1) We have 6 ways of describing modal windows that take up the full screen (click 6 times on that demo to delete these 6 rules and see the stuff underneath) * .fullscreen * .modal_editor * #guider_overlay * .mw-fullscreen-overlay * .mwEmbedPlayer * .ui-widget-overlay' 2) We have 4 slightly different ways of describing a blue button * body .ui-button.ui-button-blue * .mw-ui-button.mw-ui-primary * .guider_button * button.button.blue 3) There are 13 different CSS rules for creating a pdf icon next to a link I've also added mobile styles and styles introduced by visual editor and if you compare those to the desktop one you'll see we have even more inconsistencies. I encourage you to dig into these styles and notice similarities and help us fix this mess! I'd suggest we start moving the common styles into a common library in MediaWiki core and change all our extensions to make use of the same class names. It's a big job but I think we can get this. This script is still very much a proof of concept so if anyone is interested in improving the visualisation I'd encourage you to send me a pull request on github :)

7 9

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

Jump to page:

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