On 12/11/2013 01:36 AM, C. Scott Ananian wrote:
Could you take a look at the attached PDF, generated from
https://ml.wikipedia.org/wiki/%E0%B4%AE%E0%B4%B2%E0%B4%AF%E0%B4%BE%E0%B4%B3%E0%B4%82
with our not-yet-deployed new software? Any Malayam-specific feedback
you could provide would be very
I will ask other successful huggle 3 Mac users (these who actually
wrote the guide on wiki) what else they do so that it works to them
On Tue, Dec 10, 2013 at 6:21 PM, Ori Livneh o...@wikimedia.org wrote:
On Tue, Dec 10, 2013 at 8:14 AM, Petr Bena benap...@gmail.com wrote:
Hi,
Huggle 3 is
The basic idea is to filter out
* Suspicious edits (edits that looks like the vandalism but person who
reviews them doesn't know for sure and needs more attention by others)
* Good edits (edits that can be surely ignored by others so that
people who deal with vandalism have less work and don't do
Can you even read them by api? I know these may be part of recent
changes query, but huggle uses IRC feed for RC so the additional
information about edits are retrieved using other api's. Is there any
api that retrieve what tags are applied for an edit with certain
RevID?
On Tue, Dec 10, 2013 at
El 10/12/13 00:33, Liangent ha escrit:
On Tue, Dec 10, 2013 at 7:13 AM, Toni Hermoso Pulido toni...@cau.cat
mailto:toni...@cau.cat wrote:
Hello,
I'm trying to perform an API edit call in a maintenance script using
this example in MW 1.19.9
Le 10/12/13 18:21, Ori Livneh a écrit :
I hacked together a Homebrew formula: https://gist.github.com/atdt/7894375
The make phase works for me using qt4. The make install phase bails out
though:
== make install
./build/install
FATAL: You need to build huggle first
make: *** [install] Error 1
Le 10/12/13 05:30, MZMcBride a écrit :
I think adding an explicit HTML comment in the page source is a reasonable
suggestion to consider.
We already had an argument a few months ago regarding adding comments in
the minified css/js and we said no. Who ever look at that source code
will be able
Aye, I suppose I should implement some more options to configure
script first, which are now missing, so some parameters are not passed
to make install
it seems to expect to run from directory where huggle was built
On Wed, Dec 11, 2013 at 9:58 AM, Antoine Musso hashar+...@free.fr wrote:
Le
Hello,
This is a reminder that the Wikimedia Language Engineering team will be
hosting an IRC office hour from 1700 to 1800UTC later today on
#wikimedia-office (FreeNode). Please see below for the event details.
Thanks
Runa
=== Event Details ===
What: WMF Language Engineering Office hour
When:
I'll probably try and attend, although it's during the day so there's no
guarantee my boss won't randomly schedule a meeting or something.
*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
On Tue, Dec 10, 2013 at 11:43 PM, Aaron Halfaker
Am 10.12.2013 22:38, schrieb Brad Jorsch (Anomie):
Looking at the code, ParserCache::getOptionsKey() is used to get the
memc key which has a list of parser option names actually used when
parsing the page. So for example, if a page uses only math and
thumbsize while being parsed, the value
http://en.wikipedia.org/w/api.php?action=queryprop=revisionsrevids=585593930rvprop=tagsformat=jsonfm
Returns:
{
query: {
pages: {
12461: {
pageid: 12461,
ns: 0,
title: Gradient,
revisions: [
Ok, that is good, though it is lacking several features, including
ability to modify it (it's not possible to tag a page using these
api's) so we can use this to improve the scoring, but can't use it to
share some data with other users.
On Wed, Dec 11, 2013 at 3:09 PM, Aaron Halfaker
2013/12/10 MZMcBride z...@mzmcbride.com
* Minification reduces bandwidth usage.
** At the cost of making debugging more difficult.
There is one thing that debug mode makes harder: Seeing how the page looks
in an RTL language. That's because CSSJanus doesn't work in debug mode, and
there were
As everybody else already said, less bandwidth is a good thing for most
people, obfuscation is OK when the source is available elsewhere, and
debug=true is not hard for developers to find.
I'd actually disagree with the assertion that debug=true is easy to
find, particularly for people who
Hi,
On Mon, 2013-12-09 at 10:17 -0800, Jon Robson wrote:
Would we be able to link to such a thing from within the Bugzilla
interface to give it more visibility?
Yes, in the footer, next to Privacy policy. I've filed
https://bugzilla.wikimedia.org/show_bug.cgi?id=58332 so I don't forget.
andre
On 11.12.2013, 19:36 Brian wrote:
As everybody else already said, less bandwidth is a good thing for most
people, obfuscation is OK when the source is available elsewhere, and
debug=true is not hard for developers to find.
I'd actually disagree with the assertion that debug=true is easy to
On Wed, Dec 11, 2013 at 11:33 AM, Max Semenik maxsem.w...@gmail.com wrote:
If they look at the URL it will be pretty obvious because all of them
have debug=false as first parameter.
As a proof of concept, this is how I found out about the debug parameter
the first time I tried doing
when i open the chrome console,i always can get:
event.returnValue is deprecated. Please use the standard
event.preventDefault() instead.
is any plan to fix this?
Regrades
Sen
From SLboat(http://see.sl088.com)
___
Wikitech-l mailing list
On Wed, Dec 11, 2013 at 9:59 AM, Sen kik...@gmail.com wrote:
when i open the chrome console,i always can get:
event.returnValue is deprecated. Please use the standard
event.preventDefault() instead.
is any plan to fix this?
I don't know if there is currently a plan to fix it, but the
Hi,
I have a bunch of videos from our last conference waiting for an upload
to Commons. For this I have filed a bug several days ago:
* https://bugzilla.wikimedia.org/show_bug.cgi?id=58155
Can someone please take care of this in a timely manner? The conference
is now three weeks ago and soon
Could we make it so:
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend
has a link to
https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FMobileFrontend.git
(and all other projects do the same)
I swear I just spent 10 minutes searching through emails and
+1000 to what Max says. It really is kinda obvious to anyone who needs to
know how to get into debug mode and if not there are wiki pages and if not
it's easy enough to find out if you care enough.
That said debug mode could definitely be improved and I'm glad you brought
this topic up Max. A few
Every change has (gitblit) links.
As does the project listing page.
So does the branches page from an individual project.
-Chad
On Wed, Dec 11, 2013 at 10:45 AM, Jon Robson jdlrob...@gmail.com wrote:
Could we make it so:
Perhaps I am a dumbass, but where is the gitblit link on:
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend
which the sort of link you get from the Projects list on gerrit?
I cannot find it.
-- brion
On Wed, Dec 11, 2013 at 10:48 AM, Chad
There isn't, you're not.
This page has links: https://gerrit.wikimedia.org/r/#/admin/projects/
As does this:
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend,branches
And so would this, for example: https://gerrit.wikimedia.org/r/#/c/100811/
-Chad
On Wed,
I can see both sides of the argument here and just wanted to provide my
thoughts on this matter. The short version is basically this: Keep gadgets
for experiment, but ensure global gadgets are held to a higher standard of
quality and made more visible to a wider audience.
As a developer the
So the pages that get you *to* the project page have links to the actual
source browser, but the project detail page doesn't. Brilliant.
I'll go file a bug report against gerrit.
-- brion
On Wed, Dec 11, 2013 at 10:56 AM, Chad innocentkil...@gmail.com wrote:
There isn't, you're not.
This
Filed as http://code.google.com/p/gerrit/issues/detail?id=2335
-- brion
On Wed, Dec 11, 2013 at 11:15 AM, Brion Vibber bvib...@wikimedia.orgwrote:
So the pages that get you *to* the project page have links to the actual
source browser, but the project detail page doesn't. Brilliant.
I'll
On Wed, Dec 11, 2013 at 11:04 AM, Jon Robson jdlrob...@gmail.com wrote:
Many a time I've talked about this I've hit the argument that gerrit is
confusing to some users and is a barrier for development, but this is a
terrible unacceptable attitude to have in my opinion. Our end users deserve
a
A related feature request I just submitted -- links to review dashboards
from all project pages:
https://code.google.com/p/gerrit/issues/detail?id=2336
~Matt Walker
Wikimedia Foundation
Fundraising Technology Team
On Wed, Dec 11, 2013 at 11:20 AM, Brion Vibber bvib...@wikimedia.orgwrote:
On Wed, Dec 11, 2013 at 2:04 PM, Jon Robson jdlrob...@gmail.com wrote:
Many a time I've talked about this I've hit the argument that gerrit is
confusing to some users and is a barrier for development, but this is a
terrible unacceptable attitude to have in my opinion. Our end users deserve
a
I'm totally cool with the idea of code review for Gadgets so forth, just
not using Gerrit. We considered it for Scribunto (and heck, I wrote half of
a
proof of concept) but shot it down because the idea totally sucked.
Chad, can you expand on that statement. I've been toying for some time with
On Wed, Nov 27, 2013 at 2:55 PM, Jon Robson jdlrob...@gmail.com wrote:
One that I would like to discuss but still need to write up is
JavaScript template support in ResourceLoader. Mobile has been using
Hogan.js for some time and we would like to upstream this as a
standard.
I'll try and
On Wed, Dec 11, 2013 at 2:54 PM, Matthew Walker mwal...@wikimedia.org wrote:
I'm totally cool with the idea of code review for Gadgets so forth, just
not using Gerrit. We considered it for Scribunto (and heck, I wrote half of
a
proof of concept) but shot it down because the idea totally
On Wed, Dec 11, 2013 at 12:00 PM, Brad Jorsch (Anomie)
bjor...@wikimedia.org wrote:
On Wed, Dec 11, 2013 at 2:54 PM, Matthew Walker mwal...@wikimedia.org
wrote:
I'm totally cool with the idea of code review for Gadgets so forth,
just
not using Gerrit. We considered it for Scribunto (and
Ah; so it's actually slightly different use cases then.
My thought is that it's on the developers to merge changes that come from
the wiki.
I've thought of two ways this could work:
* For every new merge touching a documentation file; we reject changes via
a jenkins job when there are still
On 11/12/13 19:21, Chad wrote:
Sending wiki edits to Gerrit for review? Absolutely not.
I'm totally cool with the idea of code review for Gadgets so forth, just
not
using Gerrit. We considered it for Scribunto (and heck, I wrote half of a
proof
of concept) but shot it down because the idea
On 12/11/13, Tyler Romeo tylerro...@gmail.com wrote:
On Wed, Dec 11, 2013 at 2:04 PM, Jon Robson jdlrob...@gmail.com wrote:
Many a time I've talked about this I've hit the argument that gerrit is
confusing to some users and is a barrier for development, but this is a
terrible unacceptable
Hey,
Has there been thought on how GitHub can potentially help here? I'm not
sure it fits the workflow well, though can make the following observations:
* People can click an edit button on GH to edit the code, much like on
wiki.
* If the GH web UI is used, people do not have to install git
*
On Wed, Dec 11, 2013 at 2:38 PM, Tyler Romeo tylerro...@gmail.com wrote:
I can definitely understand the reasoning behind this. Right now with both
Gadgets and common.js we are allowing non-reviewed code to be injected
directly into every page. While there is a bit of trust to be had
On Wed, Dec 11, 2013 at 3:19 PM, Brian Wolff bawo...@gmail.com wrote:
I would expect any sort of code review requirement for
gadgets to meet strong resistance, especially on the smaller wikis.
Unless it was the community doing code review on itself, maybe. To
some extent this already happens on
On Wed, Dec 11, 2013 at 3:19 PM, Brian Wolff bawo...@gmail.com wrote:
One of the primary reasons gadgets/local-js exist is because local
wiki-admins feel that the mediawiki code review process is unavailable
to them. I would expect any sort of code review requirement for
gadgets to meet
On Wed, Dec 11, 2013 at 3:30 PM, Tyler Romeo tylerro...@gmail.com wrote:
In this case we should promptly work to fix this issue. To be honest, the
only difficult part of our code review process is having to learn Git if
you do not already know how to use it. If there were a way to submit
Hi everyone,
We're just over a week away from the Friday, December 20 deadline for RFCs
as items to consider at the Architecture Summit.[1] That's not a hard and
fast rule (we've never done this before), but we should definitely have a
reasonable amount of time between the point an RFC is
On 12/11/13, Tyler Romeo tylerro...@gmail.com wrote:
On Wed, Dec 11, 2013 at 3:19 PM, Brian Wolff bawo...@gmail.com wrote:
One of the primary reasons gadgets/local-js exist is because local
wiki-admins feel that the mediawiki code review process is unavailable
to them. I would expect any sort
On Wed, Nov 27, 2013 at 12:55 PM, Jon Robson jdlrob...@gmail.com wrote:
I'll try and get this written in next 2 weeks but it would be good to
capture this even in a stub like form (not sure if stubs are allowed
on the RFC page)
There are plenty of RFCs there at this point that are stubs so I
On Wed, Dec 11, 2013 at 3:21 PM, Jeroen De Dauw jeroended...@gmail.comwrote:
Hey,
Has there been thought on how GitHub can potentially help here? I'm not
sure it fits the workflow well, though can make the following observations:
Unless you're implying that github writes some code for us,
Hey,
In recent months I've come across a few mails on this list that only
contained accusations of trolling. Those are very much not constructive and
only serve to antagonize. I know some forums that have an explicit rule
against this, which results in a ban on second violation. If there is a
On Wed, Dec 11, 2013 at 5:11 PM, Jeroen De Dauw jeroended...@gmail.comwrote:
In recent months I've come across a few mails on this list that only
contained accusations of trolling. Those are very much not constructive and
only serve to antagonize. I know some forums that have an explicit rule
I think I've seen a couple of the times this has happened. It appears to me
that it might be in reaction to a perceived misunderstanding of the topic
on either party. If we assume good faith on both sides; then I think it's
reasonable for the perceived 'trolling' party to gently restate their
Le 11/12/13 19:15, Manuel Schneider a écrit :
Hi,
I have a bunch of videos from our last conference waiting for an upload
to Commons. For this I have filed a bug several days ago:
* https://bugzilla.wikimedia.org/show_bug.cgi?id=58155
Can someone please take care of this in a timely
It's not a bad thought; but I don't think it'll work for a couple of
reasons:
* It causes people to leave the site
* GItHub for various reasons requires an account (which most likely they
wont have and it doesn't seem correct to require one given our editing
philosophy)
* The editing interface is
I'm not Chad, but one of the big issues is this: Consider the trouble
that some of us as developers have using Git and Gerrit. Now think
about trying to get non-developer JS and CSS coders to be able to use
Git and Gerrit, much less to *want* to use Git and Gerrit rather than
torches and
Thanks guys!
On Wed, Dec 11, 2013 at 11:32 AM, Matthew Walker mwal...@wikimedia.org wrote:
A related feature request I just submitted -- links to review dashboards
from all project pages:
https://code.google.com/p/gerrit/issues/detail?id=2336
~Matt Walker
Wikimedia Foundation
Fundraising
Heh; wrong thread to discuss that in Jon -- this one is about
non-developers helping out writing documentation for configuration
variables and what not without having to modify the source file in gerrit.
The OTHER thread, which I forked from, is the one about what we already
allow (users to
On 12/11/13, Antoine Musso hashar+...@free.fr wrote:
Le 11/12/13 19:15, Manuel Schneider a écrit :
Hi,
I have a bunch of videos from our last conference waiting for an upload
to Commons. For this I have filed a bug several days ago:
* https://bugzilla.wikimedia.org/show_bug.cgi?id=58155
On 11/12/13 22:21, Ryan Lane wrote:
On Wed, Dec 11, 2013 at 5:11 PM, Jeroen De Dauw jeroended...@gmail.comwrote:
In recent months I've come across a few mails on this list that only
contained accusations of trolling. Those are very much not constructive and
only serve to antagonize. I know
Is this thread some trolling on its own? :P
I think we need to use less rules and more common sense.
All these etiquettes are just damaging your natural intelligence...
On Wed, Dec 11, 2013 at 11:11 PM, Jeroen De Dauw jeroended...@gmail.com wrote:
Hey,
In recent months I've come across a few
On 11/12/13 23:28, Petr Bena wrote:
I think we need to use less rules and more common sense.
This.
When you get right down to it, what even is trolling? And should it
necessarily matter? Even if someone is trolling, that doesn't mean they
may not have a real point to it, though perhaps they
On Wed, Dec 11, 2013 at 5:11 PM, Jeroen De Dauw jeroended...@gmail.comwrote:
(I'm now half expecting someone to claim this mail is a troll. Perhaps we
ought to make a contest out of making the accusation first, at least then
it will have general amusement value :D)
This contest idea sounds
:/ There are only ten videos. Is there some sort of special upload process
that needs to be followed here? Because uploading ten things to Commons
takes all of fifteen minutes.
*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
On Wed, Dec 11, 2013 at
On Wed, Dec 11, 2013 at 3:50 PM, Isarra Yos zhoris...@gmail.com wrote:
On 11/12/13 23:28, Petr Bena wrote:
I think we need to use less rules and more common sense.
This.
Rules are silly. Common sense for all :)
-Chad
___
Wikitech-l mailing list
On Wed, Dec 11, 2013 at 4:13 PM, Brian Wolff bawo...@gmail.com wrote:
I guess I should have said without banning [[MediaWiki:Common.js]]. I
was kind of assuming this proposal meant banning all site wide js
(Since otherwise what's the point of banning default on gadgets?
Default on gadgets is
On Wed, 11 Dec 2013 21:30:15 +0100, Tyler Romeo tylerro...@gmail.com wrote:
In this case we should promptly work to fix this issue. To be honest, the
only difficult part of our code review process is having to learn Git if
you do not already know how to use it. If there were a way to submit
On Wed, Dec 11, 2013 at 3:58 PM, Tyler Romeo tylerro...@gmail.com wrote:
On Wed, Dec 11, 2013 at 4:13 PM, Brian Wolff bawo...@gmail.com wrote:
I guess I should have said without banning [[MediaWiki:Common.js]]. I
was kind of assuming this proposal meant banning all site wide js
(Since
On Wed, Dec 11, 2013 at 7:15 PM, Chad innocentkil...@gmail.com wrote:
I'm going to say this one final time, since I'm feeling like a broken
record today...
We are not going to use Gerrit for gadgets and so forth. It is the
*wrong* tool for the job. Full stop.
Gerrit is a code review tool.
On Wed, Dec 11, 2013 at 4:19 PM, Tyler Romeo tylerro...@gmail.com wrote:
On Wed, Dec 11, 2013 at 7:15 PM, Chad innocentkil...@gmail.com wrote:
I'm going to say this one final time, since I'm feeling like a broken
record today...
We are not going to use Gerrit for gadgets and so forth.
The videos are (mostly) over 1 gb, which is our upload limit. Hence
maintenance script needed.
-bawolff
On 2013-12-11 4:56 PM, Tyler Romeo tylerro...@gmail.com wrote:
:/ There are only ten videos. Is there some sort of special upload process
that needs to be followed here? Because uploading
As both an active gadget writer (on pl.wikipedia) and a core developer, let me
say that while I would *love* to have a somewhat formalized code-review process
for gadgets, it is pretty much not possible, and the reason is twofold.
First, code-review is, apart from spotting bugs, about getting
On Wed, 11 Dec 2013 23:35:43 +0100, Jon Robson jdlrob...@gmail.com wrote:
I'm confused.. non-developers writing JS and CSS? This scares the
bejesus outta me.
There's so many movements urging people to learn to code right now, I don't see
how this is surprising anymore. Yes, physicians and
Hello everyone,
It’s with great pleasure that I’m announcing that Andrew Green[1] has joined
the Wikimedia Foundation as a contractor in Features Engineering working in the
Education Project.
Before joining us, Andy worked at the Instituto Mora[2] creating free software
for social science
On 2013-12-11 4:52 PM, Bartosz Dziewoński wrote:
On Wed, 11 Dec 2013 23:35:43 +0100, Jon Robson jdlrob...@gmail.com
wrote:
And it's not very easy to cause a major security bug when writing code
that runs client-side and usually only in response to user action.
Most gadgets don't, say, parse
Bartosz Dziewoński wrote:
I really liked what Jon said at the beginning, and what has apparently
been lost in the discussions already – Keep gadgets for experiment, but
ensure global gadgets are held to a higher standard of quality and made
more visible to a wider audience.. Proper global gadgets
On Wed, Dec 11, 2013 at 2:21 PM, Ryan Lane rlan...@gmail.com wrote:
On Wed, Dec 11, 2013 at 5:11 PM, Jeroen De Dauw jeroended...@gmail.com
wrote:
In recent months I've come across a few mails on this list that only
contained accusations of trolling. Those are very much not constructive
and
On Thu, Dec 12, 2013 at 12:03 AM, Rob Lanphier ro...@wikimedia.org wrote:
Or perhaps he merely suggested something that you disagreed with (or didn't
understand), without losing [his] mind or being a troll?
I'm a little skeptical about Jeroen's GitHub suggestion, but it seems like
something
+1 to everything MZM said.
Except the XSS in user/site/gadget JS vs core/extension XSS. Intuition
tells me the former is much more common. We just think about core/extension
XSS because it gets a security release and tons of attention.
-Chad
On Dec 11, 2013 8:01 PM, MZMcBride z...@mzmcbride.com
77 matches
Mail list logo
