Knowledge (XXG):Gadget/proposals/Archive 5

1876:

disagree with does not mean I am anti-WMF in general. I know for a fact that at least two people who work for the WMF are very smart. I also know that I agree with at least 80% of what those people say/do/decide. I also know that some other people working for the WMF have made decisions I agree with. If I would believe the WMF was evil I wouldn't be here. But I do believe two heads are better than one. And I do believe that good-faithed people can make mistakes (I know this from experience). I also believe in giving honest feedback but I will always try to take the circumstances in consideration. As far as I can remember I have never spoke to the wub before so I have no reason to like or dislike the wub. I am politely asking the wub to delay the implementation until we have had a decent discussion about it. Even though it is likely the wub is already aware of it I posted a link about excluding spoilers, a rule that protects us from editors who do not participate in a good-faith effort to move the discussion forward. That means I believe it is possible to have a constructive discussion about this. The worst case scenario is that the community discussion about implementation is a complete waste of time. If that is the case at least we can say we've tried. But there are plenty of smart people in this community, with valuable opinions, so I think that that worst case scenario is rather unlikely.

1936:

couple of extra days if that is possible. I am intentionally being a bit vague by saying "until we've had a decent discussion about it", I am not sure how long that would take, but it should be doable with an extra couple of days. Your reply above was very helpful, I think we want to move in the same direction, we just picked different ways to achieve the same goal. I will try to find some spare time in the next couple of days to write a more detailed explanation of my opinion. Feel free to use or ignore it. It may be a good idea to ask a couple of people if they are willing to provide feedback. Do you mind if I do? Even though the name Arcandam suggests otherwise I will not pretend I can predict what the result will be, but I can tell you what I hope for: things like bugfixes, mergeproposals, feature requests, designtweaks et cetera et cetera. Maybe we can also brainstorm together as a community about where and how we want to receive feedback. I think it is a good idea to make it an opt-in gadget ASAP so that those who want to test it can do so more conveniently BTW.

3121: 1798:

strange way. Just in case you are not: the reason is that I had a couple of bad experiences with the WMF making hasty and stupid decisions and overruling knowledgeable users and ignoring feedback. Again I must stress the fact this is not your fault and you have nothing to do with that. But would you be so kind to promise me we can have a decent discussion first before this will be enabled? I know, I am paranoid and crazy (sorry about that!), but reading that promise would be a huge relief to me. Remember:

3598:: If a file is hosted on Commons and someone clicks a thumb or a link (from en-wiki) they end up on a local page on en-wiki and they now have two options: 1) To click the link to the file on Commons and edit/add there or 2) to edit/add locally. In 99,x % of the cases the edits are (or should be) made on Commons. The gadget will send users directly to Commons and thereby reduce the number of clicks needed to edit the correct place and reduce the number of edits placed in the wrong place. 1644:

that violates any copyrights will be deleted. Encyclopedic content must be verifiable.", "If you wish to run a test, please edit the Sandbox instead."), and then once they find and click Save they get dumped to a different page from the one they were looking at. It's possible to add editnotices for guidance, but they can easily be overlooked among the other interface elements. Also note that I'm hoping to deploy this to reader-focused help pages such as

3689:, and shortly afterward there was consensus in favor of the idea. The specifics of the script weren't discussed very much, nor was the issue of testing it before enabling it by default. Testing and improving a script to the point where it's widely usable is difficult when there isn't an easy way to test it short of directly editing one's JS, so perhaps the best way to go about it is to add it as an opt-in gadget for a while first. So, I propose adding 35: 3256:) but couldn't succeed to find this link in English Wiki. Can you help me out to get this tool in English Wiki too so that I may enter Urdu interwiki link into English as I am usually make new categories on Urdu Wiki to categorize all article in a proper way. I only use English Wiki to enter Urdu interwiki and for this I've to spend lot of time to push the edit button on every single article on English Wiki to enter Urdu interwiki link. 1210:

fanboy clique has driven away tens of thousands of Knowledge (XXG) editors and their enthusiasm and their money. Just one more reason there are more articles, but less editors. Editor retention depends on overall cooperation which is sorely lacking at all levels of Knowledge (XXG). Who actually is in charge of Knowledge (XXG) anymore? It seems that no one really is. No group at the top seems to care much.

