Wikitech-l September 2014

wikitech-l@lists.wikimedia.org

129 participants
127 discussions

Determine if a extension's commit is live
by Tim Landscheidt 10 Sep '14

10 Sep '14

Hi, I want to check if https://gerrit.wikimedia.org/r/157836/ is live on dewp. So I would get MediaWiki core's SHA1 from http://de.wikipedia.org/w/api.php?action=query&meta=siteinfo, extract the extension name from the Gerrit page, look at core's extensions/$EXTENSION SHA1 for the $VERSION_SHA1 and see if in the extension's repository $CHANGE_SHA1 is a par- ent of $EXTENSION_SHA1. That sounds simple, but like work. Has someone done that already? (Web tools are welcome as well.) Tim

3 2

RfC Discussions Today/Next week
by Rachel Farrand 10 Sep '14

10 Sep '14

Hello, If you are interested in joining today's RfC discussion, the Architecture Committee will be discussing the following RfCs: * SOA Authentication (Chris Steipp) https://www.mediawiki.org/wiki/Requests_for_comment/SOA_Authentication * Server-side Javascript error logging (Gergő Tisza) https://www.mediawiki.org/wiki/Requests_for_comment/Server-side_Javascript_… Wednesday, 03 September 2014, in #wikimedia-office on Freenode IRC, 21:00-22:00 UTC *http://www.timeanddate.com/worldclock/fixedtime.html?msg=RFC+Meeting&iso=20140903T14&p1=224&ah=1 <http://www.timeanddate.com/worldclock/fixedtime.html?msg=RFC+Meeting&iso=20…>* *Proposed agenda for Sep 10: * * Data Mapper (Andrew Green) https://www.mediawiki.org/wiki/Requests_for_comment/Data_mapper * Dependency injection (Andrew Green) https://www.mediawiki.org/wiki/Requests_for_comment/Dependency_injection Wednesday, 10 September 2014, in #wikimedia-office on Freenode IRC, 21:00-22:00 UTC *http://www.timeanddate.com/worldclock/fixedtime.html?msg=RFC+Meeting+Sep+10&iso=20140910T21&p1=1440&ah=1 <http://www.timeanddate.com/worldclock/fixedtime.html?msg=RFC+Meeting+Sep+10…>* Thanks! Rachel

5 4

RFC meeting today
by Tim Starling 09 Sep '14

09 Sep '14

Today's weekly RFC meeting on will discuss the following RFCs: * Data Mapper (Andrew Green) <https://www.mediawiki.org/wiki/Requests_for_comment/Data_mapper> * Dependency injection (Andrew Green) <https://www.mediawiki.org/wiki/Requests_for_comment/Dependency_injection> It will be on the IRC channel #wikimedia-office on irc.freenode.org at the following time: * UTC: Wednesday 21:00 * US PDT: Wednesday 14:00 * Europe CEST: Wednesday 23:00 * Australia AEST: Thursday 07:00 -- Tim Starling

1 0

Parser cache update/migration strategies
by Daniel Kinzler 09 Sep '14

09 Sep '14

Hi all! tl;dr: How to best handle the situation of an old parser cache entry not containing all the info expected by a newly deployed version of code? We are currently working to improve our usage of the parser cache for Wikibase/Wikidata. E.g., We are attaching additional information related to languagelinks the to ParserOutput, so we can use it in the skin when generating the sidebar. However, when we change what gets stored in the parser cache, we still need to deal with old cache entries that do not yet have the desired information attached. Here's a few options we have if the expected info isn't in the cached ParserOutput: 1) ...then generate it on the fly. On every page view, until the parser cache is purged. This seems bad especially if generating the required info means hitting the database. 2) ...then invalidate the parser cache for this page, and then a) just live with this request missing a bit of output, or b) generate on the fly c) trigger a self-redirect. 3) ...then generated it, attach it to the ParserOutput, and push the updated ParserOutput object back into the cache. This seems nice, but I'm not sure how to do that. 4) ...then force a full re-rendering and re-caching of the page, then continue. I'm not sure how to do this cleanly. So, the simplest solution seems to be 2, but it means that we invalidate the parser cache of *every* page on the wiki potentially (though we will not hit the long tail of rarely viewed pages immediately). It effectively means that any such change requires all pages to be re-rendered eventually. Is that acceptable? Solution 3 seems nice and surgical, just injecting the new info into the cached object. Is there a nice and clean way to *update* a parser cache entry like that, without re-generating it in full? Do you see any issues with this approach? Is it worth the trouble? Any input would be great! Thanks, daniel -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.

