FWIW, for me as a power user who watches many discussions simultaneously on
multiple wikis, a unified watchlist and more refined tools for watchlist
management are among the features at the top of my development wish list.
Pine
On Mon, Jun 9, 2014 at 6:51 PM, Erik Moeller e...@wikimedia.org
On Mon, Jun 9, 2014 at 11:14 PM, Pine W wiki.p...@gmail.com wrote:
FWIW, for me as a power user who watches many discussions simultaneously on
multiple wikis, a unified watchlist and more refined tools for watchlist
management are among the features at the top of my development wish list.
Am 10.06.2014 09:33, schrieb Erik Moeller:
On Mon, Jun 9, 2014 at 11:14 PM, Pine W wiki.p...@gmail.com wrote:
FWIW, for me as a power user who watches many discussions simultaneously on
multiple wikis, a unified watchlist and more refined tools for watchlist
management are among the features
On Tue, Jun 10, 2014 at 1:09 AM, Thomas Gries m...@tgries.de wrote:
Watchlist and (fine-granular definable) E-Mail-Notifications are very
important - for my daily work.
LiquidThreads and Echo (if you opt-in to mail) offer that (using the
MediaWiki UserMailer functions).
Does Flow also
On Jun 10, 2014 9:33 AM, Erik Moeller e...@wikimedia.org wrote:
On Mon, Jun 9, 2014 at 11:14 PM, Pine W wiki.p...@gmail.com wrote:
FWIW, for me as a power user who watches many discussions
simultaneously on
multiple wikis, a unified watchlist and more refined tools for watchlist
Yes, there are docs. Please edit and link from other pages.
https://www.mediawiki.org/wiki/Google_Hangout_meetings
Nemo
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
There is no mention of this feature in
https://www.mediawiki.org/wiki/API:Rollback but according to Helder in
this bug report https://bugzilla.wikimedia.org/show_bug.cgi?id=66273
mediawiki insert every page to which a rollback api was used on to a
users watchlist.
Is there a way to disable it?
Dear Brad,
Thank you very much. Most extensions are now showing all recent branches.
The following extensions, however, still have missing branches:
Elastica: most recent `origin/REL1_22', have `origin/wmf/1.24wmf8'
MobileApp: no `origin/REL1_xx', have `origin/wmf/1.24wmf8
Popups: no
This seems to be a MW bug. Ever since we updated our wiki to MW 1.23, this has
been happening to lots of our users, myself included.
Apparently, the option to add pages edited to the watchlist is checked by
default, which probably needs to be disabled by default.
Date: Tue, 10 Jun 2014
Arcane 21 wrote:
This seems to be a MW bug. Ever since we updated our wiki to MW 1.23,
this has been happening to lots of our users, myself included.
Apparently, the option to add pages edited to the watchlist is checked by
default, which probably needs to be disabled by default.
I believe this
On Jun 10, 2014 9:18 AM, MZMcBride z...@mzmcbride.com wrote:
And
sysadmins of larger wiki installations probably want to re-visit whether
the user preferences defaults are appropriate for their communities.
They also may wan to consider reading the release announcement emails…
(e.g.
Thanks for the reminder.
However, I think that not all those settings are not necessarily good, and
here's why:
* (bug 45020) Make preferences Add pages I create and files I upload to my
watchlist and pages and files I edit true by default.
This seems to be the default on Wikia, which I have
On Tue, Jun 10, 2014 at 4:57 AM, Petr Bena benap...@gmail.com wrote:
There is no mention of this feature in
https://www.mediawiki.org/wiki/API:Rollback
Unfortunately, the documentation on mediawiki.org is sometimes out of date.
Please feel free to update it.
but according to Helder in this
On Tue, Jun 10, 2014 at 9:56 AM, Arcane 21 arc...@live.com wrote:
I personally only like to use a watchlist to keep track of select pages
instead of every page I edit, so I find this default irritating.
Then change the preference. That's what preferences are *for*.
The default value for a
Hi all,
I am working on this script
https://gerrit.wikimedia.org/r/#/c/138539/2/resources/js/ext.translate.special.pagemigration.js
for importing old translations into the Translation extension. To do so, I
have to create pages in the Translations namespace.
The function createTranslationPages()
On Tuesday, June 10, 2014, Federico Leva (Nemo) nemow...@gmail.com wrote:
Yes, there are docs. Please edit and link from other pages.
https://www.mediawiki.org/wiki/Google_Hangout_meetings
Interesting, I didn't know about this page.
Tech Talks use Google Hangout on Air, which is a slightly
So, LiquidThreads. :)
If most of the discussion goes around tree structure discussions, and how
some advanced users find wikitext's free form to be an advantage, maybe we
can agree on certain points based on where exactly is LiquidThreads being
used.
* User talk pages. Do we need multithread
On Monday, June 9, 2014, Rachel Farrand rfarr...@wikimedia.org wrote:
Correction to my last email: tomorrow's ECT IRC Hour begins at 1600 UCT
http://www.timeanddate.com/worldclock/fixedtime.html?msg=ETC+IRC+Houriso=20140610T16p1=1440
Thank you, Rachel.
The meeting is starting in a bit
On 10 June 2014 15:34, Quim Gil q...@wikimedia.org wrote:
* User talk pages. Do we need multithread tree discussions in our user talk
pages? No, we don't.
And yet this is a popular use for LQT on LQT-using wikis, so will need
to be covered by Flow.
* Regular talk pages. In most cases a
On Tue, Jun 10, 2014 at 10:34 AM, Quim Gil q...@wikimedia.org wrote:
* User talk pages. Do we need multithread tree discussions in our user
talk pages? No, we don't.
{{citation needed}}
I suspect this is just like the point below.
* Regular talk pages. In most cases a section gets 2-5
* User talk pages. Do we need multithread tree discussions in our user
talk
pages? No, we don't.
* Regular talk pages. In most cases a section gets 2-5 replies at most.
The
I think you mean on average. There are outliers here, and they aren't that
uncommon. That said i agree that in general
The other mail seems to have gone on a huge tangent about the benefits
of Flow / what it can do. This is great but I feel like my original
question has gone unanswered so I am resurrecting it with a new e-mail
subject. I worry lots of good feedback got lost in that big email
chain.
So
On Jun 10, 2014 1:10 PM, Jon Robson jdlrob...@gmail.com wrote:
The other mail seems to have gone on a huge tangent about the benefits
of Flow / what it can do. This is great but I feel like my original
question has gone unanswered so I am resurrecting it with a new e-mail
subject. I worry
On 10 June 2014 09:19, Brian Wolff bawo...@gmail.com wrote:
On Jun 10, 2014 1:10 PM, Jon Robson jdlrob...@gmail.com wrote:
The other mail seems to have gone on a huge tangent about the benefits
of Flow / what it can do. This is great but I feel like my original
question has gone
Jon, here's what I posted last week. It's possible that you missed it
because I didn't post it as a reply to you...
The Flow team is going to work in a few weeks on automatically archiving
talk pages, so that we can enable Flow on pages where there are already
existing conversations. Basically,
Any reason for no enwiki dump this month?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Jun 10, 2014 1:30 PM, Bryan White bgwh...@gmail.com wrote:
Any reason for no enwiki dump this month?
No reason yet. See
http://lists.wikimedia.org/pipermail/xmldatadumps-l/2014-June/001038.html
(You may want to subscribe there)
-Jeremy
___
Please find the notes/log from today's Engineering Community Team IRC Hour
here:
https://www.mediawiki.org/wiki/Engineering_Community_Team/Meetings/2014-06-10
Thanks! :)
On Mon, Jun 9, 2014 at 6:31 PM, Rachel Farrand rfarr...@wikimedia.org
wrote:
Correction to my last email: tomorrow's ECT
In CR comments on https://gerrit.wikimedia.org/r/#/c/135290/
it has been proposed that we make a git clone of the MW core not be
installable until $IP/vendor is populated somehow -- either by
separately cloning the mediawiki/core/vendor project, or preferably by
running composer to obtain
On 11/06/14 02:30, Tim Starling wrote:
In CR comments on https://gerrit.wikimedia.org/r/#/c/135290/
it has been proposed that we make a git clone of the MW core not be
installable until $IP/vendor is populated somehow -- either by
separately cloning the mediawiki/core/vendor project, or
there is currently a patch in gerrit which would do exactly that if merged.
On Tue, Jun 10, 2014 at 11:22 PM, Isarra Yos zhoris...@gmail.com wrote:
On 11/06/14 02:30, Tim Starling wrote:
In CR comments on https://gerrit.wikimedia.org/r/#/c/135290/
it has been proposed that we make a git
On 11/06/14 03:24, John wrote:
there is currently a patch in gerrit which would do exactly that if merged.
Why?
This sounds like a really bad idea, but maybe it isn't, and as a
sysadmin and developer I need to know what it even is so I can decide if
I should flip the fuck out. Or not.
-I
My suggestion, Flip the fuck out Its a really bad idea that wasnt thought
though, If users want SwiftMailer support it should be done in an
extension, and not in core
On Tue, Jun 10, 2014 at 11:30 PM, Isarra Yos zhoris...@gmail.com wrote:
On 11/06/14 03:24, John wrote:
there is currently a
On 2014-06-10, 7:30 PM, Tim Starling wrote:
I have suggested, as a compromise, to make the vendor directory be a
submodule pointing to mediawiki/core/vendor. Then users can either run
git submodule update --init to obtain dependencies, or they can omit
submodule initialisation and instead run
What about doing the reasonable thing and leaving core the hell alone? this
should be an extension and not shoved into core.
On Tue, Jun 10, 2014 at 11:43 PM, Daniel Friesen dan...@nadir-seen-fire.com
wrote:
On 2014-06-10, 7:30 PM, Tim Starling wrote:
I have suggested, as a compromise, to
On 11/06/14 03:31, John wrote:
My suggestion, Flip the fuck out Its a really bad idea that wasnt thought
though, If users want SwiftMailer support it should be done in an
extension, and not in core
On Tue, Jun 10, 2014 at 11:30 PM, Isarra Yos zhoris...@gmail.com wrote:
Okay, so I'm completely
That's what I needed - I prefer using documentation rather than random
options :)
Thanks
On Tue, Jun 10, 2014 at 3:57 PM, Brad Jorsch (Anomie)
bjor...@wikimedia.org wrote:
On Tue, Jun 10, 2014 at 4:57 AM, Petr Bena benap...@gmail.com wrote:
There is no mention of this feature in
There is zero reason that this shouldnt be in an extension.
Basically a few users want to install a shinny new toy called swiftmailer
into core, just because its shiny. In doing so they add a complexity and
headache. Such a addition should be done as an extension
On Tue, Jun 10, 2014 at 11:55
On 11/06/14 13:22, Isarra Yos wrote:
That's a lot of discussion, and I'm not sure which bits are actually
relevant here, so to clarify - are you saying that it's been proposed
that MediaWiki not be installable from git without extra steps? If so,
what would be the purpose of that?
In the
This also has knock on impacts elsewhere. BD808 has a patch that uses
PSR-log and Monolog for logging. We're starting to move to a model where we
recognize that we shouldn't write everything and that things in core have
significantly better replacements in the wider PHP community. It doesn't
make
40 matches
Mail list logo
