n.js/file.js&action=raw&ctype=text/javascript
>
See also
https://en.wikipedia.org/wiki/MediaWiki_talk:Common.js#Remove_MediaWiki:Common.js.2Ffile.js
<https://en.wikipedia.org/wiki/MediaWiki_talk:Common.js#Remove_MediaWiki:Common.js.2Ffile.js>
-- Krinkle
___
he prior CR+2 to have the
> change properly recognized.
>
>
Please don't (and in many repos, people can't). This bypasses Jenkins and
causes other inconsistencies. Instead wait until Jenkins is done and then CR+2
it.
-- Krinkle
___
t's post-pone this until right after Wikimedia's migration is complete.
Third parties can stick to using the LTS or the current stable version
as needed for upto several years more without issue.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
ia.org/tag/performance-team/board/?order=priority
Now that the site and user modules are primary citizens in the ResourceLoader
landscape,
their states can be tracked with mw.loader. This solves long-outstanding issues
such as
https://phabricator.wikimedia.
Fixed, and deployed.
Thanks for reporting and sorry for not noticing that earlier.
— Krinkle
> On 5 Aug 2015, at 17:12, Max Semenik wrote:
>
> Already reported as https://phabricator.wikimedia.org/T108139
> <https://phabricator.wikimedia.org/T108139>
>
> On Wed
> On 7 Aug 2015, at 13:05, S Page wrote:
>
> On Thu, 06 Aug 2015 01:24:03 +0200, Krinkle <mailto:krinklem...@gmail.com>> wrote:
>
> TL:DR; Double-check your wiki's site scripts and your personal scripts
> to ensure "document.write" is no longer used
alising our
migration
from 2005 by converting the file tables as well.
— Krinkle
> On 19 Aug 2015, at 00:52, Brion Vibber wrote:
>
> I have the impression that was an old bug which got fixed sometime in the
> last couple years -- it was accidentally using the current time instead of
&
t: -
> Host: en.wikipedia.org <http://en.wikipedia.org/>
> Accept: */*
< HTTP/1.1 200 OK
..
{"batchcomplete":""}
In the past (2012?) these were definitely being blocked. (Ran into it from time
to time on Toolserver)
It seems php file_get_contents('http://...api..&
n+ for minification. They are too slow and
cause bugs. We use JavaScriptMinifier.
-- Krinkle
[1] https://www.mediawiki.org/wiki/JavaScriptMinifier
<https://www.mediawiki.org/wiki/JavaScriptMinifier>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
around May 2016).
Tech News will announce this change as well, but please help carry this
message into your communities. In January, we will send a reminder before
the change happens.
Yours,
-- Krinkle
For details about the JavaScript-less experience, see
https://www.mediawiki.org/wiki/Compatibility
tly fail for any
number of reasons even in modern browsers, as well as on mobile browsers.
In such scenarios the stylesheet more important, and users effectively get
the fallback experience (as opposed to a page with no styling, which would
happen if we don't do that).
-- Krinkle
On Fri,
Nice work on the API!
I wrote a basic consumer of this API at
http://codepen.io/Krinkle/full/wKOMMN#wikimdia-pageviews
The only hurdle I found is that the 'articles' property is itself
nested/double encoded JSON, instead of a plain object. This was somewhat
unexpected and makes the API
This talk starts in 5 minutes.
5th Floor in WMF offices.
Live stream: https://www.youtube.com/watch?v=UlL6UoRUQAM
-- Krinkle
On Wed, Jan 13, 2016 at 1:38 PM, Rachel Farrand
wrote:
> Please join for the following tech talk:
>
> *Tech Talk**:* Creating Useful Dashboards wit
Hi,
This is the monthly report from the Wikimedia Performance Team for January
2016.
## Our progress ##
### Multi-datacenter
* The central login system started to use DB slaves for some actions
instead of master DB.
* MediaWiki Special pages and Action classes now support defining DB query
and
m mocking in PHP. – https://phabricator.wikimedia.org/T86163
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Feb 16, 2016 at 7:48 PM, Gergo Tisza wrote:
> Awesome, thanks Timo & Bryan!
>
> On Tue, Feb 16, 2016 at 9:19 AM, Krinkle wrote:
>
> > * PHPUnit is now loaded from $WORKSPACE/vendor instead of the frozen
> legacy
> > copy at /srv/deployment/integration/phpu
fix missing dependencies on wikibits. In
MediaWiki 1.28, to be released in November 2016, the wikibits module will
be removed entirely.
-- Krinkle
[1] https://www.mediawiki.org/wiki/ResourceLoader/Legacy_JavaScript
[2]
https://lists.wikimedia.org/pipermail/wikitech-l/2013-October/072776.html
[3
ge (e.g. "To enable X, copy this snippet
to Special:MyPage/common.js, and save"). I don't think we should burden
them with the updating of such snippet themselves.
However we should definitely reach out to authors of wiki pages (e.g.
documentation pages for user sc
th that resolved, we can export mw.loader.state information for page
style modules, which then allows dynamic modules to depend on them.
Thoughts?
https://phabricator.wikimedia.org/T87871
https://phabricator.wikimedia.org/T92459
-- Krinkle
[1] If one would allow page style modules to have dep
On Wed, May 4, 2016 at 4:23 PM, Brad Jorsch (Anomie)
wrote:
> On Wed, May 4, 2016 at 6:34 AM, Krinkle wrote:
>
> > [..] We don't currently require modules to say whether they are a
> dynamic module.
>
>
> Maybe we *should* require that.
>
> Then that coul
On Wed, May 4, 2016 at 1:43 PM, Brion Vibber wrote:
> Quick notes on the migration path:
>
>
> *Cached page HTML*
>
> HTML cached under the old regime would still be served for a while, but
> ResourceLoader would load the newer style. I *think* that should work as
> long as the new versions of th
On Sun, May 8, 2016 at 5:47 PM, Jon Robson wrote:
> Apologies if I'm missing something that makes this so complicated but
> could we not simply throw an error/warning if you use addModuleStyles
> on a module with scripts set
That's exactly what I'm proposing we do.
https://phabricator.wikimedi
ich would've been a workaround (albeit a costly
one, due to pull:N vs push:1).
In addition to these workflow concerns, there is also Continuous
integration of course. But that's a separate issue.
I'm bringing up these concerns now because contrary to what I expected,
Differenti
ld output A would try to load "site" as style module still
(which no longer has styles). Though after a FOUC, it would still fallback
by loading 'site.styles' on-demand as dependency of "site".
[1] https://phabricator.wikimedia.org/T124954
-- Krinkle
Next steps now written up at
https://phabricator.wikimedia.org/T92459#2281878
On Mon, May 9, 2016 at 7:45 PM, Krinkle wrote:
>
>
> On Mon, May 9, 2016 at 7:17 PM, Brion Vibber
> wrote:
>
>>
>>
>> So, step 2 happens at least 30 days after deploying step 1? Or st
ave other (more important) migrations on-going right now.
-- Krinkle
On Sat, Jun 4, 2016 at 8:54 AM, Strainu wrote:
> There is talk in some communities about the wg-globals going away later
> this year, but I can't find anything in the tech updates or mw.org
>
> Is th
TL;DR: A Node.js interactive command-line tool for fixing use of deprecated
javascript functions in on-wiki javascript.
https://github.com/Krinkle/mw-tool-tourbot
In 2011 I started a clean up of site scripts (the "Tour"). You can work on
the tour either per-issue (e.g. remove IE60Fixe
TL;DR: Participate on T589 and help decide what the upcoming schema change
should entail, and how we'll migrate existing data.
Hey all,
Couple weeks ago we dedicated an IRC office hour to
https://phabricator.wikimedia.org/T589 (RFC: image and oldimage tables).
Updated draft at:
https://www.media
them after the fact in error
logs.
Best,
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
w.mediawiki.org/wiki/Manual:Hooks/MessageCache::get
https://github.com/wikimedia/mediawiki-extensions-WikimediaMessages/blob/d742c363/WikimediaMessages.hooks.php#L22-L53
This example may be more complicated than what you need, but it's a
starting point from which you can simplify. here is a
Hi,
The Architecture Committee plans to make a decision in two weeks on the RFC
about the schema change for image and oldimage tables. [1] [2]
Please review the updated RFC page [2] and send any final comments here on
Wikitech-l or Phabricator [1] by 2017-02-01. If no new and significant
concerns
On Mon, Jan 30, 2017 at 1:57 PM, Jan Dittrich
wrote:
>
> State management and data/event propagation goes beyond of what OOUI can
> provide, as far as I (Jan) know. So an obvious candidate was looking into
> MVVM solutions of which the most well known is the React library.
If considering React
and for as long as
I can remember, such feature never existed.
As for documentation, this particular method is quite well-documented:
https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.toolbar-method-addButton
If you need a callbac
d instead use a dependency, but because
you don't want to trigger a load of this module (you merely want to hook into
it if the toolbar is there, you don't want to load another toolbar which is
what adding a dependency would do).
— Krinkle
On 23 Apr 2014, at 14:21, Justin Folvarcik
The module was split out of mediawiki.util, nothing new, no need for any
special treatment here.
It should've been given the same "target" definition as mediawiki.util.
— Krinkle
On 27 Apr 2014, at 19:37, Jon Robson wrote:
> Looks like jquery.accessKeyLabel now seem
h v1 and v2 continue to enjoy simultaneous releases for bug fixes and new
features. For example, jQuery released v1.11 and v2.1 together[4][5].
-- Krinkle
[1] http://blog.jquery.com/2013/01/15/jquery-1-9-final-jquery-2-0-beta-migrate-
final-released/
[2] http://jquery.com/upgrade-guide/1.9
g/wiki/Project_talk:X
->
https://es.wikipedia.org/wiki/Wikipedia_ discusión:X
— Krinkle
On 11 May 2014, at 16:15, Matthew Flaschen wrote:
> On 05/04/2014 05:08 AM, Max Semenik wrote:
>> This proposal makes no sense: all these namespaces _are_ dependent on wiki
>> language, so even if you
ou're a part of and take a
few minutes to ensure there are no deprecation notices being fired when using
them.
In addition, (to see if maybe you missed any) you could perform a few grep/ack
searches if you want to be extra sure (manually, so that you can mentally
exclude false positives).
query.migrate]' + msg, stack:
new Error().stack } );
};
}
I might set up some tracking for it at Wikimedia as well, but I'm not sure if
that'll work properly.
— Krinkle
[1]
https://github.com/wikimedia/mediawiki-core/blob/wmf/1.24wmf4/resources/src/mediawiki/mediawiki.js#L567
[2
On 23 May 2014, at 03:11, Gergo Tisza wrote:
> On Wed, May 7, 2014 at 9:29 AM, Krinkle wrote:
>
>> A rough timeline:
>>
>> * 12 May 2014 (1.24wmf4 [9]): Phase 1 – Instrumentation and logging
>> starts. This
>> will run for 4 weeks (until June 9).
>
Blue")
- Used for graphical user interface (e.g. anywhere HTML is displayed, whenever
it is used inside an message)
- Defined by msg key skinnname-{skin}
— Krinkle
On 25 May 2014, at 18:02, Bartosz Dziewoński wrote:
> On Sun, 25 May 2014 00:11:28 +0200, Daniel Friesen
> wrote:
>
&
https://commons.wikimedia.org/wiki/Commons:Commons_API
https://tools.wmflabs.org/magnus-toolserver/commonsapi.php
https://tools.wmflabs.org/magnus-toolserver/commonsapi.php?image=Van%20Gogh%20-%20Starry%20Night%20-%20Google%20Art%20Project.jpg&meta
— Krinkle
On 3 Jun 2014, at 14:11, Derk-Jan Hartm
f those items still using these legacy features are
aware of this so they may patch the code accordingly (using the upgrade guide[4]
and my earlier announcement [5]). When MediaWiki 1.24 is released, we will
switch off jQuery Migrate for Wikimedia wikis.
— Krinkle
[1] https://bugzilla.wikimedia.org/sh
://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=113204&oldid=113199
I documented the incident just now:
https://wikitech.wikimedia.org/wiki/Incident_documentation/20140517-bits
— Krinkle
On 1 Jun 2014, at 17:22, Helder . wrote:
> On Sat, May 31, 2014 at 1:2
On 8 Jun 2014, at 17:22, James Forrester wrote:
— Krinkle
> On Sunday, June 8, 2014, Martijn Hoekstra wrote:
>
>> On Sun, Jun 8, 2014 at 1:18 AM, Martijn Hoekstra <
>> martijnhoeks...@gmail.com >
>> wrote:
>>
>>>> Flow stores the comments as a
True, composer should be easier to work with than PEAR[1].
However, afaik we never depended on any PEAR packages.
We either shipped them (Services_JSON), provided a fallback or made the feature
optional / in an extension.
-- Krinkle
[1] Easier to instal because it requires less permissions s
box). Outlook Express, Eudora, Thunderbird, Apple Mail and
various web-based clients.
These different clients may have carried over my preferences, but they all had
an option to display it flattened. And I believe it was the default.
While we may or may not know what the default was, I'm
only concatenation and not minification, you can use
&modules=my.module.name&only=scripts&debug=true. Like all unversioned requests,
this is only cached for 5 to 30 minutes (depending on mediawiki configuration).
-- Krinkle
___
Wikitech-l mailing
tly more enhanced in that it also allows
ending individual sessions.
They also have a section "Trusted Browsers" which is slightly different in that
it lists sessions that are of the "Remember me" type and also lists
authenticated devices that won't ask for two-step verif
distributed so we can only upgrade to a version that
drops support for an API after we first upgrade to a version that provides
the new API.[4]
— Krinkle
[1] http://jqueryui.com/download/ and their source repository continues
to maintain jQuery UI 1.11.x, 1.10.x and 1.9.x
[2] http://blog.jqueryu
brary doesn't have to throw an exception in an older browser per se,
in case of jQuery UI it's quite simple. We can only upgrade to jQuery 1.10 when
we drop IE6 support for Grade A. And when we do, IE6 will become
javascriptless[1] and jQuery UI will no longer be relevant as proble
On 26 Jul 2014, at 22:32, Steven Walling wrote:
> This seems really reasonable.
>
> Are we still agreed that Grade A means anything over 1% of readership? If
> so, we should reconfirm what our browser share is really like, because last
> time I checked, IE6 was less than 1% of total and thus eli
Support can mean either depending on the context.
Most of this is uncontroversial, but I found it useful to think through and
sum up.
From a platform perspective to support a browser means that the user
experience is considered acceptable, tested against, and we're committed to
keeping it that wa
ng that route? We have quite
a lot to gain in terms of simplicity and compatibility.
Breaking things can be good, but I haven't seen any short or long term benefits
so far that would justify it.
— Krinkle
On 28 Jul 2014, at 23:02, John wrote:
> I use a standard git checkout. Moving t
pported by Mozilla and
jQuery) it's feature set was good enough to just give it everything (Grade X
instead of Grade B) per a Village Pump thread requesting it.[3]
— Krinkle
[1] https://jquery.com/browser-support/
[2]
https://www.mediawiki.org/w/index.php?title=Compatibility&oldid=111
ire javascript? Quite a few extremist (sorry) out there have javascript
disabled in their browser. We use javascript at all due to technical
restrictions related to site performance (changing the banners without purging
every single article on every wiki from cache, js seems the only way to project
cha
ly.
https://api.jquery.com/jQuery.get/
https://api.jquery.com/jQuery.post/
https://api.jquery.com/jQuery.ajax/
— Krinkle
PS: Please use the Promise interface, not the callback parameters. Don't forget
to handle errors, either.
PS2: While this will help you get the request over POST, the under
tps://gerrit.wikimedia.org/r/#/c/137168/
[5] https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
-- Krinkle
PS: You can get a sense of the progress on our different migrations, past and
present, via these graphs: http://codepen.io/Krinkle/full/zyodJ/
ce 2002 (not "1").
http://korma.wmflabs.org/browser/people.html?id=8
— Krinkle
On 17 Oct 2014, at 23:51, Ricordisamoa wrote:
> On http://korma.wmflabs.org/browser/top-contributors.html I am ranked #123
> with 3452 IRC Messages, while I cannot recall more than 20 or so.
> Mo
h.wikimedia.org/wiki/Zap/Hat
(with ZAP and HAT redirects.)
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
refix analytics-, labs-, labs-tools-, wikimedia-,
operations-, etc.
— Krinkle
On 13 Nov 2014, at 18:16, Chad wrote:
> Please help me draft some guidelines for Phabricator repo callsigns.
>
> https://www.mediawiki.org/wiki/Phabricator/Callsign_naming_conventions
>
> The subpage on
Hey all,
On 3 Jun 2014, Krinkle wrote:
> TL;DR:
> * We did not make the breaking change last week for Wikimedia; it is
> postponed.
> * MediaWiki 1.24.0 will ship with jQuery Migrate switched off.
> * Wikimedia & non-Wikimedia wikis can enable jQuery Migrate if needed.
>
ost license plate systems do the same. Though I'm not sure that was for the
best.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Very nice.
The impact can is also reflected and easy to spot in the "Cluster CPU" graphs
on Ganglia:
https://ganglia.wikimedia.org/latest/?r=month&c=Application+servers+eqiad
https://ganglia.wikimedia.org/latest/?r=year&c=Application+servers+eqiad
— Krinkle
On 3 Dec 2014,
I also have a home-grown framework:
https://github.com/Krinkle/toollabs-base
Originally created for my Toolserver tools. Recently rewritten for Tool Labs.
A few example tools:
* https://tools.wmflabs.org/orphantalk/
* https://tools.wmflabs.org/usage/?action=usage&group=Krinkle
* h
olff
>
Not entirely. Unlike message "copyright", the message used on thumb.php
("badtitletext") is not a "raw html" message. It is meant to be parsed and
displayed regularly. And always was. Except it was re-used for thumb.php, and
forgotten to be
think we should publicly discuss the full HowTo, yet. It's too soon after
release.
CVE applies a very strict policy on that as well (maybe too strict). And the
same at other trackers, and tech organisations. Feel free to ask me on IRC
or elsewhere in private, though.
— Krinkle
until a section is accessed
(lazy-load).
-- Krinkle
[1] Different ideas around an "aside"-accessible table of contents:
* http://underscorejs.org/
* Wikipedia iOS App: http://i.imgur.com/Sg0pqsg.jpg
* User manual: http://asciidoctor.org/docs/user-manual/
_
On Sun, Jan 4, 2015 at 11:42 PM, quiddity wrote:
>
> On Mon, Dec 29, 2014 at 3:42 AM, Prateek Saxena
> wrote:
>
>> On Sat, Dec 20, 2014 at 9:45 AM, Krinkle wrote:
>> > Our table of contents is in desperate need of improvement. Having that
>> be more accessible
used.
>
> Thanks,
> DanB
You shouldn't have to do that.
What is your code doing to jQuery Tablesorter?
Where do you intend to reference/use that additional code?
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
a two-line redirect using RewriteRule.
— Krinkle
On 22 Feb 2015, at 16:20, Petr Bena wrote:
> Hi,
>
> Long time ago I purchased domain cswp.cz in order to use it in same
> way as enwp.org for czech wikipedia (cswp.org was taken by something).
>
> I think that it would be probabl
tware. Please report that to them or
file a bug in Phabricator if there is something they found wrong in the
extension that could help mitigate the issue.
— Krinkle
On 22 Mar 2015, at 13:08, Thomas Mulhall wrote:
> They both have the same name and when in api it would show twice resulting
l of which are deployed at Wikimedia.)
Tracker bugs:
https://phabricator.wikimedia.org/T55120
https://phabricator.wikimedia.org/T42786
— Krinkle
Related thread: [Wikitech-l] Call to eliminate sajax, Daniel Friesen, October
2013
https://www.mail-archive.com/wikitech-l%40lists.wikimedia.org/msg
development and Jenkins equally
It runs the full QUnit test suite in a real browser (multiple even) by simply
running "npm test". [11]
Aside from Node.js, it requires no pre-installed software and is as easy as
"npm install" to set up.
— Krinkle
[1] https://phabricator.wik
lt;https://phabricator.wikimedia.org/T96230#1215473>
There's still room for more optimisations, which are tracked at
https://phabricator.wikimedia.org/T96249
<https://phabricator.wikimedia.org/T96249>.
— Krinkle
[1] https://phabricator.wikimedia.org/T93556
<https://phabric
aster/resources/src/mediawiki/mediawiki.userSuggest.js
<https://github.com/wikimedia/mediawiki/blob/master/resources/src/mediawiki/mediawiki.userSuggest.js>
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
not covered by show_bug/show_activity I assume
will become 404.
(Seems acceptable). Currently they are 301 redirect to old-bugzilla.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
ter in this case. The point is that the message is oversized. It
contains too much redundant information for a simple confirmation that the page
was added to the watchlist.
Considering that this message is not wiki-content, it doesn't make sense to
truncate it. It simply needs to be shortened
notifications that do user interactions (sticky ones, which should not
move but be sticky).
However that brings another problem: Resizing the window. The spreading of
messages over multiple columns would have to either be re-build after resizing
the window.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
#x27;t get worse, the standard will include a natural fallback by
storing the 1-0 ratio image in the src attribute. Which is what we'd want on
older browsers/devices anyway.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
http
e user know that the scheduled action
took place and that it succeeded (or failed)). If they happened as a direct
consequence of a user action, maybe it should appear inside the interface where
it was performed?
Anyway, just my 2 cents :)
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
xt). Because the "align" attribute is a means to an end that has
lots of implications and possible unintended side-effects. Contrary to
text-align and margin, which are very specific and targeted at their purpose.
By replacing a single align attribute with all kinds
Do you know whether fixes for those issues are
>> already included or not? Most important is
>> https://gerrit.wikimedia.org/r/#/c/23900/
>
> That commit is not included. I can merge it in or make a second RC with
> 1.20wmf12.
>
> What do you think is the better wa
On Sep 22, 2012, at 9:31 AM, Daniel Friesen wrote:
> On Sat, 22 Sep 2012 00:10:11 -0700, Isarra Yos wrote:
>
>> On 21/09/2012 11:46, Rob Moen wrote:
>>> On Sep 20, 2012, at 3:48 PM, Krinkle wrote:
>>>
>>>> If they happened as a direct
>>>>
On Sep 22, 2012, at 10:54 PM, Mark A. Hershberger wrote:
> On 09/22/2012 02:50 PM, Krinkle wrote:
>> On Sep 21, 2012, at 4:13 PM, Mark A. Hershberger wrote:
>>> That commit is not included. I can merge it in or make a second RC with
>>> 1.20wmf12.
>>>
>
On Sep 23, 2012, at 8:03 PM, Mark A. Hershberger wrote:
> On 09/23/2012 12:54 PM, Krinkle wrote:
>> Also, this bugzilla query should be empty before release as well (either by
>> fixing bugs,
>> or reviewing/merging pending commits that claim to fix stuff, or deferring
>
in a separate optional repository.
Or perhaps agree that skins should be installed from mediawiki/skins/*.git
repositories, but clones inside mediawiki/extensions/skins/*. That would mean
in module definitions and require's, we just add an extra /skins/.
In that case we should get rid of med
, must use this" is what we want here, at least not until it has
proven itself by being used over a long period of time by other extensions.
I mean, things don't have to be in core to be usable. Let it be an extension,
let it grow. Extensions can perfectly depend on other extensi
On Sep 26, 2012, at 8:01 PM, Niklas Laxström wrote:
> On 26 September 2012 10:08, Krinkle wrote:
>> Another problem I found in the current setup is that its a bit
>> counter-intuitive how to manage the directory structure for developers. I
>> mean, most of
On Sep 27, 2012, at 1:36 AM, Max Semenik wrote:
> On 27.09.2012, 3:26 Krinkle wrote:
>
>> On Sep 26, 2012, at 8:01 PM, Niklas Laxström
>> wrote:
>
>>> On 26 September 2012 10:08, Krinkle wrote:
>>>> Another problem I found in the current setup is tha
ch it expires after 30 days. I guess this explains why the best way is
also the least common way to categorize bot edits in analytics (unless only
covering recent data).
There is an open bug to store the bot flag in the revision table, thus making it
permanently available[2].
-- Krinkle
[1] For e
ct is a VERY bad usability choice. Frankly we shouldn't use it
> anywhere. If we're using JS to make a better UI it would actually be much
> better to output usable checkboxes and then turn the checkboxes into a
> special JS multi-select. Instead of outputting an unusable
never.
The solution I'd propose (and Daniel also mentioned this various times here and
elsewhere) to output checkboxes as fallback and an interface like "jQuery
Chosen"
as enhancement.
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l
On Oct 2, 2012, at 4:25 PM, Chris McMahon wrote:
> I am pleased to announce that Željko Filipin joins WMF this week as QA
> Engineer.
Welcome Željko!
For the last 1.5 year, hashar and I have set up the current integration
environment. I'm also in CET ("Krinkle" on freeno
e it use API modules, ResourceLoader modules, and following
current conventions for front-end code with mw and jQuery).
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
ue and $wgWellFormedXml and be
done with it. Because that it will add /> everywhere is obvious (it should have
one or two assertions to make sure the other behaviour is also tested), no need
to duplicate the entire test suite 2 or 3 times for unimportant details.
-- Krinkle
__
default-available[2] gadget". Then please, *please*, keep them in core. Because
that wouldn't be an improvement over the current situation.
If we have good ground to remove them (because they're silly options that we
don't want end-users to be thinking about), then we remove them.
bug[1], it was disabled in ContentHandler
without dedicated discussion because it was thought of as a minor oddity that
should be removed as a bug.
We know now that (though it might have been a bug originally) it is a major
feature that unless replaced, must not be removed.
-- Krinkle
[1] https://bug
d remove it yourself whenever you feel like.
-- Krinkle
[1] I intend to remove them separately, not all at once. So if support for a
few is shown, I'll still remove the rest. Please reply complete (e.g. "I use X"
will mean I keep X, it
ers as desired. Don't stamp LATER on
the bugs to make it fit the lazy search that only omits "RESOLVED/**".
@AndreKlapper: What do you think?
-- Krinkle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
1 - 100 of 504 matches
Mail list logo