4 5

Standardising icons across projects
by Jon Robson 09 Sep '14

09 Sep '14

Since we had the luxury of having several people in the office, Trevor, Juliusz, Rob Moen, Ed Sanders, Shahyar, May, Monte and I sat down to talk about the problem we currently have of having no standard way to create icons. Here is my write up of this meeting, again, if you attended please add/correct me on anything and if you were not please ask for clarification where needed. Currently we have two modes of creating icons in MediaWiki 1) Using a font 2) Using SVGs with PNG fallbacks and the markup varies depending on what extension you look at. We discussed both approaches and advantages and disadvantages of each. One of the major disadvantages of the WikiFont is the additional HTTP request it creates to download the font and cannot be embedded in the stylesheet using data uris like SVGs can (due to URL size restrictions). One of the major advantages of WikiFont is you can design a grayscale icon, and style it using font colour. Shahyar was happy to move Flow to using SVG based fonts if we could build grayscale SVGs and change their colours using ResourceLoader. One concrete example is when you have an icon used in a constructive anchor. The icon needs to be green, but when hovered over a lighter green. Another advantage brought up by May was that currently she finds it much easier to build icons in this way, and that having to maintain separate coloured versions of the SVGs is a pain point to her. We decided that we should push towards using SVGs that can be built into fonts for the purpose of the app. As next steps 1) Monte to explore using SVGs in the Wikipedia apps. He will create font from SVGs. He will work with May to ensure her workflow is as easy as before. 2) Trevor is going to look into how we can automatically generate different colour versions of SVGs and automatically create PNGs from them. 3) I am going to aim to agree on a standard icon HTML markup for mediawiki ui. We still have an issue with the fact that everyone is using different HTML markup to create icons. After reviewing all our current approaches [1] it was clear that we were relatively closely aligned and that it simply is a case of agreeing on class names. We aim to get all the above done by Sept 15th, 2014 so please poke us on the mailing list if you haven't had a follow up then. Full disorganised notes can be found here [2]. [1] https://www.mediawiki.org/wiki/Icon_standardisation [2] http://etherpad.wikimedia.org/p/Icon_standardisation

3 4

The future of skins
by Jon Robson 09 Sep '14