3170: 775: 1950:

Bugfixes, fair enough if you see any, that's the main reason I posted here. Although the code is mostly the same as the already-enabled Teahouse gadget, Andrew Garrett has looked at my changes and didn't mention any problems with them, and I've done pretty extensive testing of my own. I'm not however

1875:

I am aware of the fact that the WMF can do whatever it pleases. Like I said before I've had a couple of bad experiences with the WMF making hasty and stupid decisions and overruling knowledgeable users and ignoring feedback. But the world is a complicated place; just because the WMF did some things I

1658:

Obviously there's some overlap with the Article Feedback Tool, and using a version of that was my initial plan. However the extra development time that would have been needed on an already stretched project was too great for the payoff. This javascript approach was a quick and simple alternative. I'm

1624:

Hm, it wasn't my intention to sound rude, I apologize if I did. The people in my country are famous (and infamous) for being blunt and brutally honest which can be interpreted as being rude. I am happy to see the great number of new proposals for tools that all have one thing in common: they enable a

1537:

for attention and action by Help Project members. Since many of the people using the Help pages are not experienced Wikipedians, having a simple popup form without the complexities of the standard editing form will be better for them. In creating this gadget I've attempted to make it fairly flexible,

169:

Good point. I asked TheDJ for a good description of Sharebox which mentions the possible privacy concerns. If this becomes a gadget they will be mentioned. I expect that those with privacy concerns are not very interested in using this gadget anyway BTW. I would strongly oppose a opt-out version, but

3831:

script, I encountered some serious bugs in wikiEd's syntax highlighting. I do not have any reason to believe that these same bugs are present in Dot's syntax highlighter, but it raises the issue that using customized edit areas can cause both browser incompatibilities and javascript errors to occur.

2764:

Well, the idea is mostly just to move everything into a gadget, but since gadgets are entirely js- and css-based and MediaWiki handles js horrifically, you make a very good point. By any chance would you also be interested in helping form an angry mob to try to force Wikimedia to focus on making the

2718:

I'm not sure I follow all of that, but from what I can tell the only reason not to remove the insertion text entirely is a fringe case of people who have disabled js, no? But making everyone load both the insertion stuff and the styling to make it disappear is unfair, especially when the reason is a

2650:

I do not oppose any change to the name of the "MediaWiki:" pages to be used by the gadget, neither a better description for it (native English speakers would probably describe it better than I, but maybe something similar to "Add clickable links for inserting special characters and wiki markup under

2232:

Having said all that, the very limited remit of the proposed gadget means I'm not opposed to turning it on by default in the near future and getting some experience with how people use it, and how people react etc. However I wouldn't want it replacing the existing system in its entirety without some

2224:

the comment (discussion) page; I wonder if it's feasible to do a split screen, or maybe show a small preview of the talk page in a popup on the subject page somehow. Bottom line, I think the best bang-for-buck for this idea is to generalise it. I know that's not exactly your remit, but a generalised

1525:

is used, it creates a link which pops up a small form. This can be used to leave a message, which is saved as a new section either on the current page or on a page specified as a template parameter. If JavaScript is not available, or the browser's implementation is FUBAR (glares at Internet Explorer

1187:

I don't understand why the MediaWiki developers in charge seem to be pathologically opposed to a search link in the sidebar. That is an unbelievably simple and logical solution. I have been asking about this for years. At one point it was put in the sidebar on Knowledge (XXG) after much discussion 4

3207:

Depending on whether the user has apihighlimits, mine will make at least 1 API query per each 50 or 500 distinct wikilinks on the page. For normal page views, the German script will make at least 1 API query per each 500 distinct wikilinks on the page. For preview page views, the German script will

1816:

You need to calm down. The wub proposed the gadget in a public forum the same way any community gadget is added to the site. If the Foundation wanted to impose something on the site, we could just add it. We wouldn't go to a community forum and ask for feedback. The wub is doing that because he's a

2932:

A creative solution would be combine all the link-adding gadgets into one gadget in preferences that adds all the links into one menu in the sidebar. Maybe call that menu "More tools". By the way, Toshio Yamaguchi, you can ignore the more overzealous of the gadget deletionists. I do. Maybe Gadgets

2670:. In case it is kept enabled by default (as it currently is), it would be good to advertise that people can now disable it. On the other hand, if it is disabled by default, people will notice it was disabled, but anon users won't be able to use it, unless we create also some kind of workaround for 2219:

Overall, I like the idea of tinkering with the edit box to make it simpler and easier to submit comments and suggestions about help pages and articles, maybe without having to leave the page itself. But I don't like taking users completely out of the talk page context they should be introduced to.

2186:

system. Yes, the popup form is simpler, and that's good. But it also leaves users not engaging with talk pages, and beginning to understand those. Also, right now the gadget keeps the user on the help page once the form is submitted, which may leave the user wondering where their comment went, and

1643:

The standard editing form has a lot of features that are important for normal editing of the encyclopedia, but for readers and new editors to leave a quick comment it's slow and overcomplicated. They click the link, get taken to a big form with all these irrelevant features and warnings ("Content

1209:

search links in the sidebar. So developers think they need search links in the sidebar, but the unwashed masses of Knowledge (XXG) readers are undeserving. Personally, I am fed up with the perennial naysayers who seem to populate many Knowledge (XXG) discussions the last few years. I believe this

1935:

Yeah, we got a little sidetracked. Basically the only important thing I want to ask you for now is to give the community some extra time to give feedback instead of turning the gadget on next week, with an opt-out system. I am not talking about months or years, you said next week and I ask for a

1834:

Would you please be so kind to explain what you mean with that last sentence? I am not a native speaker. How should I interpret that sentence? I hope I misunderstand. Are you claiming I did not act in good faith? If so, do you have any proof whatsoever? If not, would you be so kind to explicitly

1797:

I apologize for treating you like this, I feel like I have to. To be honest I have no reason to assume you should be treated like this other than the fact the WMF is sponsoring you. I feel like I am being mean to you, but that is not my intention. I think you are probably aware why I act in this

1599:

It sounds like a bad idea to me. Why did you re-invent the wheel? You are not fixing the problem you claim exists, you are creating a workaround. If your popup form has an advantage over the default edit window because it is easier to understand we should change the default edit screen. Teaching

962:

I have never asked before about a gadget to put the search link in the sidebar, as far as I can remember. In the past I have asked that it be put there by default. At one time it was there by default but it was removed. So since there seems to be little enthusiasm for that I am now asking that a

3747:

I tested the script in Internet Explorer 9 and 10 as well, and while it doesn't do anything, it doesn't appear to cause errors either. I was not able to test Safari, but it should work the same as Chrome. The bottom line is that while this script will not work for everyone, I think it is useful

2552:

The gadget should probably be renamed to something more specific to its function - as it is, 'edit tools' is often confused with the edit toolbars, and since this thing just does character and string insertions using the CharInsert extension, perhaps calling it a CharInsert gadget would be less

3886:

Over the two weeks that this request has been open no objections have been made and I have made a number of improvements to the script in that time also. I am sure that we will find additional ways to improve the script in the future, but right now I'd just like to have a stable version of it

3057:

I've been invited to comment here, and it looks like a good idea to me. However, I know hardly anything about gadgets so I couldn't say if the coding is good or not. I'm also wondering if this is integratable with Dabsolver? I know all-but nothing about that tool beyond its existence though.

3603:

The gadget does not affect files hosted on en-wiki and it does not make it impossible or very difficult to edit pages locally if it for some reason is relevant. The gadget does also not move files to Commons or force anyone to upload files to Commons. So no harm is done by this gadget.

344:. It is tested and works in all major browsers (Chrome, Firefox, IE, Opera, Safari) and skins (Monobook, Vector, Modern), and can be used by members of all user groups (except for creating submissions, which is only possible by autoconfirmed, nor on protected or title-blacklisted pages 4068:

Local caching still allots bandwidth to users who never edit. As script-packed as Knowledge (XXG) is, one should always strive to load code only when needed. As for hosting the script on Meta or MediaWiki, simply ping a local admin to move/copy the code to a local MediaWiki: page.

2903:

This is a special case addition that would only be useful for a small subset of users, as most do not extensively use subpages of their userspace beyond their sandbox. For those of you who do, should an included script in your personal js not be enough? Should probably document it

820:: one enabling bold styling for unwatched changes, and one enabling an underscore (these received the most support in the RfC). Also, could you put a link to WP:CUSTOMWATCH—in case they want to make changes that aren't one of the gadgets—in the description of the gadgets? Thanks, 2220:

Maybe we can have a Simple Editbox, which can be used at any time; and a Leave Feedback button at the top of every page which draws people into using talkpages slightly more than the "talk" link does. That button gadget would ideally somehow show both the page being commented on

1608:) to leave some feedback is more difficult than just one. Do you have consensus to "go ahead and enable this next week"? Do you think the decision to "go ahead and enable this next week" should be made by you? Why? Did you coordinate a community discussion about this? Where? 3211:

If the average categories per page in a group of 50/500 is more than 10, mine will make additional queries to fetch all the categories in that group of 50/500 pages. The German script for normal pageviews would need an average of more than 1, but since it is able to use

2308:. OTOH, I don't know whether Timeshifter's problem is because of that, or because gadgets don't get implemented here so much as added after they're already written, or because no one is interested in the gadgets he is proposing, or because of some other reason. 1397:

to existing questions, I'd written a script for that purpose, which I understand several editors have been using for a while, including some Foundation people. I wonder if someone could have a look into the possibility of enabling this too as a default gadget.

1659:

in complete agreement that we need to improve the standard editing and talk page experience, but that's a little outside the scope of my project and skillset. You'll be pleased to know that people far more qualified than I am are hard at work on this, with the

1655:), and makes for a much more streamlined process which is consistent with expected behaviour from other websites. In fact I'd say we aren't really teaching people two methods of editing: this method is intuitive enough that it doesn't involve teaching at all. 3251:

As you are aware that I am doing lots of my efforts on Urdu Wiki. I often work on Knowledge (XXG) to update Interwiki links and Categories link between the two Wikipedias i.e. Urdu & English Knowledge (XXG). I am using "Hot Interwiki" link in Urdu wiki

4109:. I asked that the script be copied as-is; if you'd like to add additional loading conditions locally on the English Knowledge (XXG) that's fine too. That said, I doubt that a user who never edits is the kind of user who would install an editing gadget. — 1786:

Well, if this is the discussion then I must inform you there are objections and problems, so you cannot "go ahead and enable this next week". I don't know you so please do not take this personally, but I do know the WMF, so I will have to make this very

2539:

You need to do more than just move the js that makes the insertion happen from the default to a gadget. The charinsert interface still appears when the gadget turned off, but doesn't do anything, so that will either need to be hidden, or removed from

1749:

Apologies, I should have been clearer. We want the feedback to be recorded on a different page (not cluttering up the help pages themselves), but do want a visible link on the help page to add feedback. That's where I'm worried confusion could arise.

3294:

On high-res devices, especially those that have touch gestures such as tablets and smartphones, it would be nice to zoom in to find a finer image. I'm constantly finding myself going to the description page to view the image in a higher resolution.

1920:

I'll be the first to admit the Foundation have made mistakes in the past, but I think we're getting sidetracked here. Did my reply above address your concerns about this gadget or not? What objections or questions do you have that I can help with?

2924:

The closer at the Village Pump discussion said that "the consensus leans most towards opt-in gadget." I agree with that. There are already several gadgets in preferences for adding links to the sidebar or to menus at the top of every page. See:

2553:

confusing, and describe it as 'Add a toolbar under the editbox to insert special characters' or some such. (Calling it the 'old edit tools' won't mean anything to new users, and even those familiar with the thing may not catch on right away.)

2591:

those characters to be sent to all users). So, the only alternative for users who do not use those characters is to hide them after thei are downloaded, by using CSS. I believe this could be incorporated to the gadget in the following way:

418:) and I started to create new documentation pages, a beta script (for being actively test before the push, after realizing that some situations are not always recognized) and (obviously) an 'alpha' script which is getting new improvements. 2187:

the novice may not be able to find it in their contributions list. It certainly makes it less than clear that their comment will be reviewed by volunteers on a standard talk page, and not by some nebulous Organisation (never mind staff).

3080:(which I use in run-on-demand mode, and quite like). I'd support making one of these into a gadget, but ideally the most efficient and configurable one (Whether that means coding up a merged version, or using anomie's, or whatever). — 3713: 1047:

A very few people might install the revised gadget discussed higher up (ctrl-click to open search in new tab). But most people are not going to do that, or will even know about it. So a search link in the sidebar is simplest.

816:? It established that highlighting of unwatched changes should be off by default, but that an option should be available to enable it in preferences. Therefore, I would like to ask that two gadgets be enabled using the CSS at 242:, except for the space before dash features, which can be a bit contentious with some editors. The script has not been updated in several years and needs to be check to ensure that it complies with the current MoS. I also use 445:

and thus we might get even more submissions every day. The whole process was simplified for the submitters by creating simple links to resubmit or our bot who is cleaning up the pages and moving them out of the user space to

1082:. Like most noobs I understood basic preferences and options from my experience with browser and email options. Gadgets, addons, and extensions sounded esoteric and dangerous to me at first. I was a default kind of noob. :) 170:

as long as it stays opt-in its no problem. The stream of requests for a share button (an opt-out version), which is never going to happen anyway, would stop; we can simply tell people to use that gadget if they want to.

1021:

Average Knowledge (XXG) users, and web users in general, do not install specialized browser extensions for search. They just use the search form, or they click a search link to get to a search form. This is not rocket

2544:

entirely and then added to the page using the gadget itself. The latter would probably be preferable considering only the gadget will use that at all, and since the list below the charinsert is redundant with the

1260:

Maybe those "search links" in bugzilla sidebar (on the right) are supposed to motivate people to search more before entering a new bug. Plus they have fewer links overall so they don't need to care about space. —

3762:

be used with the browser's page zoom feature", is this a critical problem? That is, will the page be corrupted if saved when zoomed, or is it merely that the display to one user is not as might be expected?

1625:

person who reads an article to leave a comment without visiting the talkpage. But if using a separate talkpage is simply too hard, why not move the functionality of the talkpage to the bottom of every page?

2559:

It should probably be moved above the save and whatnot buttons, perhaps to directly under the editbox itself, since it is directly related to editing. Where it is currently doesn't really make much sense.

3855:

I tried the script out and definitely like it. I'm a bit worried about the Chrome incompatibilities, but those could be addressed by writing a small (Warning: may not work in Chrome) on the Gadget page.

3906:* ], make syntax stand out colorfully in the edit box. Works best in ], works almost all of the time in ], and works most of the time in ]. '''Should not''' be used with the browser's page zoom feature. 3201:

It allows the browser to cache the results for the pages linked from a page, which means if someone edits a linked page to make it be a dab or stop being a dab it might not pick up the change on reload.

2556:

Does it really need to be turned on by default? Since it seems like on this project people would just ignore it most of the time, well... would it be possible to get any usage statistics for the thing?

2173:

Despite some clever coding, there are limitations of wikitext, and in general I'm a fan of using Javascript to overcome them (as the only currently available way to do that in a well-integrated way).

4167:

It seems that few administrators are familiar enough with the gadgets pages to know how to add new ones, so I've put in the syntax highlighter gadget myself. Let me know if it causes any problems. —

2810: 270:, I have added a great functionality to replace wrongly created wikilinks to proper wikilinks (not finished, but detects most variants; an example is in a diff provided at the bottom of this page). 3131:

As best I see it, this script detects disambiguation pages, highlights the link in some shade of red and adds a BKL superscript (begriffsklärungs— disambiguation). See the screen shot to the right.

2853:

My question still stands, though: currently all the JavaScript is loaded on every page, even if the user is not in edit mode (or if the page is do not have an editbox, as in special pages - except

2686:

doesn't make any sense and should be closed as such (though I certainly wouldn't object to a new one being opened about related issues with the CharInsert extension), since any wiki admin can edit

2777:

