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
PS, i'm building an instance that is running this extension.
On Wed, May 14, 2014 at 12:34 AM, Jon Robson jrob...@wikimedia.org 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
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 color
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
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,
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 so
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 behavior
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
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 shooting
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 t...@alder-digital.de wrote:
I think the most important feature is to create on serverside a
thumbnail for each map by using something like
On 05/14/2014 03:22 PM, Daniel Kinzler wrote:
My patch doesn't change the handling of html.../html by the parser. As
before, the parser will pass HTML code in html.../html through only if
wgRawHtml is enabled, and will mangle/sanitize it otherwise.
Oh, I thought that you wanted to support
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 ParserOutput -
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
On Tue, May 13, 2014 at 4:13 PM, Sumana Harihareswara
suma...@wikimedia.org 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
Op 14 mei 2014 om 14:58 heeft Krinkle krinklem...@gmail.com 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
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
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
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
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
Almost forgot: this is https://bugzilla.wikimedia.org/show_bug.cgi?id=65042
On Wed, May 14, 2014 at 4:28 PM, Max Semenik maxsem.w...@gmail.com wrote:
During internal review, an XSS (cross-site scripting) vulnerability was
discovered in MobileFrontend extension.
Due to an unneeded unescaping
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
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 suma...@wikimedia.org
wrote:
Sorry
29 matches
Mail list logo