09 Sep '14

Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and talked about the future of skins. Hopefully this mail summarises what we talked about and what we agreed on. Feel free to add anything, or ask any questions in the likely event that I've misinterpreted something we talked about or this is unclear :) Specifically we talked about how we are unhappy with how difficult it currently is for developers to create a skin. The skin class involves too many functions and does more than a skin should do e.g. manage classes on the body, worry about script tags and style tags. Trevor is going to create a base set of widgets, for example a list generator to generate things like a list of links to user tools. The widgets will be agnostic to how they are rendered - some may use templates, some may not. We identified the new skin system will have two long term goals: 1) We would like to get to the point where a new skin can be built by simply copying and pasting a master template and writing a new css file. 2) Should be possible for us in future to re-render an entire page via JavaScript and using the modern history push state re-render any page via the API. (Whether we'd want to do this is another consideration but we would like to have an architecture that is powerful enough to support such a thing) As next steps we agreed to do the following: 1) Trevor is going to build a watch star widget on client and server. We identified that the existing watch star code is poorly written and has resulted in MobileFrontend rewriting it. We decided to target this as it is a simple enough example that it doesn't need a template. It's small and contained enough that we hope this will allow us to share ideas and codify a lot of those. Trevor is hoping to begin working on this the week of the 2nd September. 2) We need a templating system in core. Trevor is going to do some research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements. [1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library

13 22

Individual Engagement Grants Committee recruiting for members
by Pine W 09 Sep '14

09 Sep '14

Dear all, The Individual Engagement Grants Committee is seeking new members. We are diverse, consensus-based committee with members on five continents and a variety of skills. As a group we speak 16 languages and have over 500,000 edits to a variety of Wikimedia sites. We review grant applications twice per year in four categories: Research, Tools (usually software), Online community organizing, and Offline outreach and partnerships. Members may specialize in as few or as many areas as they wish. We look for the following qualifications. This information is taken from our Meta page. Mandatory: 1. Experience with the Wikimedia movement and at least one Wikimedia project <https://meta.wikimedia.org/wiki/Special:MyLanguage/Wikimedia_projects>. 2. Experience with some aspect of Wikimedia programmatic or project-based work, e.g. editor engagement, WikiProjects or other on-wiki organizing processes, outreach, events, partnerships, research, education, gadget or bot-building, etc. 3. Ability to edit basic wiki-markup (grant proposal discussions are largely conducted on meta-wiki). 4. Reasonable facility with English, for reviewing and discussing grant proposals. 5. In good community- and legal- standing (not currently blocked or banned, involved in allegations of unethical financial behavior, etc). 6. Availability to actively engage in the selection process during the published schedule for that round (time commitment is about 3 hours per week, plus 1 extra day for scoring). Preferable: 1. Experience leading, coordinating, or managing projects with an intended on-wiki or online impact. 2. Experience handling externally provided money and working within budgets, preferably in a non-profit context. 3. Experience applying for grants or working in grants programs (in the Wikimedia, academic, or wider non-profit world). 4. Ability to read and write in multiple languages. Acceptable: 1. Members may apply for an Individual Engagement Grant themselves, but they will recuse themselves from reviewing proposals in the same category as their own during that round. 2. Membership does not conflict with membership in other Wikimedia committees, including the Grant Advisory Committee <https://meta.wikimedia.org/wiki/Special:MyLanguage/Grants:PEG/Grant_Advisor…> or the Wikimania Scholarships Committee. Please apply at https://meta.wikimedia.org/wiki/Grants:IEG/Committee#ieg-candidates. The close of the application period is September 21. The Committee will review the applications internally and announce new members by early October, coinciding with the start of the public review period for new grant proposals. For the Committee, Pine

1 0

UploadWizard bug triage on Sep 09, 17:00UTC
by Andre Klapper 09 Sep '14

09 Sep '14

Heja everybody, you are invited to join us on the next Bugday: Tuesday, September 09, 2014, 17:00 to 19:00UTC [1] in #wikimedia-multimedia on Freenode IRC [2] We will take a look at open Bugzilla tickets for UploadWizard. Everyone is welcome to join. No technical knowledge needed! It's an easy way to get involved or to give something back. More information can be found here: https://www.mediawiki.org/wiki/Bug_management/Triage/20140909 For more information on triaging in general, check out https://www.mediawiki.org/wiki/Bug_management/Triage See you there? andre [1] Timezone converter: http://www.timeanddate.com/worldclock/converter.html [2] See http://meta.wikimedia.org/wiki/IRC for more info on IRC -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

1 1

Is simplicity is the key to success of Echo and Watchlist?
by svetlana 08 Sep '14

08 Sep '14

Hi all. I'm including some thoughts on Echo below. - *it* *doesn't* *scale* (constantly seeing a "(3)" or new emails pop up if you're active in ~6 discussions is a pain) - _nothing_ on-wiki ever warrants an urgent reaction ever - distracting, especially as I'm getting more active with talking - this last point caused me to switch it off entirely everywhere - I'm reading an article to get more information and this piece of software drags me back into editing while I'm merely reading something and intend to return to the watchlist in the evening - Echo a consequence of newcomers being insufficiently communicated to (i.e. too few helpers involved talking with newcomers at big wikis, let's automate that - NO! THAT's STUPID! have it semi-automated -- the entire wiki software should be centered around a big edit box and a less prominent, but comfortable, box for leaving custom messages to articles and users talk pages) - Echo is a consequence of a watchlist page which many people find insufficiently informative, intuitive, or easy to control. - special:watchlist and special:notifications overlap in functionality - the 'notifications' tab lacks a 'watchlist' column so that I can choose where events go (email, echo's nagging, or watchlist passively) - the extra term ('notifications') is clutter - please consider improving usability of the watchlist and integrating any echo fields into it - and make watchlist easier to manage - integrate these two tools together - echo is really conceptually merely a new channel where to pipe watchlist items - simplicity is the key to success svetlana -- (original rant attached for reference) Dunno. I'm pissed by Echo. Hundreds of hours of time wasted looking at a reply at a talk page or at an edit someone thanked me for. Which are not urgent at all. Yet the software notified me of them real-time. Echo is a consequence of newcomers being insufficiently communicated to (i.e. too few helpers involved talking with newcomers at big wikis). Also, a consequence of a watchlist page which many people find insufficiently informative, intuitive, or easy to control. ---- looking at Echo's 'thanks' notifications for a few months before figuring out that it's possible to disable that like I'm reading a page about electrons on-wiki and doing something of interest to me, it pops up with its number [1] I have to go and watch it despite knowing it clearly that _nothing_ on-wiki ever needs an urgent reaction about couple minutes on that daily.. clearly doesn't encourage me to talk more with people if you sum that up, it's a few tens or hundreds of hours of time wasted this year I'm supposed to concentrate and all those notifications are distracting -- I know where I am, I don't need them I became remotely active at mediawiki or meta and started getting these notifications non-stop. Frick off. This doesn't scale. does this explain the source of trouble? :-) ---- well, I ticked off everything 'web', this set it to 0 for now, but I wouldn't like to see it at all since it's bearing no extra information and people who are not sitting in a cave will find that *it* *simply* *doesn't* *scale* anyone active in ~6 discussions will find it a source of nag ---- I wouldn't like it to go forward really -- improve the watchlist instead and make it more useable please :) spending time on a means to thank a user via software, or to ask him a 'mention' at a discussion, doesn't look very productive to me -- this all can be put into watchlist nicely it doesn't need to be an extension, it needs to be an improvement in the core what to do with watchlist -- web notify thru echo, or email, or nothing and just have me peek at it in the evening extra concept 'echo', 'notification' is extra clutter nobody needs it, both these lists should be configurable in one tab of prefs add a 'watchlist' column to the 'notifications' tab -- so that I can tell whether I'd like to see thanks piped over to my watchlist etc I can see simplicity as a path to success reword things a little, name it 'watchlist notifications', make it more flexible and make it pipe things over to a single special page instead of 2 special pages this special page should remain as compact as a watchlist is -- the design of the current 'special:notifications' page is not at all good on a 600x800 screen managing watchlist is hard, fixing that is long overdue I'd _really_ like to see echo and watchlist back together in a simple intuitive system

16 22

Using magic functions (e.g. __get) to deprecate class members
by Stephan Gambke 08 Sep '14

08 Sep '14

TL;DR: Please review [1] I was asked to discuss the topic on the mailing list, so here goes. Since some time Siebrand is making an effort to improve code quality by making it phpcs-strict compliant [0]. This involves explicitly declaring the visibility of class members. Alas, intended or not, in very many cases he did not only explicitly declare the class variable's visibility, but he also changed it from the implicit 'public' to explicit 'protected' or 'private', thus introducing a major API change without a proper deprecation period. Apparently this was not noticed (or at least not challenged) by the reviewers. I checked a few of his commits and they were all merged within hours. Now, to be clear about that, I appreciate both changes - the phpcs compliance as well as the more limited accessibility of class variables. This was long overdue. However, to introduce something like this a proper deprecation period is in my opinion essential, in particular considering the extent of the changes. I do believe that Siebrand checked that the variables he declared protected or private were not used by extensions. However, he missed one (EditPage::mTokenOk) which subsequently resulted in a bug in an extension (SemanticForms). Given the number of the now newly hidden variables I am quite sure, that there are other cases. If only because many extensions are not hosted on WMF servers, so they can not be checked. To keep the changes and still be able to properly deprecate the direct access to the member variables I submitted a patch [1] that makes use of PHP magic functions [2]. They provide access to the class members and issue a deprecation warning. The intention is to keep these functions for the custom two releases [3], i.e. until 1.26, and then remove them. This patch was shot down for three reasons: <quote> * it duplicates code * there is no tests * our code base barely use the magic methods and I am pretty sure Tim Starling commented a while back about them being nasty. </quote> When I pointed out, that these functions are not re-entrant and thus Tims warning [4] did not apply the answer was "I have merely copy pasted Tim comment without even attempting to understand what it means". I was subsequently asked to present this to the mailing list which I do with this mail. I would appreciate comments on the patch (preferably constructive), that would allow us to not revert Siebrand's changes and still properly deprecate formerly public class members. Thanks. Stephan [0] https://gerrit.wikimedia.org/r/#/q/status:merged+project:mediawiki/core+bra… [1] https://gerrit.wikimedia.org/r/#/c/151370/ [2] http://php.net/manual/en/language.oop5.overloading.php#language.oop5.overlo… [3] https://www.mediawiki.org/wiki/Deprecation [4] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/85288#c17504

3 5

Language Engineering IRC Office Hour on September 10, 2014 (Wednesday) at 1700 UTC
by Runa Bhattacharjee 08 Sep '14

08 Sep '14

[x-posted] Hello, The next monthly IRC office hour of the Wikimedia Language Engineering team will be on Wednesday, September 10, 2014 at 1700 UTC on #wikimedia-office. We will be taking questions and discussing about our ongoing work, particularly around the Content Translation project[1], and upcoming plans. Please see below for event details and local time. See you there. Thanks Runa [1] https://www.mediawiki.org/wiki/Content_translation Monthly IRC Office Hour: =================== # Date: September 10, 2014 (Wednesday) # Time: 1700 UTC/1000PDT (Check local time: http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140910T1700) # IRC channel: #wikimedia-office # Agenda: 1. Content Translation project updates and plans 2. Q & A (Questions can be sent to me ahead of the event) -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation

1 0

Bugzilla Weekly Report
by reporter＠zirconium.wikimedia.org 07 Sep '14

07 Sep '14

1 0

Fwd: fab.wmflabs.org to go offline this Monday 18:00UTC
by Quim Gil 07 Sep '14

07 Sep '14

All users at fab.wmflabs.org have received this announcement. Forwarding it here just in case. ---------- Forwarded message ---------- From: <PhabAnnounce(a)phabricator.wikimedia.org> Date: Sunday, September 7, 2014 Subject: fab.wmflabs.org to go offline this Monday 18:00UTC To: qgil(a)wikimedia.org Summary: fab.wmflabs.org will be taken down this Monday 18:00UTC. Locally save tasks or workboards that you might rely on for the week. Verify your email address in fab.wmflabs.org if it's not already. The intention is for the Phabricator production instance to be available by Sept 12th. The Phabricator instance on fab.wmflabs.org has been used over the last few months for both real and test data. On Mon, Sept 8th 2014 18:00UTC this instance will be made unavailable to migrate content to the upcoming production instance on phabricator.wikimedia.org. The Labs instance will not come back online in the same form, if at all. We take the Labs instance down because we cannot make the Labs instance read-only while dumping its data. Neither can we easily display a banner on all pages warning you to not make any changes which would get lost anyway. Tickets from the following projects are marked for migration: Analytics-EEVS Architecture bugzilla-migration Chemical_Markup_for_Wikimedia_Commons Code_review_in_Phabricator Community-Engagement dev.wikimedia.org googlelogin Growth Human_Resources Language_Engineering logstash phabricator phabricator-request-project Release_Engineering rt-migration Triagers Trusted_User_Tool UI_Standardization UploadWizard_Refactoring Upstreaming_to_Phabricator.org Wiki-Release-Team Wikimedia_Phabricator_Day_1 wikimedia_phabricator_maintenance wikimedia_phabricator_rfc Some metadata[1] for tasks associated with the above should be populated in the new production system -- if the account used in fab.wmflabs.org has a verified email that is also verified in the production instance. If you are using an email but have not verified it to the Labs instance you can go here: http://fab.wmflabs.org/settings/panel/email/ and choose "verify". An email will be sent with a link. If you do not have a verified email address yet, or for some reason cannot verify an email with the Labs instance the relevant content (tickets, comments) will still be migrated. However, it will not be associated automatically with any new account in the production instance. For questions catch us (chasemp and andre__) on Freenode IRC or drop into the #wikimedia-devtools channel. Thanks, Phabricator Team [1] metadata to be migrated: ticket: author, cc, assigned, blocking/blocked -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

GSoC wrap-up posts responsibility
by Federico Leva (Nemo) 06 Sep '14

06 Sep '14

https://www.mediawiki.org/wiki/Google_Summer_of_Code_2014 states "project wrap-up post by 20 August" but I see very few.* Is it my responsibility as mentor to remind/harass my student about it, or was that already done by the admins? Thanks. Nemo (*) On the other hand I don't even know which projects were completed/passed. The official answer by Google is that http://www.google-melange.com/gsoc/events/google/gsoc2014 knows it all, but I don't see explicit pass/fail information there.

2 1

Re: [Wikitech-l] Add release to special version page
by Florian Schmidt 06 Sep '14

06 Sep '14

The date comes from the git information, if there is no .git in the installation, then no date :) So tarballs don't have some iirc. Gesendet mit meinem HTC ----- Reply message ----- Von: "Isarra Yos" <zhorishna(a)gmail.com> An: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org> Betreff: [Wikitech-l] Add release to special version page Datum: Sa., Sep. 6, 2014 08:50 On 06/09/14 06:42, Chad wrote: > Don't we already pull the date from git if it exists? > > http://en.wikipedia.org/wiki/Special:Version says yes. > > -Chad Oh neat, is that new? Or am I just that unobservant? Well, nevermind, then. What about the tarball ones, though? Do those do it? Seriously, I haven't used a tarball in... quite awhile. -I _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

