As some of you are already aware, I'm doing for this GSoC a Desktop tool
for conveniently uploading images to commons.
http://thread.gmane.org/gmane.org.wikimedia.wikilovesmonuments/2641
How can you help with this?
a) Propose a cool name for this tool
b) Suggest new functionalities/requisites
Either on http://www.mediawiki.org/wiki/User:Platonides/GSOC_proposal or
in this thread.
c) Volunteer for testing the program and giving early feedback
(please reply directly to avoid spamming the mailing list with "I can
test it, too")
We've pushed some updates to UploadWizard, most notably:
* disabled multiple-file selection in browsers where it didn't work
* files now start uploading immediately when selected (this can be disabled
server-side if there are problems with it)
* improved category input fields
* 'skip tutorial' step is now saved as a pref instead of a cookie -- so the
tutorial won't come back every time you switch computers anymore!
* fixes for when pre-upload thumbnails do and don't get drawn
* initial API for fetching upload campaign metadata
('action=uploadcampaign'), to be used by Wiki Loves Monuments mobile app
Don't be shy about giving feedback!
-- brion
Hi folks,
As any of you who might have been trying to access Bugzilla, it has
been giving us a lot of problems over the past couple of days. Our
Ops team is aware of the problem, but is a bit baffled at this point.
Since many of them are traveling or getting ready to do so, expect
that it'll probably be limping along (at best) over the weekend until
they get settled in and can devote some time to fixing this problem
correctly.
Please join in on #wikimedia-operations if you want updates or if you
have ideas about what might be going on (e.g. if you happen to be
running something that might be bogging down the server).
Rob
Hi everyone,
It looks like bugzilla.wikimedia.org is unreachable at the moment. I'm
assuming the right people are already aware of it, but as I cannot
create a bug for this, I thought I'd let you know :).
On IRC the last change reported in bugzilla is of about 07:30 UTC,
about 2.5 hours ago.
Cheers!
--
Siebrand Mazeland
Product Manager Localisation
Wikimedia Foundation
M: +31 6 50 69 1239
Skype: siebrand
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Hey,
I have some test class in which I need to (temporary) add a table. I did
some stuff that works locally for my (just constructing some SQL and
passing it to wfGetDb()->safeQuery) but it fails on Jenkins, presumably
because it's using SQLLite or whatever there. Is there a better way to add
such tables?
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
Hi folks,
Chad alerted me to the notes of the Gerrit Hackathon, which happened May 7-11:
https://groups.google.com/forum/#!msg/repo-discuss/kEL3FPT2rLo/w39qjsmnrwwJ
No one from WMF was there, but I thought you all might find this interesting.
Bits I found interesting:
* The Gerrit devs are working on a plugin/extension system, which
should make it much easier to extend Gerrit. They're planning both a
simple but stable API ("extensions"), and a more powerful but less
stable API ("plugins").
*, They plan to integrate Lucene, which in addition making search
generally work better, will also mean that they can then start moving
stuff out of the database and into git itself (in git notes[1] if
necessary for after-the-fact editing). It took me a while to
understand why this is useful, but now I get it. If they really go
all the way with this, it could mean cloning a repo will give you all
of the data in Gerrit, which means that Git guis could be made to
support Gerrit metadata, and that one might never have to interact
directly with the web interface.
* Tagging ("change labels") is on their roadmap (which the notetaker
acknowledges are "highly coveted"). However, they want to integrate
Lucene into Gerrit first, since they tags just being search metadata
that can be indexed/refreshed in Lucene rather than having to ever
live in the db.
Rob
[1] Git notes: http://schacon.github.com/git/git-notes.html
Andre Klapper <andre_klapper(a)gmx.net> writes:
> Can I (average user) add myself to that default CC list for a component
> (I am not aware of any way), or do I need to first need to find out that
> "default CC" exists, somehow find out who and how to contact for getting
> added to it (and then somebody has to add me and respond to my request)
> without losing motivation on my way to achieve all this? :-/
I just discovered the Component Watching extension for Bugzilla that allows
anyone to watch any component via their Bugzilla preferences.
https://bugzilla.mozilla.org/show_bug.cgi?id=634531
Since I think this would be very useful for Wikimedia users, I've created a
request for it:
https://bugzilla.wikimedia.org/show_bug.cgi?id=37105
--
http://hexmode.com/
Find peace within yourself and there will be peace on heaven and
earth. -- Abba Isaac
I'm adding an API module to retrieve UploadWizard upload campaign
information, which we need for the upcoming mobile application for Wiki
Loves Monuments. Essentially the app will include a very limited
implementation of a couple steps of UploadWizard for things like license
selection and filling the ID field and description, so we have one
consistent set of configuration for both web upload (using UploadWizard)
and mobile uploads (using the app).
The change waiting review in gerrit:
https://gerrit.wikimedia.org/r/#/c/7832/
If anybody's got a prime usage in mind for reading UploadWizard campaign
data from the API and has recommendations for adjusting the output format
(maybe for making the editing view more AJAX-y) please give a shout -- this
is not final and we can adjust it.
Currently it'll return XML like this:
<?xml version="1.0"?><api>
<uploadcampaign>
<campaigns>
<campaign name="wlm-es" id="2" isenabled="0" autoCategories=""
autoWikiText="" defaultAlt="" defaultCategories=""
defaultDescription="" defaultLat="" defaultLon=""
defaultOwnWorkLicence="cc-by-sa-3.0" headerLabelPage="sdfsdf"
idField="sdfafsdfd" idFieldInitialValue="" idFieldLabel=""
idFieldLabelPage="" idFieldMaxLength="25"
licensesOwnWork="cc-by-sa-3.0|cc-by-3.0|cc-zero"
ownWorkOption="choice" skipTutorial="" thanksLabelPage=""
tutorialHelpdeskCoords="27, 1319, 691, 1384"
tutorialTemplate="Licensing_tutorial_$1.svg" tutorialWidth="720" />
</campaigns>
</uploadcampaign></api>
or JSON like this:
{
"uploadcampaign": {
"campaigns": [
{
"name": "wlm-es",
"id": 2,
"isenabled": 0,
"autoCategories": "",
"autoWikiText": "",
"defaultAlt": "",
"defaultCategories": "",
"defaultDescription": "",
"defaultLat": "",
"defaultLon": "",
"defaultOwnWorkLicence": "cc-by-sa-3.0",
"headerLabelPage": "sdfsdf",
"idField": "sdfafsdfd",
"idFieldInitialValue": "",
"idFieldLabel": "",
"idFieldLabelPage": "",
"idFieldMaxLength": "25",
"licensesOwnWork": "cc-by-sa-3.0|cc-by-3.0|cc-zero",
"ownWorkOption": "choice",
"skipTutorial": "",
"thanksLabelPage": "",
"tutorialHelpdeskCoords": "27, 1319, 691, 1384",
"tutorialTemplate": "Licensing_tutorial_$1.svg",
"tutorialWidth": "720"
}
]
}
}
-- brion
Right now I am implementing a new option (as part of
https://bugzilla.wikimedia.org/show_bug.cgi?id=36425) for which I'd like to
use a <select multiple="multiple"/> html element with options. Right now
MediaWiki always generates a list of selectboxes instead of that when using
the HTMLMultiSelectField class. We are talking about 280+ selectable items
here, so for now we came to the conclusion that a real multi <select/>
would be nicer and less space consuming for now
I have already managed to implement this multiple select,
modifying HTMLMultiSelectField adding a new option 'usecheckboxes' which
can be set to false to disable the known behavior and use a select element
instead.
This would mainly be for the JavaScript-less ui. If javascript were
enabled, we could still do something nicer, for example with something like
jQuery chosen plugin here.
My question would just be, how I should implement these changes preferably.
Is it ok with the new option for HTMLMultiSelectField or should this be a
new class inheriting from HTMLMultiSelectField? I think
HTMLMultiSelectField sounds more like describing what I just implemented
rather than a bunch of select boxes, but of course renaming the existing
one could "break" extensions (even though both are fully compatible and
interchangeable). So one option would be simply naming the new one
HTMLMultiSelectField2 if we don't want to stick with an additional option
here.
Cheers
Daniel
--
Daniel Werner
Software Engineer
Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.