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]])
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
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!
tl;dr: I am going to break your workflow and your wiki. Skip to the
last section and read on.
== Background ==
As you know, I've been working on a GSoC project to better separate
skins and core MediaWiki [1]. Moving Vector and MonoBook to separate
repositories is the final step of it, and it's exactly as scary as it
sounds.
Until recently MediaWiki was heavily interconnected with the core
skins, particularly Vector – right now it is only slightly
interconnected and I have some patches pending to make it not so
at all [2].
[1] https://www.mediawiki.org/wiki/Separating_skins_from_core_MediaWiki
[2] https://gerrit.wikimedia.org/r/#/q/topic:skinning,n,z
== The plan ==
* Fix up some remaining issues with Vector being required
(I have already fixed most)
* Stop always loading MonoBook and Vector
[patch pending: https://gerrit.wikimedia.org/r/148509 + dependencies]
* Use a special fallback when no skins are installed
[patch pending: https://gerrit.wikimedia.org/r/148508]
* Move MonoBook and Vector to separate repositories
* Ship MonoBook, Vector and some more skins with the installer tarball
* Enable them during the installation
[patch merged: https://gerrit.wikimedia.org/r/138652]
== What it means for you ==
If you're upgrading a wiki or you're a developer working on master,
THIS IS A BACKWARDS INCOMPATIBLE CHANGE. Your wiki will continue to
work, it will just look ugly (no styles).
When we do this and you upgrade, you're going to get a big helpful
message asking you to install and enable some skins and explaining how
to do this (see https://gerrit.wikimedia.org/r/148508 for implementation;
basically, put the files/repository under skins/ and require_once in
LocalSettings).
Try it out with this patch: https://gerrit.wikimedia.org/r/148509
After you do this, you'll be able to switch to slightly older
MediaWiki versions without things breaking, as the new skins will work
with old MediaWiki (the new directory names are different… unless
you're using a case-insensitive OS).
I hope this sounds reasonable to everyone, and I hope to have this
done around the time of Wikimania (possibly during it; I'll be there).
I don't think there is a less disruptive way to do this, other than
not doing it at all; if you come up with one, please share it.
--
Matma Rex
According to our algorithm (*), TorBlock currently has the worse track
reviewing code contributions -- even after Tim gave a -1 to one of the
three open patches last week (thanks!). There are two patches from Tyler
that haven't received any feedback at all since August 2013.
https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions…
Your help reviewing these patches is welcome.
It is not surprising that this extension has no maintaner listed at
https://www.mediawiki.org/wiki/Developers/Maintainers (someone suggested
Tim in that table, he disagrees and edited accordingly).
Also, maybe someone is interested in maintaining this extension? Only
eleven patches submitted in the last 15 months.
(*) http://korma.wmflabs.org/browser/gerrit_review_queue.html -- the
algorithm happens to be buggy these days, but apparently equally buggy for
all repos, which still results in some kind of justice.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
I just love this Google I/O 2013 talk on human perception and
cognition, and its implications for interactive and visual design. It
is accessible, but with a lot of information and applies very well to
us I think.
I'm sure that many designers know all about this and some have
probably seen the clip before, but it is also very good for
developers, because many of these things we know subconsciously, but
it's not really part of our vocabulary.
https://www.youtube.com/watch?v=z2exxj4COhU
DJ
Hi,
the discussion stopped with the question:
How to test the new rendering on betalabs?
So, does who knows the answer?
Best
Moritz
On Tue, Jul 15, 2014 at 12:19 PM, Moritz Schubotz <schubotz(a)tu-berlin.de> wrote:
> Hi Chris,
>
> By default the Math extension users the dedicated host
> mathoid.testme.wmflabs.org this host is accessible from the beta cluster.
> A bug related to the beta cluster is available here
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=66516
>
> But I have no clue how to change the config for betalabs.
>
> Best
>
> Moritz
> Am 15.07.2014 17:06 schrieb "Chris McMahon" <cmcmahon(a)wikimedia.org>:
>
>> On Tue, Jul 15, 2014 at 1:10 AM, Moritz Schubotz <physik(a)physikerwelt.de>
>> wrote:
>>
>> > Hi Chris,
>> >
>> > me too.
>> > How can I implement in in beta labs?
>> >
>>
>> I'd say to start by filing a bugzilla ticket for Wikimedia
>> Labs/deployment-prep.
>> Then it is a matter of registering the proper extensions and config in
>> puppet.
>> Would mathoid need a dedicated host?
>>
>>
>> >
>> > Best
>> > Moritz
>> >
>> > On Mon, Jul 14, 2014 at 6:35 PM, Chris McMahon <cmcmahon(a)wikimedia.org>
>> > wrote:
>> > > I would really like to see this follow the standard deploy scheme:
>> > > implement it in beta labs; then enable it for mediawiki.org and
>> > test2wiki;
>> > > then enable it on production cluster nodes.
>> > > -Chris
>> > >
>> > >
>> > > On Mon, Jul 7, 2014 at 3:07 AM, Moritz Schubotz
>> > > <physik(a)physikerwelt.de>
>> > > wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >> during the last year the math extension achieved a goal defined back
>> > >> in 2003. Support of MathML. In addition there is SVG support for
>> > >> MathML disabled browsers. (See http://arxiv.org/abs/1404.6179 for the
>> > >> details)
>> > >> I would like to give Wikipedia users a chance to test this new long
>> > >> awaited feature.
>> > >> Therefore we would need a mathoid instance that is accessible from
>> > >> the
>> > >> production cluster. Greg Grossmeier already created the required
>> > >> table
>> > >> in the database. (Sorry for the "friction" connected with this
>> > >> process)
>> > >> Currently the MathJax team is working on a phantom.js less method to
>> > >> render texvc to mathml and svg. Some days ago I have tested that it,
>> > >> and it works quite well. I would appreciate a discussion with ops
>> > >> that
>> > >> to figure out how this can be can go to production. The original idea
>> > >> was to use jenkins to build the mathoid debian package. Even though
>> > >> the debian package builds without any issues in the launchpad ppa
>> > >> repo
>> > >> jenkins can not build the package. If there is a reference project
>> > >> that uses jenkins to build debian packages that go to production this
>> > >> would really help to figure out what is different for mathoid and why
>> > >> the package building does not work even though it works on launchpad.
>> > >>
>> > >> Best
>> > >> Physikerwelt
>> > >>
>> > >> PS: I was informed that there is a related RT that I can not access
>> > >> https://rt.wikimedia.org/Ticket/Display.html?id=6077
>> > >>
>> > >> --
>> > >> Mit freundlichen Grüßen
>> > >> Moritz Schubotz
>> > >>
>> > >> _______________________________________________
>> > >> 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
>> >
>> >
>> >
>> > --
>> > Mit freundlichen Grüßen
>> > Moritz Schubotz
>> >
>> > Telefon (Büro): +49 30 314 22784
>> > Telefon (Privat):+49 30 488 27330
>> > E-Mail: schubotz(a)itp.physik.tu-berlin.de
>> > Web: http://www.physikerwelt.de
>> > Skype: Schubi87
>> > ICQ: 200302764
>> > Msn: Moritz(a)Schubotz.de
>> >
>> > _______________________________________________
>> > 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
Replying with a subject line. :) Good luck Thomas.
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
On Thu, Jul 24, 2014 at 4:24 PM, Thomas Mulhall <thomasmulhall410(a)yahoo.com>
wrote:
> Hi should we upgrade jquery ui to version 1.10.4. even though we recently
> upgraded to version 1.9.2 we could upgrade to 1.10.4 in Mediawiki 1.25. The
> main difference is it removes internet explorer 6 support which as long as
> internet explorer 6 users can edit and view the page it wont matter to
> them. here is the changelog jqueryui.com/changelog/1.10.0/
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi,
Tomorrow a major update[1] will be deployed for the ExtensionDistributor
extension on mediawiki.org. We will start fetching branch information
directly from Gerrit instead of relying on Github. Additionally,
tarballs will be served from extdist.wmflabs.org[2] instead of using Github.
There will be a few differences, namely that tarballs are only generated
every hour, instead of on the fly like Github did. These tarballs will
include submodules inside tarballs for extensions like VisualEditor (bug
44022[3]).
If you notice any issues or have any ideas for enhancements, please file
a bug in Bugzilla[4].
Additionally, I'd like to thank ^demon and YuviPanda for their help in
putting this service together.
-- Legoktm
[1] https://gerrit.wikimedia.org/r/#/c/149474/
[2] https://extdist.wmflabs.org/dist/
[3] https://bugzilla.wikimedia.org/show_bug.cgi?id=44022
[4]
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions…