Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Risker
I've been sitting back watching this thread as it has unfolded, as well as
the discussions in a few other places, to better understand how this
particular subset of the Wikimedia/Mediawiki community problem-solved.  I'd
like to share with you all a few observations.

Steven and Jon, consider having coffee with your colleague Siko Bouterse.
Siko can tell you all about how to fail successfully.  Yes, I know it's an
oxymoron, but there are huge opportunities in trying something, having it
fail, and deriving goodwill, experience and knowledge from that failure.
You've got an amazing opportunity here to learn from a well-intentioned
process that has had significant unanticipated negative effects.  As best I
can tell, nobody doubts that this project was undertaken in good faith, and
nobody doubts that you and your team are disappointed that its outcome is
not what was anticipated.

There is a bit of amnesia about the fact that almost all editors are also
readers and regular users of the projects we create, and those editors have
been encouraged since Day One to inform developers of any technical
problems with the site; they're the canaries in the coal mine.  And for
anyone who's been editing more than 3-4 years (an ever-increasing
percentage of the editing community), "software" issues were things they
had to pretty much solve themselves within the volunteer community. For
years, most developers were volunteers too, and had close links to the
editing community.  At least a good portion of you remember those days -
because you used to be those volunteer developers that community members
would hit up to fix things, and you used to watch the village pumps to
figure out what else needed to be fixed. Until very recently, it was almost
unheard-of for community members to be told that problematic things were
going to stay that way because of a decision made by a small number of
people in an office somewhere.  When most developers were clearly
participating as community members, they behaved as though they were, at
least to a significant extent, accountable to both the editing and
Mediawiki communities; I'm not sure that sense of accountability exists
anymore.  Now, I don't think anyone begrudges the many talented developers
who started off within the community having taken the opportunity to move
on to paid positions at the WMF, and I think on the whole the big-picture
community is overall very happy with the majority of changes that have come
with the increased professionalization of the site engineering and
operations.  But this is a major change in culture, and the gulf between
volunteers (either developer or editor) and WMF staff is widening
noticeably as time progresses.  I could tell who was a volunteer and who
was staff from the way their posts were responded to in this thread; I
doubt that would have been the case even two years ago.

It's pretty clear that the objectives of this project are not successfully
met at this point, and in fact have caused major problems on non-Latin
script WMF sites, and significant but less critical problems on Latin
script sites. Several factors for this have been identified in the thread -
including limited attention to the effects on non-Latin script projects,
the insertion of philosophical principles (FOSS) without a clear
understanding of the effects this would have on the outcome, and the
unwillingness to step back when a major change results in loss of
functionality.

Think a bit more.  If this change is a cornerstone of future design
changes, it needs to work on all WMF projects, and as currently structured
you already know it can't.  It may well be best to pull back to status quo
ante in order to consider how to design not just for Latin-script sites,
but for Chinese, Arabic and Vietnamese ones.  Members of those communities
may not be writing to this mailing list, but most of the non-Latin projects
are growing much faster than the older, Latin-script sites.  They're our
future.  They have to be in the mix.

Best,

Risker
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Steven Walling
On Mon, Apr 7, 2014 at 1:19 PM, Jon Robson  wrote:

> 1) Picking a new open font that is either
> ** widely available on Linux but not so much on Windows
> ** renders well in Windows
>

Coming back to the above option...

Today we spent some time testing a stack that puts Nimbus Sans L first,
before Helvetica Neue. This is the font that currently most Linux users
(we've tested on Ubuntu and Debian) are getting via matching to Helvetica
regular. The thing we tested for primarily is how this font renders on
Windows, for the users who may have it. So far it unfortunately appears
that for Windows users with ClearType turned off, Nimbus Sans also suffers
from bug 63512, like Liberation Sans does. (Screengrab from a Windows 7
machine I have for testing: http://i.imgur.com/pAHTu1f.png).

I would like to keep trying to find a freely-licensed font that A) matches
the other neutral sans-serifs that we have specified and B) which we feel
comfortable putting first in the stack, meaning that it renders well on
Windows, Linux, and Mac on major browsers. So far we are still coming up
short.

[I am copying the above to the Talk page on mediawiki.org in case anyone
else is interested.]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Matthew Walker
On Tue, Apr 8, 2014 at 6:46 PM, Steven Walling wrote:

> On Tue, Apr 8, 2014 at 2:18 PM, Matthew Walker  >wrote:
>
> > Perhaps this is a question that has an answer elsewhere but, irrespective
> > of if this change should be made to WMF wikis, why are we:
> >
> > a) Making this a change in core?
> >
> > and b) Not making the change in core be a SASS variable that can then be
> > set as a preference somewhere? (I say this because we've consistently
> > identified that some languages need different default fonts. If it was a
> > preference in that we could set via our multiversion scripts it would
> > obviate the need for overrides in common.css just to make things work.)
> >
>
> The patches (such as the first one at
> https://gerrit.wikimedia.org/r/#/c/120978/) are to the LESS variables that
> define Vector styles.


Fair enough.


> So they're in core because Vector is in core. Based
> on conversations with Jon we should be able to work out how to do per-wiki
> or preferably per-language styles, right?


Ideally yes; not sure if we have support for that yet or not. I'll defer to
Jon. :)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Security precaution - Resetting all user sessions today

2014-04-08 Thread Daniel Norton
On Apr 8, 2014, at 7:34 PM, Chris Steipp  wrote:
> If you hit this issue, logging out and logging in again seems to fix the
> problem. I'm still trying to track down why this is happening.

Not a master/slave/LB sync thing?

Here’s the main serverfault Q&A item about Heartbleed:

http://serverfault.com/questions/587329/heartbleed-what-is-it-and-what-are-options-to-mitigate-it

--
Daniel

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Steven Walling
On Tue, Apr 8, 2014 at 2:18 PM, Matthew Walker wrote:

> Perhaps this is a question that has an answer elsewhere but, irrespective
> of if this change should be made to WMF wikis, why are we:
>
> a) Making this a change in core?
>
> and b) Not making the change in core be a SASS variable that can then be
> set as a preference somewhere? (I say this because we've consistently
> identified that some languages need different default fonts. If it was a
> preference in that we could set via our multiversion scripts it would
> obviate the need for overrides in common.css just to make things work.)
>

The patches (such as the first one at
https://gerrit.wikimedia.org/r/#/c/120978/) are to the LESS variables that
define Vector styles. So they're in core because Vector is in core. Based
on conversations with Jon we should be able to work out how to do per-wiki
or preferably per-language styles, right?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] GSoC & FOSS OPW selection process

2014-04-08 Thread Quim Gil
On Friday, April 4, 2014, Quim Gil  wrote:

>
> The selection process continues. Mentors' discretion is increasing, and so
> does candidates' curiosity. Even if we have made most of our choices, we
> don't know how many slots we will get, and we are bound to a requirement of
> confidentiality before candidates are selected on April 21. More than two
> weeks to go. Take it easy.
>
> On Monday 7 we will request a number of slots to Google, and by Wednesday
> 9 we will know how many they have allocated to us.
>

We have received the 19 GSoC slots we had requested! This show the good
work that everybody is doing in this selection process. Thank you!

Mentors will have a silent period between now and April 21. Remember, we
are not allowed to disclose any information about candidates
selected/declined before Google and the GNOME Foundation publish their
official announcements.

>
> On Friday, March 28, 2014, Quim Gil  wrote:
>
>>
>> https://www.mediawiki.org/wiki/Google_Summer_of_Code_2014
>>
>> https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_8
>>
>

-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: Security precaution - Resetting all user sessions today

2014-04-08 Thread Chris Steipp
Due to the speed of the script, it will take a while for everyone to be
logged out.

If you hit this issue, logging out and logging in again seems to fix the
problem. I'm still trying to track down why this is happening.


On Tue, Apr 8, 2014 at 4:43 PM, Greg Grossmeier  wrote:

