Hi, I'd like to present a new RFC for your consideration:
https://www.mediawiki.org/wiki/Requests_for_comment/Minifier
It is about how we can shave 10-15% off the size if JavaScript
delivered to users.
Your comments are highly welcome!:)
--
Best regards,
Max Semenik ([[User:MaxSem]])
When api.php was basically the only API in MediaWiki, calling it "the API"
worked well. But now we've got a Parsoid API, Gabriel's work on a REST
content API, Gabriel's work on an internal storage API, and more on the
way. So just saying "the API" is getting confusing.
So let's bikeshed a reasonably short name for it that isn't something awful
like "the api.php API". I'm horrible at naming.
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
Thank you for the quick fix!
Best,
--
Sukyoung
On Jan 29, 2014, at 9:55 AM, Nathan wrote:
> FYI in case you aren't subscribed to the list.
>
> ---------- Forwarded message ----------
> From: Yair Rand <yyairrand(a)gmail.com>
> Date: Tue, Jan 28, 2014 at 7:25 PM
> Subject: Re: [Wikitech-l] Bug in the Wikipedia main web page
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
>
>
> Thank you for pointing out this bug. Your suggested change to
> MediaWiki:Gadget-wm-portal.js has been implemented by Meta-Wiki
> administrator User:PiRSquared17.
>
>
> On Tue, Jan 28, 2014 at 6:50 PM, Sukyoung Ryu <sukyoung.ryu(a)gmail.com>wrote:
>
> > Dear all,
> >
> > We are researchers at KAIST in Korea working on finding JavaScript bugs in
> > web pages. While analyzing top websites from Alexa.com, we found an issue,
> > which seems to be a bug, on the Wikipedia main web page (wikipedia.org).
> > We would be grateful if you can either confirm that it is a bug and even
> > better fix it or let us know what we're missing.
> >
> > Here's the issue. When a user selects a language in which search results
> > are displayed via the language selection button from the Wikipedia main web
> > page, the following JavaScript function is executed:
> >
> > 1 function setLang(lang) {
> > 2 var uiLang = navigator.language || navigator.userLanguage, date
> > = new Date();
> > 3
> > 4 if (uiLang.match(/^\w+/) === lang) {
> > 5 date.setTime(date.getTime() - 1);
> > 6 } else {
> > 7 date.setFullYear(date.getFullYear() + 1);
> > 8 }
> > 9
> > 10 document.cookie = "searchLang=" + lang + ";expires=" +
> > date.toUTCString() + ";domain=" + location.host + ";";
> > 11 }
> >
> > Depending on the evaluation result of the conditional expression on line
> > 4, "uiLang.match(/^\w+/) === lang", the function leaves or dose not leave
> > the selected language information on the user's computer through a cookie.
> > But we found that the expression, "uiLang.match(/^\w+/) === lang", always
> > evaluates to false, which results in that the function always leaves
> > cookies on users' computers. We think that changing the contidional
> > expression, "uiLang.match(/^\w+/) === lang", to the expression,
> > "uiLang.match(/^\w+/) == lang", will solve the problem.
> >
> > This problem may occur in the main web pages of all the Wikimedia sites.
> > Could you kindly let us know what you think? Thank you in advance.
> >
> > Best,
> > Changhee Park and Sukyoung Ryu
> >
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
I've written a simple MediaWiki extension that uses an instance of the
W3C Validator service (via the Services_W3C_HTMLValidator
<http://pear.php.net/package/Services_W3C_HTMLValidator> PEAR package)
to validate SVG images hosted on a wiki. It is meant to replace the
current system on Commons, that relies on individual contributors adding
templates (e.g. InvalidSVG
<https://commons.wikimedia.org/wiki/Template:InvalidSVG>) by hand to
file description pages.
It exposes a simple API (and a Scribunto module as well) to get the
validation status of existing SVG files, can emit warnings when trying
to upload invalid ones, and is well integrated with MediaWiki's native
ObjectCache mechanism.
I'm in the process of publishing the code, but have some questions I
think the community could help me answer.
* Given that the W3C Validator can also parse HTML files, would it be
useful to validate wiki pages as well? Even if sometimes the
validation errors appear to be caused by MediaWiki itself, they can
also depend on malformed templates.
* Does storing the validation status of old revisions of images
(and/or articles) make sense?
* Do you think the extension should use the extmetadata property of
ApiQueryImageInfo instead of a its own module?
* Is it advisable to store validation data permanently in the database?
Hi all,
My apologies if this is the wrong place to start a discussion on this, but
it's a better place than nowhere. I recently took part in two very
different Wikipedia workshops -- one in Uganda for schoolchildren aged
14-17, and one Bodø, Norway, for GLAM people aged 35-55. One glaringly
obvious barrier of entry that was common for both groups is that the
CAPTCHA we use is too freaking hard.
The main concern is obviously that it is really hard to read, but there are
also some other issues, namely that all the fields in the user registration
form (except for the username) are wiped if you enter the CAPTCHA
incorrectly. So when you make a mistake, not only do you have to re-type a
whole new CAPTCHA (where you may make another mistake), you also have to
re-type the password twice *and* your e-mail address. This takes a long
time, especially if you're not a fast typer (which was the case for the
first group), or if you are on a tablet or phone (which was the case for
some in the second group).
So I would like to start a discussion about changing to a CAPTCHA that is
more user-friendly, and hopefully one that isn't as
English/Latin-alphabet-centric as the one we currently use. If Ugandan
children and old Norwegian people, which all use the Latin alphabet, have
such problems deciphering the CAPTCHA, what about people speaking languages
that don't use the Latin alphabet? I would prefer something more
simplistic, like some sort of math or image-based CAPTCHA, instead of the
current CAPTCHA we use.
--
mvh
Jon Harald Søby <http://meta.wikimedia.org/wiki/User:Jon_Harald_S%C3%B8by>
When ContentHandler support was added to MediaWiki in 2012, the content
type and content model of a revision is stored with it. However, the DB
tables for WMF wikis did not have the new columns, so
$wgContentHandlerUseDB was set to false on our wikis.
Eventually the database jobs to add and populate the columns completed, and
$wgContentHandlerUseDB has been true on some wikis including mediawiki.org
for months. There are several projects that are requesting this be set
true everywhere, T51193.
However, changing the content model of an existing page is a disruptive
change. We added the right `editcontentmodel` without which attempts to
change content model through the API or EditPage.php fail. Currently no
group (user or bot) has this right. So we think it's OK and safe to enable
$wgContentHandlerUseDB on WMF wikis.
https://gerrit.wikimedia.org/r/#/c/170129/ is the patch.
There are issues with granting the editcontentmodel right, see T85847.
The Flow discussion and collaboration software has its own contentmodel.
Currently the Flow team changes a talk page to a Flow board by editing a
PHP config variable (!), which doesn't scale. (FYI, plans for enabling Flow
are at [1], and it is happening slowly.) When we do we archive the
existing talk page content.
The first change to the status quo is allowing a *new* page to be a Flow
board. In particular, the Co-op project[2] wants to provide a Flow board
for each new editor who signs up to collaborate with a mentor. This
doesn't feel like changing the content model of a page, since there was
nothing present before. So Flow has its own right, 'flow-create-board',
which we grant to flow-bot group; attempting to add a Flow topic or Flow
board header to an non-existent page fails unless the user has this right.
The Co-op team will ask the Bot Approval Group on enwiki to grant their bot
this right.
Eventually we envision having a Special:Flowify page that will let admins
turn a page into a Flow board. This will run PHP code to archive the
current page, handle redirects, and then create a Flow board revision, etc.
This feels like the 'editcontentmodel' right, but it will probably be a
more restrictive right, 'flow-flowify'.
Daniel Kinzler proposed that we should not grant the editcontentmodel right
because any change to content model is a special case that requires smart
handling via dedicated PHP code. Which is what Flow is doing for both the
Co-op bot and the future Special:Flowify.
So is there anything to discuss? :)
[1] https://www.mediawiki.org/wiki/Flow/Rollout Relax, is happening slowly.
[2] https://en.wikipedia.org/wiki/Wikipedia:Co-op
Please join us for the following tech talk:
*Tech Talk**:* What's New with MediaWiki-Vagrant?: Simple Use Cases and
Beyond
*Presenter:* Bryan Davis & Dan Duvall
*Date:* November 25th
*Time:* 1830 UTC
<http://www.timeanddate.com/worldclock/fixedtime.html?msg=What%27s+New+with+…>
Link to live YouTube stream <http://www.youtube.com/watch?v=I66xR-fq2O8>
*IRC channel for questions/discussion:* #wikimedia-office
Google+ page <http://www.youtube.com/watch?v=I66xR-fq2O8>, another place
for questions
*Talk description:*We'll start off by giving a brief refresher on how
MW-Vagrant works and how it differs from stock Vagrant. Next, we'll
showcase some of the newest and most useful features of MWV such as
multi-wiki support, SSH/HTTP sharing, Labs integration, advanced
customization using Hiera and local roles. Finally, we'd like to show how
MWV can be useful in test-driven development by demonstrating how to run
unit and browser tests. The last 15 minutes will be reserved for Q/A.
== Outline (WIP) ==
* (10 minutes) What is Vagrant, MediaWiki-Vagrant, Puppet (dan + bryan)
* (15 minutes) Local customizations (bryan)
* (15 minutes) Running unit tests and browser tests under MW-V (dan)
* (5 minutes) Vagrant sharing (it's awesomesauce!!!) (bryan)
* (15 minutes) Q & A
I recently hit the exact same issue. It's a useful widget but has no demos
(see https://phabricator.wikimedia.org/T85467)
Luckily after a week of fiddling Florian and I have two demos that are
working. The code in the following patches should help you work out.
I understand that Andrew Garret is setting up a demo site. I wonder if
during the dev summit we could get s demo for this done and on it?
https://gerrit.wikimedia.org/r/181225https://gerrit.wikimedia.org/r/180880
On 10 Jan 2015 04:37, "Ricordisamoa" <ricordisamoa(a)openmailbox.org> wrote:
Thanks. I eventually managed to use ProcessDialog and several widgets in a
script of mine <https://it.wikipedia.org/wiki/Utente:Ricordisamoa/PDC.js>.
I just couldn't make LookupInputWidget work (phab:T85467 <
https://phabricator.wikimedia.org/T85467>, mw:Talk:OOjs
UI#OO.ui.LookupInputWidget vs jQuery autocomplete <
https://www.mediawiki.org/wiki/Talk:OOjs_UI#OO.ui.
LookupInputWidget_vs_jQuery_autocomplete>), and had to fall back to jQuery
UI's autocomplete. The 'solution' I've come up with is, more or less:
var widget= new OO.ui.TextInputWidget();
widget
.$input
.autocomplete( {
source: function ( request, response) {
response( [
request.term + 'test 1',
request.term + 'test 2',
request.term + 'test 3'
] );
}
} );
Very few examples can be found of LookupInputWidget. Does anyone have any
hints about it?
Il 19/10/2014 17:49, Bartosz Dziewoński ha scritto:
OOUI is reasonably stable and can be used in gadgets, if you wish to.
> There is some high-level documentation and several examples at
> https://www.mediawiki.org/wiki/OOjs_UI and complete API reference at
> https://doc.wikimedia.org/oojs-ui/master/ .
>
> Breaking changes still can sometimes happen and when they do, they are not
> being announced very widely (they're just committed with "BREAKING CHANGE"
> in the subject line). If you start using OOUI and something that used to
> work suddenly breaks, please complain at #mediawiki-visualeditor.
>
> _______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l