Just want to give a quick shout-out to a feature that John Du Hart's been
working on: debug toolbar!
This is a pretty spiffy-looking upgrade from the old $wgDebugComments mode
(which exported debug log items into <!-- HTML comments --> at the end of
each page). This exports the log items, and a few other bits of info such
as query data, into JSON which then gets rendered as an attractive
slide-out panel at the bottom of the window.
It can use some tweaking, but I think it's going to be helpful for a lot of
devs -- please try it out and give John your feedback! (Warning: current
version may have some HTML injection vectors, don't use on production
sites.)
Enable:
$wgDebugToolbar = true;
-- brion
A resend, but starting pretty much now.
Hey guys!
The WMF features team has been experimenting with holding our weekly
status meetings over IRC.
One of the ideas that came up was that we might want to try having an
"open" meeting - sort of like an office hours - that anyone in the
community can join and possibly ask questions.
So, we're inviting you.
This coming Tuesday, December 6th, at 11 AM PST, we'll be gathering on
irc.freenode.net in channel #wikimedia-dev. For the first bit, we'll
probably want to hold questions and answers until after we've had a
chance to give our statuses, but after that, feel free to ask about
anything.
And if no one else shows up, I'll at least have a whole IRC channel to
myself.
-b.
--
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Earlier this month, Wikimedia staff and volunteers got together in
Mumbai, India to work on mobile, offline, and
internationalisation/localisation.
https://www.mediawiki.org/wiki/India_Hackathon_2011
Photos are up:
http://en.wikipedia.org/wiki/User:Victorgrigas#Hackathon_Mumbai_2011
Some notes on our outcomes, which included many new localisations for
Kiwix and new input methods for MediaWiki, readying Narayam for
Wikimedia Incubator, a prototype onscreen keyboard built in Narayam,
Wikimedia Mobile ready for translation, new UI prototypes for language
selection, and more:
https://www.mediawiki.org/wiki/India_Hackathon_2011/Schedule_notes#Day_1_ou…
And I haven't even touched on mobile! An update specifically on mobile
progress at the hackathon:
http://lists.wikimedia.org/pipermail/mobile-l/2011-November/005200.html
-- Summary from Phil Chang:
> In summary, over one weekend more than 50 volunteers from many parts of
> India added their hard work and insights to the technical foundation of
> Wikipedia. In the mobile area alone, volunteers contributed to 17 features,
> as listed here (features that were worked on are marked with an "H"):
>
> http://meta.wikimedia.org/wiki/Mobile_Projects/features#India_Hackathon
>
> We also got support and input from most of the major mobile operators in
> India about how to make our user experience better. Free access to
> Wikipedia is moving forward on a number of fronts, as we identified several
> forms of collaboration, not just in the form of Wikipedia Zero. For
> example, there seems to be widespread interest in using an RSS feed of the
> Article of the Day, and the top 5 languages in India are important.
I'm asking Emmanuel to send an offline-related summary to
https://lists.wikimedia.org/mailman/listinfo/offline-l . And I'm
predicting the localization folks will have a summary in their next
showcase; watch
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n .
This was the largest Wikimedia tech outreach event I've been a part of,
with 80 or so new folks learning and becoming contributors. Thanks to
the Wikimedia staffers who came, for -- as Alolita put it -- "leading
project teams to do some nice development, UI design, testing and
accomplishing a lot in a short blip of time." Thanks to the local
community and chapter for putting on Wiki Conference India, which
happened at the same time:
https://meta.wikimedia.org/wiki/WikiConference_India_2011
Sorry to be brief; more details are at the links provided. I know that
the i18n team also led a translation sprint and an intro to MediaWiki
hacking in Pune after the Mumbai hackathon, but I'll leave it to them in
case they want to report about that.
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
Hello,
I need an html dump of Wikipedia but the link http://static.wikipedia.org/ does
not work.
I'd appreciate any explanation or suggestion.
Regards
Ben Sidi Ahmed
Hi everyone,
In trying to figure out where the bottlenecks are, it seemed it would
be helpful to have a breakdown of the revisions. So, here's the first
of many revision reports for 1.19:
https://www.mediawiki.org/wiki/MediaWiki_roadmap/1.19/Revision_report
This updated report now contains three sections:
* New revisions by tag
* New revisions by author
* Fixmes
There are several helpful things that jump out now:
* Many, many untagged revisions. I think would be very helpful for
those doing review to have revisions tagged by product area (e.g.
"parser", "frontend", etc). We
* The new revisions by author is a new view, and it's pretty helpful
to see the big picture. For example, it looks like Aaron, Patrick,
Roan, and Sam have a ton of stuff to review. It may be helpful for
those people to pair up with (other) reviewers for some real-time
reviews of their code.
Rob
I'm a developer at Wikia. We have a use case for searching through a file's
metadata. This task is challenging now, because the field
Image.img_metadata is a blob.
We propose expanding the metadata field into a new table. We propose the
name image_metadata. It will have three columns: img_name, attribute
(varchar) and value (varchar). It can be joined with Image on img_name.
On the application side, LocalFile's load* and decodeRow methods will have
to be changed to support the new table.
One issue to consider is the file archive. Should we replicate the metadata
table for file archive? Or serialize the data and store it in a new table
(something like fa_metadata)?
Please let us know if you see any issues with this plan. We hope that this
will be useful to the MediaWiki project, and a candidate to merge back.
Thanks,
Will
On Mon, Nov 28, 2011 at 3:16 PM, Brion Vibber <brion(a)pobox.com> wrote:
> On Mon, Nov 28, 2011 at 3:05 PM, MZMcBride <z(a)mzmcbride.com> wrote:
>
>> Brion Vibber wrote:
>>
> [snip my notes about removing the non-PNG non-source options, wanting
> higher-resolution renderings]
>
>> Did you have a chance to evaluate MathJax? <http://www.mathjax.org/> I
>> know
>> it's come up in past math discussions and that a lot of math folks think
>> it
>> looks promising. A technical analysis of its feasibility on Wikimedia
>> wikis
>> would be great. Killing the less-used, ancient math options is great, but
>> perhaps adding one wouldn't be too bad to do too. :-)
>>
>
> That's an excellent thing to bring up -- MathJAX *does* look very
> promising, and things seem to render pretty nicely. Need to make sure that
> we can either do that type of rendering cleanly with the PNG fallback
> (older browsers will still need the PNGs, so it may still be worth spending
> the time to fix baselines).
>
I've done a quick experimental mode commit:
<https://www.mediawiki.org/wiki/Special:Code/MediaWiki/104521>
definitely promising in terms of things look nice. :)
Total library size is pretty large but that includes a bunch of fallback
images which will be rarely used; don't have a good sense of the 'weight'
of including the library yet. It does load a bit slowly, but hopefully
won't interfere much while it does so.
The initial method I'm using is to output the latex source in a <script
type="math/tex"> which MathJax recognizes, and then putting the image or
text source form in a <noscript> next to it. Browsers with JS off or
unavailable will use the fallback image/text silently, while those with
script will get the pretty math inserted at runtime.
This isn't perfect though, and for instance breaks on MobileFrontend
because the <script> that actually _loads_ MathJax doesn't get loaded, and
on top of that the fallback images are still in <noscript>. ;) Also,
browsers that have script support but don't work with MathJax won't load
images, so this is insufficient.
Most compatible thing is probably to let it include the images/text form
as-is, then make sure MathJax goes over and replaces them in-place. It
might need tweaks to understand the images (source in alt text).
I'm hoping to get some feedback and advice from folks who have worked with
MathJax previously; I'll whip up some detail notes as an RFC page in a bit.
-- brion
Hi all,
We've had @wikimediatech accounts on twitter & identica for some time now:
* http://identi.ca/wikimediatech
* https://twitter.com/#!/wikimediatech
that basically broadcast every single action that is logged to the
server admin log:
* http://wikitech.wikimedia.org/view/Server_admin_log
The account has 78 followers on identica and 430 on twitter (probably
counting the spammers).
I'm wondering if there are actually people reading all the stuff
that's pushed through these channels.
My gut feeling is that the few people reading these feeds are also
those that would know to check the SLA if they encountered an issue,
or know how to use the RSS feed of the SLA page if they really wanted
the information in real time.
Meanwhile, we don't really have social media channels dedicated to
Wikimedia tech stuff, i.e. channels where we can actually post stuff,
links, blog posts, outage info, etc and engage with a larger community
of people interested in our tech operations. I feel that the accounts
would be much more useful if we reduced the amount of semi-random
information we post there.
So, I'm basically proposing to repurpose the @wikimediatech accounts for this.
Thoughts? Good idea? Bad idea? You don't care?
--
Guillaume Paumier
Technical Communications Manager — Wikimedia Foundation
http://donate.wikimedia.org
I've made an initial stab at trying to get the baseline offset for
rasterized math images; patch attached on:
https://bugzilla.wikimedia.org/show_bug.cgi?id=32694
this is a feature from Blahtex that was much requested here for helping
image renderings to match up with the surrounding text, and is done by
getting the --depth option offset from dvipng (which itself needs the
'preview' latex package to be present to get reliable results).
Unfortunately in my offhand tests this isn't giving good results; I'm
getting 0 or 1px baseline depth offsets despite having descender letters
(like "q") or using "tall" constructs like a square root or fraction. The
result is images that are higher up than they ought to be, whereas in the
default centering positioning they are often slightly lower than they ought
to be.
I'm not sure whether I'm doing something wrong, or whether the baseline
depth that is retrieved is actually bogus to begin with. Need to compare in
more detail against blahtex maybe...
... if we can't get this working, it's less of a big deal assuming MathJax
can be set up to load fairly transparently, as that'll fix things up nice.
-- brion
> Message: 7
> Date: Thu, 1 Dec 2011 12:36:02 -0500
> From: Chad <innocentkiller(a)gmail.com>
> Subject: Re: [Wikitech-l] Proposal for new table image_metadata
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <CADn73rNuSX8RegdUBCeSYG8Mz1qg5SA49VAmB5eD_Y-vB-L4dw(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, Dec 1, 2011 at 12:34 PM, William Lee <wlee(a)wikia-inc.com> wrote:
> > I'm a developer at Wikia. We have a use case for searching through a file's
> > metadata. This task is challenging now, because the field
> > Image.img_metadata is a blob.
> >
> > We propose expanding the metadata field into a new table. We propose the
> > name image_metadata. It will have three columns: img_name, attribute
> > (varchar) and value (varchar). It can be joined with Image on img_name.
> >
> > On the application side, LocalFile's load* and decodeRow methods will have
> > to be changed to support the new table.
> >
> > One issue to consider is the file archive. Should we replicate the metadata
> > table for file archive? Or serialize the data and store it in a new table
> > (something like fa_metadata)?
> >
> > Please let us know if you see any issues with this plan. We hope that this
> > will be useful to the MediaWiki project, and a candidate to merge back.
> >
>
> That was part of bawolff's plan last summer for GSoC when he overhauled
> our metadata support. He got a lot of his project done, but never quite got
> to this point. Something we'd definitely like to see though!
>
> -Chad
>
>
Chad beat me to writing essentially what I was going to say. Basically
my project ended up being more about extracting more information, and
i didn't really touch what we did with it after we extracted.
However, it should be noted that storing the image metadata nicely is
a little more complicated then it appears at first glance (and that's
mostly my fault due to stuff i added during gsoc ;)
Basically there's 4 different types of metadata values we store (in
terms of the types of metadata you think of when you think EXIF et al.
We stuff other stuff into img_metadata for extra fun)
*Normal values - Things like Shutter speed = 1/110
*unordered array - For example we can extract a "tags" field that's an
arbitrary list of tags, The subject field (from XMP) is an unordered
list, etc
*Ordered array - Not used for a whole lot Most prominent example is
the XMP author field is supposed to be an ordered list of authors, in
order of importance. Honestly, we could just ditch caring about this,
and probably nobody would notice.
*Language array - XMP and PNG text chunks support a special value
where you can specify language alternatives. In essence this looks
like an associative array of "lang-code" => "translation of field into
that lang", plus a special fallback "x-default" dummy lang code.
*Also Contact info and software fields are stored kind of weirdly....
Thus, just storing a table of key/value pairs is kind of problematic -
how do you store an "array" value. Additionally you have to consider
finding info. You probably want to efficiently be able to search
through lang values in a specific language, or for a specific property
and not caring for the language.
Also consider how big a metadata field can get. Theoretically it's not
really limited, well I don't expect it to be huge, > 255 bytes of
utf-8 seems a totally reasonable size for a value of a metadata field.
Last of all, you have to keep in mind all sorts of stuff is stored in
the img_metadata. This includes things like the text layer of Djvu
files (although arguably that shouldn't be stored there...) and other
handler specific things (OggHandler stores some very complex
structures in img_metadata). Of course, we could just keep the
img_metadata blob there, and simply stop using it for "exif-like"
data, but continue using it for handler specific ugly metadata that's
generally invisible to user [probably a good idea. The two types of
data are actually quite different].
> One issue to consider is the file archive. Should we replicate the metadata
> table for file archive? Or serialize the data and store it in a new table
> (something like fa_metadata)?
Honestly, I wouldn't worry about that, especially in the beginning. As
far as i know, the only place fa_metadata/oi_metadata is used, is that
you can request it via api (I suppose it's copied over during file
reverts as well). I don't think anyone uses that field on archived
images really. (maybe one day bug 26741 will be fixed and this would
be less of a concern).
Anyhow, I do believe it would be awesome to store this data better. I
can definitely think of many uses for being able to efficiently query
it. (While I'm on the subject, making lucene index it would also be
awesome).
Cheers,
Bawolff
p.s. If its helpful - some of my ideas from last year for making a new
metadata table are at
http://www.mediawiki.org/wiki/User:Bawolff/metadata_table and the
thread http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/48268
. However, they're probably over-complicated/otherwise not ideal (I
was naive back then ;). They also try and be able to encode anything
encodable by XMP, which is most definitely a bad idea, since XMP is
very complicated...