On 05/13/2014 05:37 PM, Daniel Kinzler wrote:
> Hi all!
>
> During the hackathon, I worked on a patch that would make it possible for
> non-textual content to be included on wikitext pages using the template
> syntax.
> The idea is that if we have a content handler that e.g. generates awesome
> d
PS, i'm building an instance that is running this extension.
On Wed, May 14, 2014 at 12:34 AM, Jon Robson wrote:
> During the Zurich hackathon, DJ Hartman, Aude and I knocked up a
> generic maps prototype extension [1]. We have noticed that many maps
> like extensions keep popping up and believed
As a continuation to the community wish expressed last year to start a
musical score transcription project [1], I'm investigating what is needed
to make it happen.
The biggest hurdle seems to be how to separate content from layout. On the
one hand users should be able to define which part to work
On 05/07/2014 10:47 PM, Tyler Romeo wrote:
> One interesting idea might be what Reddit does:
>
> For a moderator of a subreddit, whenever they make a post it just appears
> normally. However, after posting they can choose to "officiate" it. All
> that does is highlight their username a different c
I just love this Google I/O 2013 talk on human perception and
cognition, and its implications for interactive and visual design. It
is accessible, but with a lot of information and applies very well to
us I think.
I'm sure that many designers know all about this and some have
probably seen the cli
Thanks all for the imput!
Am 14.05.2014 10:17, schrieb Gabriel Wicke:> On 05/13/2014 05:37 PM, Daniel
Kinzler wrote:
> It sounds like this won't work well with current Parsoid. We are using
> action=expandtemplates for the preprocessing of transclusions, and then
> parse the contents using Parsoid
Hi,
The report covering Wikimedia engineering activities in April 2014 is now
available.
Wiki version:
https://www.mediawiki.org/wiki/Wikimedia_engineering_report/2014/April
Blog version:
https://blog.wikimedia.org/2014/05/14/engineering-report-april-2014/
We're also proposing a shorter, simpler
Le 14/05/2014 00:34, Jon Robson a écrit :
> During the Zurich hackathon, DJ Hartman, Aude and I knocked up a
> generic maps prototype extension [1]. We have noticed that many maps
> like extensions keep popping up and believed it was time we
> standardised on one that all these extensions could use
I don't think it is possible or worth the effort to scan for these in an
automated fashion within Jenkins.
Static analysis is virtually impossible due to the method names being too
simple, and lots of it relies on details of how methods are called, as well.
For example, "$something.error( .. )"
On 05/14/2014 01:40 PM, Daniel Kinzler wrote:
>> This means that HTML returned from the preprocessor needs to be valid in
>> wikitext to avoid being stripped out by the sanitizer. Maybe that's actually
>> possible, but my impression is that you are shooting for something that's
>> closer to the beh
Yes - Dan and I talked about this during the hackathon. Dan was
thinking bigger and even more generic then me. The two could
potentially play hand in hand - essentially the Map namespace would be
used to make and curate maps and provide basic embedding and the
Visualisation* namespace could be used
Am 14.05.2014 15:11, schrieb Gabriel Wicke:
> On 05/14/2014 01:40 PM, Daniel Kinzler wrote:
>>> This means that HTML returned from the preprocessor needs to be valid in
>>> wikitext to avoid being stripped out by the sanitizer. Maybe that's actually
>>> possible, but my impression is that you are s
Le 14/05/2014 15:16, Jon Robson a écrit :
> PS. Do we own wikimaps.org - I can imagine a map wiki would be
> extremely useful project to us.
The wikimaps.org is registered to the Wikimedia foundation. It has been
created back in 2004!
Tip: under Linux/Mac OS you can query domain name registrars
Tim I completely agree. This is something we need to setup.
Patches very much welcomed! :-)
On Wed, May 14, 2014 at 7:51 AM, Tim Alder wrote:
> I think the most important feature is to create on serverside a
> thumbnail for each map by using something like http://phantomjs.org/
> This thumbnail
On 05/14/2014 03:22 PM, Daniel Kinzler wrote:
> My patch doesn't change the handling of ... by the parser. As
> before, the parser will pass HTML code in ... through only if
> wgRawHtml is enabled, and will mangle/sanitize it otherwise.
Oh, I thought that you wanted to support normal wikis with $
Sorry for the short notice. Today at 2100 UTC, instead of the regular
RfC discussion, we'll talk about the performance guidelines draft in
#wikimedia-office . We discussed this some in Zurich but I'd love a
chance to ask some followup questions to firm everything up. I'd also
welcome the chance to
>
> > Can you outline how RL modules would be handled in the transclusion
> > scenario?
>
> The current patch does not really address that problem, I'm afraid. I can
> think
> of two solutions:
>
> * Create an SyntheticHtmlContent class that would hold meta info about
> modules
> etc, just like Par
Thanks for starting this Jon, the end result is going to be awesome. So
here's how I see things, it's roughly along the lines of what you've been
saying:
Server-side rendering and scaling is important. This is one of the main
reasons I picked Vega [2] for my hack. The same visualization grammar
On Tue, May 13, 2014 at 4:13 PM, Sumana Harihareswara
wrote:
> I am trying to figure out how thumbnail retrieval & caching works right
> now - with Swift, and the frontline & secondary ("frontend" and
> "backend") Varnishes. (I am working on the caching-related bit of the
> performance guidelines,
> Op 14 mei 2014 om 14:58 heeft Krinkle het volgende
> geschreven:
>
> I don't think it is possible or worth the effort to scan for these in an
> automated fashion within Jenkins.
>
> Static analysis is virtually impossible due to the method names being too
> simple, and lots of it relies on
That's an entirely different thing from scanning or catching things in
development. That's harvesting from clients in production. That is certainly
possible, and Wikimedia does that, too.
Deprecated properties[1], and features[2] use mw.track[3] to emit an event.
And the WikimediaEvents extensi
The second release candidate for 1.23.0 (1.23.0-rc.1) is now available
for download.
Note that we're making two changes in the release process:
1. We'll be making this and all future releases on Wednesday instead of
Thursday or Friday. This will allow people to avoid late Friday
nights.
Hi,
I wanted to bring to your attention a few critical issues that are negatively
affecting the workof the Commons community and the wider Wikimedia projects.
First, there are about 36 unresolved bugs [0] in the "Media storage" component.
Swift is a vitalcomponent of the projects' ability to show
Thanks, Steinsplitter!
We really appreciate your call to action to address some of the multimedia
issues you list below.
You will be glad to hear that our multimedia team is now shifting its focus to
more of that technical debt and is taking on an upgrade of the Upload Wizard as
our next big p
Hello everyone,
It's a testament to either how awesome our people are… or just how notorious I
am for not announcing things promptly that I noticed this sitting in my Google
Docs the other day with the note from the VisualEditor Team: "terry, we and
Alex think this is now good for you to post,
During internal review, an XSS (cross-site scripting) vulnerability was
discovered in MobileFrontend extension.
Due to an unneeded unescaping of already sanitized section titles, HTML
inserted as plaintext into them was injected into DOM.
While on ordinary page views only users who have intentional
Almost forgot: this is https://bugzilla.wikimedia.org/show_bug.cgi?id=65042
On Wed, May 14, 2014 at 4:28 PM, Max Semenik wrote:
> During internal review, an XSS (cross-site scripting) vulnerability was
> discovered in MobileFrontend extension.
> Due to an unneeded unescaping of already sanitize
On 2014-05-14, 4:28 PM, Max Semenik wrote:
> Another requirement for this vulnerability is screen width which must be at
> least 768 pixels.
LOL, Some part of me just loves and finds vulnerability requirements
like this awesomely amusing.
I wonder if there's an XKCD entry like this.
~Daniel Frie
That's 230am in India. Wish these meetings were held a bit earlier (9am PDT
:-)
Best,
Alolita
Alolita Sharma
आलोलिता शर्मा
Director of Engineering
Internationalization & Localization
Wikimedia Foundation
On Wed, May 14, 2014 at 5:47 PM, Sumana Harihareswara wrote:
> Sorry for the short notice
29 matches
Mail list logo