4 5

Add release to special version page
by Thomas Mulhall 05 Sep '14

05 Sep '14

Can we add a section for release date of the extension or skin release. because it would be easer to view the release date in the special version page then go to the extension page and try to look it up.

3 3

Fwd: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments
by David Gerard 05 Sep '14

05 Sep '14

I asked this on wikimedia-l in the recent discussion with no answer. I was wondering what the status of this feature was ... - d. ---------- Forwarded message ---------- From: David Gerard <dgerard(a)gmail.com> Date: 1 September 2014 18:00 Subject: Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> On 1 September 2014 17:57, Martijn Hoekstra <martijnhoekstra(a)gmail.com> wrote: > The same, by the way, goes for VE, which should have had "bail and give me > what you have now as wikitext" from the onset, and Flow which needs a "bail > and convert this thread to ye olde talkpage thread" (which I fear will be > batted away as reactionary crank talk, and "by the time flow will be done > unneeded anyway") By the way: Is Flow going to support the use case of cut'n'pasting a piece from the article page to the talk page, as a lump of wikitext or as a piece of rich text from VE? 'Cos if it doesn't, I predict that will be the sticking point with the people who actually communicate on talk pages. - d.

2 1

[x-post] Content Translation round-table on 5 September 2014, 1600 UTC
by Runa Bhattacharjee 04 Sep '14

