Great opportunity for ambassadors to get involved.
-------- Original Message --------
Subject: Re: [Wikimedia-l] Wikivoyage project launch/migration update
Date: Sun, 11 Nov 2012 11:29:08 +0530
From: Erik Moeller <erik(a)wikimedia.org>
Reply-To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>
To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>
So, if you've not been following along on wikivoyage-l (
https://lists.wikimedia.org/mailman/listinfo/wikivoyage-l ), you
should know that Wikivoyage is now hosted on WMF servers. :) We're
currently in "beta", as there's still lots of smaller and larger
issues to work through, including transferring images to Commons or
local wikis as appropriate. But now's a great time to get involved if
you want to help fix things. These are the languages that are live
now:
httsp://en.wikivoyage.org/https://de.wikivoyage.org/https://ru.wikivoyage.org/https://nl.wikivoyage.org/https://it.wikivoyage.org/https://sv.wikivoyage.org/
But, any other language code should gracefully redict you to Wikimedia
Incubator, where you can easily get started to prove viability of a
new language. :-)
Like I said: Lots of things are still wonky. If you notice something
you can't fix, please report it on Bugzilla and add it as a blocker
for the tracking bug here:
https://bugzilla.wikimedia.org/show_bug.cgi?id=41184
While we're not done yet, I'd like to take this chance to thank
everyone who's been part of the process so far:
* the existing communities for being awesome in supporting this
migration :-)
* Wikivoyage e.V. and especially Hans (for being our main tech contact
managing the DB transfers), Stefan (for handling all the
organizational fun), and Roland (for technical support and review).
* the WMF technical launch team: Chris Steipp, Daniel Zahn, Matthias
Mullie, Sam Reed + everyone who chipped in with help and support.
* the WMF legal and community advocacy team: Geoff Brigham, Kelly Kay,
Philippe Beaudette, and everyone else who helped.
* anyone else I've forgotten to name :-)
All the best,
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
_______________________________________________
Wikimedia-l mailing list
Wikimedia-l(a)lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Hey all,
Just a reminder that jQuery will (after almost 4 years of deprecation!) drop
$.browser [1] in jQuery 1.9.
Please check your scripts and make sure you are are no longer using "$.browser"
(or "jQuery.browser"). After jQuery 1.9 is released, from the next MediaWiki
deployment after that $.browser will be undefined and old code trying to access
a property of it will throw a TypeError for accessing a property of undefined.
Don't be alarmed, this has been a long time coming. It's been almost 4 years,
and by the time this is deployed it will probably have been 4 years.
For those who just realised their script is still using it, or if you read this
later to fix someone else's script that just broke (hello future, did the world
end in 2012?), I'll briefly describe two migration paths you can take from
here:
== Feature detection
In most (if not all) cases of people using $.browser it is because they want
different behaviour for browsers that don't support a certain something. Please
take a minute to look at the code and find out what it is you are special-casing
for that apparently doesn't work in a certain browser.
Research on the internet and look for a way to detect this properly (examples
below). Browser detection (instead of feature detection) is not reliable, nor is
it very effective. For example, Internet Explorer has changed a lot since IE6.
Blindly doing A for IE and B for non-IE isn't very useful anymore as most (if
not all) of the new features will work fine in IE8, IE9 or IE10.
The opposite is also true. If you do something cool for Chrome, you're missing
other WebKit-based browsers that should get the same awesomeness (Safari,
Chromium, iPhone/iPod/iPad, possibly Android, Flock, etc.) these all share the
exact same engine that backs Chrome). And what if Firefox and IE also start to
support this new awesome feature?
There are many ways to do feature detection. jQuery comes with various detectors
built-in in the object "jQuery.support"[2]. This contains for example "support.ajax",
"support.opacity" and many more[2]. You can also easily make your
own feature detector:
* var supportPlaceholder = 'placeholder ' in document.createElement('input');
* var supportJSON = !!window.JSON;
etc.
If you need any help with feature detection, I'd recommend asking in one
of the following channels on irc.freenode.net:
* ##javascript (recommended)
* #jquery
* #wikimedia-dev
== jQuery.client [3]
If you can't figure out how to detect what you really want to switch for, there
is an elaborate plugin in MediaWiki that does the same thing that jQuery.browser
used to do (and more). This can be used as an alternative migration path. To
give an impression:
> jQuery.browser
< {
chrome: true,
version: "22.0.1229.94",
webkit: true
}
> $.client.profile();
< {
name: "chrome",
layout: "webkit",
layoutVersion: 537,
platform: "mac",
version: "22.0.1229.94",
versionBase: "22",
versionNumber: 22
}
For example:
if ( $.browser.chrome ) {}
Would become:
++ dependency: jquery.client
var profile = $.client.profile();
if ( profile.name === 'chrome ) {}
But:
if ( $.browser.msie ) {
// IE doesn't support opacity
el.style.filter = 'alpha(opacity=50)';
} else { .. }
Should become:
if ( $.support.opacity ) {
el.style.filter = 'alpha(opacity=50)';
} else { .. }
Or better yet, since this is supported by jQuery core for a while now, like
this:
$(el).css('opacity', 0.5);
Which will do the right thing for newer browsers and old IE respectively.
-- Krinkle
[1] http://api.jquery.com/jQuery.browser/
[2] http://api.jquery.com/jQuery.support/
[3] https://www.mediawiki.org/wiki/RL/DM#jQuery.client