MediaWiki talk:Common.js

• MediaWiki
• Meta
• Commons
• Wikibooks
• Wikiquote
• Wikisource
• Wiktionary
• de
• fr
• pl
• ja
• jbo
• it
• nl
• es

WikiBugs

Moved this discussion to Wikipedia talk:Kvetch. --MZMcBride (talk) 22:00, 17 January 2011 (UTC)

Improve sortable tables

Sometimes we need to divide the header of a table in two lines, and use (col/row)spans for better organization of the content.

Would it be possible to improve the current script of sortable tables so that it could handle correctly cases like the following?

Wikicode {| class="wikitable sortable" |- ! rowspan=2 | Title 1 ! colspan=2 | Title 2 |- ! Title 2.1 ! Title 2.2 |- | B || C || A |- | A || B || C |- | C || A || B |}

Rendering (try to click on sorting buttons) Title 1 Title 2 Title 2.1 Title 2.2 B C A A B C C A B

As can be noticed, only the first button is added in the right place, and even this button doesn't works as expected. Here is what we should see when the table is...

...sorted by Title 1 Title 1 Title 2 Title 2.1 Title 2.2 A B C B C A C A B

...sorted by Title 2.1 Title 1 Title 2 Title 2.1 Title 2.2 C A B A B C B C A

...sorted by Title 2.2 Title 1 Title 2 Title 2.1 Title 2.2 B C A C A B A B C

Any thoughts on this? Helder 17:04, 1 January 2011 (UTC)

There are several bugreports on this problem in bugzilla. However, in MediaWiki 1.18 we will probably use tablesorter.com, instead of the current sort code, so any effort is probably better spent on porting tablesorter.com to MediaWiki. —TheDJ (talk • contribs) 00:38, 2 January 2011 (UTC)

A year or two back, I wrote some enhancements to the wikibits sort functions to support a variety of rowspan and colspan that I believe also supports complex headers as above. At the time, there didn't seem to be much interest in pushing forward with the solution, so it bas been shelved. If there is renewed interest, I can dust off the code and put out another proposal. See User:Tcncv/Table_Sort_Demo for a set of demo tables. You will need to add importScript('User:Tcncv/sorttables.js'); to your monobook.js file (or appropriate xxx.js file for your chosen skin) to see the enhancements in action with the demo cases. Adding class="tsx_sortable" to your own tables will enable the demo for them as well. I added the above table to the bottom of the demo page (here) and it behaves just as you have requeested.

So is there any interest? -- Tom N (tcncv) talk/contrib 00:56, 4 January 2011 (UTC)

Like I said, since all wikibits.js code is deprecated after 1.17, any effort is probably better spent in helping with the integration of tablesorter.com code (which also supports this). —TheDJ (talk • contribs) 11:10, 5 January 2011 (UTC)

Featured and good articles in other languages

As we still have not fixed the horrible way the "featured article star" looks in the inter-language links section, may I propose that we remove the star and replace it with a more subtle "mark the inter-language link in boldface"-effect instead? I think this would fit better with Vector's visually less distracting design. I would suggest doing exactly the same for the "good article plus-sign". A featured article on a small Wikipedia is less likely to be more in-depth than a good article on, for example, the German Wikipedia. So I do not think it really justifies using any "visual bandwidth" to make this distinction (a distinction which is likely to only be confusing to casual readers in the first place anyway). —Ruud 20:27, 1 January 2011 (UTC)

Looks just fine to me. Perhaps you should make a screenshot to better point out what bothers you about it. —TheDJ (talk • contribs) 00:39, 2 January 2011 (UTC)

I'm not really sure if adding a screenshot would be that helpful, simply take a look at "Moon" ;) I designed the star to look nice in Monobook. In Vector it is misaligned, too close to the text, has the wrong proportions (compared to the triangle next to Toolbox, Languages), wrong colour (monobook-yellow :), ...

And to clarify on the featured vs. good article part. How is a causal reader to know that a "yellow" blob next to a link is better than "green-white" blob? A single visual indication would be intuitive to understand, having multiple is not and only distracts. —Ruud 05:08, 2 January 2011 (UTC)