Good luck with that. While you are at it, point the mob at revising the site JS so that search result lists and search suggestions open in a new tab via Ctrl-click (PC) or Command-click (Mac). --

2047:

to be enabled by default, since the whole point is to target new and anonymous users. Making it opt-in would be completely pointless. Remember that this gadget will only have an effect where the

2709:

The behavior for users without JavaScript (and for those who disabled it) continues as it was in the non-gadget version: the characters are still shown so that they can copy them while editing.

853:) in the sidebar. Is there any reason this link can not be added to the Knowledge (XXG) sidebar? This would allow people to do searches in a new browser tab without covering the current page. 3279: 3264: 370: 364: 1541:

I've tested in most major browsers (Chrome, Firefox, IE 7+, Safari), and apart from the above mentioned IE6 problem didn't see any issues. If people want to see the code it's currently at

979:

Simple explanation: many don't need that feature, others have it built in in their browsers (+extensions) by pressing ; , or whatever browser, preferences or operating system they use...

356:, and I. I believe that making this script a gadget would invite more users to participate in a project that is currently suffering from a massive backlog (see various talk page threads: 596:

are the best possible thing. Is it possible to create the most delicious thing ever by combining this script with a cup of tea? Can you use this script as a mini-frisbee? I think not.

3382:

new is it? Does Firefox support it yet? Where is the correct place to report general feature requests on WP? I would still appreciate an option for progressive bitmap interlacing.

2857:). Wouldn't better to separate the JavaScript into two parts? We would still have a small "loader" in all cases, but the significant code would be loaded only when it is useful... 3275: 3260: 225:

I support the addition, although I would like to see that somebody would overtake the development... (I have some ideas and already implemented (in an other script) solutions...)

3253: 3780:

Good question. It won't corrupt anything, but the colors will be all out of place making editing difficult until default page zoom is restored. I'm open to alternate wordings. —

3580:

gadget. This was discussed briefly on the Village Pump a while back, where it received support from the few people who commented. It's already available on several other wikis.

450:. Moreover the script got many cleanup functionalities (some are still one the to do list) so that the reviewers don't have to clean up by hand (e.g. simple wikilinks, see this 3989:

either, both for performance reasons (the script is already quite slow on large pages) and to encourage a single clear, unambiguous syntax on Knowledge (XXG). While supporting

3000: 358: 4002:

I realize that a lot of people are going to disagree with me on this, and if there's consensus to adopt only a modified form of the highlighter as a gadget then go ahead. —

1959:. I believe this gadget in its current form is a marked improvement over the current system for leaving feedback on help pages, and will prove valuable for improving them. 813: 2809:

But seriously, you're right about using css to hide it and thus not having to use js being useful in general, so yeah. As for the default of on or off, I tried to start

2170:

Improving help pages is important, and I supported the fellowship on Meta (AFAIR). Getting feedback is part of improving it. Getting more and/or better feedback is good.

1401:

The aim of this script is to make it easier for new users to respond to these discussions, when they don't necessarily understand that this entails editing the section.

3490:

There is actually someone working on this right now, using latexML. The patches are in gerrit, though we are still far away from including this in WMF wiki's I think. —

2516: 873:

It already has! Non-vector skins have an additional button, vector has such a small loupe in the search field: click on that and you get to the custom/advanced search!

3810:

be used with the browser's page zoom feature." I don't think many users will understand the phrase "may not work at anything other than standard browser resolution". —

1274:. How is "Random article" or "Knowledge (XXG) Shop" more important than a search link? And there is plenty of room in the click-open menus such as the toolbox menu. -- 3686: 956: 950: 919: 915: 157: 2690:. That needs doing, and the relevant content moved into the gadget; there is no reason for people not using it to have to load it at all if they're not using it. -— 1732:

I was under the impression that you were discussing the regular Edit tab, or a section's link. Upon hitting "Save page", those take you back where you came from. --

1119:(the search options tab in preferences). I suggest it be the default that the search link be in the sidebar. Like the default settings for some Commons preferences: 451: 4051:

suggests making the script a gadget on MediaWiki.org first and then loading it from there. Do you happen to know who I would have to talk to to make that happen? —

