I noticed that one of the images uploaded to my Wiki is showing the following:
Error creating thumbnail: Invalid thumbnail parameters instead of a thumbnail.
Its a PNG image, not an SVG. There is no message in any of the log files that
I can see. Im not entirely sure how to go about diagnosing this.
Image Details:
File:Lab Map.png
(6,001 × 2,387 pixels, file size: 1,003 KB, MIME type: image/png)
Any ideas what the issue might be or where I could look for more info?
Thank you,
Derric Atzrott
Computer Specialist
Alizee Pathology
Hi folks,
As many of you may recall, we had some great conversations in
Amsterdam about how to move the architecture of MediaWiki forward (see
notes from last meeting [1]) One of the many things we resolved to do
was to have similar conversations when we had a critical mass of
developers convened in any one area geographically.
Since a number of us are in Hong Kong, we reserved a spot on the
calendar for 14:00-17:00 (Hong Kong time) tomorrow (see schedule[2]).
Tim Starling is a pretty critical attendee for this conversation, but
couldn't join us in person, but we're going to try to figure out how
to pull him in virtually with any luck.
We hope we can use this time to renew our momentum on architecture
guidelines as well as keep things going on the RFC process.
Those of you who aren't here in Hong Kong who are worried about us
settling things without you getting a say: don't worry. While we hope
to make good progress, this isn't meant to exclude discussion on the
mailing list, and we plan to have minutes available as well as to
continue conversation on this list.
The agenda for this meeting is here:
https://www.mediawiki.org/wiki/Architecture_guidelines/Meetings/Wikimania_2…
We're looking forward to a productive meeting!
Rob
[1] Notes from Amsterdam Hackathon Architecture discussion:
http://lists.wikimedia.org/pipermail/wikitech-l/2013-May/069569.html
[2] Agenda for Wikimania DevCamp:
https://wikimania2013.wikimedia.org/wiki/DevCamp/Schedule
Hi everyone,
There have been a couple of conversations recently and I am hoping to
combine them into a discussion towards a long term strategy for math on
Wikipedia.
To get things rolling, I've added a few topics below which a strategy could
address.
Perhaps a disclaimer: I manage the MathJax project. Also, I've tried to be
brief but I may have compressed too much.
Peter.
(1) math output
Currently, low resolution PNGs are the default and registered users have an
option for MathJax (except on mobile). MathML3 is the web standard for math
and part of HTML5 and epub3.
Does Wikipedia want to adopt MathML output in the long term?
MathML is still facing a chicken-and-egg problem: little browser support
means little content means little browser support etc. While it's been in
use for over a decade, most MathML is hidden on intranets (technical
documentation) and behind paywalls (publishing). But there's clearly demand
-- e.g. MathJax CDN gets 65 million unique visitors per month.
Wikipedia's long term adoption of MathML would help this crucial web
standard for education and research since browser vendors will see the
content on the open web.
But a web standard is not a value in itself -- luckily MathML has real
advantages.
* accessibility
The few existing math accessibility tools (MathPlayer, ChromeVox, FireVox)
only work with MathML. Modern accessibility features like synchronized
highlighting (for learning disabled readers) is basically impossible with
image rendering.
* rendering quality
Image renderings are not only inaccessible, they lack quality and
flexibility. Reflow, CSS, alignments are the classic problems. Static
images could be improved via SVG but even these would not be accessible or
participate in line breaking. MathML integrates naturally into HTML.
* dynamic content
Math and science are becoming native on the web -- data and markup is not
forced into image renderings anymore, instead dynamic and interactive
content is finally showing up.
These don't fit into the current authoring and rendering solution on
Wikipedia. MathML would be a critical first step towards richer scientific
content.
* editing
Editing math is an obstacle for Wikipedia users. The GSoC project for math
in VE has a lot of potential to lower the barrier. But a live preview is
not very feasible with server side image generation.
(2) math input
wikitext is human readable and serialized so MathML does not seem to fit.
But TeX-syntax is robust and powerful to create any MathML construct. Texvc
has limitations (unicode support, graphical and dynamic content), but the
syntax could be extended to overcome these and to produce dynamic content
(mathapedia is a nice example).
An extended TeX-like syntax might serve as a safe abstraction for tools
like d3.js, processing.js, ensuring that Wikipedia content is not dependent
on specific rendering solutions. The same holds for physical, chemical and
biological markup. Such TeX extensions do make backwards compatibility to
real TeX/LaTeX more difficult.
(3) First steps towards a transition.
Client-side, only Firefox has decent support, so a polyfill like MathJax
would be needed for a while. Performance, especially on mobile, would need
a thorough investigation.
Server side, there are a number of tools for converting TeX to MathML, in
particular the recent work by Martin Schubotz towards integrating LaTeXML
(a fully featured LaTeX to XML converter); there's also BlahTeX and MathJax
via js-runners.
The question regarding new forms of content and wikitext might be important
for both client and server side solutions.
To pull in the entire community, something like bug 48036 (easier MathJax
opt-in) would be great. It would allow people to vote with their feet and
tell us continually if the benefits of MathML are worth the cost.
Last week, we moved wikidata traffic in eqiad (so in practice, all non-European traffic) from Squid to the new text Varnish cluster. A few issues were found and fixed, and we haven't seen any new issues for several days.
Today I've done the same for Wikivoyage. Non-European Wikivoyage traffic, served by our eqiad cluster, is now served by Varnish. Wikivoyage has a bigger portion of normal users vs. API/bot traffic, so some new issues could surface.
Please let us know if you see any problems on Wikivoyage that might be related to the Varnish migration; file a Bugzilla ticket or mail me directly.
Thanks!
--
Mark Bergsma <mark(a)wikimedia.org>
Lead Operations Architect
Wikimedia Foundation
hi,
in visual editor, would it be possible to edit only a paragraph, when one
clicks the edit link on a paragraph? if not, why not? currently an a decent
laptop, clicking the "edit" link on whatever page or section takes at least
4 seconds. this is unexpectedly slow.
i tried to create a bug to discuss splitting VE up to only edit parts of a
page, see below. andre klapper suggested this ideally is broken up into
requirements easier to implement, and i should post this to wikitext-l. as
i did not see any discussion going on there about VE i tried here. please
forward if this to the appropriate channel if i did not get it right again.
rupert
---------- Forwarded message ----------
From: <bugzilla-daemon(a)wikimedia.org>
Date: Fri, Aug 2, 2013 at 11:03 AM
Subject: [Bug 52380] split up VE into components, clickable via links where
it is applicable
To: rupert.thurner(a)gmail.com
Andre Klapper <aklapper(a)wikimedia.org> changed bug
52380<https://bugzilla.wikimedia.org/show_bug.cgi?id=52380>
WhatRemovedAddedStatusREOPENEDRESOLVED Resolution---WONTFIX
*Comment # 5 <https://bugzilla.wikimedia.org/show_bug.cgi?id=52380#c5> on bug
52380 <https://bugzilla.wikimedia.org/show_bug.cgi?id=52380> from Andre
Klapper <aklapper(a)wikimedia.org>*
Please discuss such huge design decision suggestions first with developers on a
mailing list, like http://lists.wikimedia.org/pipermail/wikitext-l/ , to break
them down into manageable subtasks. Even if this was a valid request, it's
pretty unhandable to define when this good be "fixed".
I mark your proposed solution again as WONTFIX, as bug reports should be about
problems instead. Please leave it like that as the solution proposed here is
not planned to be implemented by developers like that.
I have just had to deal with this - AGAIN - and would like to rail for a
moment, hoping to provoke discussion to promote change. I posit that this
is big enough to deserve a Foundation-wide venue for initial discussion so
am including Wikitech-L.
Most of us are probably familiar with the cycle:
Person A on en.wp (or, any project) uploads an image which is apparently
public domain or free use by any reasonable standard. It gets put on
article X. There is much rejoicing.
Person B later thinks "Oh, this is something other projects might use, and
it's 'free', so..." and uploads it to Commons. It then gets deleted at
en.wp by a helpful bot.
Person C on Commons later identifies that it fails to be an entirely free
piece under the much-stricter Commons rules, due to some factor that A and
B were unaware of. Person C nominates it for deletion there. Poof. Gone.
Now, we have NO image, for something that is sufficiently legal under our
rules and the law for use on en.wp (and likely, most of the rest of the
projects). A delinker bot helpfully comes along and nukes references to
the image off the pages that used to have it. Maintainers who miss the bot
edit fail to notice that it's gone. Many months or years go along and
finally someone notices, and either is an admin and restores the image on
en.wp or finds an admin who restores it on en.wp.
Now, for someone who sees images as an integral part of the total
READERSHIP value we present, in terms of helping people understand things
by drawing their attention and expressing ideas and history in a visual
manner, the long periods where we've lost all image are mind-numbingly
counter to our core mission. That we've evolved into this cycle due to
bureaucratic friction does not make it acceptable.
PROPOSED: This is not acceptable. Something must be done.
SUGGESTED FIX #1: Create a parallel "Uncommons" project, for shared images
which meet minimum project legal non-copyvio standards but do not meet the
threshold Commons is insisting on (or we have defined Commons to be). This
requires coding in the WMF to allow a parallel project as image source, and
would require that Commons' deletion process be modified such that
deletions for copyright niggles be a shift-to-Uncommons rather than an
outright delete.
SUGGESTED FIX #2: Stop deleting things from local projects when they're
uploaded to commons. This requires additional diskspace from the
Foundation (by some as-yet unknown amount). Ops team - Could you attempt
to determine if this would be significant, troublesome, small enough to not
be significant, etc?
These are not the only two possible solutions, but they come to mind
immediately (and have previously when I thought of this). Additional fix
concepts solicited and welcomed.
--
-george william herbert
george.herbert(a)gmail.com
Found an interesting article on providing ARIA hints for making web forms
as accessible as possible:
http://thombergs.wordpress.com/2013/08/04/accessible-web-forms/
Luckily MediaWiki already uses label tags and fieldsets automatically, but
there was some stuff I had no idea even existed, so I though it might be
interesting.
*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | tylerromeo(a)gmail.com