I thought was "featured-gold", not "monobook-yellow". I agree the star is too close; the metrics don't match up with the rest of the side bar. I'll fix that in Vector.css now. I think the proportions are OK; the sidebar font in Vector is bigger that that of Monobook, so I think it is actually less disproportionate. But you can always propose a better looking icon. — Edokter • Talk — 12:58, 2 January 2011 (UTC)

Why is there any sort of indication at all? Let's say that I go to the Dog article to read about dogs. Am I supposed to look at the interwiki links and think to myself, "oh, I should learn Catalan so I can read more about dogs"? — RockMFR 19:41, 2 January 2011 (UTC)

No, but you could be a Catalan who knows English, stumble here, learn about the Catalan Wikipedia, see the article isn't so good and decide to bring it up to feature standards... or any imaginable scenario just like it. Point is, we promote and highlight featured articles on all projects. — Edokter • Talk — 21:22, 2 January 2011 (UTC)

Collapsible rows

Collapsible rows (in contrast to the existing collapsible tables) would be useful for taxoboxes like those in Fomes fomentarius (where an ugly hack with a table-inside-a-table is now used). I've implemented this feature in User:Ucucha/collapse.js, with an example here. Could this be added to common.js? Ucucha 23:25, 3 January 2011 (UTC)

Although the styling is a little off, nesting collapsible structures is not particularly "ugly". Collapsible tables, and collapsible divs and lists, are now included in the latest version of MediaWiki, which should hopefully be making its way onto Wikimedia wikis in the very near future. Anything we develop in the interim should be designed to be as compatible as possible with that implementation. Happy‑melon 00:04, 4 January 2011 (UTC)

RefTools consensus reached on VPP, need implementation

{{sudo}}

See Wikipedia:Village_pump_(proposals)#Proposal_-_Turn_on_RefTools_gadget_by_default. There is strong consensus supporting implementation; would someone please do so? --NYKevin @286, i.e. 05:51, 31 January 2011 (UTC)

In case whoever reads this doesn't know what the proposal means:

MediaWiki:Gadget-refToolbar.js <<this whole thing

should be copied to the end of MediaWiki:Common.js/edit.js

Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 07:09, 31 January 2011 (UTC)

I'm reading the comments in the discussion to make sure there aren't any rough edges left to be dealt with. Meanwhile, I think this should be clarified: does the script work with all skins or only with vector? Because in the latter case, it should go in MediaWiki:vector.js instead. --Waldir ^talk 22:34, 31 January 2011 (UTC)

Or maybe it only works for those who have the enhanced editing toolbar enabled in the preferences. I'm sure the script can be made to activate only in that case. I assume it simply does nothing if not, but we should probably make sure it fails cleanly, without generating javascript warnings or errors. --Waldir ^talk 22:37, 31 January 2011 (UTC)

Update: I tried it, and I have the "Enable dialogs for inserting links, tables and more" checkbox off in my preferences. It made the old version active, which didn't work well: everything showed up as normal, but as I clicked the autofill button after pasting an url, the page reloaded into view mode. If this issue can be reproduced, I think it should be solved before activating the script wiki-wide. I'm {{tl}}ing the editprotected for now. --Waldir ^talk 00:05, 1 February 2011 (UTC)

I just removed that feature from that version. I'm willing to support that version to ensure that it doesn't break, but I'm not going to be adding new features to it. If someone else wants to take it, they're more than welcome. I originally only made that version as a quick hack when the new interface was switched on by default; the dialogs were disabled in IE. But that was resolved rather quickly and I pretty much forgot about it until the recent discussion. In short, if you want the newest features, turn the dialogs on, or turn the new toolbar off completely. However, I would suggest waiting until after the next MediaWiki update (scheduled for Feb 8) as it introduces some major JavaScript changes; adding new scripts at the same time could complicate debugging. Mr.Z-man 07:16, 6 February 2011 (UTC)

Thanks for the clarifications and for fixing that. However, when I turn the dialogs on, I don't see where to activate the auto-completion feature. Is it even available in that version? Will it be? I think it's very convenient :) --Waldir ^talk 14:41, 6 February 2011 (UTC)