04 Sep '14

[X-posted announcement] Hello, The Language Engineering team of the Wikimedia Foundation has been working on a tool for easy translation of Wikipedia articles from one language to another. The Content Translation tool has been in development since early 2014 and in July it was deployed and opened for testing on beta labs. The tool currently provides an editing interface, limited machine translation capability, link and reference adaptation and dictionary support. The first rollout included machine translation support from Spanish to Catalan. Since then, the tool has been used to create more than 100 new articles for the Catalan Wikipedia. On 5 September 2014, the team will be hosting a round-table conversation with some of the editors from the Catalan Wikipedia who have been using Content Translation. The online event is scheduled from 1600 UTC to 1700 UTC. We would like to invite everyone to join us (please use the event url below) and add your questions to know more about this project. The same url can be used later to view an archived version of the event. Thank you. Event Details: ========== # Event url - https://plus.google.com/u/0/events/ckphmp2shtnc6hadsca95thshp4 # Date: September 5, 2014 (Friday) # Time: 1600 UTC (check local time: http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140905T1600) Project Details: ============ # Project Home: https://www.mediawiki.org/wiki/Content_translation # Announcements: ## http://blog.wikimedia.org/2014/07/16/first-look-at-the-content-translation-… and ## http://blog.wikimedia.org/2014/08/26/content-translation-100-published-arti… -- regards, Runa Language Engineering - Outreach and QA Coordinator Wikimedia Foundation

