Hello everyone,
On English Wikipedia in editing window, Reftoolbar is available for every
user by default, which includes button called "Cite". On clicking this a
drop down menu comes with Template, where one can select the particular
template like Cite Web, Cite News, Cite Book etc.
And after selecting one, the window pops up and the editor fills in the
details needed for the particular citation. This makes new editors job easy
while putting the proper citations for the articles and need not worry
about the syntax of Wiki markup.
As far as I know, this thing is not available for Indic Wikipedia, can this
be made possible on Indic too ? I am specially interested in Gujarati (GU)
Wikipedia, having this Citation Template and toolbar makes editors job lot
more handy and easy.
This Mailing list was introduced to me by Amir in one Translation sprint
organized in Pune, India a few weeks ago. Do I need to file a bug report on
bugzilla for this or what should I do ? Please do guide me.
Please ignore this message if I am asking something irrelevant at wrong
place and please do tell me where to ask for it.
--
Thanks
Arnav (ricku).
(User:Rangilo_Gujarati) <http://en.wikipedia.org/wiki/User:Rangilo_Gujarati>
In 1.18.0, the page Special:UserLogin no longer runs the JavaScript in MediaWiki:common.js. Is this an intentional change from 1.17, and if so, is there a workaround to make custom JS run on the login page?
(I tested this by putting alert('foo') in MediaWiki:common.js. The alert appears on all articles & special pages except Special:UserLogin.)
Thank you,
DanB
I noticed this commit during code review:
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/107350
this adds a module providing mw.Api.watch() and mw.Api.unwatch() functions
as handy wrappers around calling the MediaWiki API methods. Each takes
three parameters:
* title
* success callback
* error callback
There's a lot of such things; and it tends to get a bit ugly to keep track
of if making a lot of similar calls.
We may wish to consider using the "promise" pattern, which is available in
jQuery's "Deferred" class -- already used on things like $.ajax behind the
scenes.
Instead of passing pairs of callbacks around all the time, under the
Promise pattern, an async function can return an object to which success
callbacks can be attached. The advantage of this over explicitly passing
callbacks is that the whole state can be bundled in one item -- this can
make things easier to deal with when working with several items at once,
such as starting off a couple queries, then waiting until they all come
back.
A simple call looks fairly similar; using raw callback params:
mw.Api.watch('some title', function() {
// success!
}, function() {
// error!
});
using a $.Deferred promise:
mw.Api.watch('some title').then(function() {
// success!
}).fail(function() {
// error!
});
In many cases, code like in the mw.Api modules could probably just get the
promises 'for free' by passing through to $.ajax and returning the return
value, eliminating some of the boilerplate for passing callbacks around.
You also get benefits from functions like $.when() allowing to collect
several async tasks together...
There's a nice intro, overview, and jQuery-flavored examples on this blog
post:
http://msdn.microsoft.com/en-us/scriptjunkie/gg723713
Let's not go rewriting things for 1.19 ;) but it may be worth looking
through some more of what jQuery gives us as we design more front-end code
for 1.20 and beyond ...
-- brion
I changed the wiki skin from monobook, used since ages, to Vector and
noticed that my background image is not covering the whole screen:
(*) the <div id=mw-head> top element of the screen hides the background url.
Perhaps I misunderstand the Vector skin idea, but here are my questions:
Q1: Is this (*) the intended behaviour and Vector skin layout ?
Q2: What will be a practical solution to display the background image as
background for all elements (i.e. whole screen) except content and the
tabs elements ?
Tom
When sharing a wiki article on Facebook I get to choose which of the available images I want to illustrate the link with. However, when the sharing occurs within a comment that option isn't there, and the same image is selected universally.
http://imagebin.org/193512
Is there some way to configure which image is picked by the sharing sites? And could this be e.g. the first image within the article as opposed to the staple background structure?
Halvor
--
all communication to and from this person will be subject to public availability
public password: 17stovner
Hello,
I have added a new continuous integration job to check our postgres
support.
This is exactly the same job as MediaWiki-phpunit, only the database
backend
change.
The link is:
https://integration.mediawiki.org/ci/job/MediaWiki-postgres-phpunit/
As of now, there are two tests failing.
--
Antoine "hashar" Musso
Hi DanB,
Comments inline:
On Thu, Jan 12, 2012 at 8:31 AM, Daniel Barrett <danb(a)vistaprint.com> wrote:
> As MediaWiki 1.19 is getting ready, I'd like to offer information on how
> MediaWiki 1.18.0 was the most difficult MW upgrade I've ever been through.
>
> Some background: my team administers an internal wiki at a major company
> with ~2000 users, over 100 extensions (many of them custom/unreleased), and
> 100K articles. I've been upgrading MW regularly since 1.11 - every release
> and patch - and have never had this much trouble before, mainly because of
> extensions that broke in 1.18. The typical MW upgrade takes me a day or
> two including regression-testing our extensions. But 1.18 has taken me
> weeks and I'm still not done.
>
Ugh...sorry to hear that.
This message is meant to be constructive & helpful, not blameful: it's
> quite possible that every issue was "our fault" for not keeping up on
> exactly which functions & globals were being deprecated, etc. I'd just like
> to describe what kinds of things broke for a reasonably active wiki run by
> well-meaning people, and to document how we fixed them.
>
This is very helpful, thank you.
I understand your frustration on a lot of these points, and I hope we can
do better in future releases. A lot of the problems you point out here are
issues where we broke backwards compatibility without really good reason to
do so. It's a tough balance, because we also want to reduce our technical
debt, but I think we're probably too haphazard in our approach to nuking
and modifying interfaces.
There's a few things that folks like yourself can do to avoid these
surprises
1. Look through your logs for deprecation warnings now and when you get
1.18 fully running
2. Start testing 1.19 (trunk) *now* rather than waiting for the release.
You may be able to catch a gratuitous interface change while there's still
time to revert it, saving yourself the trouble of updating your code and
saving others from going through the breakage you're experiencing now.
3. Release the source code to your extension, either directly on our site,
or on github/gitorious/wherever in anticipation of being able to mirror
your work in our shiny new Git repo. Our devs are generally pretty good
about updating extensions that are checked into our repository
4. If you can't release the source for whatever reason, help write unit
tests for the APIs that matter to you, so that you can track when they
break or are changed.
5. If you don't have time to help write unit tests, help identify those
APIs you'd like to see have unit tests. I don't know if we have a central
place to collect "most wanted unit tests", but I'm sure something like that
could be started if you're interested in participating at that level.
I vaguely remember some of the changes you outline below, and I think some
of them even stung us during the 1.18 deploy. I'm interested in
understanding better why these changes were made.
More inline:
> 1. The global variable $action disappeared, breaking a bunch of our
> extensions. I switched to $wgRequest->getVal('action').
>
I'll assume Chad is correct that this was never intended to be a stable
global.
> 2. The removal of Xml::hidden() caused one of our extensions to
> break. I switched to Xml::input(..., array('type', 'hidden'))
>
This one bit us during the 1.18 release cycle, and it looks like we fixed
it for ourselves:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97784
...but forgot to also put it back in 1.18 (and trunk for that matter).
Aaron made that fix in the middle of the rather hectic 1.18 deployment
cycle, so I can see why we missed it, but it's still a shame. Given that
this will probably also bite us in 1.19, we should probably backport to
trunk, and REL1_18 for those people that haven't upgraded yet.
3. A few of our older extensions were not ported to ResourceLoader yet
> and were adding JS and CSS via $wgOut->add... calls. They worked in 1.17
> and all broke in 1.18. I ported them to use ResourceLoader, but this is not
> a good solution yet because of bug 31676 (the 32-stylesheet limit of IE,
> https://bugzilla.wikimedia.org/show_bug.cgi?id=31676) which IMHO is a
> very serious time-bomb waiting to explode. I hope it makes it into
> "1.19wmf deployment" as planned.
>
Is this all versions of IE?
4. Some of our parser tag extensions had a bug, in that they didn't
> return a value in the tag callback. (These tags had no visual display.)
> This didn't cause problems in 1.17 and earlier, but in 1.18.0 it caused a
> UNIQ.....QINU string to render on the page. I fixed our extensions to
> return the empty string, and the problem went away.
>
Yup, it's going to be difficult for us to make MediaWiki releases
bug-for-bug compatible on extensions.
5. The removal of $wgMessageCache->addMessage() broke many extensions,
> some ours and some from mediawiki.org like SimpleForms. Some fixes just
> required use of the i18n file. Our more difficult issue was that we were
> injecting system messages into articles to add tracking categories. On
> advice from this list (thanks!), we used code patterned after
> Parser::addTrackingCategory() to inject categories and it works fine,
> actually much better than what we had.
>
I see the change here:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81027
...but it doesn't look like there was much in the way of mailing list
discussion about this, and I also don't see that the README was updated
when this change was made.
Chad claims this was on a clear path to deprecation, but I'm not so sure it
was, based on the history of this page:
http://www.mediawiki.org/wiki/Manual:$wgMessageCache
It looks like it was marked for deprecation here:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/52503
..which means it was deprecated starting in 1.16. That's old, but not
ancient history. Ubuntu 10.04 ships with MediaWiki 1.15, and that's the
current LTS version of Ubuntu. While I understand all of the arguments for
downloading our tarball rather than using the installed package, it's
reasonable to expect that someone would have the same version of MediaWiki
that ships with their LTS box, regardless of where they got it. There may
be a better litmus than this, but this one seems to be a good compromise
between what seems to be the expectation around these parts ("1.16? that's
o-o-o-ld") and other more conservative, less predicable distros (e.g. RHEL
and Debian) that are commonly used in production environments.
This bug appears to be one consequence of this:
https://bugzilla.wikimedia.org/show_bug.cgi?id=32962
I'm not saying that we can never break backwards compatibility with
whatever reasonable litmus we choose, but that we should do so much more
reluctantly than we currently do it. There should be a tangible,
compelling feature (or complicated bug fix) that results from the breakage,
not merely cleanup.
6. The removal of ts_makeSortable() from wikibits.js threw off a bunch
> of our JavaScript: we were using the function to sort on a different column
> than the first one on render, and in extensions that create tables within
> dialogs. We left the problem unfixed until I can understand the new jQuery
> UI way of doing things (jquery.ui.sortable.js).
>
Yup, we ended up getting hit with some table sorting bugs, too, some of
which may not be solved on our wikis.
> 7. Nearly 100% of our customizations to WikiEditor 1.17 broke in
> 1.18. We had followed the documented rules on mediawiki.org, using
> extensions, ResourceLoader, etc., and everything worked in 1.17.
> Nevertheless in 1.18, toolbars and menus disappeared in IE. Menus appeared
> multiple times instead of once in Firefox. JavaScript objects in one module
> became undefined in others, even with proper dependencies. Some of these
> issues are still not worked out, but most were fixed by a variety of
> changes.
>
The dust is probably still settling on Resource Loader in many ways, so
it's not too surprising that there are problems here. It may be that there
were some changes that could have been postponed or done in a more
backwards-compatible way, but without getting into the details, I can't say
that confidently.
The fact that these are problems in a specific browser is indicative of
problems that may just be tough to avoid. We've found it's hard enough
making sure core functionality works between releases in a cross browser
way, let alone trying to make sure arbitrary developer modifications also
work.
> 8. Our MediaWiki:common.js stopped running on the login page. I
> realize this was a security fix; it just took me by surprise. Fixed by
> writing a custom extension using the hook UserLoginForm to inject the few
> lines of JS we needed, and I'm evaluating other non-JS solutions for more
> security.
>
Yeah, those are always going to be ugly.
> 9. The addHandler() function in JavaScript does not seem to work in
> IE8 anymore. We worked around this by using jQuery's "bind" function.
>
Is there a bug for this problem?
At this point, our test wiki is stable and I am not anticipating any
> further large issues, so we should roll out in the next two weeks or so.
>
Glad to hear this is still on track!
Thanks for reading, and I hope this helps someone,
Very helpful, and I hope this results in a good conversation.
Rob
As MediaWiki 1.19 is getting ready, I'd like to offer information on how MediaWiki 1.18.0 was the most difficult MW upgrade I've ever been through.
Some background: my team administers an internal wiki at a major company with ~2000 users, over 100 extensions (many of them custom/unreleased), and 100K articles. I've been upgrading MW regularly since 1.11 - every release and patch - and have never had this much trouble before, mainly because of extensions that broke in 1.18. The typical MW upgrade takes me a day or two including regression-testing our extensions. But 1.18 has taken me weeks and I'm still not done.
This message is meant to be constructive & helpful, not blameful: it's quite possible that every issue was "our fault" for not keeping up on exactly which functions & globals were being deprecated, etc. I'd just like to describe what kinds of things broke for a reasonably active wiki run by well-meaning people, and to document how we fixed them.
So, here's the list of what we had trouble with, and what we did. I welcome any improvements to our fixes!
1. The global variable $action disappeared, breaking a bunch of our extensions. I switched to $wgRequest->getVal('action').
2. The removal of Xml::hidden() caused one of our extensions to break. I switched to Xml::input(..., array('type', 'hidden'))
3. A few of our older extensions were not ported to ResourceLoader yet and were adding JS and CSS via $wgOut->add... calls. They worked in 1.17 and all broke in 1.18. I ported them to use ResourceLoader, but this is not a good solution yet because of bug 31676 (the 32-stylesheet limit of IE, https://bugzilla.wikimedia.org/show_bug.cgi?id=31676) which IMHO is a very serious time-bomb waiting to explode. I hope it makes it into "1.19wmf deployment" as planned.
4. Some of our parser tag extensions had a bug, in that they didn't return a value in the tag callback. (These tags had no visual display.) This didn't cause problems in 1.17 and earlier, but in 1.18.0 it caused a UNIQ.....QINU string to render on the page. I fixed our extensions to return the empty string, and the problem went away.
5. The removal of $wgMessageCache->addMessage() broke many extensions, some ours and some from mediawiki.org like SimpleForms. Some fixes just required use of the i18n file. Our more difficult issue was that we were injecting system messages into articles to add tracking categories. On advice from this list (thanks!), we used code patterned after Parser::addTrackingCategory() to inject categories and it works fine, actually much better than what we had.
6. The removal of ts_makeSortable() from wikibits.js threw off a bunch of our JavaScript: we were using the function to sort on a different column than the first one on render, and in extensions that create tables within dialogs. We left the problem unfixed until I can understand the new jQuery UI way of doing things (jquery.ui.sortable.js).
7. Nearly 100% of our customizations to WikiEditor 1.17 broke in 1.18. We had followed the documented rules on mediawiki.org, using extensions, ResourceLoader, etc., and everything worked in 1.17. Nevertheless in 1.18, toolbars and menus disappeared in IE. Menus appeared multiple times instead of once in Firefox. JavaScript objects in one module became undefined in others, even with proper dependencies. Some of these issues are still not worked out, but most were fixed by a variety of changes.
8. Our MediaWiki:common.js stopped running on the login page. I realize this was a security fix; it just took me by surprise. Fixed by writing a custom extension using the hook UserLoginForm to inject the few lines of JS we needed, and I'm evaluating other non-JS solutions for more security.
9. The addHandler() function in JavaScript does not seem to work in IE8 anymore. We worked around this by using jQuery's "bind" function.
At this point, our test wiki is stable and I am not anticipating any further large issues, so we should roll out in the next two weeks or so.
Thanks for reading, and I hope this helps someone,
DanB
Greetings!
Reminder about the MediaWiki Workshops for developers (volunteer and staff): Preparing extensions for MediaWiki 1.19 being held on 13 January, 2012 at 19:00 UTC in IRC (#wikimedia-dev).
This IRC workshop will be an opportunity to find out about changes in MediaWiki 1.19 that may require revisions to extensions or skins. Also an opportunity to ask MediaWiki developers questions regarding extension development.
Everyone is invited to attend. Developers interested in serving as "extensions" or "MediaWiki 1.19" experts are encouraged to signup as participants at: http://www.mediawiki.org/wiki/Project:WikiProject_Extensions/MediaWiki_Work…
More information: http://www.mediawiki.org/wiki/Project:WikiProject_Extensions/MediaWiki_Work…MediaWiki.org's WikiProject SysAdmins will also likely host similar MediaWiki Workshops to help third-party wiki system administrators. Stay tuned for more information, and chime in at: http://www.mediawiki.org/wiki/Project:WikiProject_SysAdmins/Ideas
Look forward to seeing folks! Please feel free to forward this along to any interested folks.
-greg aka varnent
-------
Gregory Varnum
Lead Administrator, WikiQueer
Lead, Aequalitas Project
@GregVarnum
fb.com/GregVarnum