You got some valid and some not so valid points here
> * It reloads the page 3 times, actually stepping through an edit form,
> modifying wikitext with JS, and saving.
Three times? More like two.
> * It is 1100 lines of ugly code.
1049 but 'ugly' is a bit over the top.
> * It isn't localised.
> * It breaks if translations or aliases of the Category namespace are
> used.
That is one point (the aliases). Localisation is otherwise irrelevant,
as there is nothing to localize.
> * It adds random text to the category display, instead of using nice
> icons.
Why would you call the + - and +/- links "random text"? And why would
icons be "nice"?!
> * It doesn't prompt for an edit summary, nor does it provide any sort
> of confirmation.
Confirmation should be evedent, as the page reloads with the category
list changed. An edit summary is provided automatically
> By contrast, my newer version:
> * Submits an edit through the API, and selectively reloads the
> category section with no user disruption other than a progress spinner.
That is indeed nice.
> * Is 300 lines of simple jQuery code.
Also nice. I hope jQuery becomes standard very soon. It was not easily
available when hotcat was developed
> * Is fully localisable.
Thats nice too, but see above
> * Has full support for translations and aliases of the category
> namespace.
Good
> * Uses icons for the actions.
Not necessarily an improvement
> * Prompts for confirmation and an edit summary before making an edit.
Hm, that is somewhat of an inconvenience if you have to change
multiple categories, or does your version gather changes and submit
them in one edit and one summary?
On Tue, Sep 15, 2009 at 1:38 PM, Gregory Kohs <thekohser(a)gmail.com> wrote:
> I was sort of surprised to learn today that Mediawiki software has had 37
> security holes identified:
>
> http://akahele.org/2009/09/false-sense-of-security/
>
> Are most of these patched now, or are they still open? If still open, is
> the Foundation making site & user security more of a priority in 2010?
>
> --
> Gregory Kohs
> _______________________________________________
> foundation-l mailing list
> foundation-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
I'm pretty sure a lot of this has been fixed (I vaguely remember Tim doing
some cleanup to the installer for XSS issues), but I can't say for sure.
Forwarding to wikitech-l, this is more of a tech issue than Foundation
one.
-Chad
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I wanted to let folks know that WMF is decommissioning some 35 servers,
and is willing to accept requests from users interested in using them
for Wikimedia-related purposes. If you can ship a server from Tampa to
where you are, and if you can put it to good use, please see
http://tinyurl.com/r3xhp7 and send your request in.
Many thanks to the tech team (in particular RobH - looks like he's
handling most or all of this) for reaching out to community members
first. I'm sure we can find happy homes for lots of this hardware, which
will help community members be productive in helping achieve Wikimedia's
mission.
- -Mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkqv1iAACgkQst0AR/DaKHtN8gCdEMaFLzmPRQQcz0f3d2vCajJI
woIAn1PV0fN9uvoKoobFMmB/kt0LmxYJ
=VrGB
-----END PGP SIGNATURE-----
The LanguageSelector extension [1] can automatically set the interface
language based on browser settings, which is nowadays the norm for
every serious multilanguage web page. It is not used on WMF wikis,
because it would interfere with caching. The strategic planning wiki
[2] has, however, relatively low traffic, and probably much higher
logged-in to anon ratio than the rest of the sites. Any chance
LanguageSelector (or something equivalent, if it exists) could be used
there?
[1] http://www.mediawiki.org/wiki/Extension:LanguageSelector
[2] http://strategy.wikimedia.org/wiki/Main_Page
I did some improvements to the JS2 documentation based on some initial
feedback of early adopters ;) The documentation has been on the
mediaWiki.org site here: http://www.mediawiki.org/wiki/JS2_Overview
== Who is this documentation for? ==
* This documentation is for any extension developer that uses javascript
and gadget developers.
* With some minor changes to how your extension includes javascript; it
can greatly improve initial page load time (by minifying, gzips, and
grouping javascript requests)
* With more effort you can build javascript interfaces that are loaded
on-demand and package all localized msgs into the JS. This can really
improve perceived performance even on 'cached scripts' pages by keeping
initial page js parsing and loading to a minimum.
* If these interfaces are reusable and generally applicable to more than
a single extension, we can ideally package them in a central location
making it easier to build off of each-others js components. (similar to
the jquery.ui, jquery plugins and the development path for the new
usability tool-bar and media components).
* I would not recommend switching over your js calls until an official
release contains the new code ;)
** (Once you do update your js include calls, you can still disable the
script-loader to get what you had before)
* Now would be a good time to start testing and give feedback.
peace,
--michael
Hello there. This is a quick status update on the project to get
OpenStreetMap maps into Wikipedia and on the Wikimedia/OpenStreetMap
toolserver setup. For those that don't know what it's all about we're:
* Setting up a testing platform (ptolemy & ortelius) to serve OSM
maps in Wikipedia which can be rolled into production
* Setting up a toolserver (cassini) which interested parties can use
to write tools that use OSM data. And combine it with Wikimedia data
if they want.
Here's an (outdated!) wiki page with some more info:
http://meta.wikimedia.org/wiki/OpenStreetMap
And here's a recent talk I gave at Wikimania discussing the current status:
http://wikimania2009.wikimedia.org/wiki/Proceedings:143
Until now we only had 1/3 machines active & accessible due to various
combinations of waiting for hardware, people being busy and it being
unclear who actually got access to those machines that I won't go
into.
That one machine was the nascent WMOSM Toolserver Cassini. I set up a
prototype multilingular rendering (since ptolemy and ortelius weren't
available at the time) which you can see here:
http://cassini.toolserver.org/tile-browse/
What we need to to currently is:
* Admins to set up ptolemy / ortelius so that they replicate the DB /
mirror tiles
* Get interested users/developers to *use* cassini for their tools so
we can get neat stuff like the multilingular-country-list
(http://cassini.toolserver.org/~mazder/multilingual-country-list/).
Sign up here: https://wiki.toolserver.org/view/Account_request
* Cassini also needs some admin love
* Work on this buglist (and more bugs) to get OSM into Wikipedia:
http://tinyurl.com/nv2sap
I did most of this on Cassini (see setup notes:
http://tinyurl.com/mbblj3) but I have limited time on it (especially
until Christmas) and system administration isn't my strong suit. So
unless we get other people to help this project is going to go
*slooowly* and you won't have OSM on Wikipedia until 2010.
Before WM2009 we had the unfortunate problem of interested parties
needing to do the above not getting access due to the issues above.
However the machines are up *now* and during WM2009 uncertainties
about who could grant access were finally solved (brion will be
dictator).
So, any potential admins for ptolemy and ortelius will have to:
1. Be qualified & motivated
Preferably someone who's worked with the OSM toolchain or is willing
to learn. If you're maintaining your own ad-hoc rendering somewhere
and are running out of server space you'll probably be motivated to
get this working sooner.
2. Reveal their name & address to the Wikimedia foundation
That's a requirement Wikimedia requires of all server administrators.
3. Agree to Wikimedia's privacy policy
URL: http://wikimediafoundation.org/wiki/Privacy_policy
ptolemy and ortelius are otherwise distinct servers on the Wikimedia
network so this amounts to basically not being silly and running a
Quake III server on them, or nmap-ing the Internet.
Cassini is more sensitive and harder to gain access to since root
admins on Cassini have access to private data about Wikimedia users
(e.g. raw database access, login cookies and so on).
But in both cases we should be able to give elevated non-Unix-root
privileges. All of this pending approval by Wikimedia of course.
Hello!
You are receiving this email because your project has been selected to
take part in a new effort by the PHP QA Team to make sure that your
project still works with PHP versions to-be-released. With this we
hope to make sure that you are either aware of things that might
break, or to make sure we don't introduce any strange regressions.
With this effort we hope to build a better relationship between the
PHP Team and the major projects.
If you do not want to receive these heads-up emails, please reply to
me personally and I will remove you from the list; but, we hope that
you want to actively help us making PHP a better and more stable tool.
The third & final release candidate of PHP 5.2.11 was just released
and can be downloaded from http://downloads.php.net/ilia/, the win32
binaries are available athttp://windows.php.net/qa/. Please try this
release candidate against your code and let us know if any regressions
should you find any. The goal is to have 5.2.11 out by next week.
In case you think that other projects should also receive this kinds
of emails, please let me know privately, and I will add them to the
list of projects to contact.
Best Regards,
Ilia Alshanetsky
5.2 Release Master
As Erik points out, at a certain point we have to actually write new
code to support new ideas. Else "projects we could do at Wikimedia"
becomes "projects we can do with a wiki engine."
e.g. OpenStreetMap would have been a natural for WMF, but it would
have required a whole new software infrastructure. And we have no
shortage of content editors, but developers appear rather rarer.
Proposals I recall seeing for new projects either fit into a current
project (e.g. Wikibooks - really, Wikipedia is a book, too) or haven't
been neutral (e.g. the victims of Soviet repression proposal, which I
think is a great idea but also think just would have been way too
intrinsically non-neutral for WMF; the reviews wiki). Any proposal
that's "hey, let's start a wiki" will, I suspect, fall into one of
those two.
We're either not thinking outside the box enough or need to build new
boxes. Or both.
What interesting new engines are there out there for gathering content
from masses of Internet users that aren't wikis as we know them? What
could we use them for besides their original purpose?
[cc'd to wikitech-l for comment as well]
- d.