1 0

[wiki co-op] Questions to address in tomorrow's user group meeting
by Mark A. Hershberger 04 Sep '14

04 Sep '14

Quim asks a couple of good questions that I think we should discuss in tomorrow's meeting. "It would be good to clarify whether this group aims to work on anything related to mediawiki.org."[1] "Why not adding "MediaWiki" explicitly in the name of the group?"[2] If you missed the announcement of this user group meeting, you can find all the information you need to join it on MediaWiki.org.[3] Hope to see you there! Mark. [1] https://www.mediawiki.org/wiki/Thread:Talk:Groups/Proposals/Wiki_Co-op/Resp… [2] https://www.mediawiki.org/wiki/Thread:Talk:Groups/Proposals/Wiki_Co-op/Medi… [3] https://www.mediawiki.org/wiki/Wiki_Co-op/Meetings/2014-09-05_Telco

1 0

Wikitech upgrade and config changes
by Andrew Bogott 03 Sep '14

03 Sep '14

Executive summary: Wikitech may be a bit different today. Please log any new issues here: https://bugzilla.wikimedia.org/enter_bug.cgi?product=Wikimedia%20Labs and select 'wikitech-interface'. The whole story: Since the birth of Labs, wikitech.wikimedia.org (formerly known as 'labsconsole') has been managed by hand by Labs operations staff. While wikitech was in rapid development it made sense to keep its off-the-cuff design, but now that it's become a (quite) essential and (fairly) stable part of our infrastructure, it was time to bring it into the fold. So, as of today, wikitech is running a wiki config that's managed by our deployment infrastructure -- Internally, this is know as being 'on the deployment train.' It's a good place to be -- wikitech will receive more timely updates, and can now be more easily configured by WMF staff and volunteers. But, be warned: since this entailed in a fresh build of wikitech from new code, there are bound to be unintended differences. I haven't found any serious ones, but I bet you will! Please be on the lookout for new bugs, unexpected changes of behavior, etc. When you find problems, report them using the bugzilla link above. If these issues are urgent (in other words, preventing you from doing stuff that you need to do) feel free to nag one of the involved people on IRC: coren, bd808, reedy, or me (andrewbogott). Many thanks to Bryan, Sam, Chad, Coren, and all others who helped with this endeavor! -Andrew

