Re: [Wikitech-l] [Wmfall] Welcome Frances Hocutt
/listinfo/wmfall -- Peter Coombe Fundraising Production Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disabling JS support in additional browsers
One thing that comes to mind is that CentralNotice is dependent on JS. Blacklisting browsers means they won't see CentralNotice banners at all. This isn't really a big concern for Fundraising: it's a small percentage of views, and not having to support these browsers in our increasingly sophisticated banners is probably a blessing. However I wonder about other uses of CentralNotice e.g. letting people know about the recent Privacy Policy and Terms of Use changes. Where we not only want to reach as many users as possible, but may also have legal obligations to. I'm not really sure how big an issue this is, or how to solve it. On 6 August 2014 19:52, Erik Moeller e...@wikimedia.org wrote: Following up on disabling JavaScript support for IE6 [1], here is some additional research on other browsers. I'd appreciate if people with experience testing/developing for/with these browsers would jump in with additional observations. I think we should wait with adding other browsers to the blacklist until the IE6 change has been rolled out, which may expose unanticipated consequences (it already exposed that Common.js causes errors in blacklisted browsers, which should be fixed once [2] is reviewed and merged). As a reminder, the current blacklist is in resources/src/startup.js. As a quick test, I tested basic browsing/editing operation on English Wikipedia with various browsers. Negative results don't necessarily indicate that we should disable JS support for these browsers, but they do indicate the quality of testing that currently occurs for those browsers. Based on a combination of test results, unpatched vulnerabilities and usage share, an initial recommendation for each browser follows. Note that due to the heavy customization through gadgets/site scripts, there are often site-specific issues which may not be uncovered through naive testing. == Microsoft Internet Explorer 7.x == Last release in series: April 2009 - Browsing: Most pages work fine (some styling issues), but pages with audio files cause JavaScript errors (problem in TMH). - Editing: Throws JS error immediately (problem in RefToolbar) Both of these errors don't occur in IE8. Security vulnerabilities: Secunia reports 15 out of 87 vulnerabilities as unpatched, with the most serious one being rated as moderately critical (which is the same as IE6, while the most serious IE8 vulnerability is rated less critical). Usage: 1% Recommendation: Add to blacklist == Opera 8.x == Last release in series: September 2005 Browsing/editing: Works fine, but all JS fails due to a script execution error (which at least doesn't cause a pop-up). Security: Secunia reports 0 unpatched vulnerabilities (out of 26). Usage: 0.25% Recommendation: Add to blacklist == Opera 10.x-12.x == Last release in series: April 2014 Browsing/editing: Works fine, including advanced features like MediaViewer (except for 10.x) Security: No unpatched vulnerabilities in 12.x series according to Secunia, 2 unpatched vulnerabilities in 11.x (less critical) and 1 unpatched vulnerability in 10.x (moderately critical) Usage: 1% Recommendation: Maintain basic JS support, but monitor situation re: 10.x and add that series to blacklist if maintenance cost too high == Firefox 3.6.* == Last release in series: March 2012 Browsing/editing: Works fine (MediaViewer disables itself) Security: 0 unpatched vulnerabilities according to Secunia Recommendation: Maintain basic JS support == Firefox 3.5.* == Last release in series: April 2011 Browsing/editing: Works fine (MediaViewer disables itself) Security: 0 unpatched vulnerabilities according to Secunia Recommendation: Maintain basic JS support == Safari 4.x == Last release in series: November 2010 Browsing/editing: Works fine Security: 1 unpatched highly critical vulnerability according to Secunia (exposure of sensitive information) Recommendation: Maintain basic JS support, but monitor == Safari 3.x == Last release in series: May 2009 Browsing/editing: Completely messed up, looks like CSS doesn't get loaded at all Security: 2 unpatched vulnerabilities, highly critical Usage share: Usage reports for Safari in [3] are broken, all Safari versions are reported as 0.0. However, [4] suggests that Safari 3 usage is negligible/non-existent. Recommendation: Styling issue may be worth investigating in case it affects other browsers and/or is JS-caused. Otherwise probably can be safely ignored. [1] http://lists.wikimedia.org/pipermail/wikitech-l/2014-August/077952.html [2] https://gerrit.wikimedia.org/r/#/c/152122/ [3] http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm [4] http://stackoverflow.com/questions/12655363/what-is-the-most-old-safari-version-which-is-used-so-far-by-users -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation ___ Wikitech-l
Re: [Wikitech-l] [Engineering] 2300 UTC Monday: grid system discussion
IANA grid expert, but I think it would be a huge missed opportunity not to let this be used for content. It could be a great help with pages like Portals, which are currently reliant on loads of inline styles for layout, or worse, tables. Peter On 2 June 2014 15:39, C. Scott Ananian canan...@wikimedia.org wrote: A grid system for content authors would be useful as well. There have been some discussions about better semantic markup for image widths and placement as part of the change to image thumbnail sizing which landed last week and was reverted yesterday. This doesn't seem to be included in the current RfC (which seems to concentrate on features for skin authors) -- do the grid experts think that discussion of how this might be used in content would be on-topic for the discussion tonight? [7pm Boston time, somehow Sumana left out the east coast from her list! ;) ] --scott On Mon, Jun 2, 2014 at 2:14 AM, Sumana Harihareswara suma...@wikimedia.org wrote: Later today, at 2300 UTC, we'll be in #wikimedia-office discussing Pau Giner's grid system RfC. https://www.mediawiki.org/wiki/Requests_for_comment/Grid_system to simplify the creation of user interfaces and make them ready for multiple screen sizes. Check out the new patchset https://gerrit.wikimedia.org/r/#/c/133683/ It makes the log-in form responsive (adjusting layout, typography and visibility to the current screen size). It does not leverage all the potential of responsive design, but may be useful as a demo to help the reviewers. This is at a time meant to make it easier for Australia and China to participate. http://www.timeanddate.com/worldclock/fixedtime.html?hour=23min=00sec=0day=02month=06year=2014 Sydney: Tuesday 9am Beijing: Tuesday 7am San Francisco: Monday 4pm I'm sorry for the late announcement of this one; for the next several weeks I'll be haranguing authors to help me get discussions set up a few weeks in advance. :) More: https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-06-02 Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Engineering mailing list engineer...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/engineering -- (http://cscott.net) ___ 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] Proposed body font stack for Latin
On 11 April 2014 20:30, Erwin Dokter er...@darcoury.nl wrote: ... Thank you for your work on this! Next up I may think about the headers font stack; While Georgia is a good serif; I detest its use of text figures. I previously suggested a solution to this that should work for most users ( https://www.mediawiki.org/wiki/Talk:Typography_refresh/Archive_2#Numbers_looks_weird_in_article_title ) Steven: was this tried? Regards, -- Erwin Dokter Peter ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Latest Snowden docs MediaWiki
On 18 February 2014 07:45, Brian Wolff bawo...@gmail.com wrote: ... The coverage I've read so far seems to suggest that he had legitimate access to the data and didn't exploit implementation details of the security system (Well the technical implementation. Arguably he exploited implementation weaknesses in the social structure that made him a trusted entity in the system with no checks against mass downloading). But again, who knows what really happened. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l This is the impression I had as well. Snowden's been described in various reports as a sysadmin, and supposedly had top secret clearance. As for the software, we already know about Intellipedia (intelligence community) [1], Bureaupedia (FBI) [2], and Diplopedia (State Department) [3] - all apparently using MediaWiki. So it doesn't surprise me that the NSA are using it too. Pete / the wub [1] https://en.wikipedia.org/wiki/Intellipedia [2] https://en.wikipedia.org/wiki/Bureaupedia [3] https://en.wikipedia.org/wiki/Diplopedia ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] I'm back from Hacker School
Hi Sumana, nice to have you back! Hope the sabbatical was a great experience for you. Peter On 4 January 2014 03:48, Sumana Harihareswara suma...@wikimedia.org wrote: Hi! As of yesterday, I'm back after my three-month sabbatical at Hacker School. I'm in catchup mode so I haven't yet resubscribed to most lists, nor quite taken back over Engineering Community Team (Quim Gil is still in charge until sometime next week when I feel back up to speed). Thank you to WMF for the sabbatical program, thanks to my boss Rob Lanphier for his support, and thanks to my team. I was able to walk away worry-free for three great months because I knew that Andre Klapper, Quim Gil, and Guillaume Paumier had my back. :) Sumana Harihareswara Engineering Community Manager 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
Re: [Wikitech-l] Search documentation
There were over 300,000 views of [[en:Help:Searching]] in June. [1] It definitely needs some improvement, but having some accurate documentation of MediaWiki search features to work from would really help. [1] https://en.wikipedia.org/wiki/Wikipedia:Help_Project/page_statistics Peter On 18 June 2013 01:59, Federico Leva (Nemo) nemow...@gmail.com wrote: The true (old) MediaWiki documentation on search is still on Meta, it needs to be rewritten on mediawiki.org (PD and up to date): https://meta.wikimedia.org/**wiki/Help:Searchinghttps://meta.wikimedia.org/wiki/Help:Searching Nobody reads the help pages, sure. That's why they should be linked from the special pages etc. as some extensions already do. https://bugzilla.wikimedia.**org/show_bug.cgi?id=43591https://bugzilla.wikimedia.org/show_bug.cgi?id=43591 Nemo __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] [Wikimedia-l] [X-POST] Universal Language Selector(ULS) Deployment - Phase 1
What is the rationale for moving ULS from the personal toolbar to the interlanguage links on some sites? I find this change odd: * makes location and appearance of ULS inconsistent between sites * personal toolbar seems the conventional place for per-account settings and tools * features it is replacing like WebFonts live in the personal toolbar * interlanguage links are something rather different, taking the user to a wholly different site Pete / the wub On 5 June 2013 20:52, Runa Bhattacharjee rbhattachar...@wikimedia.orgwrote: Hello, The Universal Language Selector (ULS)[1] provides a flexible way to configure and deliver language settings like interface language, fonts, and input methods (keyboard mappings). It combines the features of two earlier Mediawiki extensions Narayam[2] and WebFonts[3]. From June 11, 2013 on, ULS will be made available to all Wikimedia wikis in 5 phases[4]. # Phase 1: In the first phase, ULS will replace the Narayam and WebFonts extensions on 84 wikis[5]. User preferences from the replaced extensions will not be preserved. Affected communities will be informed by the Wikimedia Language Engineering team of the upcoming change. # Phase 2: In the 5 weeks that follow, ULS will be deployed on Wikipedias in size 11-20, # Phase 3: All projects without language versions # Phase 4: English language Wikipedia # Phase 5: All other wikis The ULS can be visible in two ways: 1. In the sidebar for wikis with language versions, like Wikipedia, or 2. In the personal toolbar at the top of wiki pages for wikis without language versions, like Wikimedia Commons and Meta-Wiki. Based on the geographic location of users, the initial set of language preferences is presented. Users can set the input methods and fonts to that they want to use. Logged-in users can also change the language for the MediaWiki menu items. ULS is already available on several Wikimedia wikis like Wikimedia Commons[6] and Meta-Wiki[7]. The beta installation of English Wikipedia on Wikimedia Labs[8] shows what will be available as the look and feel. A cog icon is present in the “Languages” section of the sidebar menu. Clicking the cog icon opens the Language settings panel that can be used to set the display and input settings. Please have a look at the Universal Language Selector feature description[9] or the Frequently Asked Questions[10] for more detailed information. Thank you. regards Runa [1] https://www.mediawiki.org/wiki/Extension:UniversalLanguageSelector [2] https://www.mediawiki.org/wiki/Extension:Narayam [3] https://www.mediawiki.org/wiki/Extension:WebFonts [4] https://www.mediawiki.org/wiki/UniversalLanguageSelector/Deployment/Planning [5] https://www.mediawiki.org/wiki/UniversalLanguageSelector/Deployment/Planning#List_of_affected_wikis_.2884.29 [6] https://commons.wikimedia.org/wiki/ [7] https://meta.wikimedia.org/wiki/Main_Page [8] http://en.wikipedia.beta.wmflabs.org/ [9] https://www.mediawiki.org/wiki/Universal_Language_Selector [10] https://www.mediawiki.org/wiki/Universal_Language_Selector/FAQ -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation https://meta.wikimedia.org/wiki/User:Runab_WMF ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Responsive web design
This is one of the aims of the planned 'Athena' skin: https://www.mediawiki.org/wiki/Athena Pete / the wub On 27 July 2012 11:01, John Elliot j...@jj5.net wrote: Are there any initiatives in the MediaWiki community for a MediaWiki theme that supports 'responsive design' [1] -- where content is properly laid out in an accessible form on all manner of devices including desktops and smart phones? [1] http://www.alistapart.com/articles/responsive-web-design/ ___ 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] StripState and ampersands?
On 2 July 2012 16:02, Daniel Barrett d...@vistaprint.com wrote: On 29/06/12 21:42, Daniel Barrett wrote: How can I prevent this conversion so ampersands (and presumably other special characters) are preserved? Followup up my own question: StripState is not relevant here. It's the fact that it's a parser tag extension. Simply returning in the callback will produce amp;. Is there a way to suppress this conversion when returning from a parser tag extension? DanB Platonides wrote: Why do you want a plain ? Seems like you want invalid html... Because the output may contain JavaScript and it's converting if (ab) to if (aamp;amp;b). The extension is a tag javascript that adds arbitrary javascript, supplied by the user, to the wiki page. Security is not an issue because this is a completely internal wiki. Is there a better way to implement a javascript parser tag extension so the HTML-conversion issue doesn't happen? DanB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l I don't know, but vanilla MediaWiki has the same problem: inside html tags (when they are allowed by $wgRawHtml=true) gets converted to amp; which can break javascript. https://bugzilla.wikimedia.org/show_bug.cgi?id=10407 Pete / the wub ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Inline styles trouble on the mobile site
On 28 June 2012 04:21, MZMcBride z...@mzmcbride.com wrote: Jon Robson wrote: More concretely can anyone give me a specific example of an inline style that is essential on mobile that we simply cannot scrub? We've been over this repeatedly, haven't we? Sometimes there is _data_ in the styling. If you strip out the styling, you'll be throwing away this data. I'm not sure why you're still questioning this or how you've been unable to find specific examples of this. Search the English Wikipedia for phrases such as marked in green or marked in red or whatever. I just want to point out that colour alone *should not* be used to convey data, for accessibility reasons. https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Accessibility#Color (Yes I realise that's an en.wikipedia guideline, but similar principles ought to apply across all projects) Pete / the wub ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Update on IPv6
On 8 June 2012 16:18, Risker risker...@gmail.com wrote: On 8 June 2012 10:12, Ryan Lane rlan...@gmail.com wrote: The problem was never IPv6. The problem was always about the unspoken expectation that everyone else would just drop everything else they have going on to patch up all the stuff that got broken as a result of this sudden change. I get that this was an exciting step for the engineers who got it done, and I tip my hat to all of them for pulling it off; from that sense it's been a successful implementation. I also get that at least 30% of WMF users on hundreds of projects -that's roughly how many use one or more gadgets, scripts or tools that didn't work after this switch - have now had their editing experience negatively affected, and that almost all of it could have been avoided with a month or two of notice so that patches could be written and resources could be put into place in advance. One has to hope this was a knowledge gap and that Engineering did not actually know the extent to which it would impact the projects and the end-users. Are the breakages on the site really that massive? We've been getting little to no reports of breakages. From what I understand, most of these breakages are in tools and scripts developed and operated by volunteer developers, not WMF developers. The big one is Huggle, which on enwp is used by a large majority of admins and recent changes patrollers. There are additional notes on the enwp village pump (technical) that appear to be related, although I do not have the expertise to assess this. I have been told that there are parallel issues on some of the other large projects, although I don't have direct knowledge. I only see one report of IPv6 problems at the village pump: https://en.wikipedia.org/wiki/Wikipedia:Vpt#MediaWiki:Sp-contributions-footer-anon That was a template which was fixed within a few hours. Note that the API has had some downtime recently, which has been wreaking havoc on various scripts and tools. So many of the reports at the village pump are unrelated to IPv6. Pete / the wub ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Watchlist improvements are on the way
Hi Aaron, it's great that someone's working on this - it's a much needed improvement. I was messing around with watchlist header ideas recently, and found it looked quite good to have notices in a floating box off to the right, so they're separated from the actual options. Never did try actually implementing it, but thought it might be helpful. Would also be happy to beta test whatever you come up with. Peter On 15 May 2012 18:37, Aaron Pramana aa...@sociotopia.com wrote: Hello MediaWiki Developers, I will be working on improving the watchlist feature in MediaWiki this summer for GSoC. For the initial scope of my project, I'm aiming to concurrently add grouping to watchlists, while improving the UI as recommended in the Visual Watchlist thread ( http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/61151 ). This week, I'll begin by testing ways to make the watchlist options box collapsible/not take up as much space. (So far, I've created one patch that uses the mw-collapsible class - any better ideas?) I will also begin modifying RecentChangesLine to provide the # of chars added removed, not just the net change amount (this leads up to the keystone feature of the visual watchlist.) I'm also looking for beta testers for the improved UI, so please reply back if you are interested. Thanks, Aaron Pramana ___ 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
