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...
Hi,
I have already noted that I work on extension which allows displaying
of user online status, see
https://bugzilla.wikimedia.org/show_bug.cgi?id=32128, Krinkle come
with idea that it could use ajax on user pages for status bar in order
to avoid cache issues while keep performance of interface (if cache
would need to be suppressed it would have probably negative effect on
performance althought it would happen rarely). I like that idea,
however I have no experience with ajax. If anyone who understand ajax
wanted to help it would be most appreciated!
Thanks
Is there any documentation on using the QueryPage class in an extension? I'd like to create a special page with the QueryPage features but am running into problems "hooking it up" to run. I don't see any QueryPage docs on mediawiki.org or meta. (Or is there a more modern way to get a paging Special Page?)
First I defined my subclass of QueryPage with some dummy methods:
class MyQueryPageClassName extends QueryPage {
function getName() { return 'My Query Page'; }
function getSQL() { return "select 1 as 'test'"; }
function formatResult() { return 'dummy result'; }
}
Then I hooked up my page with:
$wgHooks['wgQueryPages'][] = 'wfMyQueryPages';
function wfMtQueryPages(&$wgQueryPages) {
$wgQueryPages[] = array('MyQueryPageClassName', 'MyQueryPage');
return true;
}
At this point, the special page does not exist on the wiki. What else needs to be done to make this work?
I looked at SpecialPopularpages.php and see a global function wfSpecialPopularpages() at the end that looks necessary, but I don't see anything that calls it in the code. How does this really work? I created my own version but nothing seems to call it.
/**
* Constructor
*/
function wfMyQueryPage() {
list( $limit, $offset ) = wfCheckLimits();
$ppp = new MyQueryPageClassName();
return $ppp->doQuery( $offset, $limit );
}
Any help appreciated.
Thanks,
DanB
Just got this email from Joe Corneli. This would be a great time to
start working with interested people about integrating Etherpad with
MediaWiki.
Please reply on the designated etherpad if you are interested:
http://beta.primarypad.com/p/2r5ViOLFvL
---------- Forwarded message ----------
From: Joe Corneli <holtzermann17(a)gmail.com>
Date: Thu, Dec 1, 2011 at 3:01 PM
Subject: Etherpad International Hackathon 2012
To: Etherpad Open Source Developers <etherpad-dev(a)googlegroups.com>,
etherpad-lite-dev(a)googlegroups.com,
etherpad-open-source-discuss(a)googlegroups.com
Cc: Constantin Jucovschi <jucovschi(a)gmail.com>
Hi all:
I'd like to start organizing a set of meetups to work on Etherpad
stuff early next year. My guess is that January is a good time. Last
year we had Europe and East Coast meetings, so let's see if we can
manage at least that, again, this year.
Last year's meetings were in Bradford UK and at Olin College in
Needham, MA. This year's locations are not decided yet.
If you would be interested in attending or hosting an Etherpad hacking
event in January, please let us know:
(1) Where you are!
(2) Do you have any funding needs? (Thanks to our generous donors,
we have a small budget that can be allocated for legitimate/useful
expenses.)
(3) What dates would work best for you?
(4) What project or task might you want to tackle during the meet-up?
Other thoughts:
* for any students on the list: you may be able to get "Intersession"
credits for working on Etherpad.
* for any companies on the list: this could be a good "sponsorship"
opportunity - let's discuss any ideas!
I'm creating a pad at http://beta.primarypad.com/p/2r5ViOLFvL to
record answers or ideas, so we can avoid cross-posting a drawn out
discussion to all of these lists. Do however feel free to forward
this message to anyone who you think might be interested.
Cheers,
Joe