2 1

Fwd: [talk-ch] Luftbilder Stadt Zürich
by rupert THURNER 03 Sep '14

03 Sep '14

aerial images from the city of zürich free .... rupert ---------- Weitergeleitete Nachricht ---------- Von: "Simon Poole" <simon(a)poole.ch> Datum: 03.09.2014 00:33 Betreff: [talk-ch] Luftbilder Stadt Zürich An: "Openstreetmap Schweiz/Suisse/Svizzera/Svizra" <talk-ch(a)openstreetmap.ch > http://sosm.ch/high-resolution-aerial-imagery-from-the-city-of-zuerich/ Simon _______________________________________________ talk-ch mailing list talk-ch(a)openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch

1 0

Rachel Farrand joins the Engineering Community Team as Events Coordinator
by Quim Gil 03 Sep '14

03 Sep '14

For almost three years, Rachel Farrand has been a regular contributor in the organization of public and internal Wikimedia events since she joined the Wikimedia Foundation as an Admin Assistant and then Project Coordinator with the Engineering department. This past year, Rachel has been the lead coordinator at the WMF for the Architecture Summit in San Francisco, the Wikimedia Hackathon in Zürich, the Wikimania Hackathon in London, most of the Tech Talks scheduled, and many on-site and off-site meetings. Those of us lucky to work with Rachel know that she is a reliable and patient team worker who excels at organizing activities for others to enjoy. For all these reasons and more, we have decided to evolve Rachel's role as Events Coordinator at the Engineering Community team. With this change, Rachel will be able to dedicate more time and attention to this area, where we are already playing good tactics but we need a more consistent strategy movement-wide. Rachel's current goals include merging our Architecture Summit, WMF Tech Days, and SF Hackathon into a single event this Winter; document a HowTo for hackathon organizers compiling our many lessons learned; and keeping a regular stream of online Tech Talks and on-site Wikimedia Tech meetups in San Francisco. She will also assist in the organization of our outreach programs (Google Summer of Code, FOSS Outreach Program for Women, Google Code-in): time-based activities that share many aspects with our technical events. It’s been a great process to work with Lynette on Rachel’s transition into the ECT team, and we are delighted Engineering Community events will have the dedication and focus Rachel brings to the work!. Congrats and "Welcome" Rachel! -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