It doesn't support it for Google Books URLs (at least not yet), but it does for ISBNs on the book template and DOI/PMID for journals, click the little to do the autofilling. Mr.Z-man 06:57, 7 February 2011 (UTC)

What about just fetching the page title given an url? Those "bot generated titles" we often see around usually work well, or at most require minor tweaking. And I can even foresee more complex heuristics in the future based on, for instance, common news sites' templates, to fetch date and authors. This would be a godsend for users of {{cite web}} and {{cite news}}, which I suspect are among the most used citation templates. Any chance we can expect that kind of functionality in the future? --Waldir ^talk 01:56, 8 February 2011 (UTC)

As suggested by Mr.Z-man above, I believe we should wait until MediaWiki 1.17 is deployed (which includes ResourceLoader) before turning this on. It was supposed to be deployed last week, but it's been delayed until this Wednesday. Kaldari (talk) 20:35, 14 February 2011 (UTC)

Also note that the version that will be turned on for everyone currently resides at MediaWiki:RefToolbar.js. Please direct all further tweaks and development there. Thanks! Kaldari (talk) 20:38, 14 February 2011 (UTC)

Update: I'm currently working out some last minute implementation details with Mr.Z-man. It should be ready to go in a day or two. The script that will actually be added to MediaWiki:Common.js/edit.js is MediaWiki:RefToolbarLoader.js (in case anyone wants to help review the code). Kaldari (talk) 03:33, 17 February 2011 (UTC)

Help Please undo whatever has been done in the last few days that has prevented me from using the reftoolbar. See User_talk:Mr.Z-man#RefTools. At least leave a gadget for the 1.0 version, that used to work for me a few days ago. Please do not overwrite existing gadgets in this way, let editors choose. -84user (talk) 10:24, 17 February 2011 (UTC)

Add new features to show/hide content based on user's groups?

Note: This discussion was moved from here to hopefully receive more input.

What do you guys think of creating CSS classes that can be used by editors to show/hide content based on a user's groups? For instance, I am a member of the "autoreviewer", "reviewer", "rollbacker", "user", and "autoconfirmed" groups. There are some templates, such as {{Invitation to edit}}, that could take advantage of this by only showing the template to anonymous editors. The first discussion that I saw mentioning this was by User:MSGJ, in a discussion that was six months ago, and then it was brought up again today. If you guys want an idea of how this might work, then install this script, and then wrap any code in <div class="for-sysop-only">Text goes here</div>. The class can use any existing group, which are all listed at the top of the script, with "anonymous" and "user" added as well, since they aren't explicitly defined by MediaWiki. You can also use <div class="not-for-sysop">Text goes here</div> as well. Both examples should be self-explanatory by their class names. Thoughts on integrating this or a variant in MediaWiki:Common.js? Wikipedia:Upload already has custom code written for it in Common.js that shows different content for logged-in/out users. Gary King (talk · scripts) 20:28, 2 February 2011 (UTC)

Vandalism that only shows up for non-logged-in users? Anomie⚔ 21:58, 2 February 2011 (UTC)

Perhaps hidden content could be marked with an icon? Or just tag anonymous edits including these classes. It could also be a gadget for those who want to hide templates such as {{Invitation to edit}}, so then by default nothing is changed. Gary King (talk · scripts) 22:26, 2 February 2011 (UTC)

There already is a way to show content just for just sysops and accountcreators. class sysop-show and class accountcreator-show. Just make whatever you want to hide for other users as "display: none". P.S. autoconfirmed is not a 'real' group, it is more like the status of an account. —TheDJ (talk • contribs) 13:43, 6 February 2011 (UTC)

If this were to be implemented, then it's more than likely that those classes would be merged with this script. Also, autoconfirmed is included in wgUserGroups, anyway, so it's treated as just another group. It could perhaps come in handy in some cases. Gary King (talk · scripts) 19:03, 7 February 2011 (UTC)

RfC to change MediaWiki:Common.js for archived citations at Wikiwix

Based on the conversation here, I started an RfC to achive websites at Wikiwix, which requires modifying MediaWiki:Common.js. As this is a major change to Wikipedia, I am posting this information in several places to make certain everybody is notified. Thanks. - Hydroxonium (H₃O⁺) 15:16, 11 February 2011 (UTC)