> Chris S is actively looking into this. Thanks for the note.
>
> --
> Sent from my phone, please excuse brevity.
> On Apr 8, 2014 4:18 PM, "Risker"  wrote:
>
> > Thanks for the heads-up, Greg.  However, I'm finding that I am being
> > repeatedly logged out...it's happened every other edit I've made tonight,
> > which is a real pain.  Will report on IRC as well.
> >
> > Risker/Anne
> >
> >
> > On 8 April 2014 16:57, Greg Grossmeier  wrote:
> >
> > > FYI to this audience as well:
> > >
> > > We're reseting all user session tokens today due to heartbleed.
> > >
> > > What I didn't state below is that we have already replaced our SSL
> certs
> > > as well as upgraded to the fixed version of openssl.
> > >
> > > - Forwarded message from Greg Grossmeier 
> -
> > >
> > > > Date: Tue, 8 Apr 2014 13:54:26 -0700
> > > > From: Greg Grossmeier 
> > > > To: Wikitech Ambassadors 
> > > > Subject: Security precaution - Resetting all user sessions today
> > > >
> > > > Yesterday a widespread issue in OpenSSL was disclosed that would
> allow
> > > > attackers to gain access to privileged information on any site
> running
> > a
> > > > vulnerable version of that software. Unfortunately, all Wikimedia
> > > > Foundation hosted wikis are potentially affected.
> > > >
> > > > We have no evidence of any actual compromise to our systems or our
> > users
> > > > information, but as a precautionary measure we are resetting all user
> > > > session tokens. In other words, we will be forcing all logged in
> users
> > > > to re-login (ie: we are logging everyone out).
> > > >
> > > > All logged in users send a secret session token with each request to
> > the
> > > > site and if a nefarious person were able to intercept that token they
> > > > could impersonate other users. Resetting the tokens for all users
> will
> > > > have the benefit of making all users reconnect to our servers using
> the
> > > > updated and fixed version of the OpenSSL software, thus removing this
> > > > potential attack.
> > > >
> > > > As an extra precaution, we recommend all users change their passwords
> > as
> > > > well.
> > > >
> > > >
> > > > Again, there has been no evidence that Wikimedia Foundation users
> were
> > > > targeted by this attack, but we want all of our users to be as safe
> as
> > > > possible.
> > > >
> > > >
> > > > Thank you for your understanding and patience,
> > > >
> > > > Greg Grossmeier
> > > >
> > > >
> > > > --
> > > > | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> > > > | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |
> > >
> > >
> > >
> > > - End forwarded message -
> > >
> > > --
> > > | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> > > | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |
> > >
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: Security precaution - Resetting all user sessions today

2014-04-08 Thread Greg Grossmeier
Chris S is actively looking into this. Thanks for the note.

--
Sent from my phone, please excuse brevity.
On Apr 8, 2014 4:18 PM, "Risker"  wrote:

> Thanks for the heads-up, Greg.  However, I'm finding that I am being
> repeatedly logged out...it's happened every other edit I've made tonight,
> which is a real pain.  Will report on IRC as well.
>
> Risker/Anne
>
>
> On 8 April 2014 16:57, Greg Grossmeier  wrote:
>
> > FYI to this audience as well:
> >
> > We're reseting all user session tokens today due to heartbleed.
> >
> > What I didn't state below is that we have already replaced our SSL certs
> > as well as upgraded to the fixed version of openssl.
> >
> > - Forwarded message from Greg Grossmeier  -
> >
> > > Date: Tue, 8 Apr 2014 13:54:26 -0700
> > > From: Greg Grossmeier 
> > > To: Wikitech Ambassadors 
> > > Subject: Security precaution - Resetting all user sessions today
> > >
> > > Yesterday a widespread issue in OpenSSL was disclosed that would allow
> > > attackers to gain access to privileged information on any site running
> a
> > > vulnerable version of that software. Unfortunately, all Wikimedia
> > > Foundation hosted wikis are potentially affected.
> > >
> > > We have no evidence of any actual compromise to our systems or our
> users
> > > information, but as a precautionary measure we are resetting all user
> > > session tokens. In other words, we will be forcing all logged in users
> > > to re-login (ie: we are logging everyone out).
> > >
> > > All logged in users send a secret session token with each request to
> the
> > > site and if a nefarious person were able to intercept that token they
> > > could impersonate other users. Resetting the tokens for all users will
> > > have the benefit of making all users reconnect to our servers using the
> > > updated and fixed version of the OpenSSL software, thus removing this
> > > potential attack.
> > >
> > > As an extra precaution, we recommend all users change their passwords
> as
> > > well.
> > >
> > >
> > > Again, there has been no evidence that Wikimedia Foundation users were
> > > targeted by this attack, but we want all of our users to be as safe as
> > > possible.
> > >
> > >
> > > Thank you for your understanding and patience,
> > >
> > > Greg Grossmeier
> > >
> > >
> > > --
> > > | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> > > | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |
> >
> >
> >
> > - End forwarded message -
> >
> > --
> > | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> > | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: Security precaution - Resetting all user sessions today

2014-04-08 Thread Risker
Thanks for the heads-up, Greg.  However, I'm finding that I am being
repeatedly logged out...it's happened every other edit I've made tonight,
which is a real pain.  Will report on IRC as well.

Risker/Anne


On 8 April 2014 16:57, Greg Grossmeier  wrote:

> FYI to this audience as well:
>
> We're reseting all user session tokens today due to heartbleed.
>
> What I didn't state below is that we have already replaced our SSL certs
> as well as upgraded to the fixed version of openssl.
>
> - Forwarded message from Greg Grossmeier  -
>
> > Date: Tue, 8 Apr 2014 13:54:26 -0700
> > From: Greg Grossmeier 
> > To: Wikitech Ambassadors 
> > Subject: Security precaution - Resetting all user sessions today
> >
> > Yesterday a widespread issue in OpenSSL was disclosed that would allow
> > attackers to gain access to privileged information on any site running a
> > vulnerable version of that software. Unfortunately, all Wikimedia
> > Foundation hosted wikis are potentially affected.
> >
> > We have no evidence of any actual compromise to our systems or our users
> > information, but as a precautionary measure we are resetting all user
> > session tokens. In other words, we will be forcing all logged in users
> > to re-login (ie: we are logging everyone out).
> >
> > All logged in users send a secret session token with each request to the
> > site and if a nefarious person were able to intercept that token they
> > could impersonate other users. Resetting the tokens for all users will
> > have the benefit of making all users reconnect to our servers using the
> > updated and fixed version of the OpenSSL software, thus removing this
> > potential attack.
> >
> > As an extra precaution, we recommend all users change their passwords as
> > well.
> >
> >
> > Again, there has been no evidence that Wikimedia Foundation users were
> > targeted by this attack, but we want all of our users to be as safe as
> > possible.
> >
> >
> > Thank you for your understanding and patience,
> >
> > Greg Grossmeier
> >
> >
> > --
> > | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> > | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |
>
>
>
> - End forwarded message -
>
> --
> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] What would you miss in a Phabricator environment?

2014-04-08 Thread Quim Gil
As a complement to the upcoming Project Management Tools RfC --
https://www.mediawiki.org/wiki/Requests_for_comment/Project_management_tools_review...

If Phabricator would substitute our current collaboration tools tomorrow,
what would you miss?

Please reply in the appropriate Phabricator tasks (here is also fine, we
just want to have the feedback in one place). If you are not sure whether
feature X is supported, under development, roadmapped... just ask. Let's
create new subtasks for features considered blockers.

Mingle
http://fab.wmflabs.org/T44

Trello
http://fab.wmflabs.org/T45

Bugzilla
http://fab.wmflabs.org/T46

Gerrit
http://fab.wmflabs.org/T47

Missing one tool? Just create the task.

I took the liberty of assigning each task to someone relevant to the topic.
Feel free to take them or leave them. If you are simply interested,
"subscribe".

All these URLs should be visible to anonymous users, otherwise please
report.

PS: if you are curious about how a migration to Phabricator would look
like, you can get an idea at http://fab.wmflabs.org/project/board/14/


-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Daniel Friesen
On 2014-04-08, 12:33 PM, Martijn Hoekstra wrote:
> That is not the status quo, but the diff between the Odder patch and the
> typography refresh basically is the "Set a non-free font stack to give Mac
> now Helvetica Neue rather than Helvetica", with a -2 is planted in the
> ground before as a demarcation line. That's the point that I don't think is
> worth having a non-free font-stack for, and that I certainly think standing
> your ground for the brave new world of typography refresh is constructive
> for.
Just to randomly chime in here, as someone using a Mac bought for my
personal use by my employer awhile ago in my daily activities, I'd
prefer that the difference between Helvetica and Helvetica Neue is not
belittled.

Helvetica is an ancient font, created for print in 1957. Helvetica Neue
was still only created in 1983 but its goal of being an improvement over
Helvetica still carries over to the current computer fonts nonetheless.
I can't fathom why Helvetica is still in use when a variant created
specifically to be more legible than base Helvetica is now available –
some would say any variant of Helvetica doesn't belong on the web[1],
but Neue is still an improvement.

Flipping between Helvetica and Helvetica Neue by turning on and off a
font-face: sans-serif; overriding the current `"Helvetica Neue",
Helvetica, Arial, sans-serif` on en.wp's main page I can see a notable
difference between the two.

Primarily in the kerning, Helvetica Neue's kerning is much better than
Helvetica's, which simultaneously leaves extra space between letters
when not needed and uses too little space between letters when it's
necessary for legibility.