6 5

Lazy load - Lazy page rendering (for discussion)
by Thomas Gries 02 Sep '14

02 Sep '14

I recently found the idea of * "lazy rendering" (of tables, images, media objects) Has application of lazy load techniques ever been considered for MediaWiki pages? Here are some pointers: * https://github.com/ressio/lazy-load-xt Lazy load XT (fully featured version) * http://www.appelsiini.net/projects/lazyload Lazy Load is delays loading of images in long web pages. Images outside of viewport are not loaded until user scrolls to them. This is opposite of image preloading <http://www.appelsiini.net/2007/6/sequentially-preloading-images> … Using Lazy Load on long web pages will make the page load faster. In some cases it can also help to reduce server load. * http://www.datatables.net/extensions/scroller/ Scroller is a virtual rendering plug-in for DataTables which allows large datasets to be drawn on screen every quickly. What the virtual rendering means is that only the visible portion of the table (and a bit to either side to make the scrolling smooth) is drawn, while the scrolling container gives the visual impression that the whole table is visible… * http://www.datatables.net/release-datatables/extensions/Scroller/examples/s… DataTables' server-side processing mode is a feature that naturally fits in with Scroller perfectly. Server-side processing can be used to show large data sets, with the server being used to do the data processing, and Scroller optimising the display of the data in a scrolling viewport…

1 0

Simplest UI for creating & editing Phabricator tasks
by Quim Gil 02 Sep '14

02 Sep '14

Hi, Users of the future Wikimedia Phabricator will have a very simple and straightforward interface to create and edit tasks. Bugzilla's UI was one of the top complaints from new/casual users, and we can fix this in Phabricator easily. Currently we are testing this setup in fab.wmflabs.org, where you can see an example: http://fab.wmflabs.org/maniphest/task/create/ (imagine that the "Points" field is not there). Advanced users needing to prioritize tasks, assign them to someone, and resolve them can join the Triagers team in order to get the additional permissions: http://fab.wmflabs.org/project/view/74/ We are still fine tuning this process at http://fab.wmflabs.org/T64 -- your feedback is welcome. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

4 8

Watchlist and Echo
by svetlana 01 Sep '14

01 Sep '14

Hi all. I've noticed Echo has a separate special page, Special:Notifications. Would we like to rewrite the extension so that it adds entries to the watchlist instead? (And add 'Edits' tab into echo itself - put the watchlist items there). There is a lot of Special: pages already and adding new ones doesn't - immediately - appear to help usability. svetlana

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l September 2014