2933:

2.0 that is being worked on will provide more tabs in preferences. Tables of content on preference tab pages would help too with sorting through the gadgets. --

2663: 1530: 485:

Per Arcandam's comments, plus it ensures that there is a uniform process for dealing with and managing submissions and limits reviewers making simple mistakes.

3134:

I don't like the color nor the BKL link, although both could be changed. This is a quite large script for this one purpose and would need a bit of translation.

2905: 504:

as it allows for efficient, consistent activity within the AfC process. System works while not a gadget, but it would be easier if it were made a gadget. --

4048: 3120: 2969: 2793:

Hah. At least for the latter thing you just need an admin and a bottle of absinthe; should be enough to elicit compliance from even the most hesitant. -—

1799: 1402: 3896: 2372:

Please make the edittools script into a default gadget so we can disable it and it is easier to import to other wikis and avoid code duplication. See

1538:

so that it can be adopted for other projects in future if desired. The text and style of the form are all customisable by using template parameters.

947:

Only one of those threads has putting a search link in the sidebar as a topic, and it got no discussion. I am talking about a subsection of this one:

210:, I wonder why it hasn't been added as a gadget. I've been using this script now for several months, and it is simply amazing. Very, very helpful. -- 333: 247: 3717: 2908:

so other folks can find it, although that page could have a better sorting/searching system, and could really use more prominence in general... -—

384:

nor do they need to muddle in their userspace Javascript. It will also make the project known to those who are unaware of its existence. Thanks. —

348:). In its three-year history, it has grown to something beyond a simple script by Tim; it is now actively maintained by multiple users, including 3693:

as an opt-in gadget for users with the "move" right, so that it can be tested, discussed, and further improved until it is enabled by default. --

207: 93: 88: 76: 71: 63: 2985: 3901: 3011: 2893: 725:

Absolutely helpful, well documented and stable. Would be a miracle if it would actually entice people to help clean up the massive backlog at

3724: 3073: 2881: 2487: 2467: 923: 3690: 3438:

Please add an option to convert the TeX source into MathML for the browser to render. (Conversion should be done server-side, and cached.)

2961: 2213: 1987:

Well, OK, go ahead and enable it if you don't have the time, but I hope you don't mind if I start dreaming about what v2.0 should be like.

1667: 3033: 3007: 2950: 3512:

Oh and already right now, it's possible to choose MathJax from your preferences, which can render in multiple modes, including MathML. —

3198:

It can't handle a page being in multiple categories at once. Perhaps that's not supposed to happen with the three categories they check.

337: 4016: 3409: 3352: 2884:. I already use it and it does exactly what I want, providing a link to all pages in my userspace at the top of every page I read. -- 2470:. Many more technical people seem to pay attention there. Almost nothing seems to get implemented from this page. I don't know why. -- 3229:

I'm not sure whether the various DOM accesses are faster in mine or theirs, or whether it's enough to really matter either way. HTH.

1955:

over this, or building it into some über-comments system, since my work on this is for a limited time which is already ticking away.

3577: 3047: 2501: 2343: 2335: 1378: 1405:, people actually ask how to post a response. The script is based on the Ask gadget, and uses a similar input box, for uniformity. 2977: 1189: 415: 306: 2587:

will always be sent to all users, even to those who not use it or who disable JavaScript on their browsers (and it seems enwiki

1605: 1120: 3358:

attribute for high-resolution devices, including Javascript fallback for devices that don't yet support the property natively.

2873: 2123:

As suggested by Arcandam, I have added this to the gadgets list for people to test, although it is not yet enabled by default.

3970:

is less confusing because it makes it obvious that the element has no closing tag. In fact, MediaWiki automatically converts

3019: 1533:. The idea is to place this template on certain important help pages, and collect feedback in a centralised location such as 951:

Knowledge (XXG):Village pump (technical)/Archive 99#Preference for opening search result list or search suggestion in new tab

920:

Knowledge (XXG):Village pump (technical)/Archive 99#Preference for opening search result list or search suggestion in new tab

574: 2702:

I added the CSS to the gadget on testwiki. Now when the user disable the gadget the (non-clickable) special characters from

3571: