Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?

[Tim Starling]

On 30/10/13 11:37, Ryan Kaldari wrote:
> Regarding Nimbus Sans: Does anyone know how I can get this font without
> installing all of Ghostscript?

apt-get install gsfonts



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

Re: [Wikitech-l] Google Code-in: are you in?

[Aarti K. Dwivedi]

>add tasks *AND* volunteer for mentoring"

I agree it makes tasks easier, and I will be mentoring all the tasks I
propose and any
other tasks if I ca. Thanks a lot! :)


On Tue, Oct 29, 2013 at 11:16 PM, Andre Klapper wrote:

> Hi,
>
> On Tue, 2013-10-29 at 21:58 +0530, Aarti K. Dwivedi wrote:
> > Most probably I am late but can we still add tasks or volunteer for
> > mentoring?
>
> Thanks for your interest! Yes you can, and they are welcome!
> However I'd turn that into "add tasks *AND* volunteer for mentoring",
> because having potential mentor(s) already defined for a task makes
> planning way easier.  :)
>
> andre
> --
> Andre Klapper | Wikimedia Bugwrangler
> http://blogs.gnome.org/aklapper/
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



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

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?

[S Page]

On Tue, Oct 29, 2013 at 4:07 PM, Matthew Flaschen

I set up http://jsfiddle.net/UPBUH/ as a quick testing ground.

Nice, I tweaked it to make
http://jsfiddle.net/UPBUH/7/, you can
see what your browser + O.S. picks for each font name in the font
stack.

 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 get the same.
FWIW Chromium does something different for me, it's matching Helvetica but
not using Nimbus Sans L. something more like Liberation Sans.

>
>  we're saying we want to use that free font (because it's a free, and fits
> our intended design well).
>
If it's as good or better than Helvetica Neue, I think everyone agrees the
free font should come first. Yo, designers...? I think Quim goes further to
argue our sans-serif font list should be
   "Nimbus Sans L", "Liberation Sans", sans-serif
I have no idea what that font stack does on Windows/Mac/iOS/Android. It's
the last thing in http://jsfiddle.net/UPBUH/7/ , can people report back?

Kaldari:
"Nimbus Sans L" is the files n019003l.{afm,pfb,pfm} in
http://packages.ubuntu.com/saucy/all/gsfonts/download , the command to
extract one file is
   $ dpkg --fsys-tarfile /path/to/gsfonts_blahblah.deb | tar xOf -
./usr/share/fonts/type1/gsfonts/n019003l.pfb > /tmp/NimbusSansL.pfb
and I sent the files to you on a 3 1/2" floppy ☺

Cheers,
-- 
=S Page  Features engineer
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?

[Ryan Kaldari]

>Proprietary fonts are copyrighted (dubiously though) not patented.

Actually this is quite complicated. In the U.S., Japan, and some other
countries, typefaces cannot be copyrighted. However, specific font
implementations of typefaces can. So for, example, someone could release a
free license Helvetica within the U.S. and it would not infringe any
copyrights (within the U.S.). Typefaces can be protected by design patents
and trademarks within the U.S., however.

Regarding Nimbus Sans: Does anyone know how I can get this font without
installing all of Ghostscript?

Ryan Kaldari


On Tue, Oct 29, 2013 at 5:06 PM, Daniel Friesen
wrote:

> On 2013-10-29 4:47 PM, Quim Gil wrote:
> > On 10/29/2013 03:30 PM, S Page wrote:
> > > Removing them would be detrimental for most of our users.
> >
> > Detrimental... they would still be able to access all our content and
> > functionality without losing a single readable character, right? A lot
> > less "detrimental" than not serving them conveniently mp3, mpeg,
> > flash, Facebook/Twitter/Google login, and other proprietary options
> > already installed in your average Mac / Windows desktop that we
> > decided not to support.
> To be fair I'd like to point out that mp3 and mpeg require WMF to encode
> and serve freely licensed content in patented formats (which also have
> some legal issues). Flash requires WMF to author and serve stuff
> directly in a proprietary format. And Facebook/Twitter/Google login
> require WMF sites to be connected server-side to and dependent on
> proprietary 3rd party websites.
>
> Proprietary fonts are copyrighted (dubiously though) not patented. WMF
> is not serving any 3rd party data that is proprietary or not openly
> licensed. And the openly licensed content itself is still served in a
> single open non-proprietary format to everyone.
> The only place open vs. non-free comes into account is on the reader's
> own computer. Which is very different from the other situations listed
> where open vs. non-free is on WMF's end.
>
> ~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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] $wgRedactedFunctionArguments

[Ori Livneh]

On Tue, Oct 29, 2013 at 6:55 AM, Dan Andreescu  wrote:
>> I don't think the idea here was to ever make the stack traces *safe*,
>> just to redact the most obvious things to reduce the risk if someone
>> carelessly posts a stack trace publicly.
>>
>> Personally, I think the "Java model" as exemplified in
>> https://gerrit.wikimedia.org/r/#/c/92334/ PS3 goes too far in the
>> other direction. In this case, an option to log unredacted traces that
>> I could enable on my local test wiki would be useful.
>
>
> I think Ori's original point stands though.  Configuration could be used to
> redact fully / not redact at all for local debugging purposes.  But a black
> list for what to redact is bad for all the reasons black lists are bad
> security in general.

I think the approach we are converging on is this:

- Always redact all argument values for user-facing backtraces
- Never redact any argument values for wfDebugLog()'d backtraces
- Redact arguments by replacing each argument with the name of its
class (if object) or type (if primitive).

The redacted traces look like this:

#0 /vagrant/mediawiki/extensions/Vector/Vector.hooks.php(82):
functionThatFails(OutputPage)
#1 [internal function]: VectorHooks::beforePageDisplay(string, string)
#2 /vagrant/mediawiki/includes/Hooks.php(199):
call_user_func_array(string, array)
#3 /vagrant/mediawiki/includes/GlobalFunctions.php(3877):
Hooks::run(string, array)
#4 /vagrant/mediawiki/includes/OutputPage.php(2075): wfRunHooks(string, array)
#5 /vagrant/mediawiki/includes/Wiki.php(610): OutputPage->output()
#6 /vagrant/mediawiki/includes/Wiki.php(467): MediaWiki->main()
#7 /vagrant/mediawiki/index.php(49): MediaWiki->run()
#8 {main}

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

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?

[Daniel Friesen]

On 2013-10-29 4:47 PM, Quim Gil wrote:
> On 10/29/2013 03:30 PM, S Page wrote:
> > Removing them would be detrimental for most of our users.
>
> Detrimental... they would still be able to access all our content and
> functionality without losing a single readable character, right? A lot
> less "detrimental" than not serving them conveniently mp3, mpeg,
> flash, Facebook/Twitter/Google login, and other proprietary options
> already installed in your average Mac / Windows desktop that we
> decided not to support.
To be fair I'd like to point out that mp3 and mpeg require WMF to encode
and serve freely licensed content in patented formats (which also have
some legal issues). Flash requires WMF to author and serve stuff
directly in a proprietary format. And Facebook/Twitter/Google login
require WMF sites to be connected server-side to and dependent on
proprietary 3rd party websites.

Proprietary fonts are copyrighted (dubiously though) not patented. WMF
is not serving any 3rd party data that is proprietary or not openly
licensed. And the openly licensed content itself is still served in a
single open non-proprietary format to everyone.
The only place open vs. non-free comes into account is on the reader's
own computer. Which is very different from the other situations listed
where open vs. non-free is on WMF's end.

~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] [Design] Should MediaWiki CSS prefer non-free fonts?

[Quim Gil]

On 10/29/2013 03:30 PM, S Page wrote:

Quim:

And if we want to specify any fonts in our works, they should be free.

Uh, why?  Mac users actually have Helvetica Neue, the nicest-looking
font, Windows users have Georgia. The presence of these names in our CSS
does nothing to hinder the cause of free fonts.


Yes, it does hinder the cause of free fonts. We won't help scratching 
the itch because in practice we will rely on a proprietary solution for 
our UX work targeting the majority of users. While not forcing anybody 
to use free fonts, our mockups, tests, reviews, screenshots and what not 
will all assume the happy coincidence that Helvetica Neue ("the most 
ubiquitous in advertising copy and logos") and Georgia (Microsoft 
Corporation) are everywhere.


Now compare with this hypothetical scenario: we actually bet on a set of 
optional free fonts, because we care about typography as much as we care 
about freedom. We use them as default in our mockups, tests, reviews, 
screenshots and what not. We serve them as web fonts, we bundle them in 
our apps and offline versions, we promote them to the users missing them 
in their systems. We take note of our own itches and user feedback, and 
we file bugs and enhancement requests upstream, or send/commission 
improvements. This way we contribute spreading free typography, just 
like we contribute spreading other areas of free knowledge, free culture 
and free software.


> Removing them would be detrimental for most of our users.

Detrimental... they would still be able to access all our content and 
functionality without losing a single readable character, right? A lot 
less "detrimental" than not serving them conveniently mp3, mpeg, flash, 
Facebook/Twitter/Google login, and other proprietary options already 
installed in your average Mac / Windows desktop that we decided not to 
support.


If the above scenario to improve the MediaWiki/Wikimedia UX by improving 
free fonts is not exciting, or a priority, then at least we could be 
neutral and not promote actively any proprietary font either.


--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

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

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?

[Daniel Friesen]

On 2013-10-29 4:25 PM, Matthew Flaschen wrote:
> On 10/29/2013 07:14 PM, Daniel Friesen wrote:
>>> The extremely few users who manually customize their font-matching can
>>> still override e.g. what "Nimbus Sans L" points to on their machine.
>> You're basically suggesting that users who have customized their
>> browsers/OS to handle the patterns used on the majority of the internet
>> – many who may have done a C&P from a tutorial and actually know nothing
>> about the config itself – re-customize their browser/OS to support one
>> website/organization.
>
> Do you really think a significant number of users have manually
> customized (even by copy-and-pasting commands) the font-matching on
> their machine?
>
> I think that is a small minority, much less even than those who
> customized their browser's serif or sans-serif fonts (itself small in
> relative terms).
>
> Matt Flaschen
I might agree if there were some tangible benefit to breaking things for
those few users. But the only rationale so far for practically breaking
visual improvements which even a few readers may have done by explicitly
naming open fonts is some vague sense of FOSS idealism that dosen't
provide a single practical improvement for any reader since it doesn't
actually change the fonts used by the default OS config readers use.

It basically harasses FOSS users with local customizations to do
something that doesn't provide any benefits for other FOSS users. I see
nothing but a net loss.

~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] [Design] Should MediaWiki CSS prefer non-free fonts?

[Matthew Flaschen]

On 10/29/2013 07:14 PM, Daniel Friesen wrote:

The extremely few users who manually customize their font-matching can
still override e.g. what "Nimbus Sans L" points to on their machine.

You're basically suggesting that users who have customized their
browsers/OS to handle the patterns used on the majority of the internet
– many who may have done a C&P from a tutorial and actually know nothing
about the config itself – re-customize their browser/OS to support one
website/organization.


Do you really think a significant number of users have manually 
customized (even by copy-and-pasting commands) the font-matching on 
their machine?


I think that is a small minority, much less even than those who 
customized their browser's serif or sans-serif fonts (itself small in 
relative terms).


Matt Flaschen


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

Re: [Wikitech-l] [QA] Welcome, Rummana Yasmeen

[James Forrester]

On 29 October 2013 17:04, Rob Lanphier  wrote:

> 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.


​Welcome, Rummana - great to have you on the team.

J.​
-- 
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

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

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?

[Daniel Friesen]

On 2013-10-29 4:07 PM, Matthew Flaschen wrote:
>> 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.
You're basically suggesting that users who have customized their
browsers/OS to handle the patterns used on the majority of the internet
– many who may have done a C&P from a tutorial and actually know nothing
about the config itself – re-customize their browser/OS to support one
website/organization.

~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] Welcome, Rummana Yasmeen

[Matthew Flaschen]

On 10/29/2013 06:04 PM, Rob Lanphier wrote:

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.


Welcome aboard!  Manual testing is an important complement to automated 
testing.


Matt Flaschen


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

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?

[Matthew Flaschen]

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

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

Re: [Wikitech-l] [QA] Welcome, Rummana Yasmeen

[Chris McMahon]

On Tue, Oct 29, 2013 at 4:04 PM, Rob Lanphier  wrote:

> 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.


It is really great to have someone not only to scrutinize the behavior of
VisualEditor in different browsers, different environments, etc. etc., but
also to help out with bug triage, communicating information about current
issues, and all the human side of software testing.

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

[Wikitech-l] Welcome, Rummana Yasmeen

[Rob Lanphier]

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
ryasm...@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")

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

[Wikitech-l] Localizing site names displayed RelatedSites extension

[Eugene Zelenko]

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.

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

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?

[Brandon Harris]

They are different fonts from different font families, not members of 
the same family, and Helvetica is far, far more common than Helvetica Neue.


On Oct 29, 2013, at 10:13 AM, Steven Walling  wrote:

> 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?

---
Brandon Harris, Senior Designer, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate


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

Re: [Wikitech-l] [Design] Are external link icons useful

[Brion Vibber]

A few background notes:

* The generic external link icon is applied by virtual of existence of the
'external' class, which is a nice simple implementation. I kinda like it. :)

* In contrast, the CSS rules used to mark certain external links with the
PDF, IRC, SSL, etc "specific" icon types are relatively ugly and hard to
maintain. These use inefficient client-side attribute value matching. There
is a desire to clean these up in the style sheets, which would of course be
easiest if they're simply removed.

* If it's useful to keep those subtypes, it may be more desirable to
implement them differently (for instance by having the parser apply the
matching rules and output a class). This would simplify the CSS rules for
maintenance, since they would be able to just use the classes.

* Note that some of the rules such as PDF detection can misidentify
resource types (for instance the rules would mark a File:Blah.pdf file
*page* on Commons as "PDF" even though it's not actually a PDF download,
but an HTML web page). This would not necessarily change under the above
proposal to change implementation, as the basic problem is that you can't
really reliably determine a file type from a "file extension" on a URL (the
only real way to check is to try fetching the resource, or at least its
HTTP headers, and report back what type was received).

-- brion


On Tue, Oct 29, 2013 at 1:11 PM, Quiddity  wrote:

> As Bartosz says, and I think most of the communities would agree if asked
> on their respective village pumps - we value the external link icon in
> particular, and most of the other icons in general (with the possible
> exception of the https padlock). We think they are useful for both editors
> and readers.
>
> Re: Gadget - This isn't a particular workflow - this is:
> "I'm reading a random article, and I notice an external link icon, so, as
> a wikignome, I either: (if spam) remove it, (if citation) fix it, (if
> [subjective decision about its relevance/worth and adherence to [[WP:EL]]
> guideline) move it into the External links section."
> A gadget would not be a good replacement.
>
> By all means clean up the CSS, but do not consider removing the icons
> without seeking much much wider input.
>
>
>
> On 13-10-29 11:57 AM, Jared Zimmerman wrote:
>
>> Nick, good points, for the particular use case sounds like a gadget for
>> showing external links called out for workflows around fixing them would
>> be a good idea. After hearing everyone's thought i'm leaning toward no
>> icons for the average user.
>>
>> *
>> *
>> *
>> *
>> *Jared Zimmerman *\\Director of User Experience \\Wikimedia Foundation
>> M : +1 415 609 4043 | : @JaredZimmerman > JaredZimmerman >
>>
>>
>>
>>
>> On Tue, Oct 29, 2013 at 11:41 AM, quiddity > > wrote:
>>
>> +1 for more discussion, and onwiki discussion to find out why
>> we/they've each kept them in the individual CSS payloads for so many
>> years...
>>
>>
>> On 10/24/2013 02:48 PM, Jared Zimmerman wrote:
>>
>>> Its  definitely a less heavy handed way of doing
>>> the thing many (annoying) sites do when they warn
>>> you that you're leaving their site. I just wonder
>>> is the signal to noise it worth it. I don't know
>>> that modern web users have any expectations that
>>> link within a site always point to local site urls.
>>>
>>>
>> Wikis are special, in relation to most sites, because of the density
>> of internal links (many per paragraph), and the expectation that
>> most links are internal and will lead to a similar quality/style of
>> information. That applies from Wikisource, to Wookiepedia.
>>
>> In wikis that don't mix external links in the main content (eg most
>> Wikipedias), the icons are also useful /for editors/ as they can
>>
>> easily notice that something needs to be moved/fixed.
>>
>> See 
>> https://en.wikipedia.org/wiki/**Help:External_link_iconsfor
>>  a
>> good list of what the English Wikipedia has.
>>
>> See also recent discussion at
>> 
>> https://bugzilla.wikimedia.**org/show_bug.cgi?id=54604("Ridiculous
>> amount of CSS rules for external links")
>>
>>
>> The only icon that seems (afaik) completely unnecessary, and
>> bright/distracting, is the https padlock, which possibly
>> could/should be replaced with the standard external link icon.
>> (Unless there's a rationale for it that I'm forgetting/unaware of.)
>>
>> See this 2009 discussion where Davidgothberg created a blue (less
>> distracting) replacement, if we need to keep a padlock for some
>> reason.
>> https://en.wikipedia.org/wiki/**MediaWiki_talk:Common.css/**
>> Archive_11#Sec

