Greetings!
I’m happy to let you know that we just enabled Media Viewer by default on the Japanese, Portuguese, Spanish and Swedish Wikipedias.
Our most recent survey results show increasing satisfaction with Media Viewer, across languages:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Survey/Results_-_05-…
We will send a more detailed update on these survey results later today.
Image load times continue to decline, as more people click on thumbnails, which caches them for faster display, as shown in this graph:
http://multimedia-metrics.wmflabs.org/graphs/mmv_performance_image_global
Next week, we plan to release Media Viewer on the Telugu Wikipedia on Tuesday, as well as Wikimedia Commons on Thursday.
You can find local announcements, translations and discussion pages for all our pilots here:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan#Large_W…
As always, please let us know if you encounter any serious technical issues, or share your views on this discussion page:
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer
Special thanks to everyone who made this release possible, especially our community partners on these sites: Oona and Henrique on the Portuguese Wikipedia, as well as Justine and Santi on the Spanish Wikipedia :)
Enjoy,
Fabrice — for the Multimedia Team
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
We've recently used OOUI for Media Viewer and had to make an effort to
"keep it in its own corner" due to its size. At the moment it's loaded on
demand when you click on a button that opens the dialog where all our
OOUI-dependent UI elements happen to be.
I was wondering if there was any plan to make OOUI more modular. Or if
there's somehow an option like that which we entirely missed. It's already
relatively large (41kb gzipped on beta right now) and likely to keep
growing. While I imagine that VE needs all of it, if the goal is for it to
be reused across all projects, it seems to be like the cold cache
experience could be improved if it was available in different parts that
can be loaded on demand.
Is something like that in the works? If not, what's the reasoning for
keeping it all under one JS file in production?
Maybe it will become so ubiquitous in mediawiki code that at some point in
the future it will make sense to load all of it as part of every page. But
to me it seems like OOUI is at a turning point at the moment, where teams
likes ours are judging whether or not they should use it for their project.
Which creates an entirely different situation, because project X has to
live with the consequences of being likely to be the way through which
users will load OOUI for the first time, just because it has more traffic
that the existing places where OOUI is currently deployed. And you don't
want to be the project that people feel is slow to open the first time they
use it, due to a dependency that is quite large compared to the small
portion that is really being used in the context of that project.
With that in mind, OOUI modularity is an important factor, in my opinion,
in the decision we're soon going to have to make as a team regarding
UploadWizard.
I've created mingle cards in our current cycle for that:
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/590https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/591https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/592
Those seem like non-trivial tasks, particularly because of external
dependencies and $.browser being removed. Finding out which feature
detection is appropriate in which case will probably be time-consuming.
---------- Forwarded message ----------
From: Krinkle <krinklemail(a)gmail.com>
Date: Wed, May 7, 2014 at 6:29 PM
Subject: [Wikitech-l] Upcoming jQuery upgrade (breaking change)
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Hey all,
TL;DR: jQuery will soon be upgraded from v1.8.3 to v1.11.x (the latest).
This
major release removes deprecated functionality. Please migrate away from
this
deprecated functionality as soon as possible.
It's been a long time coming but we're now finally upgrading the jQuery
package
that ships with MediaWiki.
We used to regularly upgrade jQuery in the past, but got stuck at v1.8 a
couple
of years ago due to lack of time and concern about disruption. Because of
this,
many developers have needed to work around bugs that were already fixed in
later
versions of jQuery. Thankfully, jQuery v1.9 (and its v2 counterpart) has
been
the first release in jQuery history that needed an upgrade guide[1][2].
It's a
major release that cleans up deprecated and dubious functionality.
Migration of existing code in extensions, gadgets, and user & site scripts
should be trivial (swapping one method for another, maybe with a slight
change
to the parameters passed). This is all documented in the upgrade
guide[1][2].
The upgrade guide may look scary (as it lists many of your favourite
methods),
but they are mostly just addressing edge cases.
== Call to action ==
This is a call for you, to:
1) Get familiar with http://jquery.com/upgrade-guide/1.9/.
2) Start migrating your code.
jQuery v1.9 is about removing deprecated functionality. The new
functionality is
already present in jQuery 1.8 or, in some cases, earlier.
3) Look out for deprecation warnings.
Once instrumentation has begun, using "?debug=true" will log jQuery
deprecation
warnings to the console. Look for ones marked "JQMIGRATE" [7]. You might
also
find deprecation notices from mediawiki.js, for more about those see the
mail
from last October [8].
== Plan ==
1) Instrumentation and logging
The first phase is to instrument jQuery to work out all the areas which will
need work. I have started work on loading jQuery Migrate alongside the
current
version of jQuery. I expect that to land in master this week [6], and roll
out on
Wikimedia wikis the week after. This will enable you to detect usage of most
deprecated functionality through your browser console. Don't forget the
upgrade
guide[1], as Migrate cannot detect everything.
2) Upgrade and Migrate
After this, the actual upgrade will take place, whilst Migrate stays. This
should not break anything since Migrate covers almost all functionality that
will be removed. The instrumentation and logging will remain during this
phase;
the only effective change at this point is whatever jQuery didn't think was
worth covering in Migrate or were just one of many bug fixes.
3) Finalise upgrade
Finally, we will remove the migration plugin (both the Migrate compatibility
layer and its instrumentation). This will bring us to a clean version of
latest
jQuery v1.x without compatibility hacks.
A rough timeline:
* 12 May 2014 (1.24wmf4 [9]): Phase 1 – Instrumentation and logging starts.
This
will run for 4 weeks (until June 9).
* 19 May 2014 (1.24wmf5): Phase 2 – "Upgrade and Migrate". This will run
for 3
weeks (upto June 9). The instrumentation continues during this period.
* 1 June 2014 (1.24wmf7) Finalise upgrade.
== FAQ ==
Q: The upgrade guide is for jQuery v1.9, what about jQuery v1.10 and v1.11?
A: Those are regular updates that only fix bugs and/or introduce
non-breaking
enhancements. Like jQuery v1.7 and v1.8, we can upgrade to those without any
hassle. We'll be fast-forwarding straight from v1.8 to v1.11.
Q: What about the jQuery Migrate plugin?
A: jQuery developed a plugin that adds back some of the removed features
(not
all, consult the upgrade guide[2] for details). It also logs usage of these
to
the console.
Q: When will the upgrade happen?
A: In the next few weeks, once we are happy that the impact is reasonably
low.
An update will be sent to wikitech-l just before this is done as a final
reminder.
This will be well before the MediaWiki 1.24 branch point for extension
authors
looking to maintain compatibility.
Q: When are we moving to jQuery v2.x?
A: We are not currently planing to do this. Despite the name, jQuery v2.x
doesn't contain any new features compared to jQuery v1 [3]. The main
difference
is in the reduced support for different browsers and environments; most
noticeably, jQuery 2.x drops support for Internet Explorer 8 and below,
which
MediaWiki is still supporting for now, and is outside the scope of this
work.
Both v1 and v2 continue to enjoy simultaneous releases for bug fixes and new
features. For example, jQuery released v1.11 and v2.1 together[4][5].
-- Krinkle
[1]
http://blog.jquery.com/2013/01/15/jquery-1-9-final-jquery-2-0-beta-migrate-
final-released/
[2] http://jquery.com/upgrade-guide/1.9/
[3] http://blog.jquery.com/2013/04/18/jquery-2-0-released/
[4] http://blog.jquery.com/2014/01/24/jquery-1-11-and-2-1-released/
[5] http://blog.jquery.com/2013/05/24/jquery-1-10-0-and-2-0-1-released/
[6] https://gerrit.wikimedia.org/r/131494
[7] https://github.com/jquery/jquery-migrate/blob/master/warnings.md
[8] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg72198.html
[9] https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Afternoon, all! Now marks another issue of our weekly multimedia update.
== Media Viewer ==
We're continuing our releases this week, rolling out to the following
Wikipedias as pilot sites for an opt-out feature:
* Japanese
* Portuguese
* Spanish
* Swedish
Next Tuesday, we'll be releasing the viewer on Telugu Wikipedia, and also
possibly on Kannada Wikipedia.
We've also accomplished some bug fixes in the past week:
* Some fixes for Hebrew i18n [0] [1]
* A fix for the metadata panel [2]
Mostly our work was on metrics and some other maintenance, but we did also
add a "preferences" link to the viewer [3] and fix up displays of metadata
on various wikis [4].
This week, we'll likely add a very basic "zoom" button to the viewer, but
other work is stalled until another week.
== UploadWizard ==
I did a bunch of work on old-ish UploadWizard patches that mostly deal
with code conventions and jshint compliance. Some were merged. Others
will get worked on further in coming weeks.
This week we'll be working more on the metrics we've already started to
gather for UploadWizard - adding the later wizard steps to the schemata
and instrumentation - and likely working on analysis scripts.
== Other ==
Finally, we'll be working on a first-pass strategy for thumbnailing. There
have been issues with the image scalers lately, and helping to deal with
the additional load we've been putting on them is part of our priority for
the coming weeks.
== Communications ==
As ever, use the multimedia list or the #wikimedia-multimedia IRC channel
to contact the team and the community if you have any questions or concerns.
[0] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/553
[1] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/550
[2] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/548
[3] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/490
[4] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/249
Have a good week, and see some of you in Zurich!
--
Mark Holmquist
Software Engineer, Multimedia
Wikimedia Foundation
mtraceur(a)member.fsf.org
https://wikimediafoundation.org/wiki/User:MHolmquist
On Fri, Apr 25, 2014 at 6:27 PM, Ori Livneh <ori(a)wikimedia.org> wrote:
> On Thu, Apr 17, 2014 at 1:13 AM, Gilles Dubuc <gilles(a)wikimedia.org>wrote:
>>
>> When the user opens media viewer, but there are 4 API calls per image and
>> we preload the next/previous images fairly quickly after opening one. So
>> generally within a few seconds, you're looking at 12 API calls when opening
>> Media Viewer.
>>
>
> That's way too high. Since you're planning to deploy this soon, we should
> figure out how to meet the requirements using the infrastructure that we
> have rather than the one we'd like to have. Have you considered adding a
> MediaWiki API module to your extension that composes the data into a single
> response? You could do this without duplicating code by
> constructing DerivativeRequest objects to each endpoint, as described in <
> https://www.mediawiki.org/wiki/API:Calling_internally>.
>
This is the current behavior (in master):
- one filerepoinfo API call per page
- one imageinfo, imageusage, globalusage API call per image
- depending on the language, there might be a users API call per image,
possibly to another wiki (Commons).
- there might be another imageinfo call to get sizes for a specific
thumbnail. This on the file type/size, should be very rare.
All but the imageinfo call are cached on Varnish for one day. (Caching
imageinfo for more than a few minutes would be more problematic as users
would expect to see changes to image description etc. immediately.)
Merging filerepoinfo/imageinfo/imageusage/globalusage into a single API
call should be possible even on the client side, but it would mean that we
cannot cache anything; not sure how that affects server load (I suppose the
API has its own caching mechanism, but even that must have some overhead
compared to Varnish). Similarly, merging multiple calls to the same API
would be possible but would make caching mostly useless.
The users API call can go to a different wiki, so would be very difficult
to merge it directly with the other calls. We only use it to get the gender
of the uploader, though; maybe that information could be added to the
imageinfo API, which has its own mechanism of handling remote filerepos.
If you absolutely had to cut some functionality out in order to roll this
> out more broadly, what would you eliminate?
IMO we could get rid of the users, imageusage and globalusage calls without
much trouble. The first one is only used for gender-correct translations.
The other two are used to show some pages which use the image - since there
is not enough place on the UI to show more than a few, this is not a very
useful feature as it exists now.
We could also only enable preloading after the user has used prev/next
navigation for the first time.
Hi all,
it has been requested [1] that we localize "File:" in the wikitext that
MediaViewer suggests for embedding the image on a wiki page, so that for
example in the French Wikipedia the text would be [[Fichier:...]] instead
of [[File:...]].
Turns out this is problematic, since users might want to use the text on a
different wiki which has a different content language, and the namespace
name would not be recognized, while File works everywhere.
I can see three options:
1. use localized namespace name, accept that it will break when users try
to use it cross-wiki
2. use canonical (English) namespace name
3. use [[{{subst:ns:File}}:...]] which will translate into the local
namespace name when the page is saved.
1 seems like a bad option overall; 2 might go against community standards;
3 feels like a hack and makes newbies' first meeting with wikitext more
traumatic than it has to be. We are hesitating between option 2 and 3; we
would welcome comments on which one would be preferred by editors.
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=64710
Hi all,
I've been asked how to make templates that can provide information for
MediaViewer to display on the metadata panel; I will try to give a few
pointers.
== Metadata types that are already handled ==
If you want to ensure the some type of metadata that is already handled by
MediaViewer (license, description, author name etc.) will be read correctly
for files which have been uploaded to your wiki, you need to present it in
the same way it is presented on Commons. See the first two sections of
COM:MRD [1] (infobox templates, license templates) on how to do that.
(Also, COM:GEO [2] although currently it is not very helpful for figuring
out how to make location templates in other wikis compatible.)
tl;dr: you need to add a certain HTML id or class to some container element
in the template, and another one to the specific text that you want to be
machine-readable (such as the license name) - this usually means wrapping
the text in a <span> which does not change anything visually (or maybe
hides the text completely) but has a certain class or id.
So in practice it will look something like this:
<div class="licensetpl">
(lots of fancy HTML)
Licensed under the <span class="licensetpl_long">Do What the Fuck You Want
to Public License</span> (<span class="licensetpl_short">WTFPL</span>).
<span class="licensetpl_attr_req" style="display: none">false</span>
(more fancy HTML)
</div>
Alternatively, if you don't want to mess with existing template code, you
can just add all the information in hidden fields, the way the PD templates
do it on Commons [3]. If you have lots of templates for the same license,
and they do not share a common layout template, this way it can be done by
a bot.
== New metadata types ==
If you want to add some new kind of information to MediaViewer, you need to
make sure there is a template which will provide it in the way described
above (have a class that wraps the whole template plus a class for each
specific piece of information you want to read from it).
Just marking up the template as a whole will probably not be enough. That
way MediaViewer gets a big HTML blob instead of proper metadata. We would
really like to avoid displaying big blobs of HTML which will clash with the
design of the viewer in uncontrollable ways. We made an exception with
permission templates, because they are important (also there is lots of
them, and marking all up properly would be herculean work), we would prefer
if we didn't need to make more. So please try to figure out what is the
specific text (or link, logo image, whatever) that needs to be shown, and
add specific markup for that.
(Also, before putting a lot of work into making some templates provide
metadata, make sure somebody is willing to implement it on the MediaViewer
side!)
== IQ&A (answers to imaginary questions) ==
Q: Is the class wrapping the whole template ("licensetpl" in the above
example) important?
A: Yes! We use it to know which fields belong together when multiple
templates of the same type are used on the page.
Q: I am adapting templates for a new type of metadata. Should I use ids or
classes?
A: Classes. Please. Using ids is almost always a bad idea. Using the same
id twice on a page is invalid HTML and can cause unexpected behavior (XML
parsers choking on the page, CSS selectors not returning all matching
elements etc). You might think that the template will never need to be used
twice on a page, but you will probably be proven wrong eventually.
(Also, ids are more trouble when adding CSS styles. Although using the same
id/class for marking up metadata and for styling the content is probably a
bad idea in itself.)
Q: I want to mark up templates on my local wiki to be compatible with
Commons templates. Are all the fields described on COM:MRD used by
MediaViewer?
A: No, most aren't. You can check the source code [4] if you need an exact
list. (It is not as hard as it sounds!)
Q: Does all information come from the templates described on COM:MRD?
A: No, some comes from categories (specifically assessment data such as
featured image status - although we do not display it yet). That will not
work for non-Commons-hosted images :( If you want to help with fixing that,
see the previous section.
Q: What about internationalization?
A: If the template uses MediaWiki messages for localization, that will
work. Other methods probably won't. (Language templates like {{en}} work in
{{Information}} and similar templates, but that's probably not a method
that can be used for other types of metadata.)
[1] https://commons.wikimedia.org/wiki/Commons:Machine-readable_data
[2] https://commons.wikimedia.org/wiki/Commons:Geocoding
[3]
https://commons.wikimedia.org/w/index.php?title=Template:PD-Layout&action=r…
[4]
https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FCommonsMetadata/mas…
Hi everyone,
Keegan and I reviewed our release plan for Media Viewer today and would like to update it based on community feedback.
We propose to spread out the release to large wikis over the next 3 weeks, so we can better focus on each community’s needs. Next week, we would like to deploy on the French and Dutch Wikipedias, and carefully evaluate the performance and community feedback on these first large sites.
At the request of our community partners, we would like to push back to the following week the release to Portuguese, Swedish and a few other wikis. This will give their users two weeks to test it out in beta and and give us more feedback — and it will enable us to carefully review the performance and community response on our first large wikis and pilot sites before deploying widely on a lot of large wikis. And a week later, we would release to English, German, Italian and Russian, which are likely to require more community interaction.
Here is the updated schedule we recommend:
• May 1:
Dutch and French Wikipedias
• May 8:
Japanese, Portuguese, Spanish, Swedish, Telugu? Wikipedias, Wikimedia Commons
• May 15:
English, German, Italian and Russian Wikipedias
• May 22:
Enable by default on all wikis
Does this plan work for you? Any comments or recommendations?
You can read more here:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan#Large_W…
We’ve added links to local pages or surveys on many of these sites. If we are missing a link to an important announcement or discussion, you are welcome to add it on this page. :)
Thanks for all your help with this project. Have a wonderful weekend!
Fabrice
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
Thanks for the great work on the dashboard, Gergo!
I was wondering if it's possible, and if it would make sense to everyone,
that we filter changesets that start with WIP or [WIP] and have a separate
section at the very bottom for them?
Looking at the MultimediaViewer section of the dashboard, I find that
almost half of the changesets are marked as WIP and reviewing them when
they're at that stage makes sense if the author explicitly invites people
to (when it's a work-in-progress, but advanced enough for review).