Hey,
Validator was rejected from being included in core
I'm happy it did. The code was quite poor at that time (two years back?).
And it still is not a hallmark of great design, though certainly not below
average MW quality at this point. Regardless of that, I now think it is a
bad idea to have
2013/7/19 Antoine Musso hashar+...@free.fr
And installing yoursite would be something like:
mkdir mysite
cd mysite
composer require mediawiki/core
composer require wikibase/wikibase
# which installs data-values/data-values ask/ask as well
Just curious, why is composer require
Hey,
Just curious, why is composer require mediawiki/core needed?
Because Hashar is talking about having a MediaWiki installation package,
which effectively turns into My MediaWiki installation when you start
using it. This package specifies all the things you want to install (in its
Le 21/07/13 22:58, Ryan Lane a écrit :
When I attempt to
upgrade MediaWiki I currently have to write down all of the extensions, and
ensure all of them are compatible with MediaWiki. With some subsets, I need
to ensure they are compatible with each other (like SMW, SF, SRF). Now I'm
going to
Le 22/07/13 13:29, Denny Vrandečić a écrit :
And installing yoursite would be something like:
mkdir mysite
cd mysite
composer require mediawiki/core
composer require wikibase/wikibase
# which installs data-values/data-values ask/ask as well
Just curious, why is composer
Hey,
wikibase/wikibase does not list mediawiki/core as a dependency :)
Indeed. Right now this just allows you to install Wikibase into an existing
MW install. Before we can go all the way, we first need to be able to do a
MediaWiki (+extensions) install, which is something still under
Ah, OK, understood. Thanks.
2013/7/22 Jeroen De Dauw jeroended...@gmail.com
Hey,
wikibase/wikibase does not list mediawiki/core as a dependency :)
Indeed. Right now this just allows you to install Wikibase into an existing
MW install. Before we can go all the way, we first need to be
On 22.07.2013, 16:11 Jeroen wrote:
Hey,
Just curious, why is composer require mediawiki/core needed?
Because Hashar is talking about having a MediaWiki installation package,
which effectively turns into My MediaWiki installation when you start
using it. This package specifies all the
When I attempt to
upgrade MediaWiki I currently have to write down all of the extensions, and
ensure all of them are compatible with MediaWiki. With some subsets, I need
to ensure they are compatible with each other (like SMW, SF, SRF). Now I'm
going to need to do that and track the
Hi,
please, everyone calm down and honesty try harder to assume faith and
respect the capabilities of each other. Respect includes to avoid
terminology like to bitch, to sneak in, stupid when describing each
other's actions.
One good way is when you are angry about an email, step back, wait a
This isn't an appropriate list for this, but MaxSem and hashar told me to
post it here anyway, so here goes.
There's a patch[1] to remove 'visualeditor-enable' from $wgHiddenPrefs,
essentially allowing for disabling VE on a per-user basis again. It has
overwhelming community support, but the
On Mon, Jul 22, 2013 at 10:40 AM, Bartosz Dziewoński
matma@gmail.com wrote:
This isn't an appropriate list for this, but MaxSem and hashar told me to
post it here anyway, so here goes.
There's a patch[1] to remove 'visualeditor-enable' from $wgHiddenPrefs,
essentially allowing for
It seems that a package manager is a reasonable way to manage a growing set
of dependencies.
Composer seems to me (without knowing too much about it) to be a reasonable
package manager.
I've heard the objection expressed that this will require new users of
wikibase/etc to learn composer.
I've mentioned this informally to a few people, but it came up again in
discussion and I thought maybe I'd bring the idea to a wider audience.
TowTruck (https://towtruck.mozillalabs.com/) is a realtime collaboration
framework developed by Mozilla (but not firefox-specific). It provides the
Hi,
sorry for another long Email today.
Currently, when you change a Wikidata item, its associated Wikipedia
articles get told to update, too. So your change to the IMDB ID of a movie
in Wikidata will be pushed to all language versions of that article on
Wikipedia. Yay!
There are two use cases
On Mon, Jul 22, 2013 at 8:39 AM, Mark A. Hershberger m...@everybody.orgwrote:
On 07/21/2013 08:09 PM, Tim Starling wrote:
No, absolutely not. Do not remove something just because it has been
deprecated for two major versions.
Do you have any recommendations for how we should handle
On 07/22/2013 11:43 AM, Chad wrote:
Telling me it's like cpan just brings back awful awful memories...
I apologize. I can't say my experience with cpan was all roses, but it
seems that my experience was better than yours. ;)
--
http://hexmode.com/
Love alone reveals the true shape of the
As a user, I like to see more effective server rendered pngs as
default, just because they are simply client independent.
And also: https://bugzilla.wikimedia.org/show_bug.cgi?id=48032
praveenp
On Monday 22 July 2013 06:23:37 AM IST, Peter Krautzberger wrote:
I'm wondering if the lack of
As a(nother) user, I have been very pleased to see unicode-complete fonts
gradually make the use of images for non-roman orthography gradually
disappear. When I see non-English text on a page, greek letters, or simple
expressions with super- and sub-scripts, I can generally highlight, style,
and
Hi Nik,
Just a quick comment on choosing ElasticSearch over Solr:
We use Solr at Wikia, and we have a lot we can offer the Foundation in terms of
knowledge sharing. It might be a good idea to consider future opportunities to
collaborate while vetting ElasticSearch.
Even if ElasticSearch is
I've been working on a client's website that uses a lot of citations and
runs 1.19. After a bit of profiling over the last few days, the use of
some of Wikipedia's templates stood out. I decided to try and backport
Scribunto to 1.19 to see if that would help.
After writing a couple of shims --
On Mon, Jul 22, 2013 at 12:10 PM, Mark A. Hershberger m...@everybody.org
wrote:
Would anyone mind horribly if I branched Scribunto for 1.19 and
committed my changes there? I'm well aware that future work on
Scribunto will continue without any consideration for 1.19's capabilities.
As long
On Mon, Jul 22, 2013 at 12:00 PM, Mark A. Hershberger m...@everybody.orgwrote:
On 07/22/2013 11:43 AM, Chad wrote:
Telling me it's like cpan just brings back awful awful memories...
I apologize. I can't say my experience with cpan was all roses, but it
seems that my experience was better
Scott,
I was going to respond to this a while ago but couldn't really do it
justice. I'm still pretty sure my explanation won't be great, which is an
indication of just how good Google is.
For strait search there is nothing we can do that Google can't. It might
cost them more time and money to
It seems like there are also a bunch of hacky search-alike features built
into the mediawiki database. For example, all pages linking to this
page, my contributions, etc. From a code cleanup standpoint, it would
also be worthwhile if these were all unified and brought together under a
single
I wasn't aware the preference was hidden. Interesting. This should
definitely be merged and deployed.
*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
On Mon, Jul 22, 2013 at 9:47 AM, bawolff
You're not convincing me ;-)
-Chad
On Jul 22, 2013 9:06 AM, C. Scott Ananian canan...@wikimedia.org wrote:
On Mon, Jul 22, 2013 at 12:00 PM, Mark A. Hershberger m...@everybody.org
wrote:
On 07/22/2013 11:43 AM, Chad wrote:
Telling me it's like cpan just brings back awful awful
On 07/22/2013 09:20 AM, Derric Atzrott wrote:
If we require composer, we require users to learn to use composer.
Some like myself have never used it, and while it’s a skill I should
probably learn that will save me considerable time, it may be that
not all will find being forced to learn a new
On Mon, Jul 22, 2013 at 8:36 AM, Mark A. Hershberger m...@everybody.orgwrote:
On 07/22/2013 09:20 AM, Derric Atzrott wrote:
If we require composer, we require users to learn to use composer.
Some like myself have never used it, and while it’s a skill I should
probably learn that will save
Just to clear some things up, composer is *not* a package manager. It is
actually pretty terrible at being a package manager, mainly because it's
not supposed to be one. The purpose of composer is solely dependency
management.
Because of that, using it as a package manager requires using some
Small correction.
2013/7/22 Denny Vrandečić denny.vrande...@wikimedia.de
* Subscriptions: one table on the client. It has two columns, one with the
pageId and one with the siteId, indexed on both columns (and one column
with a pk, I guess, for OSC).
That's entityId - siteId, not pageId to
Hi,
When the ResourceLoader was deployed (or even before it) to production,
there were migration development guides for gadget/extension developers:
-
http://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension_developers
-
And now it's REOPENED. I'd like some justification rather than the VE team
saying it's our product, so we decide.
*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
On Mon, Jul 22, 2013 at 12:37 PM, Bartosz
On Mon, Jul 22, 2013 at 12:15 PM, Tyler Romeo tylerro...@gmail.com wrote:
Just to clear some things up, composer is *not* a package manager. It is
actually pretty terrible at being a package manager, mainly because it's
not supposed to be one. The purpose of composer is solely dependency
On Mon, Jul 22, 2013 at 12:53 PM, C. Scott Ananian
canan...@wikimedia.orgwrote:
Arguably the problem which needs to be solved here is dependency
management.
Regardless, the question is: can composer help? It appears that it can:
https://www.mediawiki.org/wiki/Composer
I'm interested in
On that note, I think we should start forcing MediaWiki developers to use
Eclipse for PHP. Of course some people prefer using just a text editor, but
I'm sure no matter what it'll be more efficient in Eclipse, and if it isn't
we can just have Eclipse fix it.
Seriously, though, I understand why
On Mon, Jul 22, 2013 at 12:55 PM, Tyler Romeo tylerro...@gmail.com wrote:
Partially. The issue is that extensions are both packages and dependencies.
Scribunto is itself an independent package that a wiki can install, but at
the same time it can be a dependency for other extensions. That's
On Mon, Jul 22, 2013 at 12:37 PM, Bartosz Dziewoński matma@gmail.comwrote:
The bug for that patch was just WONTFIXed, synchronizing information.
https://bugzilla.wikimedia.**org/show_bug.cgi?id=50929#c16https://bugzilla.wikimedia.org/show_bug.cgi?id=50929#c16
Just to accomodate people too
Another correction, same line. Gosh, it's hot here. Brain not working. Me
off home.
2013/7/22 Denny Vrandečić denny.vrande...@wikimedia.de
2013/7/22 Denny Vrandečić denny.vrande...@wikimedia.de
* Subscriptions: one table on the client. It has two columns, one with
the pageId and one with
On 07/21/2013 08:09 PM, Tim Starling wrote:
No, absolutely not. Do not remove something just because it has been
deprecated for two major versions.
Do you have any recommendations for how we should handle deprecations?
Is this done on a case-by-case basis?
Mark.
--
http://hexmode.com/
Love
The bug for that patch was just WONTFIXed, synchronizing information.
https://bugzilla.wikimedia.org/show_bug.cgi?id=50929#c16
--
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On Mon, Jul 22, 2013 at 6:25 AM, Denny Vrandečić
denny.vrande...@wikimedia.de wrote:
I assume Ryan didn't mean to single out the Wikidata development team.
Other teams have done this as well -- the Translate extension depends on
ULS, CodeEditor depends on WikiEditor, Semantic Result Formats
A friend of mine asked me what's the best way to identify actually executed
MediaWiki extensions, not just the ones that are installed.
Any hints? I thought that enabling debug logs for a day, then grepping for
the text of filenames in the directory 'extensions' (subtracting out the
stuff that
What do you mean by actually executed? Because that kind of various by
extension. A special page extension is executed when its special page is
viewed by a user. A parser hook extension is executed when a user saves a
page with that parser function in it. Etc.
*-- *
*Tyler Romeo*
Stevens
Hey,
I suspect you are out of luck here, and already have one of the most viable
approaches in mind. A silver bullet solution that covers all types of
extensions seems very unlikely. Even if you look at things such as all
lines of code that got executed, you'd still need to analyse this per
Hey,
npm has a newly-added 'peerDependencies' feature. It looks like composer
could use a similar feature. Anyone want to work on a composer patch?
I might be misunderstanding what this peerDependencies does, though if not,
then it is different then what is needed for the scenario described
When Vector skin became the default, users continued to have preferences
for other skins. That went extremely well, and did not negatively impact
editing. (I'll note that there were comparatively few bugs reported when
Vector became default, and none of them prevented people from doing
Hey,
Regardless, the question is: can composer help? It appears that it can:
https://www.mediawiki.org/wiki/Composer
Yeah, and we've already done most of the steps to make this work for
extensions in core. If you got a MW install, you can already install
Wikibase (together with all its
On Mon, Jul 22, 2013 at 11:24 AM, Jeroen De Dauw jeroended...@gmail.comwrote:
The solution proposed by Hashar in some other thread is to have a
MediaWiki installation package, which just contains a composer.json file
with core in it, where people can add dependencies, and then install.
Before
I am getting real sick of the WMF developers shoving shity products down
the throat of their users and saying FUCK YOU. That is the pattern that I
have seen over the recent months starting primarily with Notifcations and
now moving to VE. It really pisses me off that more and more sites are
On Mon, Jul 22, 2013 at 9:51 AM, Tyler Romeo tylerro...@gmail.com wrote:
Seriously, though, I understand why the VE team might want to force
everybody to use VE
That's a misrepresentation of the facts. We're not talking about
forcing people to use VE. We're talking about whether there should
be
I support merging and deploying https://gerrit.wikimedia.org/r/73565 as
soon as possible. That said, there are still open questions in my mind.
C. Scott Ananian wrote:
Erik Moeller wrote:
Our overall concern, and the reason we did not offer a preference, is
that out of sight, out of mind makes it
Minimal java-script load my ass, I guess you must be using a fiber-optic
connection. Most pages already have a lag due to the amount of JS needed to
run the site. Jumping pages have been a normal thing since resourceloader
(caused by lagging JS issues)
On Mon, Jul 22, 2013 at 2:36 PM, Erik
Putting all of the issues aside, I'd like to know what the reason is for
hiding the preference. Let's assume for a second that VE does not hinder
users at all, that it's JS footprint is nonexistent, and that the interface
changes aren't that bothersome (which, to an extend, are true). Even with
The npm peerDependency option is explicitly for extensions/plugins that
depend on other extensions. Ie, a jQuery plugin that requires another
jQuery plugin to also be loaded (a peer). This is the inter-extension
dependency problem that was being discussed, as I understand it. (I could
be wrong of
Le 22/07/13 15:20, Derric Atzrott a écrit :
To throw another viewpoint into the mix. If we require composer, we
require users to learn to use composer. Some like myself have never
used it, and while it’s a skill I should probably learn that will
save me considerable time, it may be that not
Thanks!
-Adam
On Mon, Jul 22, 2013 at 11:04 AM, Jeroen De Dauw jeroended...@gmail.comwrote:
Hey,
I suspect you are out of luck here, and already have one of the most viable
approaches in mind. A silver bullet solution that covers all types of
extensions seems very unlikely. Even if you
Le 22/07/13 19:31, Ryan Lane a écrit :
Another reason for having separate components like the WikibaseModel or
Diff is that they are not MediaWiki extensions, but pure PHP libraries.
Any PHP script can reuse them. Since the WikibaseModel is not trivial, this
should help with the writing
Sounds like a wide net will need to be used. Thanks!
-Adam
On Mon, Jul 22, 2013 at 10:45 AM, Tyler Romeo tylerro...@gmail.com wrote:
What do you mean by actually executed? Because that kind of various by
extension. A special page extension is executed when its special page is
viewed by a
2013/7/22 Antoine Musso hashar+...@free.fr
Given we migrated our community from
subversion to git, I am confident enough that using composer will be
very easy to the community.
:D
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On Mon, Jul 22, 2013 at 9:51 AM, Eran Rosenthal eranro...@gmail.com wrote:
Hi,
When the ResourceLoader was deployed (or even before it) to production,
there were migration development guides for gadget/extension developers:
-
Le 22/07/13 15:40, Bartosz Dziewoński a écrit :
This isn't an appropriate list for this, but MaxSem and hashar told me to
post it here anyway, so here goes.
There's a patch[1] to remove 'visualeditor-enable' from $wgHiddenPrefs,
essentially allowing for disabling VE on a per-user basis
On Mon, Jul 22, 2013 at 3:00 PM, Antoine Musso hashar+...@free.fr wrote:
The reason I did not deploy that change on sight it is that it goes
against bug 48666 which asked to hide the preference:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48666
Since I was not willing to enter an
On Mon, Jul 22, 2013 at 11:41 AM, John phoenixoverr...@gmail.com wrote:
Minimal java-script load my ass,
Your language and tone are inappropriate. Please keep it civil.
I guess you must be using a fiber-optic
connection. Most pages already have a lag due to the amount of JS needed to
run the
2013/7/22 Ryan Lane rlan...@gmail.com
For pure PHP libraries, they could be distributed like pure PHP libraries
usually are. They can be packaged for multiple distros and be available via
apt/yum/composer (or pear). Having them as MediaWiki extensions is somewhat
awkward.
Yes, agree on
On Mon, Jul 22, 2013 at 3:23 PM, Denny Vrandečić
denny.vrande...@wikimedia.de wrote:
Assume you have class Ext which relies on class Core, but class Core should
not rely on class Ext, because they are on different architectural levels.
If Ext and Core are together, your CI will load them both
Thanks to Chad, this has now moved to Gerrit as labs/tools/grrrit. And
since gitblit is still down, you can browse the code at
https://github.com/wikimedia/labs-tools-grrrit
--
Yuvi Panda T
http://yuvi.in/blog
___
Wikitech-l mailing list
2013/7/22 Tyler Romeo tylerro...@gmail.com
Architectural integrity of code is a design-level issue. Continuous
integration is a programming and quality assurance-level issue. They have
nothing to do with each other, and you can maintain architectural integrity
just fine without having to
Hey,
The solution proposed by Hashar in some other thread is to have a
MediaWiki installation package, which just contains a composer.json
file
with core in it, where people can add dependencies, and then install.
Before that will work, we'll need to get rid of global scope
assumptions
Le 19/07/13 23:26, Antoine Musso a écrit :
mkdir mysite
cd mysite
composer require mediawiki/core
composer require wikibase/wikibase
# which installs data-values/data-values ask/ask as well
snip
And a vendor directory containing all dependencies. At the root of your
directory you
On 23/07/13 04:36, Erik Moeller wrote:
On Mon, Jul 22, 2013 at 9:51 AM, Tyler Romeo tylerro...@gmail.com wrote:
Seriously, though, I understand why the VE team might want to force
everybody to use VE
That's a misrepresentation of the facts. We're not talking about
forcing people to use VE.
On 22 July 2013 11:45, Tyler Romeo tylerro...@gmail.com wrote:
Putting all of the issues aside, I'd like to know what the reason is for
hiding the preference. Let's assume for a second that VE does not hinder
users at all, that it's JS footprint is nonexistent, and that the interface
changes
On 7/22/13, James Forrester jforres...@wikimedia.org wrote:
On 22 July 2013 11:45, Tyler Romeo tylerro...@gmail.com wrote:
Putting all of the issues aside, I'd like to know what the reason is for
hiding the preference. Let's assume for a second that VE does not hinder
users at all, that it's
On Mon, Jul 22, 2013 at 6:49 PM, Brian Wolff bawo...@gmail.com wrote:
Really? Given the number of inane preferences in Special:Preferences
(I'm looking at you preference to disable sending 304 status codes),
this is where we're going to draw the line?
A preference for this seems fairly
On Tue, Jul 23, 2013 at 7:19 AM, Brian Wolff bawo...@gmail.com wrote:
Really? Given the number of inane preferences in Special:Preferences
(I'm looking at you preference to disable sending 304 status codes),
this is where we're going to draw the line?
And also considering the fact that there
On Mon, Jul 22, 2013 at 9:35 PM, James Forrester
jforres...@wikimedia.orgwrote:
It would imply that this is a preference that Wikimedia thinks is
appropriate. This would be a lie. For a similar example, see the removal of
the disable JavaScript option from Firefox 23.
You still haven't
On Mon, Jul 22, 2013 at 7:17 PM, Tyler Romeo tylerro...@gmail.com wrote:
On Mon, Jul 22, 2013 at 9:35 PM, James Forrester
jforres...@wikimedia.orgwrote:
It would imply that this is a preference that Wikimedia thinks is
appropriate. This would be a lie. For a similar example, see the
On 7/22/13, Ryan Lane rlan...@gmail.com wrote:
On Mon, Jul 22, 2013 at 7:17 PM, Tyler Romeo tylerro...@gmail.com wrote:
On Mon, Jul 22, 2013 at 9:35 PM, James Forrester
jforres...@wikimedia.orgwrote:
It would imply that this is a preference that Wikimedia thinks is
appropriate. This
On Mon, Jul 22, 2013 at 10:25 PM, Ryan Lane rlan...@gmail.com wrote:
Assuming a proper implementation of edit/edit source I'm not sure what the
big deal is, but I'm not a hardcore editor so I'm likely just not seeing
it.
I don't edit that much myself, so I can't speak first-person here, but
On 06/29/2013 10:23 PM, sankarshan wrote:
On Sat, Jun 29, 2013 at 3:09 PM, sankarshan foss.mailingli...@gmail.com
wrote:
On Sat, Jun 29, 2013 at 5:09 AM, Sumana Harihareswara
suma...@wikimedia.org wrote:
* Growing Tech Ambassadors membership, to improve two-way communication
between
On Mon, Jul 22, 2013 at 10:25 PM, Ryan Lane rlan...@gmail.com wrote:
Maybe there's a comparison to be made, but there's not really a simple way
to disable VE in MediaWiki other than by having a preference.
I suppose the closest comparison to the Firefox situation would be if
the preference
Hi,
Do you know what file formats will be used for the processes below especially
with importing/exporting from one MediaWiki to another MediaWiki?
Again, you're help is greatly appreciated.
If there is anything else, please let me know.
Thanks!
Agenda and minutes from the second quarterly review of the Engineering
Community Team:
https://www.mediawiki.org/wiki/Volunteer_coordination_and_outreach/ECT_July_2013_quarterly_review
Some highlights:
* The Community Liaisons (coordinated through the Legal Community
Advocacy group) will
On 23/07/13 11:35, James Forrester wrote:
It would imply that this is a preference that Wikimedia will support.
This would be a lie. We have always intended for VisualEditor to be a
wiki-level preference, and for this user-level preference to disappear once
the need for an opt-in (i.e., the
Tyler Romeo wrote:
On Mon, Jul 22, 2013 at 9:35 PM, James Forrester
jforres...@wikimedia.orgwrote:
Each added preference adds to the complexity of our software -
so increasing the cost and slowness of development and testing,
and the difficulty of user support.
Stop being so dramatic. This
I'm glad that Tim is bringing some facts and numbers that back up what the
community is demanding.
To do otherwise will be to play tug-of-war which will lead to an even worse
outcome.
Besides of enabling the preference, a good approach would be to activate or
deactivate that preference depending
James Forrester wrote:
Creating such a preference is a lie, and a lie I cannot endorse.
Oh, for Christ's sake, James. The last thing this thread needs is very bad
pseudo-poetry. And that's not a lie.
What we need is for you and Erik to recognize that you're wrong and to
make this right. Is
On Mon, Jul 22, 2013 at 8:44 PM, Tim Starling tstarl...@wikimedia.org wrote:
and the results from Aaron Halfaker's study [2]
As noted at the top of the page, the analysis is still in progress.
Importantly, there were many confounding variables in the test, some
of which are already documented.
88 matches
Mail list logo