In general Neue has better kerning between letters, putting things
closer together:
- In "Main Page" it drops the unnecessary space inside Pa that Helvetica
has.
- In "Main page" in the sidebar it puts all letters closer together,
dropping unnecessary space between ai and ag
- In the content "All" drops unnecessary space between ll and "The"
drops unnecessary space between Th
- and so on

While in other cases Neue separates things that Helvetica puts together
to it's detriment: cl, co, ct, te, all have extra space between them,
while Helvetica puts them close together in ways that could be mistaken
for other letters (d, oo, d, b).

[1] http://www.64notes.com/design/stop-helvetica-arial/

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: Security precaution - Resetting all user sessions today

2014-04-08 Thread Brian Wolff
Googling, I found http://heartbleed.com/ and
https://www.openssl.org/news/secadv_20140407.txt gave more technical
description of the issue in question, which I found interesting.
Thought I'd pass the links along in case they are useful to anyone
else.

Anyhow, some scary stuff there.

--bawolff

On 4/8/14, Greg Grossmeier  wrote:
> FYI to this audience as well:
>
> We're reseting all user session tokens today due to heartbleed.
>
> What I didn't state below is that we have already replaced our SSL certs
> as well as upgraded to the fixed version of openssl.
>
> - Forwarded message from Greg Grossmeier  -
>
>> Date: Tue, 8 Apr 2014 13:54:26 -0700
>> From: Greg Grossmeier 
>> To: Wikitech Ambassadors 
>> Subject: Security precaution - Resetting all user sessions today
>>
>> Yesterday a widespread issue in OpenSSL was disclosed that would allow
>> attackers to gain access to privileged information on any site running a
>> vulnerable version of that software. Unfortunately, all Wikimedia
>> Foundation hosted wikis are potentially affected.
>>
>> We have no evidence of any actual compromise to our systems or our users
>> information, but as a precautionary measure we are resetting all user
>> session tokens. In other words, we will be forcing all logged in users
>> to re-login (ie: we are logging everyone out).
>>
>> All logged in users send a secret session token with each request to the
>> site and if a nefarious person were able to intercept that token they
>> could impersonate other users. Resetting the tokens for all users will
>> have the benefit of making all users reconnect to our servers using the
>> updated and fixed version of the OpenSSL software, thus removing this
>> potential attack.
>>
>> As an extra precaution, we recommend all users change their passwords as
>> well.
>>
>>
>> Again, there has been no evidence that Wikimedia Foundation users were
>> targeted by this attack, but we want all of our users to be as safe as
>> possible.
>>
>>
>> Thank you for your understanding and patience,
>>
>> Greg Grossmeier
>>
>>
>> --
>> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
>> | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |
>
>
>
> - End forwarded message -
>
> --
> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |
>

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Matthew Walker
Perhaps this is a question that has an answer elsewhere but, irrespective
of if this change should be made to WMF wikis, why are we:

a) Making this a change in core?

and b) Not making the change in core be a SASS variable that can then be
set as a preference somewhere? (I say this because we've consistently
identified that some languages need different default fonts. If it was a
preference in that we could set via our multiversion scripts it would
obviate the need for overrides in common.css just to make things work.)

~Matt Walker
Wikimedia Foundation
Fundraising Technology Team


On Tue, Apr 8, 2014 at 2:03 PM, Martijn Hoekstra
wrote:

