Sending a Cc: to wikitech-l, hoping that someone knows something about it there.
What is the actual situation with respect to this extension? Who
decides whether and when it will be put into effect on Wikipedia?
André Engels
On Tue, Dec 27, 2011 at 6:20 PM, Tisza Gergo <gtisza(a)gmail.com> wrote:
> Andre Engels <andreengels <at> gmail.com> writes:
>>
>> A more far-reaching and better solution has already been discussed for
>> years, namely porting the interwikis to a separate (wiki) site, so
>> that such changes can be made at once for all languages rather than
>> having to be done separately at each. Maybe that will be worked on
>> with the data project the Germans are setting up.
>
> You mean the Interlanguage extension[1], right? The extension page says it is
> stable, so maybe the projects just need to start actually using it?
>
>
> [1] https://www.mediawiki.org/wiki/Extension:Interlanguage
>
>
> _______________________________________________
> Pywikipedia-l mailing list
> Pywikipedia-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
--
André Engels, andreengels(a)gmail.com
The support requests for users with "PHP Fatal error: Cannot redeclare
wfProfileIn()" continue in #mediawiki.
My idea on how to fix the issue previously was to include in 1.18.1
(whenever we release it) an includes/ProfilerStub.php with something like:
<?php wfDeprecated( 'includes/ProfilerStub.php' );
So that it would override any dead includes/ProfilerStub.php from an old
version of MediaWiki and the bad require_once people still have would just
become a no-op and things would continue working.
I've been starting to think that in 1.19 we should drop StartProfiler.php
altogether.
StartProfiler.php simply exists to initiate the profiler. It's basically a
LocalSettings.php that runs before LocalSettings.php
Back in 1.17 we loaded things in the order:
StartProfiler, Defines, AutoLoader, DefaultSettings, LocalSettings
However the order we load things now is:
Init, AutoLoader, Profiler, Defines, StartProfiler, DefaultSettings,
LocalSettings
So there is absolutely no extra value to StartProfiler now since it loads
directly before our settings and can no longer profile things before the
settings.
To top it off we have comments like these in our code:
# Include site settings. $IP may be changed (hopefully before the
AutoLoader is invoked)
If $IP is changed, it's naturally going to be changed in LocalSettings.php
We're 'hoping' the AutoLoader won't be invoked until AFTER $IP is
modified. But loading StartProfiler BEFORE it and recommending patterns
that might invoke the AutoLoader.
Considering the support requests we get related to bad StartProfiler.php
files, the bad documentation on how to setup StartProfiler.php, and the
fact it doesn't add any advantage over LocalSettings.php anymore. I'm
thinking we should stop including StartProfiler.php and just make anyone
who actually wants to use the profiler move their profiler configuration
into LocalSettings.php with the rest of their config.
We could include a debug line if we want:
if ( is_readable( "$IP/StartProfiler.php" ) ) {
wfDebug( 'You have a outdated StartProfiler.php in your install which is
no longer in use. We recommend you delete it and move any profiler config
you wish to keep into your LocalSettings.php' );
}
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Hi, I talked with a developer of cluebot and we have had an
interesting idea. It would be really cool if tools like huggle, clue
bot and others could communicate so that for instance people would not
attempt to revert same edit in same time, could report to cluebot new
vandalism so that it could update the definitions or mark edits as
valid, share whitelist and such. For this it's necessary to create
some communication protocol which tool would be using.
My original proposal was to use irc for this because it's not so
complicated, but Ryan told me that using the
http://burrow.openstack.org/ would be much better for this purpose,
what do you think about it, is there someone who would like to discuss
some standardised protocol we could implement to the tools for
vandalism help?
My idea was to setup a simple irc network on labs where the tools
would be able to send messages, each project would have own channel
and tools would use standardised messages including various data.
However this has some disadvantages, the port 6667 could be firewalled
and it doesn't offer so many features. Also it's quite possible that
someone could "hack" into communication channel in order to cause
harm.
So maybe the first question to discuss is which system to use, if irc
or queues? The next step would be probably to set up a wiki page with
details so that developers could update specification of this
protocol.
Now that skins/common/wikibits.js is gone, so is the function ts_makeSortable. What is the equivalent call to ts_makeSortable(table) in MediaWiki 1.18?
Here is our code we need to convert:
function makesortable( context ) {
$('table.sortable', context)
.each(function(index, table){
if (!$(table).find('th a span.sortarrow').length) {
ts_makeSortable(table);
}
});
}
This is from an extension that sorts a table by a specified column when the page is rendered.
Thank you.
DanB
Hi!
I'm working on a booking-extension for booking events for my users.
To make management easy, I have my event-pages simply to include
{{Special:Booking}} to be put into the booking- and calendar-list.
Is there a way to get the page-id of the parent-page?
It's easy to se if the special-page is included in another page, but I
want to show dates, prices etc depending on the page being viewed.
Any hints, or do I have to to split the extension into a special-page +
a tag-extension?
--
Henning Wangerin
Skoltoften 9, DK - 6400 Sonderborg
www.alslug.dk - www.opensourcedays.org - www.ubuntudanmark.dk
Is there a 404 hook that triggers when a user tries to look up a page that
doesnt exists in the database?
It should hopefully replace the page
shown<http://en.wikipedia.org/wiki/SomePageThatDoesn'tExists>
.
- Hunter F.
We've sorta informally done things were revisions have gotten tagged for
some particular person's review as an area of specialty, but we've never
really had formal division of labor among separate parts -- nothing for
instance that can be used to automatically queue things up for particular
peoples' inboxes for timely review.
Often, little things are suitable for many people to look at, but major
subsystem refactorings -- like the landing of Aaron's file backend changes
-- really are specialized and need to be looked over by somebody who's a
specialist, rather than just whoever gets around to looking it over.
I'd like us to seriously consider having primary reviewers for various code
modules, so things like this get handled asap and don't end up falling
through the cracks -- big changes, and small confusing changes ;) -- should
get pretty consistently treated.
Projects like Firefox or the Linux kernel tend to have responsible parties
for various modules, who either manage ingestion of patches through the
source control or issue tracker and do testing, review, feedback, and
eventual merging. I think we would do well to emulate this a little more
explicitly than we do today, especially if we're trying to keep from having
an ever-growing review backlog.
Thoughts? Volunteers?
-- brion
If I create a tag extension like this:
$parser->setHook('foobar', 'myCallback');
function myCallback($input, $args, $parser, $frame) {
return 'hello world';
}
can the callback "myCallback" efficiently detect the name of the parser tag, "foobar", that invoked it?
The business problem is this: I use the same callback with 20 different tag names, and I'd like the behavior to change slightly depending on which tag name was used. (The tag names are the names of database servers in my company, and the callback accesses the particular database.)
Right now I am using a very inefficient solution: dynamically creating 20 callbacks (one for each tag name), each with slightly customized behavior. I'd rather do it with one callback.
I realize this would be easy if I'd used a single tag name plus a variable argument, but it's too late to make that change. (The tags have been used 10,000 times and are widely known in our company.)
Thank you very much.
DanB
ps: I asked this a few years ago, when the answer was "no," but maybe things have changed by now.....
Ryan wrote:
>
> Green has a meaning of "Go" or of "this is ok" in many cultures.
> Making either side green gives a bias to the diff. Similarly with red.
> Red means "Stop" or "this is not ok". Many people associate red with
> blood, and green with nature.
When the French created the new color scheme, they assigned no meaning to
the colors, and neither should we. You can associate any meaning with any
color and find fault with any one of them... Yellow means "hate" in other
cultures. Blue means "move over, police!". The possibilities are endless.
Let's just make everything gray... Oh no, grey depresses me...
Fact is, red/green is good for inline diffs, but any other color is fair
game for side-by-side diffs.
--
Erwin Dokter