Re: [Wikitech-l] RC for Mediawiki 1.22: 1.22.0rc0

[Bartosz Dziewoński]

I'll take this opportunity to remind everyone that there are currently still 18 
open bugs targeted for 1.22, 11 of them with patches awaiting review, and at 
least 2 being 1.22 cycle regressions (both have patches pending).

https://bugzilla.wikimedia.org/buglist.cgi?quicksearch=milestone%3A22

--
Matma Rex

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

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?

[Daniel Friesen]

On 2013-10-29 1:13 PM, Steven Walling wrote:
>
> On Tue, Oct 29, 2013 at 12:51 PM, Jared Zimmerman
> mailto:jared.zimmer...@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?
From my memory there were versions of OSX that had Helvetica but not
Helvetica Neue. Hence `"Helvetica Neue", "Helvetica"` will pick the best
Helvetica available for the computer.

Makes sense since Helvetica Neue was an iteration that was created later
than Helvetica.

~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

[Wikitech-l] RC for Mediawiki 1.22: 1.22.0rc0

[Mark A. Hershberger]

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-NOTES-1.22
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.gz.sig
http://download.wikimedia.org/mediawiki/1.22/mediawiki-1.22.0rc0.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

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

Re: [Wikitech-l] [Design] Should MediaWiki CSS prefer non-free fonts?

[Steven Walling]

On Tue, Oct 29, 2013 at 12:51 PM, Jared Zimmerman <
jared.zimmer...@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/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?

[Quim Gil]

As one that started of participated in this discussion in many "back
corners"...

On 10/27/2013 09:50 AM, Chad wrote:

Our ideologies are far more important than typography.


We bet on free licenses for all the content and software we produce, 
even if sometimes potentially superior "free as in beer" alternatives 
are available. We systematically bet on free as in freedom content, file 
formats and programs not only because they are free, but also because by 
using them we contribute to their promotion, consolidation and success.


I personally don't see a reason to sacrifice this consistency in order 
to use and advertise a proprietary typeface because it looks better 
today in certain displays.



I agree with Kaldari and Brandon earlier: serif, sans-serif, monospace.


+1.

And if we want to specify any fonts in our works, they should be free. 
Why would we need to start our own foundry from scratch? There are many 
free typefaces, more and better every year. Google has done a big 
investment and as a result Android ships with free fonts only, and they 
host a huge repository of free webfonts. Even Adobe publishes pretty 
decent free fonts these days. The trend is clear, we are not in 2003 
anymore. I don't see why we have to go in a different direction instead 
of supporting the trend of free fonts explicitly or, at least, stay 
neutral (serif, sans-serif, monospace).


--
Quim Gil
Technical Contributor Coordinator @ 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] Should MediaWiki CSS prefer non-free fonts?

[Matthew Flaschen]

On 10/28/2013 07:43 AM, Liangent wrote:

btw. Be aware of internationalization issues: not to say that fonts are
usually tied to a (group of) alphabets. Even digits can be affected by the
language info of the context they live.

See [1]: this is the standard English Wikipedia signup screen, and [2]:
with ?uselang=zh-cn added.

[1] http://imagebin.org/275031
[2] http://imagebin.org/275032


Just for the record, neither of those are Georgia.  They have both been 
substituted/fallbacked.  Georgia has very recognizable numbers since 
they shift on the baseline.  See the right column of 
https://www.mediawiki.org/wiki/File:Account-Creation-Mockup-ByTheNumbers.png


It is indeed interesting that the system uses different fonts based on 
the language, even for the numerals.  The Chinese one isn't even a 
serif, although 'serif' is the last in the stack.


Matt Flaschen


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

Re: [Wikitech-l] Should MediaWiki CSS prefer non-free fonts?

[Matthew Flaschen]

On 10/27/2013 03:37 PM, Steven Walling wrote:

Many FOSS communities have dealt with the trade off between great-looking
fonts and freedom by commissioning foundries to get their own free fonts.
See also: Ubuntu, Android, and more. I've talked to the design team about
this idea, including perhaps getting a foundry to donate a unique font
stack in exchange for the publicity they'd get.


Do we really need our own, or are there already quality free fonts we 
can list?  Has the design team taken a good look at the existing free fonts?


My general position is that it is not a violation of our principles to 
list a proprietary font in the stack.  However, we should never 
*distribute* such a font.


I would prefer that free fonts appear first, and that is more workable 
if we can find good free fonts that suit our design needs.  We should 
also ensure that the interface does not look worse in the future than it 
does today, when using free fonts.


Also, remember that font-matchers may substitute a free font when they 
are given a proprietary font name.


Matt Flaschen

CCing design

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

Re: [Wikitech-l] Filtering out bugs that wait for a response

[Bartosz Dziewoński]

On Tue, 29 Oct 2013 14:54:49 +0100, Petr Bena  wrote:


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)?


No, but there are some things which may or may not be close enough for your use 
cases.

You can filter bugs by time since they were last changed in any way, or by 
number of comments.

You can mark such bugs as UNCONFIRMED, or set their assignee to their reporter (and this 
is easy to search for: you can just do "assignee:%reporter%"). You can then 
search by change history to these fields determine which bugs are the oldest.

Or, if this is just for yourself, you can add freetext input to the whiteboard 
field and filter by that.

So no, there's no direct solution, but it seems possible to come up with a good 
ersatz workflow.

--
Matma Rex

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

Re: [Wikitech-l] [Design] Are external link icons useful

[Jon Robson]

+ wikitech


On Tue, Oct 29, 2013 at 8:54 AM, Siebrand Mazeland (WMF) <
smazel...@wikimedia.org> wrote:

> Also see https://gerrit.wikimedia.org/r/#/c/23424/
>
> In my opinion, external link icons add a lot of visual noise and not that
> much relevant information.
>
>
> On Mon, Oct 28, 2013 at 11:22 PM, Jon Robson wrote:
>
>> Changed subject to reflect this change in topic.  Also cc'ing design
>> mailing list.
>>
>> In terms of external links to me I don't care about whether I'm leaving
>> the site or not. If I clicked on something and it wasn't what I expected
>> that's a badly labeled link. A link saying there is more information on the
>> [white house official website] and a link to the word [house] should be
>> enough information to tell which I'd external and which isn't.
>>
>> I actually think the only place an icon next to a link really makes sense
>> is for downloads. Clicking something that downloads a PDF when I thought it
>> was a web page is a little confusing (on mobile at least).
>>
>> That said if all the external links are in the external links /
>> references section wouldn't encouraging that organisation of links be
>> better?
>>
>> Also I agree with Juliusz that we shouldn't force behaviour of where
>> links open. It should be up to the user if they want the same tab or new
>> one and it should be configurable within the browser preferences.
>>  On 24 Oct 2013 16:07, "Juliusz Gonera"  wrote:
>>
>>>  No, we should definitely not warn people, that's just weird ;) It's
>>> not like something bad is about to happen.
>>> I'm also not saying that users have the expectation that links point to
>>> local URLs, I'm only saying that it might be a useful piece of information
>>> to some.
>>>
>>>
>>> On 10/24/2013 02:48 PM, Jared Zimmerman wrote:
>>>
>>>  Its  definitely a less heavy handed way of doing the thing many
>>> (annoying) sites do when they warn you that you're leaving their site. I
>>> just wonder is the signal to noise it worth it. I don't know that modern
>>> web users have any expectations that link within a site always point to
>>> local site urls.
>>>
>>>  *
>>> *
>>>  *
>>> *
>>> *Jared Zimmerman * \\  Director of User Experience \\ Wikimedia
>>> Foundation
>>>M : +1 415 609 4043 |   :  
>>> @JaredZimmerman
>>>
>>>
>>>
>>>
>> ___
>> Design mailing list
>> des...@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/design
>>
>>
>
>
> --
> Siebrand Mazeland
> Product Manager Language Engineering
> Wikimedia Foundation
>
> M: +31 6 50 69 1239
> Skype: siebrand
>
> Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
>
> ___
> Design mailing list
> des...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/design
>
>


