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]])
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
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
>
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
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
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!
On Wednesday, October 22, 2014 the Quality Assurance Group and Team
Practices Group hope you will join us for a meet-up at the WMF entitled
'Exploratory Testing for Complex Software; Lessons from Cloud Foundry' with
special guest speaker Elisabeth Hendrickson [1]. We will be discussing
testing in agile iterative software development, and in particular exploratory
testing <https://en.wikipedia.org/wiki/Exploratory_testing> [0]. This will
be a lively and enlightening conversation, aimed at everyone concerned
about the overall quality of software - even those who do not necessarily
contribute code.
*When*: Wednesday, October 22, 2014, 6:00pm - 8:30pm (for WMF folks there
is a calendar event on the Engineering calendar)
*Where*:
Wikimedia Foundation
6th Floor, collab space
149 New Montgomery St.
San Francisco, CA
(Accessible for remote participation via Hangouts on Air; link TBA)
*From the meet-up invite
<http://www.meetup.com/wikimedia-tech/events/207856222/>*[2]:
In modern software development organizations, the days are gone when
separate, independent Quality Assurance departments test software only
after it is finished. Iterative development and agile methods mean that
software is constantly being created, tested, released, marketed, and used
in short, tight cycles. An important testing approach in such an
environment is called Exploratory Testing, and the Wikimedia Foundation has
made significant investments to support Exploratory Testing for its
software development projects.
Elisabeth Hendrickson is "test obsessed". She was an early adopter and
vocal proponent of all aspects of agile software testing. She has been
particularly instrumental in encouraging and defining the practice of
Exploratory Testing. Elisabeth's 2013 book "Explore It!: Reduce Risk and
Increase Confidence with Exploratory Testing" is the standard reference on
the subject.
Join us in the Wikimedia Foundation collaboration space to hear Elisabeth
discuss her experience doing software testing for complex projects, with
particular examples of Exploratory Testing from her current work as
Director of Quality Engineering for Cloud Foundry.
This talk is for everyone involved in the overall quality of software, and
it will be of particular interest to Project Managers, Product Managers,
and those working with software development projects who do not necessarily
contribute code directly to the projects.
[0] https://en.wikipedia.org/wiki/Exploratory_testing
[1] Elisabeth Hendrickson is a tester, developer, and Agile enabler. She
wrote her first line of code in 1980, and almost immediately found her
first bug. In 2010 she won the prestigious Gordon Pask Award from the Agile
Alliance. She is best known for her Google Tech Talk on Agile Testing as
well as her wildly popular Test Heuristics Cheatsheet. In 2003, she learned
how to do Agile for real from Pivotal Labs while working as a tester on one
of their projects. In 2012 she decided it was time to take up permanent
residence in the Pivotal offices, where she is the Director of Quality
Engineering for Cloud Foundry, Pivotal's Open Source Platform as a Service
(PaaS).
[2] http://www.meetup.com/wikimedia-tech/events/207856222/
--
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
Hello everyone,
I've been a Tor user for many years and I frequently make use of anonymising
proxies services. Recently (yesterday), I set up my first Tor relay.[1] This
has once again gotten the use of Tor and other anonymising services with
Wikipedia on my mind again.
In a recent article on the Tor blog,[2] Wikipedia is actually called out a
number of times for being unfriendly to Tor, and I think they make a good point.
"[H]ow can we quantify the loss to Wikipedia, and to society at large, from
turning away anonymous contributors? Wikipedians say 'we have to blacklist all
these IP addresses because of trolls' and 'Wikipedia is rotting because nobody
wants to edit it anymore' in the same breath, and we believe these points
are related."
There must be a way that we can allow users to work from Tor. My understanding
of why we block Tor categorically is that it is very hard to block individual
Tor users. Perhaps we could allow Tor users to only edit pages if they make
an account? That would allow us to at least block those accounts, which
increases the cost of being problematic on Wikipedia a bit.
Or to take from the blog post, perhaps Tor users could be issued a certificate
that they could use to prove their identity from one session to another. New
Tor users would need to prove they are the same person as someone we already
trust or their edits would be put in some sort of review queue.
Or combine the two and new accounts made from Tor connections would need to have
their edits reviewed, or perhaps just wouldn't get autopatrolled status as
quickly (if ever).
There has got to be a better solution to the problem than just blocking all Tor
users completely.
Thank you,
Derric Atzrott
[1]:
https://atlas.torproject.org/#details/6413D947D15B81B423D65D76DA3F2BFEF76BE…
[2]:
https://blog.torproject.org/blog/call-arms-helping-internet-services-accept…
ymous-users
Hello!
We are happy to announce the MediaWiki Developer Summit 2015, which will be
taking place on January 26th and January 27th in San Francisco, California,
USA.
Registration is now open.
Details about the MediaWiki Developer Summit 2015 and a link to the
registration form can be found here:
https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2015
Hope to see you in San Francisco!
Rachel