Re: [Wikitech-l] Inhibitors for Mobile Content Service to use Parsoid output

[Brian Gerstle]

On Fri, Oct 16, 2015 at 5:59 PM, Gabriel Wicke  wrote:

> On Fri, Oct 16, 2015 at 2:50 PM, Brian Gerstle 
> 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:
>
>
> https://upload.wikimedia.org/wikipedia/commons/thumb/d/d9/Collage_of_Nine_Dogs.jpg/40px-Collage_of_Nine_Dogs.jpg
>
>
It's been mentioned elsewhere (I believe by Gergo) that these URLs aren't
stable, and can't be reliably constructed by clients. Is that still the
case?


>
> The corresponding Parsoid HTML contains the original height & width in data
> attributes:
>
>  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.
>
>
> > And prevent cache fragmentation on img resolutions.
> >
>
> Isn't the srcset using a limited set of resolution factors?
>
>
> >
> > On Friday, October 16, 2015, Dmitry Brant  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  > > > wrote:
> > >
> > > > On Fri, Oct 16, 2015 at 11:14 AM, Bernd Sitzmann <
> be...@wikimedia.org
> > > >
> > > > 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@lists.wikimedia.org 
> > > > 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@lists.wikimedia.org 
> > > 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@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
>
>
> --
> Gabriel Wicke
> Principal Engineer, Wikimedia Foundation
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> 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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Inhibitors for Mobile Content Service to use Parsoid output

[Brian Gerstle]

Right, but the point is to avoid an extra round trip just to get a URL.

On Mon, Oct 19, 2015 at 3:20 PM, Bartosz Dziewoński 
wrote:

> On 2015-10-19 17:28, Brian Gerstle wrote:
>
>> It's been mentioned elsewhere (I believe by Gergo) that these URLs aren't
>> stable, and can't be reliably constructed by clients. Is that still the
>> case?
>>
>
> The URL looks different for very long file names and for different file
> types. There is an API endpoint to get it, though:
> https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query=imageinfo=json=url=40=File%3AExample.jpg
>
> --
> Bartosz Dziewoński
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> 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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] JetBrains IDE licenses for MW developers - php, js/node, python, C/C++, puppet, ruby, ...

[Yuri Astrakhan]

Developers, we now have licenses for JetBrains' IDEA Ultimate
 (JavaScript, PHP, Python, ...)  and CLion
 (C/C++).  The IDE supports debugging in
Vagrant and on-the-fly static code analysis.

If you are a volunteer developer, and want to use an IDE, contact me for a
license. Those with access to the office wiki may register directly at the
licenses  page.

Please try it for a bit before getting a license -- just in case you don't
like it.

P.S. This is only for those who want JetBrains' IDE. If you are happy with
Vim, good for you. If you like Atom or Sublime, great. If notepad is the
best text editor of all times, all the power to you.  Bikeshedding should
go into a separate thread ))
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Inhibitors for Mobile Content Service to use Parsoid output

[Bartosz Dziewoński]

On 2015-10-19 17:28, Brian Gerstle wrote:

It's been mentioned elsewhere (I believe by Gergo) that these URLs aren't
stable, and can't be reliably constructed by clients. Is that still the
case?


The URL looks different for very long file names and for different file 
types. There is an API endpoint to get it, though: 
https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query=imageinfo=json=url=40=File%3AExample.jpg


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] TimedMediaHandler changing interactions with ResourceLoader

[Brion Vibber]

I've gone ahead and merged these two changes by TheDJ to MwEmbedSupport and
TimedMediaHandler extensions (they are interdependent):

* https://gerrit.wikimedia.org/r/#/c/172556/
* https://gerrit.wikimedia.org/r/#/c/172421/

These clean up how TMH's JavaScript modules get integrated into MediaWiki's
ResourceLoader, and should both reduce weird timing bugs and make it muuuch
easier to refactor things further.

It's worth checking these on the beta cluster; if all is well they can go
out to Wikimedia sites with the next branch point.


As an intermediary step, some weeks ago we merged this change to mark
parser output requiring video modules, so the standard RL caching _should_
mean everything keeps working on cached pages once the newer revs go live:

* https://gerrit.wikimedia.org/r/#/c/230153/


With all these going out, we'll be able to finalize work on integrating the
VideoJS player framework to replace our old hacked-up version of the
Kaltura player, and generally modernize and vastly improve the playback
experience.

-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Inhibitors for Mobile Content Service to use Parsoid output

[Subramanya Sastry]

On 10/16/2015 01:14 PM, Bernd Sitzmann wrote:

In any case, given that Parsoid's HTML clients usually talk through
RESTBase rather than with Parsoid directly, this optional API flag would
also have to be supported in RESTBase, and could potentially follow the
redirects on behalf of the clients.

I'm not sure why RESTBase would have to support this. I think there should
be also some indication in Parsoid's output to indicate that a redirect
happened and from where, like it's done on the website.


No client talks to Parsoid directly anymore (except temporarily while 
resolving some issue maybe). So, any API flags that need to be passed 
through to Parsoid should be exposed in the RESTBase API as well.


Given that, I observed that RESTBase could potentially follow the 
redirect instead of passing it to Parsoid to follow the redirect (and 
eliminate the extra hop). But, yes, it does make sense to do this in 
Parsoid directly behind an API flag or a different endpoint.


Subbu.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l