This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the
current talk page.
Hello! If this CSS adds or modifies icons shown after external links, you'll be interested in knowing that such icons have been
removed from MediaWiki core, a change which will reach this wiki in
few days. You may want to consider whether you still need them. If you have questions, please ask at
bugzilla:63725. Regards,
Nemo09:45, 10 April 2014 (UTC)
Edit request
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Change var soxredToolUrl='//tools.wmflabs.org/xtools/pcount/index.php?name=$1&lang=$2&wiki=$3'; to var soxredToolUrl='//tools.wmflabs.org/supercount/index.php?user=$1&project=$2.$3';JV Smithy (
talk)
15:40, 21 April 2014 (UTC)
It's not a one-to-one replacement, as <code>...</code> tags force a white background as well as a monospace font. So it depends what the <tt>...</tt> tags were being used for. In this case it looks like it's used for previewing template code, so switching to code tags is probably ok.
Technical 13, what do you think? — Mr. Stradivarius♪ talk ♪03:20, 17 June 2014 (UTC)
I avoided requesting this switched to code tags because the navigational popups have a yellow background. — {{U|
Technical 13}}(
e •
t •
c)03:49, 17 June 2014 (UTC)
It's possible to use <code style="background: inherit;">...</code>: Popup Code Popup That way, the semantic use of
the code element - to represent a fragment of computer code - is indicated. The span element just changes the appearance, it does not convey meaning. --
Redrose64 (
talk)
10:33, 17 June 2014 (UTC)
This option is annoying and not really working. If tested all mod keys (except of meta) and none of them are really usable. I get the problem which was already mentioned here :
2009 also my browser get always freezed after some time (FF and Chrome on Win 7). So I propose the stroke this option out or mark it as beta, or improve the code. Thanks for the tool, best regards → User: Perhelion08:36, 7 August 2014 (UTC)
Show source text at modules
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Hi! At templates, this script shows the source text of the page. It would be even more useful at modules, because now it shows usually just local p={}. Can somebody add it to the script (I think it's around the 550. line)? Thanks, --
Tacsipacsi (
talk)
11:05, 28 September 2014 (UTC)
Not done:@
Tacsipacsi: Sorry, but really we need the code to be ready and working before we can enact edit requests like this one, and also not many (any?) users who are good with JavaScript patrol these edit requests. If you need help with the coding,
WP:VPT is the best place to ask. Best regards — Mr. Stradivarius♪ talk ♪09:05, 30 September 2014 (UTC)
Feature request: Popups display of
Special:Diff links
Understood. I was asked in the German Wikipedia to put that feature request. The
Template:Diff in the German Wikipedia seems to be corrupted. Therefore its recommended to use Special:Diff. But Special:Diff doesn't comply with Gadget-popups.js. First of all, I'll discuss this issue in the German Wikipedia. If required, then I'll try to code a template addition. --
Ptolusque (
talk)
00:26, 1 October 2014 (UTC)
First of all, thanks for this improvement! I've been wanting this since I started using popups! I just have one question: Why does it work on
Special:Diff/620573180/620804084 as a link, but selected in the source, it shows a cache key? —PC-XT+04:22, 14 October 2014 (UTC)
Most recent edit popup broken
This edit by
Amalthea breaks the popup for the "most recent edit" action. The popup always shows the most recent edit to
Main Page because getWiki() creates a URL with the title parameter set to the empty string. In this case, since oldid=cur, MediaWiki has no idea that we want a particular page's last revision, so it chooses Main Page by default. It seems like the old version of that function would've always been correct: even if given a numeric oldid for a page other than article, MediaWiki would always prefer oldid. –
Minh Nguyễn💬04:52, 28 October 2014 (UTC)
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Popups references the magnify-clip.png file directly using its path, which is silly because it doesn't even need to. The file is going to be removed soon. See
bugzilla:69277 and
bugzilla:69678#c10.
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I noticed that this gadget doesn't use ResourceLoader, so it isn't getting minified automatically. As a test, I tried enabling ResourceLoader for the Vietnamese Wiktionary's copy of NavPop and quickly ran into a couple of JavaScript errors that broke the gadget. The errors would be fixed by
these changes. These changes break support for IE 4–6, which should be perfectly fine because MediaWiki no longer loads JavaScript in IE 7 and below as of MediaWiki 1.24wmf21 (deployed to this wiki in September 2014). Would an administrator please apply these three changes and enable ResourceLoader for this gadget at
MediaWiki:Gadgets-definition? Thanks! –
Minh Nguyễn💬11:12, 15 November 2014 (UTC)
Hello! This script has been detected as using deprecated parameters that need to be replaced with the updated version. Examples include addOnloadHook( ... ) needs to be replaced with $( function() { ... } ); all wgGlobalVariables need to be properly gotten with mw.config.get( 'wgGlobalVariable' ); and addPortletLink needs to be called with mw.util.addPortletLink. Please see
MW:ResourceLoader/Legacy JavaScript for details. Thank you. — {{U|
Technical 13}} (
e •
t •
c)20:24, 19 January 2015 (UTC)
In more modern browsers, yes. In older ones not. In vague ones not. It's better to make sure, actually, it's probably already running because of other dependencies, just not declared. —
TheDJ (
talk •
contribs)
18:54, 6 July 2015 (UTC)
what i was trying to say is, ttbomk there is no RL module named JSON (or "mediawiki.JSON"). you are probably correct that it would have been more polite to verify that "JSON" is not null, and even better, that typeof(JSON.parse)==='function' (and maybe fallback to the previous call to eval()), but i don't think the first statement of this section is correct. peace -
קיפודנחש (aka kipod) (
talk)
19:28, 7 July 2015 (UTC)
Dear friends; I contact you because you have been editing the actual gadget JavaScript code or have been involved in security and other issues about the gadget. m:MediaWiki:Gadget-popups.js (and the empty
m:MediaWiki:Gadget-popups.css) allow user to select the gadget functionality by selecting the gadget in
m:special:Preferences#mw-prefsection-gadgets. Unfortunatelly it will not be active at other projects via the (unified?) global user account. https://meta.wikimedia.org/?oldid=15121460# created by simple copy and paste allowed te generation of some links but did not provide the full functionality known from
w:en:,
m: etc. Can you please help to get a working version running at meta supporting global accounts? Thanks in advance for all your efforts. Best regards
Gangleri (
talk)
07:30, 14 December 2015 (UTC)
Hi! I added code to load
MediaWiki:Gadget-navpop.css at
https://meta.wikimedia.org/?oldid=15130039# and was verry pleased about the work the gadget code does. In general I select the local language in preferences at every wiki where I sign in. I made a brief tour at
wikt:is:,
w:is:,
w:tn:,
testwiki: and
w:arc and have find it a good start with Gadget-popups.js despite the fact that not all links have provided popup functionality. In addition the Right To Left (RTL) project in Aramaic was showing some minor directionality issues (the size in bytes is rightmost while the corresponding unit is leftmost). That is all for now. Please do not hesitate to write abouut your experience and list the issues you have detected.
@
Gangleri: Any user can effectively make this gadget a global gadget for themself by adding a call to the file from their
m:Special:mypage/global.js page.
the only difficulty that I have is that it fails for me with an @import of the navpop.css page to that pair. So I cheated and manually copied the whole navpop.css file to my
m:Special:mypage/global.css, which works for me, though doesn't update with fixes and improvements.
Hi! Since earliest WMF times wikipedians contributing to non-Latin language versions expressed their wish to have the option to use shorter urls then available through UTF-8 url encoding. The shortest variant for WMF type page urls known to me is
https:{{SERVER}}/?curid={{PAGEID}}#
I think it would be a significant improvement to add PAGEID to the available popups. PAGEID is preserved during page moves but (to my knowledge) not after undelete and for shure not after reimports. These two situalions occur quite seldom so PAGEID would be a good approach.
notes: a) The "diff"-link is intended for an exploit of diff which allows to analyse the difference between two different but same style wiki pages as in
https://test.wikipedia.org/?diff=254163&oldid=254616 . It would make much more sense to create and use a further LUA module which could extract the / all "mw.config.set" values from an arbitrary wiki page and use
https://test.wikipedia.org/?diff={{REVISIONID}}&oldid={{#mw.config.set: wgCurRevisionId | template talk:4x4 type square/T065}}
b) I experimented a lot with portable wiki code between all WMF projects and used interwiki links to the local wiki as in
w:en:most-perfect magic square. I am not sure if the gadget code will handle this link as a link to the local wiki. It does not.
c) Local links in general and "shortest links" in particular should be handeled as normal local wiki links. Example
https://en.wikipedia.org/?curid=706451# for the same page as mentioned at b).
Please add the extendedconfirmed group to the list of groups that are not included in the navpop when you hover of a username. This can be done by adding
APerson was this tested somewhere with someone who had set, then unset their gender (i.e. is it now a nul value, or is it some other value that this doesn't have a default to?) —
xaosfluxTalk03:15, 15 April 2016 (UTC)
xaosflux, I switched my gender to unspecified, verified that the symbol didn't appear, then switched it back to male. Do you think I should ask someone on IRC to do so?
APerson (
talk!)
03:36, 15 April 2016 (UTC)
As discussed
here (permalink), this gadget should be hosted on GitHub and updates should be made using an upload script,
Twinkle-style. I think this would encourage new development because edit requests are a pretty cumbersome method of requesting changes for a script like this. It would also make things like automated testing of pull requests possible. Pinging recent gadget contributors(MSGJ—
Xaosflux—
Legoktm—
Krenair—
Mr. Stradivarius—
Edokter—
Majora).
APerson (
talk!)
16:28, 19 April 2016 (UTC)
Pull requests would take the place of edit requests for changes to the code, as that's what GitHub is designed for. We could get an adminbot running to deploy from the repository, and until it starts running, we could just ping friendly admins on IRC. Gerrit would be great too.
APerson (
talk!)
01:42, 20 April 2016 (UTC)
I agree that it's important to have as many people as possible looking at suggested changes to the gadget. However, I think GitHub, Gerrit, Phab, or whatever platform we eventually use will definitely make it possible for users to track new proposed changes.
APerson (
talk!)
16:38, 20 April 2016 (UTC)
Per
this discussion, I've added a display of the last time a user has edited on the bottom of the user info pane. The updated version of the code can be found here; the diff that shows this patch being applied onto the current version of the script is here.
APerson (
talk!)
02:45, 24 May 2016 (UTC)
I started running various style checkers on the code in hopes of getting it to the point where I can start writing testcases further down the road. With this patch, I've fixed a few of the worst offenders from a stylistic perspective (e.g. I changed code of the form a && b(); to if(a) { b(); }). The updated code can be found at this version of User:Enterprisey/popups.js.
Enterprisey (
talk!) (formerly
APerson)04:28, 11 June 2016 (UTC)
Please copy the sandbox over onto the main gadget - I undid some changes I made to legacy protocols that actually broke certain menus, such as the "popups" one.
Enterprisey (
talk!) (formerly
APerson)03:52, 9 July 2016 (UTC)
Having fixed a few of the style issues in my previous edit request, I decided to fix them all in my current one. The proposed version of the code is the first one to pass a Javascript linter, which should make future improvements to the code immensely easier. (Instead of going back through the code to see what they missed, contributors can simply run the linter to point out their errors.)
Yes, I've tested this. However, due to the extensive nature of this change (it fixes up lines spread throughout the code), I'm going to try and solicit a few current popups users to test out the code.
Enterprisey (
talk!) (formerly
APerson)04:12, 14 June 2016 (UTC)
Sorry, I had to revert this, it was causing "LOCKED, HIDDEN" to show up for every user, and I don't really have time to review all of the other changes...
Legoktm and
MSGJ, I fixed it by using a combination of !== undefined and simple truthiness tests. (Example: when we're testing exec() output, simple truthiness is much better than != null for clarity reasons.) Updated version has been uploaded to the sandbox.
Enterprisey (
talk!) (formerly
APerson)04:09, 18 June 2016 (UTC)
I don't know when it happened – not very long ago – but when using Popups by hovering on a link, choosing actions|view article or actions|talk page from its menu no longer shows the linked page: it either shows shows the same page that one is hovering on (on article talk pages), or else it tries to display page User:, Talk: or User talk: and fails. I don't suppose many people use this feature, but I do, and it used to work! —
SMALLJIM09:06, 10 July 2016 (UTC)
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I suggest replacing on line 2753 action=raw&ctype=text/css&maxage=0&smaxage=0 with plain action=raw. The reason is that these options no longer actually add any purpose. In 2016, this is probably hurting more than it used to fix in 2006 :) —
TheDJ (
talk •
contribs)
09:06, 1 September 2016 (UTC)
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
On line 3773 the script checks if a.navpopup is null, but does not check if it is undefined. This sometimes causes the error: in Firefox: TypeError: a.navpopup is undefined, in Chrome: Uncaught TypeError: Cannot read property 'isVisible' of undefined index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript:3774. That sometimes happens to me when I point to links while the page is still loading. This error does not prevent the script from working afterwards. Please add the check for undefined. --
V111P (
talk)
03:04, 19 September 2016 (UTC)
@
V111P: Please specify the exact change you are requesting. The easiest way is to copy the page to your userspace, make the changes, and then provide a link to that userpage. Regards — Martin (
MSGJ ·
talk)
11:28, 19 September 2016 (UTC)
Sorry, @
MSGJ: Line 3773 currently is if (a.navpopup === null) return; I request that it becomes: if (a.navpopup === null || typeof a.navpopup === 'undefined') return; The line numbers are visible when editing the code (with the Code editor), or you can search for a.navpopup === null and you'll find it. Thanks. --
V111P (
talk)
12:05, 19 September 2016 (UTC)
There were some changes to MediaWiki recently and now when using Chrome every once in a while I'll get an error from this script in the console. To prevent this, the dependency on mw.util should be declared before using a function from it, as described here:
[1] The error message in the console is: Uncaught TypeError: Cannot read property 'getParamValue' of undefined index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript:1093 This error does not prevent the script from working afterwards.--
V111P (
talk)
03:06, 19 September 2016 (UTC)
Well we could add some 'double' certainty into the script, but it will be slower to load it that way... Maybe we should instead check the loading state, and throw a warning to console if the libs are not loaded... that might save a few people. —
TheDJ (
talk •
contribs)
13:55, 19 September 2016 (UTC)
Why would it slow down loading? AFAIK, mw.loader checks first if the given dependency is already loaded and doesn’t load it twice. And many users load Popups via importScript (or its mw.loader equivalent)—global, common, skin.js’s, foreign wikis’ gadgets or even site scripts. I think their (our) number exceeds the number of users who use the enwiki gadget, so in average it’s worth make sure every dependency is loaded. Once it’s loaded dynamically, we can load it only when it’s used, so in this example, mw.util will be loaded if user actually attempts to use the auto-edit feature. --
Tacsipacsi (
talk)
15:01, 3 October 2016 (UTC)
Not slower per se, but slower potentially. This is because you would bypass the bundled delivery and have to make a new request (this is one of many reasons that gadgets are 'better' than userscripts). Especially in browsers without full HTTP 2.0 support loading many userscripts will add up and consequently slow you down. —
TheDJ (
talk •
contribs)
20:02, 3 October 2016 (UTC)
Then probably we could create a page which makes sure everything is loaded; users and wikis which don’t want to pay attention on regular updates can include that, and enwiki gadget and other users for whom performance is more important than convenience can include the original version. --
Tacsipacsi (
talk)
20:11, 3 October 2016 (UTC)
"LOCKED" and "HIDDEN" seem to be broken, again. This change fixes these issues, once and for all. (I also fixed the Category:Foo thing from the previous section, because I was only modifying comments and why not.) The updated code can be found at
the sandbox.
Enterprisey (
talk!)
22:24, 16 November 2016 (UTC)
MediaWiki:Gadget-popups.js is currently in
Category:Foo (the category is only displayed on preview). It also transcludes
Template:', ' and is in many WhatLinksHere like
Special:WhatLinksHere/User:Lupin/foo3. This is all because js pages are evaluated as wikitext when link tables are made (the result is ignored when the page itself is rendered). The normal solution is to add // <!-- at the top and // --> at the bottom. This will normally make the whole page a wikitext comment to prevent it from being processed as wikitext and affect link tables. However, in this case there are already many --> which would terminate the comment. <nowiki>...</nowiki> has the same problem: Existing </nowiki> would terminate it. We could use <includeonly>...</includeonly> since the page is not transcluded as wikitext anywhere. Or we could just comment out the category code and ignore the WhatLinksHere entries.
PrimeHunter (
talk)
10:20, 21 October 2016 (UTC)
Eh, this seems.. undesirable. This does it's own interpretation of a Mediawiki message, where we have perfectly good libraries to do so (so that we don't get XSS vulnerabilities everywhere). See
mw:Manual:Messages_API#Using_an_API_query_from_JavaScript. Just make sure the relevant modules are loaded, and you guard against old versions of wiki potentially not having them. Also, you might as well use jQuery promises instead of callbacks. —
TheDJ (
talk •
contribs)
09:35, 19 December 2016 (UTC)
I used a pretty bad and hacky method of displaying the watchlist message in my previous patch; following
TheDJ's helpful suggestion, I've replaced it with a much better (and thoroughly tested) one. Updated version in this revision of
the sandbox.
Enterprisey (
talk!)
07:58, 23 December 2016 (UTC); better link added 08:39, 23 December 2016 (UTC)
Don't know what was changed recently @
TheDJ and
Enterprisey: but global renamers are no longer showing up in the "groups" area at the bottom of popups. It used to and all the other global groups still show up fine. Would either of you be able to look into this? Thanks! --
Majora (
talk)
03:37, 28 December 2016 (UTC)
@
Xaosflux: I could have sworn it used to show up on popups. Could definitely be mistaken though. Has happen before (a few times today even
). --
Majora (
talk)
03:43, 28 December 2016 (UTC)
Feature request for files: have metadata available in pop-up
This script is used universally, and there would be value to have the following added/available to the popup display
where a file is linked, that the metadata of the file is available, ie. dimensions of file, the size of the file, and if a multipage file eg.djvu, the number of pages of the file.
Issues with the latest update were raised in
this discussion, so I changed the user contribs view so that it shows (diff | hist) links instead of the old (cur | last) links, in line with the watchlist and pretty much every other interface page.
Alright, done. The change the responding admin needs to make is the addition of a single line, shown in
this diff, which should allow other wikis to change the value associated with the the send thanks key.
Enterprisey (
talk!)
04:06, 25 July 2017 (UTC)
No problem! Going to re-enable this request real fast, because I think the enwiki version's code also needs to be changed. (This way, other language wikis can continue to use it as a template.)
Enterprisey (
talk!)
18:24, 25 July 2017 (UTC)
This Gadget behaces really weird (as in: some parts work normally, others (i.e. positioning of the popup) fail without any notice) if it’s included twice, i.e. if someone has the "manual installation" in their global.js and at the same time has a local gadget which includes this one enabled. I’m assuming it wouldn’t be difficult to check whether this script has been executed already and skip the second pass? --nennt
michruhig
ip (
Diskussion)
20:39, 27 July 2017 (UTC)
@
TheDJ: The local gadgets are usually including this one (using the "manual installation"), so there’s no need to change something there :-) I’ve only checked a few wikis though, but I hope the others are smart enough to not use an outdated copy. If they do, it’s their fault anyway. Thank you for the quick fix! ---nennt
michruhig
ip (
Diskussion)
20:03, 28 July 2017 (UTC)
link to other languages
Hello, good afternoon. It would be great if through the popup i'd be able to view a review of the article in other languages the same way i view in the original language, or at least be able to jump to another language through the popup. can someone add a link to other languages inside the popup that would enable it?
melo kol haaretz kevodi (
talk)
10:00, 13 January 2017 (UTC)
Bug for languages that include regex special characters in Namespace names
Hello,
We have a small bug for languages that have namespaces that include regex special characters, such as parentheses. In Portuguese, for example, the user namespace is "Usuário(a)", this breaks the calls that depend on the contribs regex, as they expect the targeted user to be the third match and with this it becomes the fourth. To solve this, we need to escape these characters. I made a
naive approach over in a subpage of mine, it does seem to work with no problems. (pinging
TheDJ)
Chico Venancio (
talk)
21:47, 16 October 2017 (UTC)
@
TheDJ: Yep, of course that works, and is better. I tried to look inside Popups code for a regex escape function but forgot to check mediawiki javascript modules. Thanks for the prompt attention to this.
Chico Venancio (
talk)
14:51, 18 October 2017 (UTC)
That still doesn't fix all problems btw, as it doesn't detect the gender specific variants of such links. For that, instead of looking at wgFormattedNamespaces, it should instead use the nsRe function, and escape possibly escape those instead... —
TheDJ (
talk •
contribs)
15:09, 18 October 2017 (UTC)
It fixes every link generated inside popups itself, in my experience. For onwiki links we also need to use either the canonical english page term and the localized term ("contributions" and "contribuições", for example). But this fix already improves my case use significantly.
Chico Venancio (
talk)
15:22, 18 October 2017 (UTC)
Yes, i'm aware of that problem. Lets do one step at a time indeed. I'm currently trying to weed down popups to somewhat more manageable proportions, in hopes of making it slightly easier to keep it alive.. —
TheDJ (
talk •
contribs)
15:42, 18 October 2017 (UTC)
TheDJ, sorry, I think I tested a different version when I wrote that this version was ok. I blame caches.
nsRe(pg.nsUserId) does in fact solve the problem by escaping "Usuário\(a\)", but it adds another html escaped version that is not regex escaped "Usu%C3%A1rio%5C(a%5C)", so we get to the same error of creating an extra capturing group again.
Chico Venancio (
talk)
19:44, 19 October 2017 (UTC)
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
There are currently popupRedirAutoClick and popupDabsAutoClick option that can change the button which is pressed when fixing redirects or dabs. But there is no such option for removing red links. I have modified a script to fix this by adding the popupRedlinkAutoClick option:
User:Alexei Kopylov/sandbox/Gadget-popups.js (
diff). Please copy it over onto the main gadget.
Alexei Kopylov (
talk)
08:11, 6 April 2018 (UTC)
Show information about a user (like "204 edits since: 2006-09-21, last edit on 2018-04-07") before page preview, next to the page statistics (like "16.5kB, 70 wikiLinks, 14 images, 3 categories, 4 days 23 hours old"). Because now you need sometimes to scroll down to see this information.
Make popupSummaryData govern whether this user info will be shown as well as the page statistics (i.e. if popupSummaryData=false then do not show user info).
If simplePopups=true and popupSummaryData=true then show page statistics (including user info), but popupSummaryData should be set to false by default if simplePopups=true (so the default behavior for users who sets simplePopups=true will not change).
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I have fixed two bugs: the popup window did not close in some cases when you have set popupModifier. (One was triggered by pressing wrong modifier on the link, and then pressing right modifier outside the link; and another when the link was hided, e.g. when pressing 'edit' link on wikidata page). Please copy
my fix to the main file.
Alexei Kopylov (
talk)
17:39, 12 April 2018 (UTC)
I have made one more change that implements my suggestion 1 from the previous section
[2]: now it puts user info in separate element and put it on top not on bottom (it was hard to reach it sometime). — Preceding
unsigned comment added by
Alexei Kopylov (
talk •
contribs)
02:24, 14 April 2018 (UTC)
One more bug fix: According to documentation if you set simplePopups=true, then the default structure should be 'original'. This does not work. The following simple fix solve this problem:
[3].
Alexei Kopylov (
talk)
03:45, 15 April 2018 (UTC)
Show user info when popupUserInfo=true and simplePopup=true
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I have change the behavior of the script when an user set simplePopup = true, but also set popupUserInfo=true or popupCategoryMembers=true then it shows the correspondent info anyway. In this way one can enable showing short info, but disable showing full preview (
diff).
This also includes a small bug fix (the popup preview button did not always hide when clicked, e.g. when the target page was empty).
Alexei Kopylov (
talk)
02:24, 19 April 2018 (UTC)
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I have implemented a feature that allow a accept a version (marked it as patrolled).
It adds a "mark patrolled" link if
you are viewing a difference between the last patrolled (a.k.a. stable) version and a newer version
you have the 'review' right
popupReview option is set to true
This link is added in a section popupMiscTools that was not used. I'm planning to add more links in this section (like thank, revert, block) in the feature.
For now popupReview is false by default (so the default behavior should not change), but eventually we should set it true by default.
There was a menu item "marked patrolled" in the code, but it did not work (at least in Russian, German and English wikis). Should I just clean up the code or is it somehow still used in some wikis?
Probably instead of "marked patrolled" it should be called "accept change", I'm not sure what terminology is used in English Wikipedia, I just used an old popupString.
Done I copied your most recent version of that sandbox, rather than the version you linked to. I hope that is correct. I am unable to answer your questions I'm afraid. Perhaps
User:TheDJ would be able to comment? — Martin (
MSGJ ·
talk)
07:08, 17 May 2018 (UTC)
@
TheDJ: the old patrolled link never showed up unless you explicitly put "rcid" in the link like this:
/info/en/?search=Christopher_Silber?rcid=42. However I've never seen such links in the wild. But maybe in some wikipedias they are still used? So I'm not sure what would be the best action: to remove old functionality or to leave both of them (in this case we need to have separate names for old and new functionalities ("make patrolled" and "make reviewed"?).
Alexei Kopylov (
talk)
22:50, 17 May 2018 (UTC)
@
MSGJ: I've
replaced it with the version
Alexei Kopylov linked to. The only difference was Alexei had turned on some debug logging options by default, presumably for testing. It's not something everyone needs to have on by default, it just litters the console. ~ Amory(
u •
t •
c)15:43, 17 May 2018 (UTC)
Minor documentation issue: in the lede it says Firefox: hold down the Shift key while clicking Reload; "Shift" should be "Control" and it could also mention the Ctrl+F5 shortcut.
Here's the suggested whole paragraph, reformatted a bit with nifty button graphics:
Note: After saving, you have to bypass your browser's cache to see the changes:
Internet Explorer: hold down Ctrl while clicking (the refresh/reload toolbar icon)
Firefox: hold down Ctrl while clicking or press Ctrl+F5 or Ctrl+⇧ Shift+R
@
AlanM1: do you just want the word changed, or are you trying to implement all these graphics, etc? For the later we will need you to specify the exact "from" and "to" (or insert 'this' at line 'x') as if you were making the edit yourself. If you just want to "discuss" an improvement, the edit request template should be deactivated. How would you like to proceed? —
xaosfluxTalk15:24, 30 August 2018 (UTC)
Withdrawn for now. I've confirmed Ctrl+F5 in Firefox 61, as well as Shift+Reload. Ctrl+Reload opens the page in a new tab instead, caching unknown. In Edge, it's Ctrl+F5 and Ctrl+Reload. I tried IE11 and got confusing results that require more research than I can do at the moment. Sorry for the waste of time :( —[AlanM1(
talk)]—17:01, 30 August 2018 (UTC)
Proposed change: Shortmenus style "popups" menu-item into shorter icon
TLDR: Because it is rarely needed and gets in the way and increases the chance of linewrap, [I suggest we] change the current text "popups" into just a star/cog (UTF or image, whatever works), in the "menus" and "shortmenus" style-configurations. See current text screenshots at
/Structure_examples#Menus.
Ok. I propose using either ⚙ (
unicode for 'gear' since 2005), or just a plain ascii '*' if there are any concerns about the former. IIUC that string is only used in the 'menus' and 'shortmenus' structures (i've updated all the
screenshots to confirm), and
Minor "popupDabRegexp" edit to match portuguese disambiguation template
Hi all, on the
pt: wiki I had to slightly edit the popupDabRegexp value to make the popupFixDabs feature works.
Instead of (\{\{\s*disambig(... I put (\{\{\s*d[ie]sambig(... to match the
Desambiguação template.
I changed it in my personal
Common.js and it works.
I've been seeing popups from the links in the
Charinsert box below the textbox. When I put my mouse over them, they show a popup with the current page (because they have href="") rather than the tooltip for the edit menu ("Click on the character or tag to insert it into the edit window").
This has happened several user pages of mine and is happening here, though it didn't happen on
MediaWiki talk:Edittools. I edited a section of
Climate and it didn't happen, but then edited the whole article and it happened.
It might have to do with relative execution time of the scripts, because the bug only happens with the menu that is loaded first. When I switch to another menu, the links don't have popups. The
Charinsert script inserts new HTML when a menu is selected. Maybe the Charinsert links are only popup-ified if the Charinsert script happens to insert them before the popups script is executed.
Please remember that the script is exported to a huge variety of third-party projects. Not all of them can update the site engine in a timely manner. And some changes can break the script work for them.
Ivan-r (
talk)
17:46, 13 October 2019 (UTC)
@
Ivan-r: we don't "export to" anywhere. If an external web site is importing raw code from us, they may want to consider using a versioning system (such as pointing to a specific revision here, forking, etc) if they don't want to be on our "live" copy. —
xaosfluxTalk21:00, 13 October 2019 (UTC)
Since I was named here, I just wanted to note that I've indeed seen this. I think it's a worthy consideration, but
xaosflux has hit the nail on the head. ~ Amory(
u •
t •
c)21:41, 13 October 2019 (UTC)
Do you mean "(Blocked)"? I'm not sure it conveys the meaning. Maybe "(editing restricted)" or something? ~ Amory(
u •
t •
c)01:13, 14 January 2020 (UTC)
With the above tweaks, that'd look like
this I suppose? Will hold off adding it for a bit pending other input, but I imagine folks won't really notice until a change is made. ~ Amory(
u •
t •
c)10:50, 14 January 2020 (UTC)
In short, storing the minute offset associated with the user's selected timezone, and using it to localize timestamps that may occur during times when the offset is different, is the wrong approach. If the offset is stored during winter time, localization of timestamps that occur during summer time will be wrong and vice-versa. —[AlanM1(
talk)]—00:04, 8 March 2020 (UTC)
Help in SqWiki
Hello! :)
Lately the navigation popups gadget has stopped working for us in SqWiki. I know the code of gadgets is localized (I'm an I-Admin) but it stopped working spontaneously and even though I made sure we had the same code as the one here, it still doesn't work. No one has changed the common.js/css pages. First I thought it was only me because of some changes I may had made at my preferences that didn't go well with the gadget but yesterday I got emailed by another admin and he was having the same problem. Strangely enough for both of us the gadget works well in EnWiki. Has anything changed lately? Can anyone take a look at our project, maybe point out the problem? Any help in general is appreciated. :) -
Klein Muçi (
talk)
06:42, 7 April 2020 (UTC)
Hello. Popups is a gadget on bnwiki. For redirect, bnwiki uses #পুনর্নির্দেশ. since পুনর্নির্দেশ is not defined here, this gadget doesn't follow redirect on bnwiki. To fix it, Please replace
Question: there are some invisible characters in the text you are requesting. Please confirm if these are needed or update your request. — Martin (
MSGJ ·
talk)
22:12, 23 May 2020 (UTC)
getting popups to work on content generated by other scripts
so if my script generates some content, contained in, say, OOJS or jQuery.ui dialog box, and i want the links in the newly minted content to be hooked to the gadget too, is there something i can do?
That’s rather a workaround than a solution, as it requires action from the user rather than the programmer. You might use mw.hook('wikipage.content').fire($content) if that’s appropriate, but probably the gadget should invent a new hook, as other consumers of the wikipage.content hook might expect the $content parameter to contain the whole page text, freshly from the parser (i.e. they might do non-idempotent changes on the content). —
Tacsipacsi (
talk)
10:58, 27 June 2020 (UTC)
thanks both. after some discussion on mw gelp desk, i think i understand my mistake now - the content added is not under the #content part of the page - it's stuck to something under the #p-personal div, which is outside the content. this is what fails the inbuilt "page preview" popups, which is what i'd really want. thanks again -
קיפודנחש (aka kipod) (
talk)
05:02, 2 August 2020 (UTC)
trying to translate, hoping i understood the request correctly: when the popup is for an article, show interwiki links at bottom. the query you'll need to perform, if you want to fulfil this request is { action: 'query', prop: 'langlinks' }. personally, i do not think the interwiki links are useful enough to justify the screen real estate and the effort. at most, i would add the number of interwiki at some corner of the popup, using tooltip to explain what this number indicates ("the article exists in X languages" - bonus point for listing the first N). peace -
קיפודנחש (aka kipod) (
talk)
21:45, 4 December 2020 (UTC)
JS error: "TypeError: $.inArray is not a function"
Eh, I've been meaning to look into this for a while since I get it sometimes here. This thing is a miserable beast to go through. ~ Amory(
u •
t •
c)16:15, 29 November 2020 (UTC)
If someone can give me a repeatable way of finding it, I'll try and look into it. I've not run into it for a while. ~ Amory(
u •
t •
c)13:29, 4 December 2020 (UTC)
in the scope of this line (i.e., inside Insta.convert() ), it replaces jQuery "alias" $. so in this scope, $.inArray is invalid. remedies: if the array is "normal", you can use <arrayVar>.indexOf. if jquery inArray is desired, call it using jQuery.inArray(). personally, i would rename the "$()" function (i think it was written before jQuery became standard mw library). if you want to try and repro: i did not dive deep into the code, but from a glance, my guess is that it has something to do with nested lists (i.e., lines which begin with **#* and such). peace -
קיפודנחש (aka kipod) (
talk)
21:13, 4 December 2020 (UTC)
Ah good eye
קיפודנחש, that's awful! A couple others there should be renamed; I've done a
quick replace in my userspace, and while with a quick glance overall it seems to work, I've not got a great idea about how to specifically test these changes or ramifications.
Jdlrobson do you have another way to repeat that particular error, at least? I couldn't trigger it on your initial example, and as noted haven't been able to find it here lately, though I know it exists. ~ Amory(
u •
t •
c)18:30, 5 December 2020 (UTC)
I looked into it a bit and can confirm the find/replace will fix the error. The problematic $.inArray call will run when viewing a preview to
User:Enterprisey/sandbox5; you need a list indented with ; (since Previewmaker.prototype.mopup will remove lists indented with :). There are only two calls to $.inArray in the whole script. However, it doesn't raise an error when it tries to call the function; it just returns to the caller. I have no idea why that happens. Maybe it's just a JavaScript thing.
Enterprisey (
talk!)
23:08, 5 December 2020 (UTC)
So... that link has what triggers the error but it doesn't trigger the error? Am I reading that correctly? ~ Amory(
u •
t •
c)02:56, 6 December 2020 (UTC)
It executes the line that ought to trigger the error and then returns from the function instead of saying anything. I am thoroughly befuddled. Maybe I should ask Stack Overflow or something.
Enterprisey (
talk!)
03:42, 6 December 2020 (UTC)
@
Enterprisey: I had a stupid caps error; previews show fine on your link, whereas the original just showed nothing. So, regardless of not being able to trigger the original error, an improvement! ~ Amory(
u •
t •
c)11:41, 6 December 2020 (UTC)
Hmm, I think I can see some issues with my quick replace. For one, it looks like some popups have abbreviated previews? Also, upon second generation for the same link, I get a compareLineString is not defined error. I'll try and look into it a bit more tomorrow. ~ Amory(
u •
t •
c)11:41, 6 December 2020 (UTC)
Okay all I've just pushed a change to fix both the issues in this section. I was able to replicate the error on ca.wiki (I was using the wrong link...) which helped soothe my cautious soul, but ping me if anything is busted!
~ Amory(
u •
t •
c)12:41, 9 December 2020 (UTC)
Malformed URI sequence
@
Amorymeltzer: I could have sworn I got the same error here, too, but now I can't reproduce it. Maybe I was thinking of this bug: If I (FF 83/Linux) hover over
this link, I get https://en.wikipedia.org/?title=User:Amorymeltzer/popup.js&action=raw&ctype=text/javascript at line 2205: URIError: malformed URI sequence. Don't know if that's related.
Suffusion of Yellow (
talk)
22:05, 5 December 2020 (UTC)
@
Suffusion of Yellow: That's a separate issue, that amusingly I was dealing with earlier today. Basically, decodeURI (and decodeURIComponent) are stupid and can't percent-encode % per se, so the whole thing just falls apart What I just did was:
That basically percent-encodes any % that doesn't look like a proper hexcode. We can do that here too, I suppose. ~ Amory(
u •
t •
c)03:02, 6 December 2020 (UTC)
Actually, looks like popups already does this? See the functions myDecodeURI and safeDecodeURI. Your issue appears to be the only extant use of the native decodeURI, and a quick test shows that merely replacing it makes the popup work. The title is erroneous/misleading, though, as in your case it will show "X#3%" as the title, when we'd prefer "X#3"? Half a loaf, I suppose! ~ Amory(
u •
t •
c)03:11, 6 December 2020 (UTC)
Okay, had a moment, I think I took care of it, check out
this comparison. Basically, (some? all?) citations previews use _, which were removed by decodeExtras, so using that broke 'em. I added my regex to decodeEscapes in the case where no valid %-encodings were found, and swapped the order in decodeNasties so that decodeURI was only called on the now-properly-escaped text. I'll do some more testing later, since it's not urgent, but I think this should clear up this issue. ~ Amory(
u •
t •
c)15:30, 9 December 2020 (UTC)
We certainly will! Yay to not having to code in the dark any more. Hopefully this means we'll catch the bugs before people report them :) Exciting times to be a Wikimedia developer!
Jon (WMF) (
talk)
02:14, 26 January 2021 (UTC)
Jon (WMF), I actually went ahead and replaced your changes with my version above, hope you don't mind: I was still able to trigger the issue on the same link above after the changes you made. Was there something you tested it on I could confirm this works as well? ~ Amory(
u •
t •
c)02:17, 26 January 2021 (UTC)
I do not mind at all. In fact I appreciate your help and support with getting these issues addressed. Don't worry you will hear from me again if the error resurfaces haha! :)
Jon (WMF) (
talk)
02:20, 26 January 2021 (UTC)
Something wrong after fix URL problem. (Popups 's Script on Chinese Wikipedia is is a direct reference to English Wikipedia's) --
Cwek (
talk)
03:00, 26 January 2021 (UTC)
In the French Wikipedia also. The title of a target page which contains non-ASCII characters is wrong (but the link works).
Seudo (
talk)
10:03, 26 January 2021 (UTC)
So sorry for that, thanks for the note! I've gone and reverted the change. Will look into a better fix later! ~ Amory(
u •
t •
c)11:32, 26 January 2021 (UTC)
Currently the script does not work well with the new wikitext mode as it cannot automatically edit and fill in the edit summary. Is it possible to fix this by replacing "action=edit" with "action=submit" in the generated links since "action=submit" opens the old editor? ~
Aseleste (
t,
e |
c,
l)
15:25, 7 April 2021 (UTC)
@
TheDJ: I am referring to any action that takes you to the wikitext editor. Somehow forgot to watchlist this page, sorry. ~
Aseleste (
t,
e |
c,
l)
17:41, 8 April 2021 (UTC)
timeZone support
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
As described in
phab:T223002, there have long been problems with DST in popups. This
change should fix that, by using the timeZone the user has configured instead of the offset (which should not be relied upon). We make use of toLocaleString to render a string in the specified user language locale and the configured timezone. IE11 is the only browser we support that doesn't support this method, and in that case we fallback to the old system. It also introduces the options popupLocale, popupDateTimeFormatterOptions, popupDateFormatterOptions and popupTimeFormatterOptions to override as desired. —
TheDJ (
talk •
contribs)
22:33, 3 April 2021 (UTC)
Regarding if( tzComponents.length === 3 && tzComponents[0] === 'ZoneInfo') { ... } else { errlog( 'Unexpected timezone information: ' + tz ); }, @
TheDJ, tzComponents[0] can also be System (wiki default time) or Offset (exact offset specified rather than a zone). –
SD0001 (
talk)
08:05, 4 April 2021 (UTC)
Yes, I know, it's just that I can't do much with that information. System == UTC (already the fallback). Unless its not, which means not a WMF server and I don't see why we need to support those installations. (Nvmd, I forgot about non-english there.. I'll see about fixing that too) This System setting should only occur for new users who have never set their timezone. The Offset case can happen more often, but should still be rare. I guess in theory we could fallback to offset calculation here, but I'm not sure that is worth it. —
TheDJ (
talk •
contribs)
09:36, 4 April 2021 (UTC)
This System setting should only occur for new users who have never set their timezone.
I’ve changed my preferences (including my timezone preferences) quite a number of times, but settled at the default System, as I prefer to see the same time in page histories and in signatures. I’m pretty sure I’m not alone; this occurs not only for new users. —
Tacsipacsi (
talk)
01:00, 5 April 2021 (UTC)
Done I've synced in the requested change, please ping me here if any issues are presenting now. Any int-admin should feel free to revert if breaking issues have been created. —
xaosfluxTalk14:59, 12 April 2021 (UTC)
I'm thinking about code changes to make {{User They them pronouns}} put "they/them" in the same place where "he/him" sometimes appears today. That's going to be tricky to localize, though - anyone have any suggestions? We could start another mapping of language-specific data, separate from the current mapping of translations, that can hold mappings of templates to pronoun displays, perhaps?
Enterprisey (
talk!)
07:59, 10 August 2021 (UTC)
Other option is to make those templates emit a span with a class that can be recognised that is used to parse out the information you want to display. —
TheDJ (
talk •
contribs)
08:35, 10 August 2021 (UTC)
Yeah, that sounds like a better idea. Or maybe a HTML attribute data-mw-use-pronouns="they/them", for direct display in Popups, which removes the need for any sort of mapping or translation layer. I know Popups already fetches the wikitext of the user page; I don't know if it already fetches the HTML, but I guess that's not much of a concern.
Enterprisey (
talk!)
21:37, 10 August 2021 (UTC)
You're going to have to fetch additional data regardless, because the wikicode fetcher/interpreter only fetches the first part of the page and the template can be anywhere. It also doesn't really do anything with templates. So it's either via the rendered html, or via something like categories. But categories could be way more controversial. —
TheDJ (
talk •
contribs)
11:00, 11 August 2021 (UTC)
Perhaps don't get married to this specific template for this purpose? There are a ton of these templates if you count all the forks. You could just make a single custom template for popups purpose, with the directions being to put it at the top of the page - it wouldn't have to have visible output (it could just output an empty div with a class for example). —
xaosfluxTalk13:58, 11 August 2021 (UTC)
At
User talk:Nardog/MoveHistory#Odd side effect, a user thought Navigation popups stopped working on links in diffs made by
wikEdDiff because of my script, when (as far as I could tell) it was because wikEdDiff was sometimes loaded after Navigation popups had already run. I suggested code to make sure they are loaded in the right order (or can the order be specified in
gadgets definition or somewhere?), but this seems like a problem that can be worked around by Navigation popups attaching event handlers to an element near <body> rather than to individual links, taking advantage of event delegation, so it can show popups on links inserted later by other scripts.
Nardog (
talk)
00:53, 31 August 2021 (UTC)
Popups on search suggestions?
One kind of link on which Navigation Popups don't seem to appear are the search suggestions that pop up if I type into the search bar (e.g., if I type "a" I get suggestions of
A,
Association football,
Australia,
Animal,
Arthropod, ..., any of which I can click to navigate to the article). Would it be reasonable to make Navigation Popups show for these links? —
2d37 (
talk)
05:33, 28 September 2021 (UTC)
Page Previews incompatibility
As raised
here, incompatibility with the more modern Page Previews is a real drawback to the Navigation popups tool—is there a plan to add an option for the Navigation popups to only be shown for non-mainspace pages? —
Bilorv (talk)
13:33, 28 September 2021 (UTC)
@
Bilorv: despite
WP:DTTR: {{sofixit}}? (
) Basically, there is no centralized "design authority" on this, so whatever someone wants to work on is fine. There should be very little pushback if someone wants to introduce an opt-in option to the gadget. —
xaosfluxTalk15:05, 28 September 2021 (UTC)
@
Xaosflux: always happy to be sofixit'd. I have some fluency in programming, but none on Wikipedia, so I can't really estimate the scale of the task from my level of knowledge. Would we be looking at wrapping some code in a simple conditional ("if !getValueOf('popupDisableMainspace') || [function to get page namespace] != 0") or a huge overhaul of hundreds of lines of code? —
Bilorv (talk)
15:54, 28 September 2021 (UTC)
presuming this is not something everyone wants, it can be implemented individually, in a roundabout way: basically, instead of enabling the gadget in preferences, one can load it "manually" from their
personal script page, applying any filter desired, such as namespace id != 0, or even article name != 'Kung Fu Panda' or "today is not Tuesday". peace -
קיפודנחש (aka kipod) (
talk)
21:21, 30 September 2021 (UTC)
i missed the "fluency in programming, but none on Wikipedia" part. sorry. to load the gadget, use the command
// simply load it:mw.loader.load(' ext.gadget.Navigation_popups');// gadget may be named differently on other wikis// alternatively, "everywhere except article space":if(mw.config.get('wgNamespaceNumber')!=0)mw.loader.load('ext.gadget.Navigation_popups');
An interesting concept,
קיפודנחש. When I use this conditional version it shows me navigation popups as normal for non-mainspace links, and for mainspace links it shows me both the popups and the hovercards. When I change this to:
if(mw.config.get('wgPageName')!='Kung Fu Panda')mw.loader.load('ext.gadget.Navigation_popups');
I get the exact same effect, whether on links to
Kung Fu Panda or other mainspace pages. Same also for simply:
your condition should still work, but only ON THE 'Kung Fu Panda' PAGE (it won't work for links to this page!)
the decision to load or not load the gadget is done only once, when the page is opened.
i suggest you try to see what is the behavior for internal links which appear _in_ the page
Kung Fu Panda (presuming you have the condition), and if indeed you see what you want to see, you can change the condition to mw.config.get( 'wgNamespaceNumber' ) != 0; (tbh, the "!= 0" part is superfluous, since 0 is false, so it's more for the human reader than for the machine).
i might have misunderstand the original request - i thought you wanted to disable popup on mainspace, not "disable popup for links to mainspace pages". note that the 2nd, more sophisticated way, requires more than just navpop change: the inbuilt "hovercard" (i think this was the original name of this feature) would detect "navigation popups", and disable itself when detected, respecting the seniority of the latter. presuming this is still done, what you ask might require some changes to the inbuilt feature, otherwise each may give "right of way" to the other, such that neither will work for mainspace links.
typically, mainspace IL should be only to mainspace pages, so my "reverse" solution (based on namespace of current page rather than that of the linked page) should be "almost good enough". you may have other places where may want to squelch navpop, e.g. watchlist, categories, or "what links here" pages (. my suggestion was to find a criterion for "where to load navpop" which works for you. i can't think of something like "which links to ignore" way, short of actually meddling with the code of both navpop and the inbuilt feature. sorry. peace -
קיפודנחש (aka kipod) (
talk)
22:31, 30 September 2021 (UTC)
@
קיפודנחש: have you actually tested the code yourself? I tried both versions of "links to mainspace pages/
Kung Fu Panda" and "links on mainspace pages/
Kung Fu Panda" with both versions of the conditional, figuring myself that the code you'd given looked more like it was designed for links on a page, and none of the four of them worked. I reasoned similarly to you that disabling popups in mainspace was close enough. —
Bilorv (talk)
15:59, 1 October 2021 (UTC)
and it does exactly that: navpop works everywhere except in mainspace (note that for links to articles from non-article space, like the link to kung fu panda above, you get both: "page preview" does not detect navpop, since it's not selected in preferences, and navpop itself works outside of mainspace). i understand you were asking something a bit different - discriminating based on the page linked, but this is, as you put it, "close enough".
i also verified that indeed, the inbuilt "article preview" self-disables when navpop is enabled in preferences => gadgets. navpop provides more functionality than page preview (basically everything under "actions"), and i imagine most navpop users want it on mainspace too. again, such an option in navpop will not be enough - in addition to disabling navpop for mainspace links, something will have to be done to tell "page preview" that the user selected this option, so it should not "self disable", and still disable itself for navpop users who did not choose this option. all this is doable, but it seems highly unlikely it will be done. peace -
קיפודנחש (aka kipod) (
talk)
17:10, 1 October 2021 (UTC)
I didn't notice your edit
here changing the code without comment. I'll go with this bodge for the time being, though it seems to be that despite being told to fix it myself, I do not have the technical permissions to actually implement my initial request. —
Bilorv (talk)
17:04, 2 October 2021 (UTC)
One could edit it in a sandbox and offer the sandbox version to be copied by an interface editor. (Personally I don't think I have the confidence to try fiddling with a widely-used 243-kilobyte JavaScript script myself.) —
2d37 (
talk)
09:16, 3 October 2021 (UTC)
@
2d37: I don't have the technical permissions to edit the functionality of hovercards, which seems to be necessary for this change. —
Bilorv (talk)
16:54, 3 October 2021 (UTC)
Ah, my apologies, yes, I thought
MediaWiki:Gadget-popups.js was meant. (As it's all
dynamic JavaScript, I suppose it's possible to mess with the Page Previews from within (a non-gadget version of) Navigation Popups, but I don't suppose it's wise.) —
2d37 (
talk)
00:13, 4 October 2021 (UTC)
Interface-protected edit request on 8 October 2021 (2)
Request to deploy
this new version of popups (
diff).
This has the following changes:
Use the proper groupnames, instead of the technical groupnames (administrator instead of sysop)
Add support for WhatLinksHere, Diff, emailuser and Contributions pages in non-english languages, by fetching the Special page name aliases from the API.
@
TheDJ: just a quick note that this isn't being purposefully ignored as far as I know, the change is just quite large and likely no one has had enough time to review it yet. I'll likely just promote your change soon as I trust you and it could always be rolled back - just haven't found a good time to schedule that where I'd be around to fall it back if needed. Thank you for continuing to work on this development! —
xaosfluxTalk23:23, 18 October 2021 (UTC)
Hmm... following this change, when I hover over a user, the user groups now display as the system message names for some time until another network request completes. I imagine the user group names don't actually change much... would it be possible for there to be some caching or some other way to prevent this behavior? It's a minor cosmetic issue, I guess, but it's a little annoying. And to end on a positive note, thank you for putting the effort into this change; it does look a lot better to have the proper names be used.
Enterprisey (
talk!)
06:49, 20 October 2021 (UTC)
No significant delay here – less than a second, if at all. On the other hand, contributions for IP editors have a very narrow column for the article name. --
Michael Bednarek (
talk)
07:25, 20 October 2021 (UTC)
@
Michael Bednarek the column sizing is intentional. It was to fix the overflow. The columns are now divided 3:7 between article name and comment. Its hard to find a good tradeoff for that. —
TheDJ (
talk •
contribs)
07:48, 20 October 2021 (UTC)
Yes I sometimes see it too. Unfortunately popups is designed to render early and then fill in information as it arrives. That also happens here and I have no easy way to get around to it. There is also not really a usable cache for this, as popups only has in-memory caches, so adding a new one would be some additional work. —
TheDJ (
talk •
contribs)
07:51, 20 October 2021 (UTC)
This does look jarring. @
TheDJ perhaps the delays can be mitigated with simple http caching? I see the message fetch requests don't have maxage param, though these are unlikely to change at all. –
SD0001 (
talk)
15:31, 20 October 2021 (UTC)
It's a like a different kind of
FOUC, which while not "important", is usually considered worth fixing. I see it on every username hover. –
SD0001 (
talk)
16:06, 20 October 2021 (UTC)
Do the the flashing, I'm in favor of not using the localized group name parts - other improvements still seem fine. Anyone want to mock up a proposed new version? —
xaosfluxTalk16:23, 20 October 2021 (UTC)
I hope this is the correct page to ask my question. While using the gadget on dewiki, I noticed that the UserData line for links to user pages is always in English (e.g. he/him · autoreview, editor, last edit on 2021-10-01). Is there a way to localise it? Regards,
XanonymusX (
talk)
22:58, 30 September 2021 (UTC)
@
XanonymusX: As far as I know, user groups are just the technical names (this is why you’re flagged as a “sysop” on dewiki instead of an “admin”). Everything else should be translatable through window.popupStrings, e.g.
window.popupStrings={...'he/him':'er/ihn',// or whatever is used in German; be careful to use pronouns and not biological sex/gender (see [[phab:T284783]])'last edit on ':'letzter Beitrag am ',...};
Thanks, that
worked! The only part I have not been able to change is “# edits since:”; how to find out what the exact string is in this case? I have tried “edits since” and “edits since: ”, to no avail. Of course, displaying the technical names for the user group is not very nice in a non-English environment; similarly, the number and date formats do not fit with the German translations of the remaining text. Any chance that these could be localised as well? Regards,
XanonymusX (
talk)
11:32, 4 October 2021 (UTC)
Should be ' edits since: ' as can be found in
MediaWiki:Gadget-popups.js. "similarly, the number and date formats do not fit with the German translations of the remaining text" these should be getting localised by your browser (and for me it shows "4. Oktober 2021" for instance). If it doesn't work for you, can you specific exact pages and language settings you use, as well as the browser you use ? —
TheDJ (
talk •
contribs)
11:47, 4 October 2021 (UTC)
This discussion reminded me of a long-standing problem I have with popups at the German Wikipedia: every aspect there works, except the popup list in a revision history or watchlist for "Beiträge" (contribs) does not show. But, when I hover over a user name and then "Benutzer" (user) and go to "Beiträge", the popup list does show. However, this method requires hovering 3 levels and a steady hand on the mouse. The failure to show the popup list for "Beiträge" directly baffles me. --
Michael Bednarek (
talk)
13:06, 4 October 2021 (UTC)
This is because popups has 3 links with hardcoded strings, since it didn't traditionally know the translated name of those links.
I played with
adding some options, which should make it possible to set something like window.popupContributionsLinkRegexp = 'Contributions|Contribs|Beiträge|'+encodeURI('Beiträge'); from the de.wp configuration script. Not deployed yet. I also worked on translating the group names, but the strategy I'm using there doesn't work yet, as apparently you can only retrieve a max of 50 messages and we have 91 groups and dynamically loading them within popups with the current structure is a bit hard... If anyone has ideas.. —
TheDJ (
talk •
contribs)
20:54, 4 October 2021 (UTC)
Thanks, somehow I had been unable to find that specific string! It’s working now. The dates however are always shown as 2021-10-08 to me and the byte number always uses a point instead of a comma. I use Chrome, language preference is de; I also tried it with Firefox now, still the same.–
XanonymusX (
talk)
21:47, 8 October 2021 (UTC)
Popups at DE Wikipedia's watchlist show German dates for me ("9. Oktober 2021"), article size is shown as nnn.nkB, but still nothing is shown for "Beiträge". --
Michael Bednarek (
talk)
01:26, 9 October 2021 (UTC)
@
Michael Bednarek: I still see ISO 8601 (YYYY-MM-DD) dates everywhere, the article size is also incorrect (the dot is a thousands separator in German, not a decimal separator: the English 1,234.5, meaning one thousand two hundred thirty-four and a half, is 1.234,5 in German). The fix for the contributions link is ready but hasn’t been deployed yet (see edit request below). —
Tacsipacsi (
talk)
11:57, 9 October 2021 (UTC)
When I use popups to hover over your username at
https://de.wikipedia.org/?title=Benutzer_Diskussion:Tacsipacsi&action=history (2nd line) I see "er/ihm · autoreview, editor, 323 Beiträge seit 20. Juni 2012, letzter Beitrag: 23. Juni 2019", hovering over "Diskussion" shows "er/ihm · autoreview, editor, 323 Beiträge seit 20. Juni 2012, letzter Beitrag: 23. Juni 2019¶5.2kB, 11 Wikilinks, 0 Bilder, 0 Kategorien, 119 Wochen alt" (¶ is a new line). Hovering over "Beiträge" shows the browser's, not popups', tooltip "Spezial:Beiträge/Tacsipacsi". This behaviour is the same for Firefox and Chrome. --
Michael Bednarek (
talk)
12:31, 9 October 2021 (UTC)
I see er/ihm · autoreview, editor, 323 Beiträge seit 2012-06-19, letzter Beitrag: 2019-06-23 (the second line is the same for me as for you). But I’m okay with the ISO date format, so I don’t think we should spend much time debugging the difference. —
Tacsipacsi (
talk)
14:40, 9 October 2021 (UTC)
I noticed for the first time today on the German Wikipedia that popups showed entries under "Beiträge" (contribs) (see
above). Thank you to whoever fixed this. --
Michael Bednarek (
talk)
01:10, 26 October 2021 (UTC)