-- 
Jon Robson
http://jonrobson.me.uk
@rakugojon
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Code-in: are you in?

[Andre Klapper]

Hi,

On Tue, 2013-10-29 at 21:58 +0530, Aarti K. Dwivedi wrote:
> Most probably I am late but can we still add tasks or volunteer for
> mentoring?

Thanks for your interest! Yes you can, and they are welcome! 
However I'd turn that into "add tasks *AND* volunteer for mentoring",
because having potential mentor(s) already defined for a task makes
planning way easier.  :)

andre
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/


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

Re: [Wikitech-l] Google Code-in: are you in?

[Quim Gil]

On 10/29/2013 09:28 AM, Aarti K. Dwivedi wrote:

 Most probably I am late but can we still add tasks or volunteer for
mentoring?


Yes!


Apologies for being late,


You answered here. You are not late. Thank you for your involvement!

--
Quim Gil
Technical Contributor Coordinator @ 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

[Wikitech-l] Fwd: What's the prefered way to contribute patches to Pediapress' mwlib?

[Jeremy Baron]

adding their list

-- Forwarded message --
From: "Strainu" 
Date: Oct 29, 2013 12:30 PM
Subject: [Wikitech-l] What's the prefered way to contribute patches to
Pediapress' mwlib?
To: "Wikimedia developers" 
Cc:

> 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
>
> ___
> 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's the prefered way to contribute patches to Pediapress' mwlib?

[Strainu]

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

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

Re: [Wikitech-l] Google Code-in: are you in?

[Aarti K. Dwivedi]

Hey,

Most probably I am late but can we still add tasks or volunteer for
mentoring?

Apologies for being late,
Aarti


On Mon, Oct 28, 2013 at 9:22 PM, Quim Gil  wrote:

> We have applied to Google Code-in and we will know whether we have been
> accepted or not this Friday. Thank you to all the contributors that have
> helped so far listing tasks and volunteering as mentors!
>
> We can keep improving 
> https://www.mediawiki.org/**wiki/Google_Code-In
>
>
> On 10/26/2013 02:07 AM, Jiabao Wu wrote:
>
>> I am very keen to help the Code-ins.
>>
>
> Very good!
>
>
>  I have posted a quite general task on
>> https://www.mediawiki.org/**wiki/Google_Code-In#Code.
>> Shall I split the
>> task to smaller ones (similar to the size as annoying_little_bugs) and
>> define them before 28 October?
>>
>
> Yes, splitting into digestible, self-contained bites is necessary. You can
> still list those tasks in the Code-in page. It is a good exercise to
> complete that feature anyway.
>
>
>  I was GSoC 2013 participant and work on [bug 43058] VisualEditor Math.
>> I think this is a perfect chance for GSoCers. It will help us to
>> review our work as well as furthering the development.
>>
>
> I fully agree. I pinged most of the GSoC projects in the past days, and I
> will do it again if we get accepted in this program.
>
> Also, being a GCI mentor right after being a GSoC student must be very
> exciting. To me it shows a degree of success that the GSoC project delivery
> alone can't measure.
>
> Thank you Jiabao and Liangent for setting this precedent. I hope you will
> inspire other former GSoC students to follow.
>
>
>  On Thu, Oct 24, 2013 at 8:39 PM, Guillaume Paumier
>>
>>> This was the perfect opportunity to create the long-overdue task list
>>>
>>> around tech communications:
>>> https://www.mediawiki.org/**wiki/Technical_communications/**
>>> What_you_can_do
>>>
>>
> Exactly, Google Code-in can be a very good excuse to publish those
> backlogs of little tasks that most of us have in mind, or even documented,
> but never find the time to crunch ourselves, or find someone to work on
> them.
>
> I have also took several tasks that were sitting untouched in my backlog,
> and they are now under Outreach/Research.
>
>
> --
> Quim Gil
> Technical Contributor Coordinator @ 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
>



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

Re: [Wikitech-l] $wgRedactedFunctionArguments

[Zack Weinberg]

On Tue, Oct 29, 2013 at 9:55 AM, Dan Andreescu  wrote:
> I think Ori's original point stands though.  Configuration could be used to
> redact fully / not redact at all for local debugging purposes.  But a black
> list for what to redact is bad for all the reasons black lists are bad
> security in general.

Theoretically speaking, the right way to do this would be to identify
the (small, one hopes) number of *sources* of sensitive data and
change them to return objects of a special class, which would then
automatically print out as "[REDACTED]" (if so configured) in a stack
trace. This would have other benefits; for instance, the special class
could arrange to handle the data extra-carefully (scrubbing it from
memory when no longer required, doing constant-time comparisons, that
sort of thing) and code that needed to treat the datum as anything
other than an opaque blob would have to explicitly unwrap it, which
would then be a red flag for code review.

I don't have any idea how hard this would be; I'd guess somewhere
between "conceptually easy but a huge number of tedious
almost-but-not-quite-mechanical changes to implement" and "infeasible
due to API breakage".

zw

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

Re: [Wikitech-l] Filtering out bugs that wait for a response

[Lydia Pintscher]

On Tue, Oct 29, 2013 at 2:54 PM, Petr Bena  wrote:
> 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.

Same here. You are looking for
https://bugzilla.wikimedia.org/show_bug.cgi?id=36064


Cheers
Lydia

-- 
Lydia Pintscher - http://about.me/lydia.pintscher
Product Manager for Wikidata

Wikimedia Deutschland e.V.
Obentrautstr. 72
10963 Berlin
www.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

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

[Wikitech-l] OPW project: redesigning mediawiki.org homepage?

[Quim Gil]

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_tweaks


--
Quim Gil
Technical Contributor Coordinator @ 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] $wgRedactedFunctionArguments

[Dan Andreescu]

> I don't think the idea here was to ever make the stack traces *safe*,
> just to redact the most obvious things to reduce the risk if someone
> carelessly posts a stack trace publicly.
>
> Personally, I think the "Java model" as exemplified in
> https://gerrit.wikimedia.org/r/#/c/92334/ PS3 goes too far in the
> other direction. In this case, an option to log unredacted traces that
> I could enable on my local test wiki would be useful.


I think Ori's original point stands though.  Configuration could be used to
redact fully / not redact at all for local debugging purposes.  But a black
list for what to redact is bad for all the reasons black lists are bad
security in general.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Filtering out bugs that wait for a response

[Petr Bena]

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.

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

Re: [Wikitech-l] $wgRedactedFunctionArguments

[Brad Jorsch (Anomie)]

On Mon, Oct 28, 2013 at 12:42 AM, Ori Livneh  wrote:
> I think that the proper way to handle low-level operational data like
> stack traces is to make it clear that it is liable to contain
> sensitive information, and to make no pretense at all of sanitizing
> it.

I don't think the idea here was to ever make the stack traces *safe*,
just to redact the most obvious things to reduce the risk if someone
carelessly posts a stack trace publicly.

Personally, I think the "Java model" as exemplified in
https://gerrit.wikimedia.org/r/#/c/92334/ PS3 goes too far in the
other direction. In this case, an option to log unredacted traces that
I could enable on my local test wiki would be useful.

-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation

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