Wikitech-l August 2014

wikitech-l@lists.wikimedia.org

133 participants
134 discussions

Missing Section Headings
by Marc Riddell 13 Sep '24

13 Sep '24

Hello, I have been a WP editor since 2006. I hope you can help me. For some reason I no longer have Section Heading titles showing in the Articles. This is true of all Headings including the one that carries the Article subject's name. When there is a Table of Contents, it appears fine and, when I click on a particular Section, it goes to that Section, but all that is there is a straight line separating the Sections. There is also no button to edit a Section. If I edit the page and remove the "== ==" markers from the Section Titles, the Title then shows up, but not as a Section Heading. Also, I don't have any Date separators on my Want List. This started 2 days ago. Any thoughts? Thanks, Marc Riddell [[User:Michael David]]

10 11

How to make commits from mirrored Wikimedia repos show up on your GitHub profile
by Bartosz Dziewoński 27 Jun '24

27 Jun '24

I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here. tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.) (Is there a place on mw.org to put this tidbit on?) ------- Forwarded message ------- From: "Brian Levine" <support(a)github.com> (GitHub Staff) To: matma.rex(a)gmail.com Cc: Subject: Re: Commits in mirrored repositories not showing up on my profile Date: Tue, 09 Jul 2013 06:47:19 +0200 Hi Bartosz In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit. The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits. Cheers Brian -- Matma Rex

3 3

New RFC: better JS minification
by Max Semenik 01 Nov '15

01 Nov '15

Hi, I'd like to present a new RFC for your consideration: https://www.mediawiki.org/wiki/Requests_for_comment/Minifier It is about how we can shave 10-15% off the size if JavaScript delivered to users. Your comments are highly welcome!:) -- Best regards, Max Semenik ([[User:MaxSem]])

9 12

Bikeshedding a good name for "the api.php API"
by Brad Jorsch (Anomie) 11 Aug '15

11 Aug '15

When api.php was basically the only API in MediaWiki, calling it "the API" worked well. But now we've got a Parsoid API, Gabriel's work on a REST content API, Gabriel's work on an internal storage API, and more on the way. So just saying "the API" is getting confusing. So let's bikeshed a reasonably short name for it that isn't something awful like "the api.php API". I'm horrible at naming. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation

30 38

Re: [Wikitech-l] Bug in the Wikipedia main web page
by Sukyoung Ryu 25 May '15

25 May '15

Thank you for the quick fix! Best, -- Sukyoung On Jan 29, 2014, at 9:55 AM, Nathan wrote: > FYI in case you aren't subscribed to the list. > > ---------- Forwarded message ---------- > From: Yair Rand <yyairrand(a)gmail.com> > Date: Tue, Jan 28, 2014 at 7:25 PM > Subject: Re: [Wikitech-l] Bug in the Wikipedia main web page > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > > > Thank you for pointing out this bug. Your suggested change to > MediaWiki:Gadget-wm-portal.js has been implemented by Meta-Wiki > administrator User:PiRSquared17. > > > On Tue, Jan 28, 2014 at 6:50 PM, Sukyoung Ryu <sukyoung.ryu(a)gmail.com>wrote: > > > Dear all, > > > > We are researchers at KAIST in Korea working on finding JavaScript bugs in > > web pages. While analyzing top websites from Alexa.com, we found an issue, > > which seems to be a bug, on the Wikipedia main web page (wikipedia.org). > > We would be grateful if you can either confirm that it is a bug and even > > better fix it or let us know what we're missing. > > > > Here's the issue. When a user selects a language in which search results > > are displayed via the language selection button from the Wikipedia main web > > page, the following JavaScript function is executed: > > > > 1 function setLang(lang) { > > 2 var uiLang = navigator.language || navigator.userLanguage, date > > = new Date(); > > 3 > > 4 if (uiLang.match(/^\w+/) === lang) { > > 5 date.setTime(date.getTime() - 1); > > 6 } else { > > 7 date.setFullYear(date.getFullYear() + 1); > > 8 } > > 9 > > 10 document.cookie = "searchLang=" + lang + ";expires=" + > > date.toUTCString() + ";domain=" + location.host + ";"; > > 11 } > > > > Depending on the evaluation result of the conditional expression on line > > 4, "uiLang.match(/^\w+/) === lang", the function leaves or dose not leave > > the selected language information on the user's computer through a cookie. > > But we found that the expression, "uiLang.match(/^\w+/) === lang", always > > evaluates to false, which results in that the function always leaves > > cookies on users' computers. We think that changing the contidional > > expression, "uiLang.match(/^\w+/) === lang", to the expression, > > "uiLang.match(/^\w+/) == lang", will solve the problem. > > > > This problem may occur in the main web pages of all the Wikimedia sites. > > Could you kindly let us know what you think? Thank you in advance. > > > > Best, > > Changhee Park and Sukyoung Ryu > > > > > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l(a)lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >

3 3

Upcoming jQuery upgrade (breaking change)
by Krinkle 02 Dec '14

02 Dec '14

Hey all, TL;DR: jQuery will soon be upgraded from v1.8.3 to v1.11.x (the latest). This major release removes deprecated functionality. Please migrate away from this deprecated functionality as soon as possible. It's been a long time coming but we're now finally upgrading the jQuery package that ships with MediaWiki. We used to regularly upgrade jQuery in the past, but got stuck at v1.8 a couple of years ago due to lack of time and concern about disruption. Because of this, many developers have needed to work around bugs that were already fixed in later versions of jQuery. Thankfully, jQuery v1.9 (and its v2 counterpart) has been the first release in jQuery history that needed an upgrade guide[1][2]. It's a major release that cleans up deprecated and dubious functionality. Migration of existing code in extensions, gadgets, and user & site scripts should be trivial (swapping one method for another, maybe with a slight change to the parameters passed). This is all documented in the upgrade guide[1][2]. The upgrade guide may look scary (as it lists many of your favourite methods), but they are mostly just addressing edge cases. == Call to action == This is a call for you, to: 1) Get familiar with http://jquery.com/upgrade-guide/1.9/. 2) Start migrating your code. jQuery v1.9 is about removing deprecated functionality. The new functionality is already present in jQuery 1.8 or, in some cases, earlier. 3) Look out for deprecation warnings. Once instrumentation has begun, using "?debug=true" will log jQuery deprecation warnings to the console. Look for ones marked "JQMIGRATE" [7]. You might also find deprecation notices from mediawiki.js, for more about those see the mail from last October [8]. == Plan == 1) Instrumentation and logging The first phase is to instrument jQuery to work out all the areas which will need work. I have started work on loading jQuery Migrate alongside the current version of jQuery. I expect that to land in master this week [6], and roll out on Wikimedia wikis the week after. This will enable you to detect usage of most deprecated functionality through your browser console. Don't forget the upgrade guide[1], as Migrate cannot detect everything. 2) Upgrade and Migrate After this, the actual upgrade will take place, whilst Migrate stays. This should not break anything since Migrate covers almost all functionality that will be removed. The instrumentation and logging will remain during this phase; the only effective change at this point is whatever jQuery didn't think was worth covering in Migrate or were just one of many bug fixes. 3) Finalise upgrade Finally, we will remove the migration plugin (both the Migrate compatibility layer and its instrumentation). This will bring us to a clean version of latest jQuery v1.x without compatibility hacks. A rough timeline: * 12 May 2014 (1.24wmf4 [9]): Phase 1 – Instrumentation and logging starts. This will run for 4 weeks (until June 9). * 19 May 2014 (1.24wmf5): Phase 2 – "Upgrade and Migrate". This will run for 3 weeks (upto June 9). The instrumentation continues during this period. * 1 June 2014 (1.24wmf7) Finalise upgrade. == FAQ == Q: The upgrade guide is for jQuery v1.9, what about jQuery v1.10 and v1.11? A: Those are regular updates that only fix bugs and/or introduce non-breaking enhancements. Like jQuery v1.7 and v1.8, we can upgrade to those without any hassle. We'll be fast-forwarding straight from v1.8 to v1.11. Q: What about the jQuery Migrate plugin? A: jQuery developed a plugin that adds back some of the removed features (not all, consult the upgrade guide[2] for details). It also logs usage of these to the console. Q: When will the upgrade happen? A: In the next few weeks, once we are happy that the impact is reasonably low. An update will be sent to wikitech-l just before this is done as a final reminder. This will be well before the MediaWiki 1.24 branch point for extension authors looking to maintain compatibility. Q: When are we moving to jQuery v2.x? A: We are not currently planing to do this. Despite the name, jQuery v2.x doesn't contain any new features compared to jQuery v1 [3]. The main difference is in the reduced support for different browsers and environments; most noticeably, jQuery 2.x drops support for Internet Explorer 8 and below, which MediaWiki is still supporting for now, and is outside the scope of this work. Both v1 and v2 continue to enjoy simultaneous releases for bug fixes and new features. For example, jQuery released v1.11 and v2.1 together[4][5]. -- Krinkle [1] http://blog.jquery.com/2013/01/15/jquery-1-9-final-jquery-2-0-beta-migrate- final-released/ [2] http://jquery.com/upgrade-guide/1.9/ [3] http://blog.jquery.com/2013/04/18/jquery-2-0-released/ [4] http://blog.jquery.com/2014/01/24/jquery-1-11-and-2-1-released/ [5] http://blog.jquery.com/2013/05/24/jquery-1-10-0-and-2-0-1-released/ [6] https://gerrit.wikimedia.org/r/131494 [7] https://github.com/jquery/jquery-migrate/blob/master/warnings.md [8] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg72198.html [9] https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap

6 14

Feature request.
by Nkansah Rexford 30 Nov '14

30 Nov '14

Hi all, I'm Rexford, and just posting here for the first time. Please inform if this place isn't the right area to suggest features. I was encouraged to request features here. Please correct me if I'm wrong. Its about edit conflict on Wikipedia and other projects. It happens when I get into an article to edit, but before I could save, someone else goes into the article, edits and save. It happens to myself and many out there. Sometimes many minutes work of changes can be lost. The feature request is this: When a person starts editing an article, and another person tries to edit that same article, he or she gets a message on screen that the article is already engaged. This suggestion is similar to how WordPress informs the second person who tries to edit a page whiles someone else is already editing. Its likely one wouldn't like to edit a page when he or she knows someone is in it editing. I think its much better that way than allowing multiple edits on the page but allowing one persons edit to go in per save. Thanks. rexford | google.com/+Nkansahrexford | sent from smartphone

20 53

People with knowledge of English swear words needed :o
by Petr Bena 20 Nov '14

20 Nov '14

Are you good in swearing? WE NEED YOU Huggle 3 comes with vandalism-prediction as it is precaching the diffs even before they are enqueued including their contents. Each edit has so called "score" which is a numerical value that if higher, the edit is more likely a vandalism. If you want to help us improve this feature, it is necessary to define a "score words" list for every wiki where huggle is about to be used, for example on English wiki. Each list has following syntax: (see https://en.wikipedia.org/w/index.php?title=Wikipedia:Huggle/Config&diff=573…) score-words(score): list of words separated by comma, can contain newlines but comma must be present example score-words(200): these, are, some, words, which, presence, of, increases, the, score, each, word, by, 200, So, if you know english better than me, which you likely do, go ahead and improve the configuration file there, no worries, huggle's config parser is very syntax-error proof. If you have any other suggestion how to improve huggle's prediction, go ahead and tell us!

8 8

OOjs, MobileFrontend and Flow
by Jon Robson 20 Sep '14

20 Sep '14

Shahyar, Juliusz, Trevor, Roan and I met to discuss using oojs inside the mobile and Flow projects. The following 3 patches kicks off moving MobileFrontend's class model towards that of oojs - many thanks for Roan for doing most of the legwork :-): https://gerrit.wikimedia.org/r/155593 https://gerrit.wikimedia.org/r/155589 https://gerrit.wikimedia.org/r/129336 On the long term we'd look to swap out the Class.js and eventemitter.js files in MobileFrontend for oojs, but this is going to be tricky and require some care, possibly mixing both oojs and MobileFrontend's class code in the repository at the same time. e.g. increasing JavaScript on the short term, but reducing it on the longterm. The MobileFrontend core development team will need to work out how best to manage this transition. Since Flow is very DOM-focused, as opposed to many smaller JavaScript modules with element management per the currently-accepted use of OOjs, it is unclear how we may go about integrating with OOjs fully. However, some potential use cases have been identified as candidates for implementing OOjs on an interim basis, primarily by abstracting some current FlowBoardComponent workflows, such as those which handle (re-)rendering of existing and new content fetched from the API.

3 6

Status of collation config updates?
by Bartosz Dziewoński 17 Sep '14

17 Sep '14

Hi, There are currently three pending patches to change category collation configuration for various Wikimedia wikis: https://gerrit.wikimedia.org/r/140580 https://gerrit.wikimedia.org/r/147922 https://gerrit.wikimedia.org/r/154213 (This generally makes it so that accented letters like 'é' or 'ą' are not sorted at the end of lists, after 'z', and fixed ordering for languages with interesting alphabets; see https://www.mediawiki.org/wiki/Manual:$wgCategoryCollation.) I have previously been told that these are on hold because of WMF's Trusty migration and the need to rebuild all existing collation data. (No one told me how long that might take, but by my estimates that can't possibly take more than two or three weeks, and I know for a fact that it can be done with no downtime and minimal problems.) That was about two months ago. Is anything known about the current status of the collation things, and the Trusty migration in general? Is there any public venue that I could follow to know what is going on, or at least a private one I could be cc'd on if I asked pretty-please? Is there any ETA, even vague, as to when things might get done? I would like to update the bugs that are stuck with this information. -- Matma Rex

2 4

Jump to page:

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 August 2014