On Fri, Oct 16, 2015 at 2:50 PM, Brian Gerstle <bgerstle(a)wikimedia.org>
wrote:
I've mentioned this idea before, but having a
service which allowed you to
reliably get image thumbs for a given file at a specified width/height
would obviate the srcset.
Our thumbs are already created on demand, based on the image width
specified in the URL. Example for a 40px wide thumb:
The corresponding Parsoid HTML contains the original height & width in data
attributes:
<img resource="./File:Collage_of_Nine_Dogs.jpg" src="//
data-file-width="1665" data-file-height="1463"
data-file-type="bitmap"
height="228" width="260">
Based on this information, it shouldn't be too hard to calculate 1.5x / 2x
resolution thumb urls with a combination of multiplication & rounding.
On Friday, October 16, 2015, Dmitry Brant <dbrant(a)wikimedia.org> wrote:
We can indeed fall back to TTS if the spoken
article is not available, or
offer a choice between TTS and the spoken version. The intention was for
this to be a quick win of surfacing a useful, if lesser-known, facet of
Wikipedia content.
That being said, this doesn't necessarily need to be a blocker for
transitioning the Content Service to Parsoid. If all else fails, we can
ascertain the audio URL on the client side based on the File page name.
As
for transcodings of video files, we already make
a separate API call to
retrieve them, so perhaps we can continue to do that until we're able to
get them directly from Parsoid?
It sounds like a more pressing issue right now is the srcset
attributes...
On Fri, Oct 16, 2015 at 2:30 PM, Luis Villa <lvilla(a)wikimedia.org
<javascript:;>> wrote:
On Fri, Oct 16, 2015 at 11:14 AM, Bernd Sitzmann
<bernd(a)wikimedia.org
<javascript:;>>
> wrote:
>
> > It looks like Mobile Apps and Mobile Web have different priority
> > > requirements from Parsoid here. Looking at
> > >
https://en.wikipedia.org/wiki/Wikipedia:Spoken_articles, I also
see
> that
> > > there are only 1243 spoken wikipedia articles (that are probably
not
> all
> > > the latest version of these articles). It also doesn't look like
the
> > video
> > > player works currently in mobile web or in mobile apps (except
maybe
> > > Android ?).
> >
>
> With due respect for the hard work people have put in on that project,
is
there any
indication Spoken Articles has any traction and will grow
beyond
> that ~1K articles? Wouldn't using Android's TTS API to read the most
> up-to-date version of the article be a much better user experience (35M
> articles, always up-to-date, instead of 1K articles, almost always out
of
date?)
Luis
--
Luis Villa
Sr. Director of Community Engagement
Wikimedia Foundation
*Working towards a world in which every single human being can freely
share
in the sum of all knowledge.*
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org <javascript:;>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Dmitry Brant
Mobile Apps Team (Android)
Wikimedia Foundation
https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org <javascript:;>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
EN Wikipedia user page:
https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l