> On Tue, Apr 8, 2014 at 10:20 PM, Steven Walling  >wrote:
>
> > On Tue, Apr 8, 2014 at 12:33 PM, Martijn Hoekstra <
> > martijnhoeks...@gmail.com
> > > wrote:
> >
> > > On Tue, Apr 8, 2014 at 8:13 PM, Erik Moeller 
> wrote:
> > >
> > > > On Tue, Apr 8, 2014 at 10:59 AM, Martijn Hoekstra
> > > >  wrote:
> > > > > So, the font stack changes with regards to the status quo now
> change
> > > > > nothing for Windows users, changes Helvetica -> Helvetica neue for
> > Mac
> > > > > users and changes Arial, DejaVu Sans or Arimo for possibly
> something
> > > > else,
> > > > > amongst which Nimbus Sans L, maybe, maybe not.
> > > >
> > > > Actually, it's a bit more complicated. All users get serif fonts for
> > > > headings, which they didn't before and which is probably the biggest
> > > > visual before/after difference. The serif fonts still prioritize
> > > > free/libre fonts over non-free ones.
> > > >
> > > > The body fonts prioritized free/libre fonts on deployments, but for
> > > > Windows users without ClearType/anti-aliasing, those render very
> > > > poorly, so they were disabled shortly after deployment. This is now
> > > > causing people to be upset because the initial agreement to never
> > > > prioritize non-free fonts is no longer maintained for the body.
> > > >
> > > > Odder's patch would revert to sans-serif as a generic classification
> > > > for the body, but doesn't touch the font specification for the
> headers
> > > > (yet). The commit summary is a bit misleading in that regard.
> > > >
> > >
> > > Yes, I should have made that clear: I do very much support the Odder
> > > patch[1] ( https://gerrit.wikimedia.org/r/#/c/124475/ ) that reverts
> > body
> > > to sans serif and keeps @content-heading-font-family: "Linux
> Libertine",
> > > Georgia, Times, serif;
> > >
> > > That is not the status quo, but the diff between the Odder patch and
> the
> > > typography refresh basically is the "Set a non-free font stack to give
> > Mac
> > > now Helvetica Neue rather than Helvetica", with a -2 is planted in the
> > > ground before as a demarcation line. That's the point that I don't
> think
> > is
> > > worth having a non-free font-stack for, and that I certainly think
> > standing
> > > your ground for the brave new world of typography refresh is
> constructive
> > > for.
> > >
> >
> > This is a persistent myth floating around about this. Neue for Mac users
> is
> > most definitely not the only effect of explicitly declaring the stack. As
> > Jared, S Page, and others have already pointed out, and as is stated in
> the
> > FAQ on mediawiki.org, the impact of the current stack is:
> >
> > -- Linux users get Nimbus Sans L, instead of DejaVu Sans, Liberation
> Sans,
> > or whatever else the default sans is on your distro. Nimbus has an
> improved
> > x-height and is much more consistent with the other sans-serifs we're
> > specifying.
> >
>
> Unfortunately, we didn't properly test this. With the large diversity in
> results of the tests we did do on
> https://www.mediawiki.org/wiki/Typography_refresh/Font_choice/Test I doubt
> it's a hard rule that Linux users will now universally get Nimbus Sans L.
> I'm also not sure that Nimbus Sans L is the superior alternative over
> Liberation Sans. I'm by no means an expert, but in the tests on
> https://www.mediawiki.org/wiki/Typography_refresh/Font_choice it scored
> exactly the same as Helvetica Neue (both in the good an the bad). Nimbis
> Sans L unfortunately hasn't been part of that test.
>
> -- Windows users always get Arial, unless they have Helvetica installed.
> > This means many of the Windows users who might otherwise have set an
> > alternative sans in their browser default (like Verdana or Tahoma) will
> now
> > always get Arial.
> >
>
> Windows Helvetica seems to be generally a lie, and is not Helvetica but
> "Helvetica" (actually Arial). I don't see overriding a users preference
> with our preference as an advantage. Most people don't change their default
> font in their browser. In those cases it's probably good if we work with
> our preferences instead. If someone put in the effort to set a different
> preferred font probably did that for a reason that we shouldn't override. I
> assumed that we only wanted to override "unset" user preferences, and not
> actually override the settings that users have explicitly ch

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Martijn Hoekstra
On Tue, Apr 8, 2014 at 10:20 PM, Steven Walling wrote:

> On Tue, Apr 8, 2014 at 12:33 PM, Martijn Hoekstra <
> martijnhoeks...@gmail.com
> > wrote:
>
> > On Tue, Apr 8, 2014 at 8:13 PM, Erik Moeller  wrote:
> >
> > > On Tue, Apr 8, 2014 at 10:59 AM, Martijn Hoekstra
> > >  wrote:
> > > > So, the font stack changes with regards to the status quo now change
> > > > nothing for Windows users, changes Helvetica -> Helvetica neue for
> Mac
> > > > users and changes Arial, DejaVu Sans or Arimo for possibly something
> > > else,
> > > > amongst which Nimbus Sans L, maybe, maybe not.
> > >
> > > Actually, it's a bit more complicated. All users get serif fonts for
> > > headings, which they didn't before and which is probably the biggest
> > > visual before/after difference. The serif fonts still prioritize
> > > free/libre fonts over non-free ones.
> > >
> > > The body fonts prioritized free/libre fonts on deployments, but for
> > > Windows users without ClearType/anti-aliasing, those render very
> > > poorly, so they were disabled shortly after deployment. This is now
> > > causing people to be upset because the initial agreement to never
> > > prioritize non-free fonts is no longer maintained for the body.
> > >
> > > Odder's patch would revert to sans-serif as a generic classification
> > > for the body, but doesn't touch the font specification for the headers
> > > (yet). The commit summary is a bit misleading in that regard.
> > >
> >
> > Yes, I should have made that clear: I do very much support the Odder
> > patch[1] ( https://gerrit.wikimedia.org/r/#/c/124475/ ) that reverts
> body
> > to sans serif and keeps @content-heading-font-family: "Linux Libertine",
> > Georgia, Times, serif;
> >
> > That is not the status quo, but the diff between the Odder patch and the
> > typography refresh basically is the "Set a non-free font stack to give
> Mac
> > now Helvetica Neue rather than Helvetica", with a -2 is planted in the
> > ground before as a demarcation line. That's the point that I don't think
> is
> > worth having a non-free font-stack for, and that I certainly think
> standing
> > your ground for the brave new world of typography refresh is constructive
> > for.
> >
>
> This is a persistent myth floating around about this. Neue for Mac users is
> most definitely not the only effect of explicitly declaring the stack. As
> Jared, S Page, and others have already pointed out, and as is stated in the
> FAQ on mediawiki.org, the impact of the current stack is:
>
> -- Linux users get Nimbus Sans L, instead of DejaVu Sans, Liberation Sans,
> or whatever else the default sans is on your distro. Nimbus has an improved
> x-height and is much more consistent with the other sans-serifs we're
> specifying.
>

Unfortunately, we didn't properly test this. With the large diversity in
results of the tests we did do on
https://www.mediawiki.org/wiki/Typography_refresh/Font_choice/Test I doubt
it's a hard rule that Linux users will now universally get Nimbus Sans L.
I'm also not sure that Nimbus Sans L is the superior alternative over
Liberation Sans. I'm by no means an expert, but in the tests on
https://www.mediawiki.org/wiki/Typography_refresh/Font_choice it scored
exactly the same as Helvetica Neue (both in the good an the bad). Nimbis
Sans L unfortunately hasn't been part of that test.

-- Windows users always get Arial, unless they have Helvetica installed.
> This means many of the Windows users who might otherwise have set an
> alternative sans in their browser default (like Verdana or Tahoma) will now
> always get Arial.
>

Windows Helvetica seems to be generally a lie, and is not Helvetica but
"Helvetica" (actually Arial). I don't see overriding a users preference
with our preference as an advantage. Most people don't change their default
font in their browser. In those cases it's probably good if we work with
our preferences instead. If someone put in the effort to set a different
preferred font probably did that for a reason that we shouldn't override. I
assumed that we only wanted to override "unset" user preferences, and not
actually override the settings that users have explicitly chosen. I was
apparently mistaken in that.

-- And yes, Mac users or those with it installed get Neue Helvetica instead
> of older version. This is a minor but worthwhile improvement for Mac users.
> For example, Neue Helvetica actually has properly designed font weights for
> bold, italic, etc. so that the cap height and x-height are consistent
> between weights. Regular Helvetica was really not consistently designed
> across weights.
>
> Declaring some of the system defaults explicitly is not only an improvement
> for Mac users. It means that regardless of whether you switch between
> devices/browsers, you always get a grotesque/neo-grotesque sans-serif (
> https://en.wikipedia.org/wiki/Vox-ATypI_classification) which is ideal for
> reading long, large blocks of text and is more neutral.
>
>
> >
> > [1]My only nitpick about it is th

[Wikitech-l] Fwd: Security precaution - Resetting all user sessions today

2014-04-08 Thread Greg Grossmeier
FYI to this audience as well:

We're reseting all user session tokens today due to heartbleed.

What I didn't state below is that we have already replaced our SSL certs
as well as upgraded to the fixed version of openssl.

- Forwarded message from Greg Grossmeier  -

> Date: Tue, 8 Apr 2014 13:54:26 -0700
> From: Greg Grossmeier 
> To: Wikitech Ambassadors 
> Subject: Security precaution - Resetting all user sessions today
> 
> Yesterday a widespread issue in OpenSSL was disclosed that would allow
> attackers to gain access to privileged information on any site running a
> vulnerable version of that software. Unfortunately, all Wikimedia
> Foundation hosted wikis are potentially affected. 
> 
> We have no evidence of any actual compromise to our systems or our users
> information, but as a precautionary measure we are resetting all user
> session tokens. In other words, we will be forcing all logged in users
> to re-login (ie: we are logging everyone out).
> 
> All logged in users send a secret session token with each request to the
> site and if a nefarious person were able to intercept that token they
> could impersonate other users. Resetting the tokens for all users will
> have the benefit of making all users reconnect to our servers using the
> updated and fixed version of the OpenSSL software, thus removing this
> potential attack. 
> 
> As an extra precaution, we recommend all users change their passwords as
> well.
> 
> 
> Again, there has been no evidence that Wikimedia Foundation users were
> targeted by this attack, but we want all of our users to be as safe as
> possible. 
> 
> 
> Thank you for your understanding and patience, 
> 
> Greg Grossmeier
> 
> 
> -- 
> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |



- End forwarded message -

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |


signature.asc
Description: Digital signature
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Jared Zimmerman
I want to clarify Steven's point, which was mostly clear but I want to make
sure the details and rationale are pointed out.

When mixing serif and san-serif typefaces using any random two font faces
is not acceptable, therefore letting the browser/OS arbitrarily choose any
serif to pair with any san serif isn't acceptable, if we're following any
rules about pairing typefaces. This is a major argument for keeping font
specifications for both body and header, to keep these harmonious.



*Jared Zimmerman * \\  Director of User Experience \\ Wikimedia Foundation

M : +1 415 609 4043 |   :  @JaredZimmerman



On Tue, Apr 8, 2014 at 1:20 PM, Steven Walling wrote:

> On Tue, Apr 8, 2014 at 12:33 PM, Martijn Hoekstra <
> martijnhoeks...@gmail.com
> > wrote:
>
> > On Tue, Apr 8, 2014 at 8:13 PM, Erik Moeller  wrote:
> >
> > > On Tue, Apr 8, 2014 at 10:59 AM, Martijn Hoekstra
> > >  wrote:
> > > > So, the font stack changes with regards to the status quo now change
> > > > nothing for Windows users, changes Helvetica -> Helvetica neue for
> Mac
> > > > users and changes Arial, DejaVu Sans or Arimo for possibly something
> > > else,
> > > > amongst which Nimbus Sans L, maybe, maybe not.
> > >
> > > Actually, it's a bit more complicated. All users get serif fonts for
> > > headings, which they didn't before and which is probably the biggest
> > > visual before/after difference. The serif fonts still prioritize
> > > free/libre fonts over non-free ones.
> > >
> > > The body fonts prioritized free/libre fonts on deployments, but for
> > > Windows users without ClearType/anti-aliasing, those render very
> > > poorly, so they were disabled shortly after deployment. This is now
> > > causing people to be upset because the initial agreement to never
> > > prioritize non-free fonts is no longer maintained for the body.
> > >
> > > Odder's patch would revert to sans-serif as a generic classification
> > > for the body, but doesn't touch the font specification for the headers
> > > (yet). The commit summary is a bit misleading in that regard.
> > >
> >
> > Yes, I should have made that clear: I do very much support the Odder
> > patch[1] ( https://gerrit.wikimedia.org/r/#/c/124475/ ) that reverts
> body
> > to sans serif and keeps @content-heading-font-family: "Linux Libertine",
> > Georgia, Times, serif;
> >
> > That is not the status quo, but the diff between the Odder patch and the
> > typography refresh basically is the "Set a non-free font stack to give
> Mac
> > now Helvetica Neue rather than Helvetica", with a -2 is planted in the
> > ground before as a demarcation line. That's the point that I don't think
> is
> > worth having a non-free font-stack for, and that I certainly think
> standing
> > your ground for the brave new world of typography refresh is constructive
> > for.
> >
>
> This is a persistent myth floating around about this. Neue for Mac users is
> most definitely not the only effect of explicitly declaring the stack. As
> Jared, S Page, and others have already pointed out, and as is stated in the
> FAQ on mediawiki.org, the impact of the current stack is:
>
> -- Linux users get Nimbus Sans L, instead of DejaVu Sans, Liberation Sans,
> or whatever else the default sans is on your distro. Nimbus has an improved
> x-height and is much more consistent with the other sans-serifs we're
> specifying.
> -- Windows users always get Arial, unless they have Helvetica installed.
> This means many of the Windows users who might otherwise have set an
> alternative sans in their browser default (like Verdana or Tahoma) will now
> always get Arial.
> -- And yes, Mac users or those with it installed get Neue Helvetica instead
> of older version. This is a minor but worthwhile improvement for Mac users.
> For example, Neue Helvetica actually has properly designed font weights for
> bold, italic, etc. so that the cap height and x-height are consistent
> between weights. Regular Helvetica was really not consistently designed
> across weights.
>
> Declaring some of the system defaults explicitly is not only an improvement
> for Mac users. It means that regardless of whether you switch between
> devices/browsers, you always get a grotesque/neo-grotesque sans-serif (
> https://en.wikipedia.org/wiki/Vox-ATypI_classification) which is ideal for
> reading long, large blocks of text and is more neutral.
>
>
> >
> > [1]My only nitpick about it is that I'm wondering what Times is doing in
> > that stack. I can't think of any situation where a user wouldn't have
> Linux
> > Libertine or Georgia, but does have Times, yet doesn't have it as its
> > default serif font. When one has specifically set a default serif
> different
> > from Times, you probably have a good reason for it - or at least a better
> > reason than the websites desire for Times, and we should respect that.
> Yet
> > this beef is very small compared to all other issues in this thread.
> >
>
> Times, like setting Helvetica, is there be

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Steven Walling
On Tue, Apr 8, 2014 at 12:33 PM, Martijn Hoekstra  wrote:

> On Tue, Apr 8, 2014 at 8:13 PM, Erik Moeller  wrote:
>
> > On Tue, Apr 8, 2014 at 10:59 AM, Martijn Hoekstra
> >  wrote:
> > > So, the font stack changes with regards to the status quo now change
> > > nothing for Windows users, changes Helvetica -> Helvetica neue for Mac
> > > users and changes Arial, DejaVu Sans or Arimo for possibly something
> > else,
> > > amongst which Nimbus Sans L, maybe, maybe not.
> >
> > Actually, it's a bit more complicated. All users get serif fonts for
> > headings, which they didn't before and which is probably the biggest
> > visual before/after difference. The serif fonts still prioritize
> > free/libre fonts over non-free ones.
> >
> > The body fonts prioritized free/libre fonts on deployments, but for
> > Windows users without ClearType/anti-aliasing, those render very
> > poorly, so they were disabled shortly after deployment. This is now
> > causing people to be upset because the initial agreement to never
> > prioritize non-free fonts is no longer maintained for the body.
> >
> > Odder's patch would revert to sans-serif as a generic classification
> > for the body, but doesn't touch the font specification for the headers
> > (yet). The commit summary is a bit misleading in that regard.
> >
>
> Yes, I should have made that clear: I do very much support the Odder
> patch[1] ( https://gerrit.wikimedia.org/r/#/c/124475/ ) that reverts body
> to sans serif and keeps @content-heading-font-family: "Linux Libertine",
> Georgia, Times, serif;
>
> That is not the status quo, but the diff between the Odder patch and the
> typography refresh basically is the "Set a non-free font stack to give Mac
> now Helvetica Neue rather than Helvetica", with a -2 is planted in the
> ground before as a demarcation line. That's the point that I don't think is
> worth having a non-free font-stack for, and that I certainly think standing
> your ground for the brave new world of typography refresh is constructive
> for.
>

This is a persistent myth floating around about this. Neue for Mac users is
most definitely not the only effect of explicitly declaring the stack. As
Jared, S Page, and others have already pointed out, and as is stated in the
FAQ on mediawiki.org, the impact of the current stack is:

-- Linux users get Nimbus Sans L, instead of DejaVu Sans, Liberation Sans,
or whatever else the default sans is on your distro. Nimbus has an improved
x-height and is much more consistent with the other sans-serifs we're
specifying.
-- Windows users always get Arial, unless they have Helvetica installed.
This means many of the Windows users who might otherwise have set an
alternative sans in their browser default (like Verdana or Tahoma) will now
always get Arial.
-- And yes, Mac users or those with it installed get Neue Helvetica instead
of older version. This is a minor but worthwhile improvement for Mac users.
For example, Neue Helvetica actually has properly designed font weights for
bold, italic, etc. so that the cap height and x-height are consistent
between weights. Regular Helvetica was really not consistently designed
across weights.

Declaring some of the system defaults explicitly is not only an improvement
for Mac users. It means that regardless of whether you switch between
devices/browsers, you always get a grotesque/neo-grotesque sans-serif (
https://en.wikipedia.org/wiki/Vox-ATypI_classification) which is ideal for
reading long, large blocks of text and is more neutral.


>
> [1]My only nitpick about it is that I'm wondering what Times is doing in
> that stack. I can't think of any situation where a user wouldn't have Linux
> Libertine or Georgia, but does have Times, yet doesn't have it as its
> default serif font. When one has specifically set a default serif different
> from Times, you probably have a good reason for it - or at least a better
> reason than the websites desire for Times, and we should respect that. Yet
> this beef is very small compared to all other issues in this thread.
>

Times, like setting Helvetica, is there because it's what Linux systems
recognize and match to. Linux fc-match has no idea what Georgia and Linux
Libertine are unless you've installed them. By setting Times, we ensure
that Linux uses Nimbus Roman No9 L for headings, which complements the body
typeface selected on Linux well and which is consistent in style with the
other serifs specified.

A lot of this stuff is already documented in the FAQ on [[Typography
refresh]] on mediawiki.org. We produced it to answer the basic questions
just like this.


>
>
> >
> > There's some additional discussion about Georgia as a font choice due
> > to its use of text figures (AKA old-style numerals), which some people
> > find look odd in headings with numbers, especially in non-Latin
> > scripts where old-style numerals may not be commonly encountered. Due
> > to this, some are arguing for also changing the style for headings to
> > serif (_not_ sans-

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Jon Robson
Copying and pasting what I wrote on that patchset
"For the record, I'm happy to +2 this if necessary but I still feel
this is a short term crappy solution that doesn't truly promote unfree
fonts as claimed in the commit message (since we are basically saying
in this give non-free Helvetica for Mac users, Arial for Windows users
[1]) and I'd welcome conversation around finding a suitable open font
to make this more explicit and building a font stack that is language
dependent.

Awaiting agreement... but not pulling the trigger.

[1] http://css-tricks.com/sans-serif/";

I really feel like we are making a mountain out of a mole hill here.
This new patch from Odder doesn't truly achieve supporting open fonts
so in my opinion is no different from the existing state of things
apart from leaving things more up to chance.

On Tue, Apr 8, 2014 at 12:38 PM, Erik Moeller  wrote:
> Just a note that Brandon just commented on the patchset:
>
> "We discussed this patch today during our weekly design team meeting
> and how to move forward. At this point in time we are leaning towards
> +2'ing this but we want to have a bit of discussion internally before
> doing so.
>
> We'll have something at the end of the day, so we're asking that no
> one merge it until then."
>
> I think that's a completely reasonable request.
>
> Thanks to everyone who's been speaking up in support of positive
> changes to our typography while also being constructive and critical
> as appropriate. I think one of the cool things about Wikimedia is that
> we're willing to try and experiment even at the risk of causing
> breakage and disruption, but the flip side of that is listening to
> each other and optimizing things together towards the right outcome.
> We've got tons of smart people around the world helping with this,
> which is awesome. As always, I have confidence in our collective
> ability to figure things out :)
>
> Erik
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Erik Moeller
Just a note that Brandon just commented on the patchset:

"We discussed this patch today during our weekly design team meeting
and how to move forward. At this point in time we are leaning towards
+2'ing this but we want to have a bit of discussion internally before
doing so.

We'll have something at the end of the day, so we're asking that no
one merge it until then."

I think that's a completely reasonable request.

Thanks to everyone who's been speaking up in support of positive
changes to our typography while also being constructive and critical
as appropriate. I think one of the cool things about Wikimedia is that
we're willing to try and experiment even at the risk of causing
breakage and disruption, but the flip side of that is listening to
each other and optimizing things together towards the right outcome.
We've got tons of smart people around the world helping with this,
which is awesome. As always, I have confidence in our collective
ability to figure things out :)

Erik
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Martijn Hoekstra
On Tue, Apr 8, 2014 at 8:13 PM, Erik Moeller  wrote:

> On Tue, Apr 8, 2014 at 10:59 AM, Martijn Hoekstra
>  wrote:
> > So, the font stack changes with regards to the status quo now change
> > nothing for Windows users, changes Helvetica -> Helvetica neue for Mac
> > users and changes Arial, DejaVu Sans or Arimo for possibly something
> else,
> > amongst which Nimbus Sans L, maybe, maybe not.
>
> Actually, it's a bit more complicated. All users get serif fonts for
> headings, which they didn't before and which is probably the biggest
> visual before/after difference. The serif fonts still prioritize
> free/libre fonts over non-free ones.
>
> The body fonts prioritized free/libre fonts on deployments, but for
> Windows users without ClearType/anti-aliasing, those render very
> poorly, so they were disabled shortly after deployment. This is now
> causing people to be upset because the initial agreement to never
> prioritize non-free fonts is no longer maintained for the body.
>
> Odder's patch would revert to sans-serif as a generic classification
> for the body, but doesn't touch the font specification for the headers
> (yet). The commit summary is a bit misleading in that regard.
>

Yes, I should have made that clear: I do very much support the Odder
patch[1] ( https://gerrit.wikimedia.org/r/#/c/124475/ ) that reverts body
to sans serif and keeps @content-heading-font-family: "Linux Libertine",
Georgia, Times, serif;

That is not the status quo, but the diff between the Odder patch and the
typography refresh basically is the "Set a non-free font stack to give Mac
now Helvetica Neue rather than Helvetica", with a -2 is planted in the
ground before as a demarcation line. That's the point that I don't think is
worth having a non-free font-stack for, and that I certainly think standing
your ground for the brave new world of typography refresh is constructive
for.

[1]My only nitpick about it is that I'm wondering what Times is doing in
that stack. I can't think of any situation where a user wouldn't have Linux
Libertine or Georgia, but does have Times, yet doesn't have it as its
default serif font. When one has specifically set a default serif different
from Times, you probably have a good reason for it - or at least a better
reason than the websites desire for Times, and we should respect that. Yet
this beef is very small compared to all other issues in this thread.


>
> There's some additional discussion about Georgia as a font choice due
> to its use of text figures (AKA old-style numerals), which some people
> find look odd in headings with numbers, especially in non-Latin
> scripts where old-style numerals may not be commonly encountered. Due
> to this, some are arguing for also changing the style for headings to
> serif (_not_ sans-serif) as a generic classification, or removing
> Georgia from the stack. That particular issue hasn't been discussed in
> detail yet, as far as I can see.
>
> I think the differences of opinion here are not worth a holy war.
> Prioritizing a non-free font before free ones for the _body_ with a
> clear FIXME indicating that this is not a desirable state is IMO only
> marginally different from reverting to sans-serif until we have a
> free/libre font that _can_ be prioritized for the body. So I think
> either outcome should be OK for the short term, and we should focus on
> the longer term question of a good font stack for the body that
> prioritizes free/libre fonts.
>
> Let's not polarize each other too much. All the arguments I've heard
> have been fundamentally reasonable and rational, not just "Change is
> evil". Some people hate the serifs per se, but that's a smaller
> discussion compared to these conversations, which are about
> substantial things that can be reasoned about.
>
> Erik
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] DataStore: progress report

2014-04-08 Thread Max Semenik
Hey, some time passed since the DataStore RFC[1] was approved, and the
code is ready for your consideration: [2]. Your comments will be
highly appreciated!



[1] https://www.mediawiki.org/wiki/Requests_for_comment/DataStore
[2] https://gerrit.wikimedia.org/r/#/c/79029/



-- 
Best regards,
  Max Semenik ([[User:MaxSem]])


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Brian Wolff
On Apr 8, 2014 12:10 PM, "Isarra Yos"  wrote:
>
> On 08/04/14 06:57, S Page wrote:
>>
>> In https://gerrit.wikimedia.org/r/#/c/124475/ (go back to sans-serif)
>> Legoktm claims "There was a consensus that listing only non-free fonts
was
>> not acceptable", that's not my recollection.  Was a bug ever filed?
>>
>> Kaldari valiantly tried to put non-free fonts first, that caused bug
>> 63512.  Now as I understand it, we're back to:
>> * Mac users get Helvetica Neue
>> * Windows users get Arial unless they have Helvetica Neue (unlikely) or
>> Helvetica (I can't reproduce bug 63662)
>> * Linux users get whatever F/OSS font fontconfig supplies for the
>> well-known string "Helvetica", I get Nimbus Sans L
>> * Android users ?? (Nobody responded.)
>
>
> Linux often gets arial. Anyone with wine will probably have it installed,
too, and most will have wine even if they don't use it. It's not
necessarily a particularly good copy, either.

I have wine. However firefox on my linux seems to think Nimbus sans is a
good match for helvetica and displays that. Arial would look much better.

(This is just an aside, if it was only me having font issues, i would suck
it up and get over it. Im concerned with the larger context)

--bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Steven Walling
On Tue, Apr 8, 2014 at 8:10 AM, Isarra Yos  wrote:

> Linux often gets arial. Anyone with wine will probably have it installed,
> too, and most will have wine even if they don't use it. It's not
> necessarily a particularly good copy, either.


With the current stack that won't happen even if the user has downloaded
Arial, because Helvetica comes before Arial in the font-family settings.
Linux systems (you can check this using fc-match
https://en.wikipedia.org/wiki/Fontconfig#Utilities) recognize and try to
match Helvetica first. We specifically put Helvetica there first so Linux
users would always get a good free font they have that is equivalent. For
most users (Ubuntu, Debian) this will be Nimbus Sans L.

Steven
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Erwin Dokter

On 08-04-2014 19:29, Jared Zimmerman wrote:

I don't really have the energy to keep having this conversation, I
appreciate that everyone has taken the time to weigh in on this whatever
you opinion is on the matter.


I am sorry you feel that way. But I have to make one thing clear:

This is not an aestethic issue. This is a *technical* one.

I do appriciate all the work the designers have done and I do believe 
the new typography is in essense very well thought out.


However, its *technical* implementation is severy flawed.

It has caused many non-latin projects to force them to override the 
global font stack in their local CSS to reset it to sans-serif, because 
parts of their site have become unreadable or illegible. That makes this 
a *breaking change*, and as such, *must* be reverted.


I do not accept that there will be a "few" readers left with issues; our 
primary goal is legibility. And if legibility is damaged on a world-wide 
encyclopedia, how can you even *think* about defending a breaking change?


Regards,
--
Erwin Dokter


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Erik Moeller
On Tue, Apr 8, 2014 at 10:59 AM, Martijn Hoekstra
 wrote:
> So, the font stack changes with regards to the status quo now change
> nothing for Windows users, changes Helvetica -> Helvetica neue for Mac
> users and changes Arial, DejaVu Sans or Arimo for possibly something else,
> amongst which Nimbus Sans L, maybe, maybe not.

Actually, it's a bit more complicated. All users get serif fonts for
headings, which they didn't before and which is probably the biggest
visual before/after difference. The serif fonts still prioritize
free/libre fonts over non-free ones.

The body fonts prioritized free/libre fonts on deployments, but for
Windows users without ClearType/anti-aliasing, those render very
poorly, so they were disabled shortly after deployment. This is now
causing people to be upset because the initial agreement to never
prioritize non-free fonts is no longer maintained for the body.

Odder's patch would revert to sans-serif as a generic classification
for the body, but doesn't touch the font specification for the headers
(yet). The commit summary is a bit misleading in that regard.

There's some additional discussion about Georgia as a font choice due
to its use of text figures (AKA old-style numerals), which some people
find look odd in headings with numbers, especially in non-Latin
scripts where old-style numerals may not be commonly encountered. Due
to this, some are arguing for also changing the style for headings to
serif (_not_ sans-serif) as a generic classification, or removing
Georgia from the stack. That particular issue hasn't been discussed in
detail yet, as far as I can see.

I think the differences of opinion here are not worth a holy war.
Prioritizing a non-free font before free ones for the _body_ with a
clear FIXME indicating that this is not a desirable state is IMO only
marginally different from reverting to sans-serif until we have a
free/libre font that _can_ be prioritized for the body. So I think
either outcome should be OK for the short term, and we should focus on
the longer term question of a good font stack for the body that
prioritizes free/libre fonts.

Let's not polarize each other too much. All the arguments I've heard
have been fundamentally reasonable and rational, not just "Change is
evil". Some people hate the serifs per se, but that's a smaller
discussion compared to these conversations, which are about
substantial things that can be reasoned about.

Erik
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Martijn Hoekstra
On Tue, Apr 8, 2014 at 7:29 PM, Jared Zimmerman <
jared.zimmer...@wikimedia.org> wrote:

> I don't really have the energy to keep having this conversation, I
> appreciate that everyone has taken the time to weigh in on this whatever
> you opinion is on the matter.
>
> From Issara...
>  * Windows users got fonts optimised for Windows, and which Windows
>knows well how to render. They may not be free, but /we/ weren't the
>ones prioritising the non-free.
>  * Linux users got whatever (probably free) font their distribution
>provides, for which in all likelihood their fontconfig (rendering
>settings) is also optimised.
>  * Those with cleartype etc off previously had fonts that rendered
>properly or they would not have been using their system with
>cleartype etc off for all this time.
>  * Anyone previously using free fonts, on whatever platform, did not
>have their choices overridden. This also applies to those using
>dyslexic-friendly and other accessibility-oriented fonts.
>
> From S Page
> * Mac users get Helvetica Neue
> * Windows users get Arial unless they have Helvetica Neue (unlikely) or
> Helvetica (I can't reproduce bug 63662)
> * Linux users get whatever F/OSS font fontconfig supplies for the
> well-known string "Helvetica", I get Nimbus Sans L
>
>
> With the changes from Jon's patch removing Arimo and Liberation Sans, the
> current font stack renders very closely to what it was originally for
> Windows, and is improved for Mac and Linux users. For anyone on any
> platform who has made the decision to have helvetica on their machine they
> get an experience which is more consistent across devices, and platforms.
>

So, the font stack changes with regards to the status quo now change
nothing for Windows users, changes Helvetica -> Helvetica neue for Mac
users and changes Arial, DejaVu Sans or Arimo for possibly something else,
amongst which Nimbus Sans L, maybe, maybe not. It's not clear if the linux
change is an improvement, as we have only one test case.

Is that amount of change - effectively changing from Helvetica to Helvetica
neue on Mac and nothing else - really worth defining a non-free font stack
for? Is it even worth the fight over it? Or have we gotten ourselves in a
situation where not backing downhas become more important than the merits
of the discussion. Do you really want to defend the position "We must use a
non-free font stack, because otherwise our Mac users will get Helvetica
rather than Helvetica Neue"?

--Martijn


>
> We said from day one that their might be some issues for a few non-latin
> scripts, and we've reached out to the admins of those sites to help them
> make small tweaks, as of jon's patch no one has provided us with any
> screenshots which highlight the issues that have been mentioned from this
> thread, I would welcome those screenshots as well as comments from users
> fluent in the languages to comment on the matter.
>
> I understand if you "don't like it" there are a lot of things I don't like
> too. Sadly that is a fact of life. Sometimes we don't like thing, sometimes
> we have to learn to get used to things when they change. The thing that
> confuses me, is that someone would go so far as to try to prohibit others
> from doing their job based on their subjective opinion. Do product and
> design people go and -2 developers patches when they don't agree on the
> choices they've made? They do not. Do you know why? Its because we trust
> them to make good decision based on the acceptance of their knowledge of
> their domain. Why is Design different? Why does everyone think they have
> equal say when it comes to aesthetic choices, its a good question, one I
> don't think I'll try to answer here, but I think the gist of it is that
> everyone has opinions, everyone says "I could have done that" whether they
> could or not, whether they did or not.
>
> We try as much as we can, with our limited time, and limited resources to
> validate our decisions in a measurable way. Sometimes this isn't possible,
> sometimes things are immeasurable. Does this mean that we shouldn't do
> them? No, it does not.
>
> The question was asked, why do we spend so much time on this when there are
> other pressing matters to attend to. The answer is simple, because of this
> process, this discourse where every decision is questioned, because a
> process that should take a month takes six. I honestly want to move on to
> tackle other problems, but if everything that my team or the product teams
> work on comes up for a vote, it questioned to this degree, nothing will
> happen, nothing will improve.
>
> I'm tired of fighting over this, I'd like to move on, and moving on does
> not mean going on to the status quo.
>
>
>
>
>
> *Jared Zimmerman * \\  Director of User Experience \\ Wikimedia Foundation
>
> M : +1 415 609 4043 |   :  @JaredZimmerman<
> https://twitter.com/JaredZimmerman>
>
>
>
> On Tue, Apr 8, 2014 at 8:10 AM, Isarra Yos  wrote:
>
> > On 08/04/14

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Tomasz W . Kozlowski
Jared Zimmerman writes:

> I'm tired of fighting over this, I'd like to move on, and moving on does
> not mean going on to the status quo.

The status quo has been thoroughly tested by 400 million viewers a month, for 
46 months (June 2010-March 2014; ); it is a flexible and elegant solution 
that leaves the choice of the exact font up to the reader's software, as 
already explained by Isarra.

I'm tired of having https://gerrit.wikimedia.org/r/#/c/124475/ blocked for no 
good reason at all, when five people have already +1'd (how many other 
patches have you seen like that?). 

Steven has essentially said that we're /temporarily/ reverting to a setting 
that is know to work over his dead body; we don't need you to take the same 
approach, too.

Or, alternatively, please do explain here why setting font-family to "sans-
serif" is disruptive, sub-standard and generally not a bright idea.

Tomasz


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Jared Zimmerman
I don't really have the energy to keep having this conversation, I
appreciate that everyone has taken the time to weigh in on this whatever
you opinion is on the matter.

From Issara...
 * Windows users got fonts optimised for Windows, and which Windows
   knows well how to render. They may not be free, but /we/ weren't the
   ones prioritising the non-free.
 * Linux users got whatever (probably free) font their distribution
   provides, for which in all likelihood their fontconfig (rendering
   settings) is also optimised.
 * Those with cleartype etc off previously had fonts that rendered
   properly or they would not have been using their system with
   cleartype etc off for all this time.
 * Anyone previously using free fonts, on whatever platform, did not
   have their choices overridden. This also applies to those using
   dyslexic-friendly and other accessibility-oriented fonts.

From S Page
* Mac users get Helvetica Neue
* Windows users get Arial unless they have Helvetica Neue (unlikely) or
Helvetica (I can't reproduce bug 63662)
* Linux users get whatever F/OSS font fontconfig supplies for the
well-known string "Helvetica", I get Nimbus Sans L


With the changes from Jon's patch removing Arimo and Liberation Sans, the
current font stack renders very closely to what it was originally for
Windows, and is improved for Mac and Linux users. For anyone on any
platform who has made the decision to have helvetica on their machine they
get an experience which is more consistent across devices, and platforms.

We said from day one that their might be some issues for a few non-latin
scripts, and we've reached out to the admins of those sites to help them
make small tweaks, as of jon's patch no one has provided us with any
screenshots which highlight the issues that have been mentioned from this
thread, I would welcome those screenshots as well as comments from users
fluent in the languages to comment on the matter.

I understand if you "don't like it" there are a lot of things I don't like
too. Sadly that is a fact of life. Sometimes we don't like thing, sometimes
we have to learn to get used to things when they change. The thing that
confuses me, is that someone would go so far as to try to prohibit others
from doing their job based on their subjective opinion. Do product and
design people go and -2 developers patches when they don't agree on the
choices they've made? They do not. Do you know why? Its because we trust
them to make good decision based on the acceptance of their knowledge of
their domain. Why is Design different? Why does everyone think they have
equal say when it comes to aesthetic choices, its a good question, one I
don't think I'll try to answer here, but I think the gist of it is that
everyone has opinions, everyone says "I could have done that" whether they
could or not, whether they did or not.

We try as much as we can, with our limited time, and limited resources to
validate our decisions in a measurable way. Sometimes this isn't possible,
sometimes things are immeasurable. Does this mean that we shouldn't do
them? No, it does not.

The question was asked, why do we spend so much time on this when there are
other pressing matters to attend to. The answer is simple, because of this
process, this discourse where every decision is questioned, because a
process that should take a month takes six. I honestly want to move on to
tackle other problems, but if everything that my team or the product teams
work on comes up for a vote, it questioned to this degree, nothing will
happen, nothing will improve.

I'm tired of fighting over this, I'd like to move on, and moving on does
not mean going on to the status quo.





*Jared Zimmerman * \\  Director of User Experience \\ Wikimedia Foundation

M : +1 415 609 4043 |   :  @JaredZimmerman



On Tue, Apr 8, 2014 at 8:10 AM, Isarra Yos  wrote:

> On 08/04/14 06:57, S Page wrote:
>
>> In https://gerrit.wikimedia.org/r/#/c/124475/ (go back to sans-serif)
>> Legoktm claims "There was a consensus that listing only non-free fonts was
>> not acceptable", that's not my recollection.  Was a bug ever filed?
>>
>> Kaldari valiantly tried to put non-free fonts first, that caused bug
>> 63512.  Now as I understand it, we're back to:
>> * Mac users get Helvetica Neue
>> * Windows users get Arial unless they have Helvetica Neue (unlikely) or
>> Helvetica (I can't reproduce bug 63662)
>> * Linux users get whatever F/OSS font fontconfig supplies for the
>> well-known string "Helvetica", I get Nimbus Sans L
>> * Android users ?? (Nobody responded.)
>>
>
> Linux often gets arial. Anyone with wine will probably have it installed,
> too, and most will have wine even if they don't use it. It's not
> necessarily a particularly good copy, either.
>
>
>  quoting Isarra Yos
>>
>>
>>  Given that no objective and verifiable issues with this were ever
>>> provided
>>> ... Why? All this effort, and for what?
>>>
>>>  BECAUSE DESIGN. (I begged

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Isarra Yos

On 08/04/14 06:57, S Page wrote:

In https://gerrit.wikimedia.org/r/#/c/124475/ (go back to sans-serif)
Legoktm claims "There was a consensus that listing only non-free fonts was
not acceptable", that's not my recollection.  Was a bug ever filed?

Kaldari valiantly tried to put non-free fonts first, that caused bug
63512.  Now as I understand it, we're back to:
* Mac users get Helvetica Neue
* Windows users get Arial unless they have Helvetica Neue (unlikely) or
Helvetica (I can't reproduce bug 63662)
* Linux users get whatever F/OSS font fontconfig supplies for the
well-known string "Helvetica", I get Nimbus Sans L
* Android users ?? (Nobody responded.)


Linux often gets arial. Anyone with wine will probably have it 
installed, too, and most will have wine even if they don't use it. It's 
not necessarily a particularly good copy, either.



quoting Isarra Yos



Given that no objective and verifiable issues with this were ever provided
... Why? All this effort, and for what?


BECAUSE DESIGN. (I begged and pleaded with the talented designers who work
next to me to put something emphatic in the Typography refresh FAQ.) It's a
better design. It makes MediaWiki web sites look better for millions of our
users by mentioning proprietary fonts that 90+% of them have. That's not
"objective and verifiable", it just is. Is it worth mentioning non-free
fonts?  People disagree. But I'm saddened by the implicit and overt
hostility towards the art of design here ("its debatable whether this
actually represents "progress"", "it seems like things have shifted more to
managers at WMF make the decisions", etc.).


Saying something is 'better' doesn't make it so. There are real reasons 
behind why anything is better than something else, or it would not be 
better. Even art in general is not purely subjective; if it were, we 
wouldn't hire artists and designers at all because it would be just as 
subjective to them and everyone would have different views and it'd just 
be hopeless.


Good design is good because it plays to the way our brains work. Even 
without a background in neuroscience, artists and designers learn over 
time what works and why, and they often take classes to enumerate the 
concepts as well. These are concepts they should be referring to here, 
things about the composition, the contrast, the use of space, the 
interplay between the colours. You can't just say this painting did this 
'because design' and expect anyone to take you seriously. You can, 
however, say that the added negative space helps to emphasise the 
subject, drawing attention away from that place in the background where 
someone punched a hole through the canvas. They may still not take you 
seriously because then they know you punched a hole in the canvas, but 
it's a real, understandable reason.


But there's more that needs to go into something like this beyond just 
the general principles of design - this isn't a painting, but a thing 
that people use. So what of the users themselves? What of the languages 
that it will be in, the disabilities that need to be accommodated, the 
hardware on which it will be displayed, the software that will be 
rendering it to the end user, and the principles we uphold? How is it 
better in these respects, and for these?


'Just is' doesn't fly. There is so much more to design than that, and to 
suggest otherwise discredits those who make it their passion.


-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Erwin Dokter

On 08-04-2014 03:25, Steven Walling wrote:


I totally agree. I don't see how there is any indication this is
functionally broken or a major regression across languages, keeping in mind
the necessity of ULS et al still. What major language-related bugs have
been raised that would not be present regardless for most default
sans-serifs?

I see some cases, such as CJK, where users may not prefer the serif
headings...


I know that Japanese Wikipedia has reset [1] their font stack entirely 
one day after the refresh.


[1] 
https://ja.wikipedia.org/w/index.php?title=MediaWiki:Vector.css&diff=51273586&oldid=46047818


Regards,
--
Erwin Dokter


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Erwin Dokter

On 08-04-2014 05:01, Ori Livneh wrote:


Erwin, can you help me understand what is a "suitable localization
mechanism"? I filed bug 59983 ("Investigate noto font as potential
replacement for diverse font families") back in January because I thought
it could help with localization, so I'd really like to grok this.


Dumping Noto in the main font stack is not going to work as each Noto 
font is geared toward displaying a specific script. What I mean by 
'mechanism' is not unlike ULS webfonts, which serves the appropriate 
font depending on the user agents requested language.


Noto is unsuitable in the context of this typography refresh (unless the 
refresh itrself will incorporate a similair mechanism).


Regards,
--
Erwin Dokter


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Brian Wolff
On 4/8/14, S Page  wrote:
> In https://gerrit.wikimedia.org/r/#/c/124475/ (go back to sans-serif)
> Legoktm claims "There was a consensus that listing only non-free fonts was
> not acceptable", that's not my recollection.  Was a bug ever filed?
>
> Kaldari valiantly tried to put non-free fonts first, that caused bug
> 63512.  Now as I understand it, we're back to:
> * Mac users get Helvetica Neue
> * Windows users get Arial unless they have Helvetica Neue (unlikely) or
> Helvetica (I can't reproduce bug 63662)
> * Linux users get whatever F/OSS font fontconfig supplies for the
> well-known string "Helvetica", I get Nimbus Sans L
> * Android users ?? (Nobody responded.)
>
> quoting Isarra Yos
>
>
>> Given that no objective and verifiable issues with this were ever provided
>> ... Why? All this effort, and for what?
>>
>
> BECAUSE DESIGN. (I begged and pleaded with the talented designers who work
> next to me to put something emphatic in the Typography refresh FAQ.) It's a
> better design. It makes MediaWiki web sites look better for millions of our
> users by mentioning proprietary fonts that 90+% of them have. That's not
> "objective and verifiable", it just is. Is it worth mentioning non-free
> fonts?  People disagree. But I'm saddened by the implicit and overt
> hostility towards the art of design here ("its debatable whether this
> actually represents "progress"",

How is that hostile to the "art of design". I have no problem with
what the typo refresh project set out to do. I have a problem with
what it actually did. I'm totally fine with the "art of design" as an
abstract idea and I agree with 3 of the 4 stated requirements of Typo
refresh (neutral on the consistency requirement).

> "it seems like things have shifted more to
> managers at WMF make the decisions", etc.).

To clarify I never said that was necessarily a bad thing. Maybe it is,
maybe it isn't. All I'm saying is that seems to be the direction we're
heading. Heck in the context I was arguing for the side of typography
refresh...

--bawolff

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Federico Leva (Nemo)
(5) is the only serious option. Steven, you're being unnecessarily 
negative, nobody is proposing a revert. We can keep "serif" for headers 
in core (but not Georgia and Times because they were catastrophic). 
That's progress.


Nemo

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Martijn Hoekstra
On Apr 8, 2014 3:46 AM, "Steven Walling"  wrote:
>
> On Mon, Apr 7, 2014 at 5:40 PM, MZMcBride  wrote:
>
> > I've read through this thread and I've formulated two questions:
> >
> > * Is there consensus to specify "font-family: 'Helvetica Neue',
Helvetica,
> > Arial, sans-serif;" in MediaWiki core?
> >
>
> I am going to be annoying and answer your question with a question:
> consensus among who? How do make a decision like this?
>
> On the one hand, you have Wikimedia users, who don't really care about the
> appearance of promoting FOSS or not. They just want to things to work and
> look good. They also believe that the only consensus that matters is the
> one on their local wiki. They could honestly care less what the
> conglomeration of volunteer and staff developers think their internal
> consensus is. And mostly, even when something is a consensus decision
based
> on an RFC/discussion, the Wikimedia Foundation gets the blame (as we
> should).

Is the above the group amongst who you think there is consensus to go with
font stack "font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif;" ?
It seems a rather nebulous group. Are you sure there is consensus amongst
them, or could it reflect wishful thinking of what you're pretty sure they
must agree with.

Also, I doubt that this entire group doesn't care about specifying non free
fonts. If you hand-wave the group that does away, that leads to circular
reasoning that the group that doesn't care about specifying non free fonts
really doesn't care if non free fonts are specified. That doesnt tell us
much.

I'm starting to doubt there is any group of people that you're not willing
to dismiss the opinion of because the have the wrong opinion and we
shouldn't listen to them on the issue of non free fonts.

>
> On the other hand, we have MediaWiki developers, some of whom would rather
> throw up their hands and not specify a real font stack, rather than touch
> the non-free fonts *most users already have* with a ten foot pole. They
> seem to think that an RFC or discussion on Wikitech-l is what represents a
> consensus that must be respected. And they don't feel responsible for what
> gets released on Wikimedia sites necessarily.
>
> We can gain more consistent, accessible typography across languages with
an
> iterative approach that continues to build on what we've done over the
last
> five months. Or we can go back to the drawing board to try and please
> everyone, which is an impossibility if you ever want to make progress.
>
>
> > * Is there an issue with specifying "font-family: sans-serif;" in
> > MediaWiki core?
> >
>
> Do you mean just for body type as Odder proposed in
> https://gerrit.wikimedia.org/r/#/c/124475/, or for everything?
>
> Steven
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l