Wikipedia:Village pump (technical): Difference between revisions

Policy

Technical

Proposals

Idea lab

WMF

Miscellaneous

• Table of contents
• First discussion
• End of page
• New post

Shortcuts

• WP:VPT
• WP:VP/T
• WP:TECHPUMP
• WP:PUMPTECH

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

view · edit Frequently asked questions (see also: Wikipedia:FAQ/Technical) Click "[show]" next to each point to see more details. If something looks wrong, purge the server's cache, then bypass your browser's cache. This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown. No, we will not use JavaScript to set focus on the search box. This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences. No, we will not add a spell-checker, or spell-checking bot. You can use a web browser such as Firefox, which has a spell checker. If you have problems making your fancy signature work, check Help:How to fix your signature. If you changed to another skin and cannot change back, use this link. Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem. If an image thumbnail is not showing, try purging its image description page. If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear. For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Currently, when editing the source text (i.e. not the visual editor), under the "advanced" formatting tab there is a button to insert a line break, which inserts the code <br>. As discussed at WP:LINEBREAK, this can break several of the available syntax highlighters for wikicode in the editing view (mis-highlighting all text in the page after the occurrence of that tag), and so should be avoided. Is it possible to change the interface so it inserts <br /> instead? (I apologize if I'm not using the right vocuablary.) MarginalCost (talk) 21:00, 4 June 2019 (UTC)[reply]

MarginalCost, if a syntaxhighlighter cannot handle a simple br tag, it's broken and shouldn't be used. —TheDJ (talk • contribs) 23:13, 4 June 2019 (UTC)[reply]

@TheDJ: Okay, new topic: The built-in Wikipedia syntax highlighter available through the user preferences/gadgets menu is broken and shouldn't be used.

If <br /> is the recommended output, why stick with the less-preferred one? MarginalCost (talk) 23:40, 4 June 2019 (UTC)[reply]

Gadgets are not official. They are maintained entirely by volunteers. --Izno (talk) 00:05, 5 June 2019 (UTC)[reply]

This is a long-standing known issue with the syntax highlighter, and there are periodic fruitless arguments about it on this page. Since the MW parser outputs <br />, and that form allows the syntax highlighter to help editors find and fix other syntax problems, it seems to me that the least bad option is to insert <br /> as the preferred option. I can find only one Phabricator task that relates to br tags and syntax highlighting (linked at the right side of this section), but I'm pretty sure I have seen others. – Jonesey95 (talk) 08:30, 5 June 2019 (UTC)[reply]

The button used to insert <br />, but this was changed by TheDJ in T150172. Perhelion argued at the time that <br /> should be replaced because HTML5 prefers <br>. However, <br /> is valid HTML5, and the MediaWiki parser will convert <br> to <br />. From what I can see, there's two options: go full-on <br>, which includes changing the parser, fixing the syntax highlighters, and changing the advice on WP:LINEBREAK, or go full-on <br />, which only needs a revert of that change by TheDJ. I'm in favour of the latter. Opinions? (also pinging Fomafix, who commented on that phab task.) rchard2scout (talk) 11:01, 5 June 2019 (UTC)[reply]

Rchard2scout It just doesn't matter that much, unless you are the type of person that cares about adding or removing spaces between heading syntax and the heading content... Fruitless arguments indeed. Harmonisation of the wikicode is NOT needed here and a waste of editor time. Tools should be able to handle both, both are allowed wikicode, both are allowed in html5, one is better xml, the other better html5. I personally don't see the need for either wikEd or Remember theDots syntaxhighligh lib. Neither are used by more than a couple of people in the grant scope of things. And confusing users with documentation on details of line break syntax.. really.. who reads that and comes away with any level of understanding ?? A line break is <br> done. —TheDJ (talk • contribs) 13:26, 5 June 2019 (UTC)[reply]

Interesting support, with details, for <br> from a dev: diff "...<br> is valid wikitext...". I support that view—simple is good and changing wikitext to insert a space and a slash is pointless and confusing for onlookers. Johnuniq (talk) 00:25, 6 June 2019 (UTC)[reply]

Alright, TheDJ's arguments and Tim Starling's explanation have me convinced. One interesting quote from that reply by Tim: RemexHtml "will initially output "<br />" for compatibility with parser tests", which means it could be changed in the future, and we really shouldn't base our decisions about wikitext on the HTML output it generates. Let's not fix things that ain't broken, and those who care about syntax highlighting gadgets should fix their syntax highlighting gadgets. rchard2scout (talk) 19:08, 6 June 2019 (UTC)[reply]

Just so you know, the space in <br /> is entirely optional (personally I think <br/> looks better without the space). <br> without the slash is in no way "better" HTML5. The main reason why I don't want to support <br> in the syntax highlighter is because it's confusing to have some tags be automatically closing while other tags like <references/> require the slash. Also, I don't want to have to maintain an ever-growing list of automatically-closing tags. —Remember the dot ^(talk) 00:34, 9 June 2019 (UTC)[reply]

In HTML, the only valid self-closing tags are the void elements, and in fact any self-closed tag in the list of all valid HTML tags not present in the list of void elements is an error (e.g. <span/>). So, you probably should also not support the invalid HTML (except where appearing inside of e.g. <pre>). In the list there, only a couple of those appear as wikitext (though <source> has different semantics in wikitext). That list basically hasn't changed since HTML 4. So...

As for confusion, there's nothing you can do about that--some tags will be self-closing in some situations, and we've introduced a few others to wikitext (e.g. <section> for section transclusion), and some tags will never be self-closing, as is the case for that vast majority of the HTML tags you can write in wikitext (<code>, <div>... and just about every other). What's actually confusing is when a maintained gadget breaks on valid wikitext and then we get discussions like this one.... --Izno (talk) 02:29, 9 June 2019 (UTC)[reply]

Sure there's something we can do about that: Deprecate the use of <br> without the slash (maybe show a warning if the non-slashed version is used) and stop considering it "valid" wikitext. It's just not a popular solution because people insist that requiring the slash on tags like <references/> and <section/> but not on <br> and <hr> is somehow more straightforward. —Remember the dot ^(talk) 06:41, 9 June 2019 (UTC)[reply]

The reason it's unpopular is because it's valid HTML, which enjoys a consensus your gadget does not. Right now both of the WMF-sanctioned highlighters (one in the 2017 WTE and the other in the 2010) work just fine (if more-simply in other aspects). A whitelist/blacklist on your part is not hard to maintain once initially implemented and could even be maintained by another editor if you are disinterested. --Izno (talk) 15:50, 9 June 2019 (UTC)[reply]

HTML5 made everything "valid", including <p> and <div> tags without accompanying </p> and </div>. This syntax cannot be supported in the syntax highlighter without major detriment to its performance. Nevertheless, you are welcome to get permission to move mw:User:Remember the dot/Syntax highlighter and mw:User:Remember the dot/Syntax highlighter.js out of the User namespace, edit them based on community consensus, update mw:MediaWiki:Gadget-DotsSyntaxHighlighter.js to match, and continue to maintain the shared fork by adding new translations etc. If you implement automatically-closing tags nicely--with a voidTags config parameter analogous to nowikiTags and sourceTags--I won't revert it. Considering how strongly people seem to feel about this, I'm surprised that no one has done that already. —Remember the dot ^(talk) 20:36, 9 June 2019 (UTC)[reply]

No, the </p> tag has never been required until recently (it wasn't mentioned in HTML 1, was implicitly optional in HTML 2.0, explicitly optional in HTML 3.2 and HTML 4, and became conditionally optional in HTML 5); whereas the </div> tag has always been mandatory (HTML 3.2, HTML 4 and HTML5 spec). --Redrose64 🌹 (talk) 22:50, 9 June 2019 (UTC)[reply]

Oh interesting. Thanks for pointing out that HTML5 doesn't deserve all the blame for implicit </p> tags and implicit </div> is still technically forbidden. However, the fact remains that the syntax highlighter wouldn't be able to support implicit </p> without major, performance-killing modifications. —Remember the dot ^(talk) 23:20, 9 June 2019 (UTC)[reply]

.

Between HTML 4 and 5, there were some iterations of XHTML. Closing tags (or self-closing where no content) were required for everything including <p>...</p>, <hr/>, etc., so that it would validate as proper XML. The space before the slash was an optional but recommended kludge to keep earlier parsers happy (It's valid SGML, and HTML4 parsers would see the slash as an invalid attribute). As mentioned above, <references/> isn't any kind of (X)HTML, it's XHTML-inspired wikicode (and well-formed XML).

When I view HTML source on a Wikipedia page as delivered to the browser, the <p>...</p> tags are paired not naked. If MediaWiki hasen't turned that on its head to go fully down the HTML5 rabbit-hole, then I say our tools should keep inserting XHTML-compatible <br />. The instant counter-argument is that MW emits <!DOCTYPE html>. Sigh. (Although there's an HTML5-style doctype, does MediaWiki create anything else that's not good XML?)

Anybody know what Visual Editor inserts for br?

— Pelagic (talk) 09:17, 16 June 2019 (UTC)[reply]

Yes, I forgot about XHTML 1.0. That was essentially HTML 4.01 with a few extensions and a much tighter syntax: there were no optional tags; tag and attribute names had to be lowercase; all attribute values had to be quoted; etc. But XHTML was more of an offshoot from the main route, rather than a step in the progression. --Redrose64 🌹 (talk) 10:35, 16 June 2019 (UTC)[reply]

The latest HTML5 spec states "This specification defines an abstract language for describing documents and applications...There are various concrete syntaxes that can be used to transmit resources that use this abstract language, two of which are defined in this specification...The first such concrete syntax is the HTML syntax...The second concrete syntax is the XHTML syntax...This specification defines the latest version of the XHTML syntax, known simply as 'XHTML'." So no, XHTML was not a temporary deviation from the main route; HTML and XHTML continue in parallel as equivalent syntaxes for representing essentially the same content. —Remember the dot ^(talk) 14:30, 16 June 2019 (UTC)[reply]

It states at the top "W3C Working Draft, 18 October 2018". This is not a W3C Recommendation, so is in a fluid state and not to be considered definitive or final. See World Wide Web Consortium Process Document, section 6.1.2. --Redrose64 🌹 (talk) 23:05, 16 June 2019 (UTC)[reply]

In addition to the HTML 5.3 specification I linked above, the HTML 5.0, HTML 5.1, and HTML 5.2 specifications all say the exact same thing about XHTML. XHTML has been there all along and it's unlikely to disappear. —Remember the dot ^(talk) 06:13, 19 June 2019 (UTC)[reply]

KISS. Keep It Simple, Stupid. KISS principle. I use <br> all the time on wikis outside Wikipedia. Don't f*ck it up by requiring the use of <br /> in wikitext editing in the MediaWiki software. And you notice how <br /> with the space can wrap to 2 lines in the wikitext. Yet more confusion. <br> is simpler than </br> too. Or <br/>. People forget where to put the slashes for all of these tags. I still do sometimes. -- Timeshifter (talk) 09:29, 9 June 2019 (UTC)[reply]

If MediaWiki required <references> and <section> instead of <references /> and <section />, I would agree with you. However, requiring the slash on some tags but not others, or leaving it up to the whim of the author, is not KISS. The default "tag soup" serialization of HTML5 is in fact the antithesis of the KISS principle. —Remember the dot ^(talk) 20:36, 9 June 2019 (UTC)[reply]

I agree, Remember the dot. If the core software is XML-compatible, then the add-ons, toolbars, templates, etc. should be also. If we can output code that works in HTML5 and XHTML, then why not? Pelagic (talk) 09:17, 16 June 2019 (UTC)[reply]

By the way, if the network connection is fast enough, it's actually faster to send data uncompressed than to send it in a compressed format and then decompress it on the receiving end. For the same reason, 10 or 20 years from now I suspect XHTML5 will surge in popularity because it puts so much less strain on the CPU. —Remember the dot ^(talk) 20:54, 9 June 2019 (UTC)[reply]

Definitely not, with thinner and thinner fab processes, devices will be more efficient and more powerful as well (a reminder that we have AI/ML on our smartphones now). You're right about the first point as we are approach higher bandwidths, but not so much about the second, the end winners are going to be JavaScript and Python as resource-hunger becomes less and less of an issue and everyone wants a scripting language to just do anything, no doubt. --qedk (t 桜 c) 14:41, 16 June 2019 (UTC)[reply]

Intel has been trying for years to go from a 14 nanometer process to a 10 nanometer process and still hasn't succeeded in mass-producing 10nm chips. Silicon atoms are only 0.2nm in diameter, so 10nm means lithography that is 50 atoms wide. At some point in the near future, we just won't be able to go any smaller and unless someone discovers a better semiconductor than silicon, we will be at the limit of single-thread general-purpose CPU performance. The bottom line is that we can't rely on CPUs getting faster any more; instead we are compelled to write more efficient software. You can already see the effects of this shift in the increasing popularity of C and C++ and the emergence of new compiled languages like Cython, Go, and Rust, as well as interest in binary (non-textual) data formats such as BSON and Protocol Buffers. —Remember the dot ^(talk) 15:08, 16 June 2019 (UTC)[reply]

Oh and how could I forget WebAssembly, which is basically a compiled version of JavaScript? —Remember the dot ^(talk) 15:13, 16 June 2019 (UTC)[reply]

And of course, massively-parallel hardware (and software that must adapt to that) —PaleoNeonate – 15:16, 16 June 2019 (UTC)[reply]

TSMC and Samsung are already mass-producing 7nm, whether Intel catches up is irrelevant. And just to remind you, in terms of stats, JavaScript and Python are the only languages to not lose out in the TIOBE index rankings (Python is the largest gainer) and both of them are now on the top of StackOverflow stats, with JS leading in terms of numbers and Python in terms of growth of the numbers. ...instead we are compelled to write more efficient software, this statement was probably true in the conventional times but now we are moving at a different pace and maybe this statement will come to fruit in the later part of the next decade but not earlier than that. --qedk (t 桜 c) 15:34, 16 June 2019 (UTC)[reply]

How to type things like "t-Bu" using the <chem> tag?

According to mhchem, it should be something like $t${-}Bu, using $...$ for italics and {-} to indicate that the hyphen is really a hyphen (instead of a bond).

In the present-day <chem>:

$t${-}Bu produces ${\displaystyle {\ce {\$t\${-}Bu}}}$ (very wrong),

\mathit{t}{-}Bu produces ${\displaystyle {\ce {{\mathit {t}}{-}Bu}}}$ (italic t, but {-} still makes a bond),

\mathit{t}\text{-}Bu produces ${\displaystyle {\ce {{\mathit {t}}{\text{-}}Bu}}}$ (how?!),

\mathit{t}\text-Bu produces a syntax error.

Is there any reasonable way to get hyphens inside <chem>? The question is not about workarounds for this particular case, but about the general approach that will work in more complex examples, like "[t-Bu]₂O" over a reaction arrow inside <chem>. — Mikhail Ryazanov (talk) 03:22, 7 June 2019 (UTC)[reply]

Have you looked at {{Chem}}? It might work for you. – Jonesey95 (talk) 04:58, 7 June 2019 (UTC)[reply]

{{Chem}} only helps to make some lower and upper indices, so it is of no use here. Especially for "more complex examples, like '[t-Bu]₂O' over a reaction arrow". — Mikhail Ryazanov (talk) 19:13, 7 June 2019 (UTC)[reply]

According to Help:Displaying a formula#Chemistry, <chem>X</chem> is just shorthand for <math chem>\ce{X}</math>. This makes it possible to not have everything in the \ce tag. The next problem is that everything in <math> is in LaTeX math mode, which doesn't have a hyphen, only a minus sign. I played around a little and put together <math chem>t\textrm{-}\ce{Bu}</math>, which produces ${\displaystyle t{\textrm {-}}{\ce {Bu}}}$. Would something like that work for you? --rchard2scout (talk) 22:10, 7 June 2019 (UTC)[reply]

Partially, thanks. Now the question is how to make "[t-Bu]₂O"? Unmatched ] inside \ce{} produces a TeX parse error. (I've also noticed that <chem>\textrm-</chem> does not fail like <chem>\text-</chem>, but yields ${\displaystyle {\ce {\textrm {-}}}}$. Where does it get these braces?!) — Mikhail Ryazanov (talk) 22:47, 7 June 2019 (UTC)[reply]

@Physikerwelt: Maybe you might have an interest in this discussion (both to advise on deprecated tags and perhaps provide a solution). --Izno (talk) 02:51, 9 June 2019 (UTC)[reply]

Well, if nobody here knows more, maybe there is a better place to ask? — Mikhail Ryazanov (talk) 06:05, 17 June 2019 (UTC)[reply]

Mikhail Ryazanov, You can try WT:CHEM/WT:CHEMICALS maybe? Galobtter (pingó mió) 06:53, 17 June 2019 (UTC)[reply]

Resolved

Cross-posting this from User talk:mxn#User:Mxn/CommentsInLocalTime since I haven't heard back. Maybe someone here can help.

I happened to come across this, and I love it. I'm just wondering if there are some further customization things I can do.

• Instead of "Last [Day]", is it possible to just have "[Day]"? So instead of Last Wednesday at 10:00 PM, just Wednesday at 10:00 PM.
• Change the date format to have the month come before the day: May 29, 2019 at 10:00 PM instead of 29 May 2019 at 10:00 PM  Resolved
• Completely disable the hover tooltip

Thanks in advance for your time. Add: Here is my page, for reference: User:Amaury/common.js. Amaury • 04:44, 7 June 2019 (UTC)

Amaury (✉) 16:21, 8 June 2019 (UTC)[reply]

Without "Last": you probably can change that through one of these: moment().calendar(referenceTime, formats), moment.updateLocale/moment.locale/[1] or moment.calendarFormat

Disable tooltips - assign to tooltipFormats value of null (or empty string '') (tooltipFormats: null), or remove tooltipFormats from configuration entirely (insert delete window.LocalComments.tooltipFormats before window.LocalComments = $.extend(window.LocalComments,... line). It may produce an empty tooltip though (tooltip is inserted as title attribute in <time> tag). MarMi wiki (talk) 19:57, 8 June 2019 (UTC)[reply]

@MarMi wiki: tooltipFormats: null removes the tooltip, but still leaves the dotted underline with the question mark when hovering over it. Any way to remove that? As for removing the "last," I am not understanding what I need or what to do. Amaury (✉) 02:30, 9 June 2019 (UTC)[reply]

@Amaury: It's like that:

//this can be moved before importScript
window.LocalComments = $.extend(window.LocalComments, {
	formats: {
		day: function (then) { return then.calendar(); },
		week: function (then) { return then.calendar(); },
		other: "MMMM D, YYYY [at] h:mm A",
	},
	tooltipFormats: null
});

//load moment
$.when(mw.loader.using('moment')).then( function(){
 moment.updateLocale('en', {
	calendar : {
     lastWeek: 'dddd'
 	}
 });
 
 //load script - it must run (not necessarily, see note below) after moment.updateLocale
 importScript( 'User:Mxn/CommentsInLocalTime.js' ); // Backlink: [[User:Mxn/CommentsInLocalTime.js]]
 //in case importScript fail (in tests I was using loader) 
 //mw.loader.load( '//en.wikipedia.org/w/index.php?title=User:Mxn/CommentsInLocalTime.js&action=raw&ctype=text/javascript' );
 //if script is loaded before moment.updateLocale, you probably could re-initialize (update) the output by manually calling the two methods which script runs after loading moment (code in loader at the bottom in CommentsInLocalTime.js) - but this may duplicate the timestamps.
})

//set text-decoration and cursor to initial values
$.when(mw.loader.using('mediawiki.util')).then( function(){
 //you can place the css (between '') in your <s>custom</s> common.css instead here
 mw.util.addCSS('time.localcomments.explain[title] {text-decoration: initial;cursor: initial;}')
})

@MarMi wiki: Thanks, but mxn has responded and provided a much simpler solution to that on their talk page. Amaury (✉) 01:15, 10 June 2019 (UTC)[reply]

Please can someone help User:QEDK fix his signature as it appears in Wikipedia:Administrators'_noticeboard#User:WMFOffice_-_Ban_Proposal and in User_talk:QEDK#Problem_with_your_sig_on_AN? It's forcing the following text to appear in a black font, which is invisible to users of the green-on-black gadget. Thanks. DuncanHill (talk) 10:46, 12 June 2019 (UTC)[reply]

The code for my signature is <span style="font-family:'Trebuchet MS',Geneva,sans-serif">[[User:QEDK|<font color="#000000">qedk<font>]] ([[User talk:QEDK|<font color="#000000">t</font>]] 桜 [[Special:Contributions/QEDK|<font color="#000000">c</font>]])</span><span style="font-family:'Trebuchet MS',Geneva,sans-serif">[[User:QEDK|<span style="color:black">qedk</span>]] ([[User talk:QEDK|<span style="color:black">t</span>]] 桜 [[Special:Contributions/QEDK|<span style="color:black">c</span>]])</span>. From what I can tell, it is definitely a drawback of the tool itself but if there is no resolution for the people using the gadget, anyone is feel free to roll back my signature to the old version. --qedk (t 桜 c) 10:54, 12 June 2019 (UTC)[reply]

See WP:SIGFONT. DuncanHill (talk) 10:58, 12 June 2019 (UTC)[reply]

@DuncanHill: Can you confirm the above signature works fine for you? --qedk (t 桜 c) 11:02, 12 June 2019 (UTC)[reply]

I can now read what follows your first signature in this thread, which I could not do before. DuncanHill (talk) 11:04, 12 June 2019 (UTC)[reply]

Sidenote: that gadget probably need some adjustment for 2017 wikitext editor (Preferences - Beta), example: Wikipedia:Signature_tutorial#Real-life_examples, try editing Real-life_examples section. With that gadget on, parts of text is hidden (black text on black background, even highlighted text is still invisible). MarMi wiki (talk) 11:13, 12 June 2019 (UTC) Scratch that - it's a syntax highlighter fault. MarMi wiki (talk) 11:22, 12 June 2019 (UTC)[reply]

• @QEDK: You still have not fixed either AN or your talk page. DuncanHill (talk) 11:23, 12 June 2019 (UTC)[reply]

I've fixed AN for you, by copying and pasting the version of your sig above over the version in the thread. DuncanHill (talk) 11:33, 12 June 2019 (UTC)[reply]

Thanks DuncanHill, I had to go out for an eye check-up and didn't have time to fix it. --qedk (t 桜 c) 11:52, 12 June 2019 (UTC)[reply]

That's OK - I found one more which I also fixed. I see you've fixed it on your talk page, thank you. I hope the check up went well. DuncanHill (talk) 11:54, 12 June 2019 (UTC)[reply]

Another 0.25 increase, which falls in the range of not-so-good, not-terrible news. Rest was fine fortunately, thanks for asking. --qedk (t 桜 c) 15:22, 12 June 2019 (UTC)[reply]

Whenever somebody updates their signature, it would be nice to have some sort of maintenance tool that ran every, say, 24 hours and updated all previous signatures to match the new change. That way, if there were any situations like this, people wouldn't have to remember to update problematic previous signatures manually. Amaury 14:15, 14 June 2019 (UTC)[reply]

Sounds nice theoretically , but [a] some users have hundreds of thousands of contributions - not all to "talk" of course, but still quite the overhead. [b] What if the change has an adverse effect on page content, such as an open tag rendering all subsequent page content bright pink or bold or gigantic etc... [c] The custom signature might contain contemporaneous content, such as a name/nickname change or a previously non-existent link that would simply be wrong/misleading if applied retrospectively. (etc...) -- Begoon 09:58, 16 June 2019 (UTC)[reply]

A manual tool/script would work great tho. --qedk (t 桜 c) 10:02, 16 June 2019 (UTC)[reply]

I suppose so - it would definitely need a bot flag because you're not going to make many friends lighting up thousands of watchlists to change a signature. I'm pretty sure, also, there have been objections to people doing this with, say, AWB - and you'd probably get similar objections to mass edits some would view as "pointless". If it's to fix an error that has a negative impact, as above, that would probably be viewed as ok, but I doubt purely 'cosmetic' alterations would be popular with some. -- Begoon 10:06, 16 June 2019 (UTC)[reply]

I would hate to think that each time I change my sig, some poor subroutine has to wade through the project to fix something that doesn't need fixing. Roxy, the dog. wooF 10:16, 16 June 2019 (UTC)[reply]

On lots of discussion forums (not all), when you view old posts you will see people's 'current' signature/avatar. This, though, is because that software doesn't save the rendered content with the post(s) like Mediawiki does, but generates it 'on the fly' each time. This comes with its own peculiarities though, such as viewing old posts with content like "that cat in your avatar is pretty" when the avatar has, by now, been updated to be a picture of "Judge Dredd", or the old post discusses signature content that has since been altered... -- Begoon 10:32, 16 June 2019 (UTC)[reply]

Unless ofcourse, it does... --qedk (t 桜 c) 10:42, 16 June 2019 (UTC)[reply]

We already have bots (such as WOSlinkerBot (talk · contribs)) that are authorised to fix signatures with problematic markup, mainly concerning missing or misplaced closing tags - for instance, if instead of this:

[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]]

I had used one of these:

[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Redrose64]]
[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Redrose64]]</span>
[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</font>rose64]]

a bot could swoop in and fix it up. Apart from that, and other changes in accordance with WP:SIGCLEAN, existing signatures should be left alone. --Redrose64 🌹 (talk) 10:49, 16 June 2019 (UTC)[reply]

I hope I'm not the only one who finds it challenging to keep up with fast-moving pages such as Wikipedia:Community response to the Wikimedia Foundation's ban of Fram. Take a few hours off to sleep and there are literally hundreds of new posts, some of which are helpfully at the bottom, but others for sensible reasons are interspersed as responses to earlier posts. It's not easy to keep current.

I do know how diffs work, so I can and did look at all changes since my best guess at the last time I looked at the page, but the formatting is less than ideal.

My question is whether there is a way to write a script or propose a change to the underlying software to make it easier to see what has been changed since my last visit. My first thought is that all new material could have a highlighted background and soft gray or yellow. As I read the new material, I could either mouse over it which would change the background to default (probably too difficult), or after reading the entire page, click the box that says this is now current and it would change the default.

While one usage for this would be for fast-moving pages such as the one identified, I can think of other uses. Because of my involvement in copyright issues I'm often removing material made by a very new editor, who might come to my talk page and ask a question. In many such cases, they don't know our protocol and drop a note at the top of my talk page. While I do get a ping to know that someone has responded, , I automatically look at the bottom of the page and seeing nothing new, presume that it's an old pain and I've already seen the relevant material. Occasionally, I stumble onto it days later. If it had a distinctive highlight, I'd be less apt to miss it.

This probably belongs in ideas if it's sensible and requires more discussion but I'm posting here on the chance there's a way to do it now and I just don't know how to accomplish it.S Philbrick(Talk) 15:20, 12 June 2019 (UTC)[reply]

It might also be simple and useful to allow users to expand their Page History display beyond the last 50 revisions. I've been using History to keep up with the updates on that page when I'm on, but if I take a break for an hour to walk the dog and water the plants, I now have a full screen of "updated since your last visit" revisions on the History display and can't just do a collective diff to the last visit. Alternatively, a one-click option to display such a collective diff of all updates since the last time an editor visited a page might not go wrong, as it would have a similar effect. (While I admit that the "difference between revisions" raw wikitext display isn't the easiest to read, it at least allows one to fairly quickly see what's changed, so...) rdfox 76 (talk) 16:22, 12 June 2019 (UTC)Stricken as moot rdfox 76 (talk) 16:39, 12 June 2019 (UTC)[reply]

When viwing page history, you should find, at both top and bottom, a row showing "(newest | oldest) View (newer 50 | older 50) (20 | 50 | 100 | 250 | 500)". Several of those are links; try them. --Redrose64 🌹 (talk) 16:27, 12 June 2019 (UTC)[reply]

Well, that's weird. Could have sworn I didn't see them last time I checked history on WP:FRAM. (I'm familiar with those from the watchlist!) Guess it's another consequence of having been still waking up when I first got on this morning. Stricken! rdfox 76 (talk) 16:39, 12 June 2019 (UTC)[reply]

If you don't visit the page, but first go to the page history, does it not say updated since my last visit on the more recent revisions? That's what I do. The information clears when you view the page, so for such pages, I usually just leave a tab open to the page history and refresh that as needed. WP:POPUPS are also helpful in following links to history without first going to the page in question. ~ Amory (u • t • c) 20:38, 12 June 2019 (UTC)[reply]

The issue with the green thing is that you know that something changed but you don't know the something. So, either you see the diffs and then Ctrl+F for the text or you just blindly try to find where it was added. The issue is problematic on very long pages where a few words might match a lot of texts and require you to substantially copy over part of the diff and require you to go through maybe one or several diffs to see what changed. Sphilbrick basically wants to see what was added in the page itself, to identify what and where it was added, and I agree, this would be an amazing tool for long and winded pages (see WP:FRAM). Especially to resolve the edit conflicts on frequently edited pages, the current resolver is plain annoying. --qedk (t 桜 c) 07:50, 13 June 2019 (UTC)[reply]

Just realized that Sphilbrick was talking about the same page. Ditto! --qedk (t 桜 c) 07:51, 13 June 2019 (UTC)[reply]

Amorymeltzer, Yes, it does, and that's better than nothing, but not exactly what I was hoping for. S Philbrick(Talk) 19:21, 13 June 2019 (UTC)[reply]

Not sure if you are aware of it, but there is a beta feature that enables a "Visual" mode versus the standard "Wikitext" mode for viewing differences between two versions. It doesn't always do a great job with large diffs, and sometimes it just hangs (typically again with large diffs, but sometimes with just a few edits, too). To enable it, go to your preferences, select "Beta features", and check "Visual differences". You will then be able to switch back and forth between visual and wikitext mode when viewing a diff. isaacl (talk) 15:41, 16 June 2019 (UTC)[reply]

Is there a way to count how many pages link to a certain page? I can use Special:WhatLinksHere to find all the links, but not obvious way to count them other than grovelling over the full list. -- RoySmith (talk) 20:54, 12 June 2019 (UTC)[reply]

XTools' articleinfo has this information (e.g., Macbeth has 4195 incoming), although if that's all you want or you want to check multiple pages quickly, the API (docs) are probably a simple way to go (e.g., Macbeth). ~ Amory (u • t • c) 21:24, 12 June 2019 (UTC)[reply]

Search can also do this; see Special:Search/linksto:"World of Warcraft". --Izno (talk) 22:32, 12 June 2019 (UTC)[reply]

And perhaps something more interesting, Special:Search/linksto:"World of Warcraft" -hastemplate:"Warcraft universe". --Izno (talk) 22:34, 12 June 2019 (UTC)[reply]

OK, that's a start, thanks. Is there some way to access that inside of a page? I looked at the list of magic words, and didn't see anything. How, for example, is "This template is used on approximately 390,000 pages." generated? I assume there's some Lua magic behind that? -- RoySmith (talk) 22:12, 13 June 2019 (UTC)[reply]

No, those are manually updated. There's talk of a bot here or there to update those, but that's hard wikitext based on one of the above methods, not magic. --Izno (talk) 00:00, 14 June 2019 (UTC)[reply]

A few minutes back I started experiencing a problem with my watchlist (desktop version): some elements, such as (diff|hist) etc are suddenly missing; the fonts of some some other elements also appear to have changed. Two quick questions for now:

• Is anyone experiencing anything similar?
• Is there an easy way for me to temporarily disable all gadgets and scripts to check if the problem is being caused by changes to any of those? I haven't added/removed any user script recently.

I'll post screenshots if I'm unable to resolve this soon. Abecedare (talk) 00:37, 13 June 2019 (UTC)[reply]

I experience the issue on both Firefox and Chrome, and even after disabling all the watchlist related gadgets. Abecedare (talk) 01:06, 13 June 2019 (UTC)[reply]

@Abecedare: please try the watchlist in safemode and see if it is the same? — xaosflux ^Talk 01:08, 13 June 2019 (UTC)[reply]

If it does, try disabling some of your user scripts from User:Abecedare/common.js and see if you can find the cause. — xaosflux ^Talk 01:10, 13 June 2019 (UTC)[reply]

@Xaosflux: Tried both. Problem persists. Abecedare (talk) 01:15, 13 June 2019 (UTC)[reply]

AFK for an hour. Will be able to try out any further suggestions after that. Thanks. Abecedare (talk) 01:20, 13 June 2019 (UTC)[reply]

I'm having the same issue on Chrome/macOS.- MrX 🖋 01:41, 13 June 2019 (UTC)[reply]

@MrX: try monobook safemode: here just to see if it is skin-specific. — xaosflux ^Talk 02:02, 13 June 2019 (UTC)[reply]

@Xaosflux: Yes, same problem with that skin.- MrX 🖋 02:26, 13 June 2019 (UTC)[reply]

For me too, on Windows 10, the problem persists with Monobook+safemode+all custom scripts disabled.

Can somebody confirm that the default ordering of fields in the watchlist is as follows? (see 'default' screenshot)

BulletPoint (diff|hist) .. EditTypeAbbr PageName Time ..(BytesChanged)..UserName(EditSummary)

In contrast, for inexplicable reasons, the ordering I now see is:

BulletPoint EditTypeAbbr Time PageName (diff|hist) ..(BytesChanged)..UserName(EditSummary)

I can learn to work with this but would prefer to go back to "normal", without the reordering and odd spacing. Also if it helps: I don't use any custom CSS'es. Page history pages appear fine. My watchlist on Commons appears fine. Abecedare (talk) 02:45, 13 June 2019 (UTC)[reply]

• In your preferences, is it all messed up still if you pick "Use non-JavaScript interface"? — xaosflux ^Talk 02:55, 13 June 2019 (UTC)[reply]

Yes.- MrX 🖋 02:58, 13 June 2019 (UTC)[reply]

Ditto. Abecedare (talk) 02:59, 13 June 2019 (UTC)[reply]

MrX I manged to resolve the problem by unchecking "Group changes by page in recent changes and watchlist" at Preferences->Recent Changes. I got the idea from this 2012 helppage and fwiw, I don't recall checking the "Group changes" preference in the first place. Can you see if this works for you too? Abecedare (talk) 03:13, 13 June 2019 (UTC)[reply]

Abecedare, yes that resolved it for me as well. Thank you for finding the solution. I don't remember selecting that option, but I can't be sure I didn't sometime in the distant past. - MrX 🖋 12:03, 13 June 2019 (UTC)[reply]

Great. Considering this broadly resolved (the finer issues can continue to be discussed at phabricator). Thanks Xaosflux, for your time and help! Abecedare (talk) 20:14, 13 June 2019 (UTC)[reply]

I recall that a wishlist item in a recent-ish survey was the ability to block a user from editing a set of articles in a given category, instead of protecting all those articles. For example, an editor could be restricted from editing all the articles in say Category:1950 films. Did this ever get implented, or did I dream it all?! Thanks. Lugnuts ^{Fire Walk with Me} 08:31, 14 June 2019 (UTC)[reply]

I think it's on the way of being implemented, but not active on enwiki yet. Certainly I can't see any special input boxes on Special:Block/Lugnuts yet (sorry, that was the first page available) Jo-Jo Eumerus (talk, contributions) 08:42, 14 June 2019 (UTC)[reply]

Development of blocking by category has been put on hold for now but blocking from specific pages has been deployed on dozen projects already. For enwiki, Wikipedia:Requests for comment/Partial blocks has not been formally started yet. – Ammarpad (talk) 10:35, 14 June 2019 (UTC)[reply]

Thank you both. I knew I'd seen something about it, but wasn't sure if it had yet gone live. Lugnuts ^{Fire Walk with Me} 12:01, 14 June 2019 (UTC)[reply]

Apologies if I'm asking a perennial (I feel I can't be the first), but I couldn't find it in my keyword search

In long lists (ones longer than the height of a normal screen), could the headers be frozen (like the top line in an Excel sheet can be), as it can involve a lot of flicking up and down to remember exactly which column is which?

Cheers,

Nosebagbear (talk) 09:53, 14 June 2019 (UTC)[reply]

There's a gadget for this but it only works on some select browsers. You can see that in Preferences → Gadgets under "Testing and development." – Ammarpad (talk) 10:26, 14 June 2019 (UTC)[reply]

That's for tables, I'm not too sure what headers of long lists means? Section headers, maybe? --qedk (t 桜 c) 10:44, 16 June 2019 (UTC)[reply]

Lists don't have headers. The (abandoned) proposed HTML 3.0 spec would have provided the LH element, but that was omitted from the HTML 3.2 spec and has not resurfaced since. --Redrose64 🌹 (talk) 11:09, 16 June 2019 (UTC)[reply]

@Redrose64: The correct HTML element in HTML 5 for a "list header" is <figcaption> paired with <figure> plus the list itself of course, but neither are supported in wikitext as either wikitext or HTML. --Izno (talk) 23:53, 16 June 2019 (UTC)[reply]

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following lists: Wikipedia technical issues and templates Wikipedia proposals When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

Currently, one of the most backlogged processes is Request an Account (ACC) , which exists mainly (though not entirely) for helping with 3 purposes: Those having trouble completing CAPTCHA; enabling the choosing of a username that is too similar to an existing username under certain circumstances & creating an account for those hindered by a rangeblock.

The current backlog on pending requests is 4 months.

In the last couple of months multiple editors have signed up to be ACC tool users, Tool users are signed up to the confidentiality agreement and meet various other criteria.

Currently here are limits, however, on both their ability to create accounts. Two options could ease their work.

1. Raise the local account creation rate limit from 4 to 10. The new limit only to extended-confirmed users to prevent any abusive behaviour from IPs.
2. Automatically grant account creator permission, on request, to new ACC tool users. This would allow them both to bypass the limit entirely, but would also let them ignore the antispoof and title blacklist when making accounts.

Pinging all participants in the local chat discussion: @Ajraddatz, FlightTime, Xaosflux, TheSandDoctor, AfroThundr, QEDK, and Oshwah: Nosebagbear (talk) 13:11, 14 June 2019 (UTC) [reply]

• NOTE: Option 2 is broader than Option 1, however they do not completely overlap. Option 1 would allow any EC-confirmed editor to create up to 10 accounts per IP address, option 2 is specifically targeted at ACC-users. Thus participants can !vote for either/both/none of the options.

• Support for option 1 only. Speaking as an ACC administrator, I believe that automatically granting all new ACC tool users the account creator user right (option 2) would open the door for new tool users to potentially handle requests incorrectly and without limitations before it's caught and identified - which would not be a good thing at all. We need to have a limit for how many accounts that new tool users can create per day by default. When a tool user shows proficiency with handling requests correctly, they can apply for and (after approval by an ACC admin via a comment made to the request) be granted the account creator flag in order to remove those limits. Option 2 would remove the need for an ACC tool administrator to give their approval before an admin can grant the user rights to the requesting user. This approval is still necessary and absolutely needed. Raising the current limit of 4 creations per day to 10 creations per day would loosen the restrictions so that users can help take care of the current backlog of requests at ACC, while still being on a set limit during the time that they're learning and demonstrating their knowledge and proficiency with ACC tool user interface. This option is the best way to resolve the concerns expressed. :-) ~Oshwah~^{(talk) (contribs)} 13:25, 14 June 2019 (UTC)[reply]
• Support for option 1; encourage ACC admins to quickly work with new ACC volunteers to get them trained and empowered with additional flags as soon as feasible. — xaosflux ^Talk 13:43, 14 June 2019 (UTC)[reply]
• Support option 1 Per above. Also, as all rights on Wikipedia are, it is granted on the basis of need for the right, inherent oppose for point 2. --qedk (t 桜 c) 13:59, 14 June 2019 (UTC)[reply]
• Support option 1 as per my comment in the previous discussion. I also agree with Oshwah on automatically granting new users the ACC bit. The current method of granting the right after a couple weeks of activity allows the team to gauge the user's performance and whether or not they have learned the policies and procedures properly. Lowering the barrier further could lead to a problematic user potentially causing a lot more damage (no rate-limit, anti-spoof override, username title blacklist override) than they otherwise could if we had to manually grant those rights. On the other hand, when all is in order, granting them the right is usually quick and painless anyway. — AfroThundr ^{(u · t · c)} 14:04, 14 June 2019 (UTC)[reply]
• Support alternate option where an group named Account creation helper is formed, which would contain only the noratelimit right.--Snaevar (talk) 14:38, 14 June 2019 (UTC)[reply]

I appreciate the idea, but I just don't see how this implementation would be useful here, or how it would resolve any issues that the account creator flag wouldn't already resolve. If an ACC admin user can trust an ACC tool user enough to have no account creation limit, that admin user should also trust the tool user enough to be able to correctly and properly handle requests that tripped the antispoof extension and require a flagged user to override (and vice versa). ~Oshwah~^{(talk) (contribs)} 14:45, 14 June 2019 (UTC)[reply]

• Support 1. After thinking about this a bit more, I'm not sure if tying the rate limit to extendedconfirmed would be possible. If not, I still think we should raise the limit, but maybe to 6 like it was before instead. The limit was lowered mainly for projects without 300 active local sysops who couldn't instantly respond to mass account creation. -- Ajraddatz (talk) 15:16, 14 June 2019 (UTC)[reply]

  Rights like PMR have increased limits for certain flags (in that case, page moves), this would just mean adding a flag like that to EC right holders. --qedk (t 桜 c) 15:23, 14 June 2019 (UTC)[reply]

  Yes, most ratelimits are determined on a per-account basis (or per IP for anonymous users). But I seem to remember account creations being different, and being specifically tied to the IP. I assume/hope that a defined higher ratelimit for extendedconfirmed would override that. And no need to tie it to a specific permission; it can be done for the group itself. -- Ajraddatz (talk) 22:58, 14 June 2019 (UTC)[reply]

  Yep, but that's a non-issue as far as devs are concerned. Delving into the issue of newer technical changes, from my experience talking to people on SRE/Deployment (and Anomie, TheDJ), technically unfeasible things are pretty rare and I have not seen requests getting turned down (rarely, if ever) with "MediaWiki does not support this", if it's a feature change, or some irreproducible bug, it's a different thing but for example, during the RfC for Template editor rights, a lot of people were worried about the tecnical changes but eventually it was done, with no big deal at all. That's how it is for most new things (and TE rights had a new protection level as well), so I would say a change would be technically feasible until a dev says exactly otherwise. --qedk (t 桜 c) 07:50, 16 June 2019 (UTC)[reply]

  With dev time almost anything is possible; my concern would be if the current software doesn't support the change, then we should be looking at easier options like raising the max number to 6 / IP as it used to be. Adding a new protection level is easy to do through the software. Fundamentally changing the account creation throttle might be more difficult. But agreed that we should ask rather than muse about things we know little about :-) -- Ajraddatz (talk) 01:03, 18 June 2019 (UTC)[reply]

• (ACC admin comment) I'm pretty sure option 1 isn't possible without development, i.e. it is not a simple configuration change. AFAICT, IP account creation limits can only be set as a count per interval with the noratelimit right being the only way for a user to bypass that limit. (mw:Manual:$wgAccountCreationThrottle) Oppose option 2 for the reasons outlined by Oshwah. Support returning the daily IP limit to 6 unless the Security Team​​ provides a good reason that it needs to remain at 4. — JJMC89 (T·C) 05:50, 15 June 2019 (UTC)[reply]

  The Security Team doesn't have a problem with bumping the IP limit from 4 to 6 or even 10, as originally proposed. SBassett (WMF) (talk) 21:32, 21 June 2019 (UTC)[reply]

• Comment. My preference would be to at least be granted access to the tool. I've waited for a week or so now. :/ –MJL ‐Talk‐^☖ 16:04, 18 June 2019 (UTC)[reply]

• @Nosebagbear: regarding your proposed options, and since this is VPT, can you explain the specific technical changes you are proposing - or is this more of a "let some developer figure it out" type of request? Is the "automatic" granting you are asking some sort of technical change you are proposing, or is it a procedural/policy change? — xaosflux ^Talk 13:24, 14 June 2019 (UTC)[reply]

  Xaosflux - If option 1 were to reach consensus, it would be corrected by filing a phab ticket to have this done. See phab:T212667. ~Oshwah~^{(talk) (contribs)} 13:27, 14 June 2019 (UTC)[reply]

  Thanks. — xaosflux ^Talk 13:29, 14 June 2019 (UTC)[reply]

  (edit conflict) @Xaosflux: - changing the rate limit is obviously possible. Whether it can be changed "in bands" to different protection levels is, I'm afraid, I query for those more technically savvy than me. If they say that's impossible (or akin), then this would need to be rethought. Nosebagbear (talk) 13:29, 14 June 2019 (UTC)[reply]

• For the problem that is trying to be solved - is overriding anti-spoof the normal resolution, or is getting them to pick a new username? — xaosflux ^Talk 13:25, 14 June 2019 (UTC)[reply]

  Xaosflux - For instances where similar usernames exist and are caught by anti-spoof, it depends. See this section of the ACC guide for the policy on when ACC tool users with the account creator flag can override the antispoof flag and proceed with creation. ~Oshwah~^{(talk) (contribs)} 13:30, 14 June 2019 (UTC)[reply]

  @Oshwah: thanks, option 1 above won't fix the antispoof ones, is that a significant part of the backlog? Just asking so we don't spend time getting something done that won't help. — xaosflux ^Talk 13:33, 14 June 2019 (UTC)[reply]

  Xaosflux - No. Requests that have tripped the anti-spoof extension make approximately 3.5% of all total requests at this time. Of those, users without the account creator flag can still see if the similar accounts are active, and decline the request if any of them are. The only time that a request requires a user with the account creator flag is when a request trips the antispoof extension and the similar accounts are all inactive. This means that the antispoof needs to be overridden, the request approved, and the account created. ~Oshwah~^{(talk) (contribs)} 13:37, 14 June 2019 (UTC)[reply]

• Why not grant Wikipedia:Event coordinator to new members of ACC? EVC will give them ability to bypass 4 account limit and it also doesn't allow overriding antispoof/title ban restrictions. ‐‐1997kB (talk) 16:36, 14 June 2019 (UTC)[reply]

  1997kB - Not a bad thought, but event coordinators can set new accounts as 'confirmed' using Special:UserRights, which is an ability that they don't need. Essentially, we'd be trading apples and oranges here if the concern is over access to some user rights they shouldn't have. As I said above, I believe that if an ACC admin can trust an ACC user to create accounts with no limit, they should also trust them to properly handle requests that tripped the antispoof extension and require a user with the account creator permissions to override and create (and vice versa). :-) ~Oshwah~^{(talk) (contribs)} 16:42, 14 June 2019 (UTC)[reply]

  @Oshwah: - I realise I agree with you, but to run with the Event-Coordinator compromise theory a bit further, it would be clearer cut - the damage possible is pretty tiny. Even if they made every account they created confirmed, it wouldn't cause a great uptick in carnage. Nosebagbear (talk) 22:36, 14 June 2019 (UTC)[reply]

  Fair point. ~Oshwah~^{(talk) (contribs)} 02:31, 15 June 2019 (UTC)[reply]

  @Oshwah: what is the expected amount of accounts to be created by "new" ACC volunteers per period? (i.e. would 6 or 8 be enough?) since the "rights they don't need" here to ECC users is expected to be way more than is needed by the relatively minuscule ACC team. — xaosflux ^Talk 16:59, 14 June 2019 (UTC)[reply]

  Xaosflux - Honestly, any increase from 4 would be beneficial. Even if the increase is just by a few... :-) ~Oshwah~^{(talk) (contribs)} 17:41, 14 June 2019 (UTC)[reply]

I think we should have a bot or some kind of tool check for accounts which are hitting the account creation limit but do not hold the rights event coordinator, account creator and are also not ACC tool users. The account creation limit was lowered for a reason and increasing it without keeping a check in place would be a gross violation of WP:BEANS imo. Thoughts, @Nosebagbear, JJMC89, Xaosflux, and Oshwah:? --qedk (t 桜 c) 14:19, 14 June 2019 (UTC)[reply]

A recurring database report may be able to solve this for you. — xaosflux ^Talk 14:27, 14 June 2019 (UTC)[reply]

If this is a major issue, the report would have to be run quite frequently, and viewed frequently by patrolling users. Otherwise, this method might not be effective enough at stopping abuse and quickly enough... ~Oshwah~^{(talk) (contribs)} 14:30, 14 June 2019 (UTC)[reply]

(edit conflict) QEDK - Doesn't sound like a bad idea to me. How would this new bot alert others that an account is hitting a limit and isn't within one of those groups? Who would this bot alert? Where? This is something that we should figure out if we're going to consider an idea like this... :-) ~Oshwah~^{(talk) (contribs)} 14:29, 14 June 2019 (UTC)[reply]

It can function the same way AnomieBot handles WP:TPERTABLE, there's no annoying notifications involved and interested people can simply watch the page and report when they find anyone suspect. --qedk (t 桜 c) 14:33, 14 June 2019 (UTC)[reply]

QEDK - Nice... I like it. :-) ~Oshwah~^{(talk) (contribs)} 14:36, 14 June 2019 (UTC)[reply]

Functionally, a bot wouldn't be able to work "that way". Also, bot's wont be able to see "that you got denied by the limit" , but a bot could periodically generate a report of "accounts created per user over some time period" and could either filter out members of certain groups or just report the groups as well. — xaosflux ^Talk 14:38, 14 June 2019 (UTC)[reply]

Why not? The logic is pretty simple, you would need to check creation logs iterating a certain period (maybe an hour) and track accounts which create another account for 24 hours at minimum and more if they somehow meet the limit each day (hence, suspect). Wikipedia accounts which do not have a similarly authorized account in ACC (or the other account creation rights as well) have demonstrably no reason to carry out actions like this, hence red-flagging them almost immediately. --qedk (t 桜 c) 14:49, 14 June 2019 (UTC)[reply]

A bot could create a report, technically it won't be able to tell if you actually got stopped by the limit, just that you hit it or approached it. It wouldn't work "the way" of the protected edit requests in that those don't mine logs, they make use of what links here/category memberships. But the output could still be made. Have a bot periodically (say hourly) ingest the user account creation log and make a report. I think it may even be helpful to have it report on everyone, or everyone with say 3+ creations - and also to identify accounts made by coordinators, etc - so they can be coached as needed. — xaosflux ^Talk 14:54, 14 June 2019 (UTC)[reply]

Yeah, I mean, technically not. But I'm saying it like the logic is clear that an account cannot make more than 10, so an account which makes 10 accounts can be construed to have hit the limit, what's important is identifying if anyone is trying to make a large number of accounts in a short period of time, hitting the actual limit is more of a formality. --qedk (t 桜 c) 15:06, 14 June 2019 (UTC)[reply]

Something like quarry:query/36938? It can't tell if they're an ACC tool user, obviously. If this query is correct, there's not a whole lot of ACC activity going on. — MusikAnimal ^talk 19:46, 14 June 2019 (UTC)[reply]

@MusikAnimal: thanks for the query, even including everyone with 3+ creations over the last whole 10 days (quarry:query/36941). I haven't checked their groups, but the impact here seems to be very small. — xaosflux ^Talk 20:07, 14 June 2019 (UTC)[reply]

Almost all ACC users in that 10+ range, minus the one event coordinator. Unfortunately I won't be appearing in that query anytime soon due to a certain rangeblock with "account creation disabled" set. Really puts a damper on ACC work... — AfroThundr ^{(u · t · c)} 01:51, 15 June 2019 (UTC)[reply]

@AfroThundr3007730: - I thought individual accounts could be exempted from rangeblocks? If so then ACC tool users would be a priority Nosebagbear (talk) 14:32, 15 June 2019 (UTC)[reply]

@AfroThundr3007730: this is a known issue, even effects admins: phab:T189362. — xaosflux ^Talk 15:16, 15 June 2019 (UTC)[reply]

@Nosebagbear: Besides IPBE, I'm not aware of any (current) facility to exempt an individual user from the effects of a rangeblock, at least not the account creation part.

@Xaosflux: - thanks, suspect it was one of those merging of facts I got while swinging around the policy pages. Clearly, I'd made a terrible nerd Nosebagbear (talk)

@Xaosflux: Yep, definitely tracking that one, and if they do get around to implementing it, I would be first in line to request IPBE so I can get back to helping in ACC. — AfroThundr ^{(u · t · c)} 18:37, 15 June 2019 (UTC)[reply]

Could use an abusefilter for this - something along the lines of Special:AbuseFilter/527. Galobtter (pingó mió) 15:33, 15 June 2019 (UTC)[reply]

The idea of granting (permanent) Event Co-ordinator rights to any ACC tool user who didn't possess Account Creator rights was mooted as a compromise. The right waives the account creation limit, and also allows accounts to be made confirmed. Obviously the latter isn't needed, but as I noted above, even if a tool-user went rogue, the maximum potential damage is significantly smaller (than the additional rights of Account Creator). It makes a good halfway house between nothing and Account Creator, and if Option 1 turns out to be inviable, then it might be the only way to significantly help with their task. Nosebagbear (talk) 18:46, 17 June 2019 (UTC)[reply]

Is it possible to attach a flaoting navbar outside of a table, but so that it aligns with the right hand side of the table? Take a look at my sandbox to see, what I'm trying to achieve. Thanks. Wikiinger (talk) 18:34, 14 June 2019 (UTC)[reply]

If you add it as a header, people with the sticky header gadget can see it. I believe position: sticky is what's needed in any element like that, and probably (!) can be achieved with the help of TemplateStyles and/or a change in local .css. --qedk (t 桜 c) 18:42, 14 June 2019 (UTC)[reply]

Actually, I want to have it below the table (forgot to mention). So I think the header is not an option (I might take it as a last resort). Also this is supposed to go on a "real" template, so a change in local .css is not an option either. Wikiinger (talk) 19:03, 14 June 2019 (UTC)[reply]

Make a template wrapper for the table and use WP:TemplateStyles. --qedk (t 桜 c) 19:19, 16 June 2019 (UTC)[reply]

Is there a tool or gadget available to get rid of all external links in an article, either by removing them entirely, transforming them into references, or converting them into wikilinks? Thanks. — Gorthian (talk) 18:58, 14 June 2019 (UTC)[reply]

WP:REFILL will do some of that. If you've got something that's already marked up as a reference (i.e. inside a <ref> tag) but it's only a bare URL, it'll build a full citation for you. But, it won't help if it's just an external link in single brackets. -- RoySmith (talk) 19:54, 14 June 2019 (UTC)[reply]

Unfortunately, the single-bracket kind are what I want to eliminate. See Steven Amsterdam, for a mild example. It’d be nice not to have to do all of it by hand. — Gorthian (talk) 20:06, 14 June 2019 (UTC)[reply]

Gorthian, I understand this doesn't respond at all to your question, but before you spend any time on it, why on earth are we permitting an article in which 86% of the content is contributed by user:Stevenamsterdam1? When the subject makes some contributions, that can be salvaged but this doesn't seem like one of the situations. S Philbrick(Talk) 18:33, 17 June 2019 (UTC)[reply]

Sphilbrick, I know. I was going to address that, too, but I’m doing too little editing these days, and hadn’t gotten to it. But I’ve run across other articles where various editors have added a plethora of external links, and have often wished for a tool like this. This was just the most recent, and handy. — Gorthian (talk) 23:30, 17 June 2019 (UTC)[reply]

Gorthian, I get it. Part of me thinks this would be a useful tool to have. Another part thinks it would be good to do a review of say 100 or so examples, to see how often the best path is conversion into a proper footnote, and how often the inclusion of such a link is more likely to mean COI, or unreliable resource, or other problems. If there are a substantial proportion of such instances the translate to salvageable content then perhaps it's worth investigating a tool to do this, but I'd like to see the stats before devoting resources. I hope you're right that this would be useful tool. S Philbrick(Talk) 00:33, 18 June 2019 (UTC)[reply]

Try Wikipedia:User scripts/Requests? Galobtter (pingó mió) 19:40, 18 June 2019 (UTC)[reply]

I haven't heard of a really good solution. mw:Citoid in the visual editor will do some of those for you, with a little effort. You'll have to copy the URL (and remove it from the spot where it doesn't belong), put your cursor where the ref tag ought to be, and paste the URL in to the tool (Command-Shift-k to open the correct dialog box). Whatamidoing (WMF) (talk) 18:10, 21 June 2019 (UTC)[reply]

In my coding I have a navigator at the top of articles to enable me to browse articles alphabetically. However it no longer seems to work fully, if I browse two or three pages the next article link doesn't appear. Can somebody help fix it so it works and two links appear at the top left and right of every page?♦ Dr. Blofeld 07:14, 15 June 2019 (UTC)[reply]

Presumably this is some kind of gadget or other script. Which one? --Redrose64 🌹 (talk) 07:19, 15 June 2019 (UTC)[reply]

I assume he's referring to User:PleaseStand/prevnext.js. That script hasn't been changed in five years, and the attached stylesheet in six years, so I assume it's been broken by either an update to Dr. Blofeld's browser, or an update to Wikipedia's API. Someguy1221 (talk) 09:26, 15 June 2019 (UTC)[reply]

Yes that's right, for some reason it's not showing after I browse a few pages. Used to fine of course.♦ Dr. Blofeld 15:59, 15 June 2019 (UTC)[reply]

An editor has been adding large tables to a number of articles, such as Plainville, Connecticut, which appears to have disrupted the layout. I tried adding "mw-collapsed" to make the tables more compact, but was not able to float the tables left. Any help would be appreciated. Thank you. Magnolia677 (talk) 17:31, 15 June 2019 (UTC)[reply]

• At Plainville, Connecticut, User:Nthep fixed the table layout with an edit summary "don't float the table - keep it in the section it belongs in". I tried this same fix at Newington, Connecticut and it worked fine, but when I also added "mw-collapsed", that feature didn't work (the "show all" was disabled). Any help would be appreciated, as User:WikiGeek0485 has added these large tables to a number of articles. Magnolia677 (talk) 10:54, 16 June 2019 (UTC)[reply]

It works with wikitable mw-collapsible mw-collapsed (as described in documentation Help:Collapsing#Collapsing_by_default), but the long title is then squeezed (spelled almost word under word). |+ class="nowrap" | Newington... prints title in one line. MarMi wiki (talk) 18:54, 16 June 2019 (UTC)[reply]

If you're wondering why float:right was removed, zoom out of that page by Ctrl+- (Control and minus key) and observe the table. MarMi wiki (talk) 19:11, 16 June 2019 (UTC)[reply]

Please observe MOS:COLLAPSE. --Redrose64 🌹 (talk) 17:50, 17 June 2019 (UTC)[reply]

We have two Wikipedia pages that bear the following titles:

• Κ-casein
• K-casein

The first one is a redirect to the second. But no typographical difference is visible to me, so I cannot say whether the page ought to be moved from the second title to the first. What am I missing? Michael Hardy (talk) 22:11, 15 June 2019 (UTC)[reply]

The first title contains a non-ASCII character for the "K", it is "GREEK CAPITAL LETTER KAPPA". power~enwiki (π, ν) 22:20, 15 June 2019 (UTC)[reply]

Yup, while the other is the standard Latin capital K. I've added an appropriate redirect category to that. --Masem (t) 22:24, 15 June 2019 (UTC)[reply]

@Power~enwiki: @Masem: How did you find out that that's what it is? Michael Hardy (talk) 23:22, 15 June 2019 (UTC)[reply]

Find a unicode converter online (numerous ones out there). Copy directly from the article titles and paste into the converter which should spit out unicode values. --Masem (t) 23:44, 15 June 2019 (UTC)[reply]

Simpler method: take the links above and reduce them to the first character only:

• Κ
• K

Then click each link in turn and see where you end up. --Redrose64 🌹 (talk) 09:38, 16 June 2019 (UTC)[reply]

They also look fairly different in the monospaced source editor, but of course not everyone uses it. ~ Amory (u • t • c) 10:32, 16 June 2019 (UTC)[reply]

That also depends on what monospaced font your browser is using. With Courier New they look the same. Eman235/talk 22:40, 17 June 2019 (UTC)[reply]

It might be better to nominate this redirect for deletion for WP:R#DELETE reason #8. Unfortunately, it looks like the editor who created this is in 2008 is no longer active and wouldn't be able to give their creation rationale. Checking pageviews, the Greek letter redirect gets virtually no traffic so does not appear to be useful BUT, as this very thread proves, it creates a maintenance burden. Jason Quinn (talk) 10:03, 20 June 2019 (UTC)[reply]

@Jason Quinn: The creation rationale is simple: the article begins "Κ-casein, or kappa casein, is a ..." - that word "kappa" (which is the Greek letter, not the sportswear manufacturer) is why. What makes you think that it's a maintenance burden? --Redrose64 🌹 (talk) 18:55, 20 June 2019 (UTC)[reply]

The (Kappa) Κ-casein redirect page makes sense and should not be deleted. It looks strange because Wikipedia articles don't begin with lowercase letters, but try the lowercase form as a link: κ-casein. Notice that wikipedia correctly resolves that to the uppercase article, (Kappa) Κ-casein, which then redirects to (Kay) K-casein, i.e. kappa casein aka κ-casein.—wing gundam 19:22, 20 June 2019 (UTC)[reply]

I used to be able to carry out uncontroversial category re-naming using the page move feature but I don't seem to able to do this any more. Is this a policy change or a technical issue?--Obi2canibe (talk) 12:23, 16 June 2019 (UTC)[reply]

Both. Per policy, categories should not be renamed except through CFD, and, as an attempt to enforce that policy, I got consensus to restrict the technical ability to move categories to page movers, admins, and bots. * Pppery * _{it has begun...} 13:04, 16 June 2019 (UTC)[reply]

OK, thanks for responding.--Obi2canibe (talk) 14:21, 16 June 2019 (UTC)[reply]

Is it not possible to move a script page? Trying to do so gives the error "[XQaN5wpAAD8AADZAmukAAAAU] 2019-06-16 18:43:52: Fatal exception of type "InvalidArgumentException" repeatedly. SD0001 (talk) 18:45, 16 June 2019 (UTC)[reply]

If you're trying to move a script page (js/css/json) in your own userspace, it is allowed (I just tried it) but you cannot move MediaWiki-namespace or other user's script pages, since you do not have the right to edit them in the first place. --qedk (t 桜 c) 19:16, 16 June 2019 (UTC)[reply]

That is obvious. I got the above error on trying to move within my userspace. Never mind, I c&p-moved it anyway. SD0001 (talk) 20:23, 16 June 2019 (UTC)[reply]

Your first sentence is a rather mean retort when your original question didn't specify where and the "rules" changed within the last year as to not being able to edit/move scripts outside your own userspace. Glad you were able to sort your problem out. Killiondude (talk) 23:14, 16 June 2019 (UTC)[reply]

This is phab:T225366. --Izno (talk) 23:56, 16 June 2019 (UTC)[reply]

A reader ( ticket:2019061710006603) reported a problem with: Portal:Computer_science

As you can see, almost all of the content is forced way to the right.

It seems to have been introduced with this edit, With the ironic edit summary "Deleted line forcing all content to the extreme right."

I see some code in the fourth and fifth lines that looks problematic but fixing this is outside my technical skills.S Philbrick(Talk) 18:09, 17 June 2019 (UTC)[reply]

[2] fails because Computer science has special code in the lead. PrimeHunter (talk) 18:24, 17 June 2019 (UTC)[reply]

Yes, the module that builds a portal page by extracting the lead section of an article (in this case Computer science) apparently cannot handle tables commenced using the {| markup. --Redrose64 🌹 (talk) 21:08, 17 June 2019 (UTC)[reply]

{{Transclude lead excerpt | Computer science | paragraphs=6}} currently works [3] but may fail later. Maybe it would be more stable to noinclude parts of the lead in Computer science. PrimeHunter (talk) 08:22, 18 June 2019 (UTC)[reply]

Hello. In the article Kurchatov, Russia reference number three shows as a bare url. However this is one of those where the bare url is in the template rather than the article. Now I have gotten pretty good at tracking these down to fix the bare url but I am flummoxed by this one. It isn't in {{Infobox Russian inhabited locality}} nor is it in {{Ru-pop-ref}} so it may be in something attached to one of them or somewhere else entirely. Any help you can give will be appreciated. MarnetteD|Talk 18:18, 17 June 2019 (UTC)[reply]

It's on Wikidata. Nardog (talk) 18:26, 17 June 2019 (UTC)[reply]

Thanks Nardog. I have not edited there before. Can I add a cite template or should I ask someone there to fix it? MarnetteD|Talk 18:30, 17 June 2019 (UTC)[reply]

The other source there has the title, publisher, and retrieved date filled in, so it seems to me one can (or should be able to) fix it by adding those attributes for the gks.ru source too. It strikes me as a defect on the infobox template's part that even though two sources are given on Wikisource, only one is shown on the infobox. Nardog (talk) 18:48, 17 June 2019 (UTC)[reply]

Steel1943 was able to figure out how to fix this. For anyone who is interested please see this thread User talk:Steel1943#Question. My thanks to Nardog and Steel1943 for their work on this. MarnetteD|Talk 19:33, 18 June 2019 (UTC)[reply]

Hello! Firstly, I would like to apologise because my request is not enwiki-related; I hope someone will have a little time for helping. I would like to create a gadget for closing AfD requests on the Hungarian Wikipedia but I have never done this before. I imagine it like c:MediaWiki:Gadget-PermissionOTRS.js with a pop-up window. Bellow you can find an example.

=== [[:19 (együttes)]] ===
{{törlés gombsor|19 (együttes)|2019-06-17}}<br />{{törlés allap útmutató}}

A legutóbbi [[Wikipédia:Törlésre javasolt lapok/19 (együttes)|törlési megbeszélés]] óta továbbra sem [[WP:NEV|nevezetes]]. – [[Szerkesztő:Balint36|balint36]] <sup>[[Szerkesztővita:Balint36|🚌 buszmegálló]]</sup> 2019. június 17., 11:21 (CEST)
*{{t}} Nem nevezetes. – [[Szerkesztő:Ary|Ary]] <sup>[[Szerkesztővita:Ary|vita]]</sup> 2019. június 17., 14:15 (CEST)

{{Tt}} // first template
Here is my reason why I closed this discussion. ~~~~ // reason

=== [[:19 (együttes)]] ===
{{törlés gombsor|19 (együttes)|2019-06-17}}<br />{{törlés allap útmutató}}

A legutóbbi [[Wikipédia:Törlésre javasolt lapok/19 (együttes)|törlési megbeszélés]] óta továbbra sem [[WP:NEV|nevezetes]]. – [[Szerkesztő:Balint36|balint36]] <sup>[[Szerkesztővita:Balint36|🚌 buszmegálló]]</sup> 2019. június 17., 11:21 (CEST)
*{{t}} Nem nevezetes. – [[Szerkesztő:Ary|Ary]] <sup>[[Szerkesztővita:Ary|vita]]</sup> 2019. június 17., 14:15 (CEST)

{{Ta}} // second template

The reason should be specific (you can write anything) or pre-filled (standard closing reasons) and the user should choose between them. The gadget should need administrator right and check that the title of the page starts with Wikipédia:Törlésre javasolt lapok/. I would be grateful if somebody could help me and create the working beta of the gadget. I believe that I will be able to work on it in the future if I have the basics. Thanks in advance! Best regards, Bencemac (talk) 19:47, 17 June 2019 (UTC)[reply]

@Bencemac: I can help try to help out. Give me a few days for a beta version DannyS712 (talk) 00:14, 18 June 2019 (UTC)[reply]

Thank you very much! Bencemac (talk) 06:53, 18 June 2019 (UTC)[reply]

20:37, 17 June 2019 (UTC)

Does anyone know why CAT:CSD shows Category:Candidates for uncontroversial speedy deletion containing 40 more pages than are actually in the category when you open it? I've got a feeling I've asked this before but can't find it. GoldenRing (talk) 09:03, 18 June 2019 (UTC)[reply]

Yeah, it's been ongoing for a while:

• Wikipedia:Village_pump_(technical)/Archive_169#Something_strange_at_Category:Candidates_for_speedy_deletion
• Wikipedia:Village_pump_(technical)/Archive_169#Category_count_wrong
• Wikipedia:Village_pump_(technical)/Archive_170#Non-backlog_category_with_template
• Wikipedia:Village_pump_(technical)/Archive_171#CAT:CSD_admin_backlog
• Wikipedia:Village_pump_(technical)/Archive_173#CSD_categories

See phab:T221795 and phab:T18036 (and duplicates: phab:T202833, phab:T195397, and phab:T200402). I'm sure it's come up elsewhere as well. ~ Amory (u • t • c) 10:29, 18 June 2019 (UTC)[reply]

@Amorymeltzer: Hmmm, okay, thanks. Not something that's going to fixable in the short term, then. GoldenRing (talk) 12:29, 18 June 2019 (UTC)[reply]

I want to find all my subpages, except for the ones under User:RoySmith/drafts/. I see mention on WT:Special:PrefixIndex of a grep tool (which now seems to live at https://tools.wmflabs.org/grep/), but that's either broken, so so slow as to appear broken. Any better ideas? -- RoySmith (talk) 17:52, 18 June 2019 (UTC)[reply]

There might be a tool for it around somewhere, but it was faster to use a blunt instrument than to go looking for one. —Cryptic 19:38, 18 June 2019 (UTC)[reply]

Also, there are so few pages that just going to Special:PrefixIndex/User:RoySmith reveals all the pages, and since they are sorted the ones you don't want are all lined up anyway. — xaosflux ^Talk 19:48, 18 June 2019 (UTC)[reply]

Ewww. Token-sucking. Risker (talk) 20:32, 18 June 2019 (UTC) Please pardon the drive-by gross-out[reply]

Yeah, well, but it'll make a great DYK hook :-) -- RoySmith (talk) 16:04, 19 June 2019 (UTC)[reply]

Special:Search/intitle:/RoySmith/ -intitle:/RoySmith\/drafts/ seems to work when set to the User namespace also. Curiously, Special:Search/intitle:/RoySmith\// -intitle:/RoySmith\/drafts/ does not. --Izno (talk) 20:45, 18 June 2019 (UTC)[reply]

I'm trying to track down changes to Anna Pavlova and am getting no hits at all. Has one of the software changes broken the "find additions and removals" tool? Yngvadottir (talk) 04:19, 19 June 2019 (UTC)[reply]

Yep, seems to be broken. I just tried several searches on a completely different article and they all came up "0 versions found" even though the words are in the article. Softlavender (talk) 06:08, 19 June 2019 (UTC)[reply]

Yep. Tried it just a few minutes ago. We really need it fixed, among other things it let's us find out when copyvio was added. Doug Weller talk 14:55, 19 June 2019 (UTC)[reply]

Have you tried the RevisionSlider feature as an alternative? --Redrose64 🌹 (talk) 19:59, 19 June 2019 (UTC)[reply]

I find that incomprehensible I'm afraid, and it sounds like an exercise in dexterity? I wanted to know when "little toe" entered the article, surely a search function? Yngvadottir (talk) 20:04, 19 June 2019 (UTC)[reply]

It's been reported to the author here: de:Benutzer Diskussion:Flominator/WikiBlame#WIkiblame down? --AntiCompositeNumber (talk) 20:12, 19 June 2019 (UTC)[reply]

Oh good, I couldn't figure out who to report it to. I see my guess was right as to the cause. Yngvadottir (talk) 04:15, 20 June 2019 (UTC)[reply]

It's fixed! About to thank Flominator, although the test revealed a weakness in articles with this much history - it returned the 2010 restoration of the vandal string rather than the 2008 insertion (I searched manually from the start of the history). Yngvadottir (talk) 21:15, 20 June 2019 (UTC)[reply]

Hi. I've recently started working on a script to create a global watchlist, and have hit a snag. Using the watchlist API, I can retrieve a user's (filtered) watchlist on the same wiki. If you install User:DannyS712 test/watch demo.js, at Special:BlankPage/Global you should see a string version of the RSS feed of your personal watchlist. But, I have been unable to figure out how to retrieve that RSS feed using the API for your watchlist on another site (e.g. meta). Can anyone help? --DannyS712 (talk) 06:18, 19 June 2019 (UTC)[reply]

DannyS712, You should use mw:ResourceLoader/Core_modules#mediawiki.api, and use mw.ForeignApi to communicate with the API of another wiki. Quick note if you don't know that there is a crosswatch tool but it is broken. Galobtter (pingó mió) 07:53, 19 June 2019 (UTC)[reply]

@Galobtter: I tried, and it didn't work - I read through mw:API:Cross-site requests before I came here --DannyS712 (talk) 08:08, 19 June 2019 (UTC)[reply]

Hmm, quick testing with:

var api = new mw.ForeignApi( 'https://meta.wikimedia.org/w/api.php' );
api.get( {
    action: 'feedwatchlist',
    format: 'json'
} ).always( (arguments) => { console.log(arguments); });

just gives a result of "http", no idea why - sorry, can't help. Galobtter (pingó mió) 09:34, 19 June 2019 (UTC)[reply]

Attempting the same code with mw.Api() instead of mw.ForeignApi( 'https://meta.wikimedia.org/w/api.php' ); also gives the same response "http". Looks like a phab ticket needs to be filed. SD0001 (talk) 15:25, 19 June 2019 (UTC)[reply]

@DannyS712: Use action: 'query', format: 'json', list: 'watchlist'. Works with mw.ForeignApi as well (you have to be logged in obviously, which someone who is using the script will be). It doesn't use RSS feeds but actual JSON, which should be easier to deal with. The RSS feed is also restricted using watchlist tokens, and each wiki has a unique token, so there's that too. --qedk (t 桜 c) 15:37, 19 June 2019 (UTC)[reply]

@QEDK: Wow - that'll make it so much easier. I didn't realize the watchlist "list" existed. Thanks, --DannyS712 (talk) 09:01, 20 June 2019 (UTC)[reply]

Glad to be of help. --qedk (t 桜 c) 09:32, 20 June 2019 (UTC)[reply]

@DannyS712: Using jQuery.get works fine for me:

$.get('//meta.wikimedia.org/w/api.php', {
	action: 'feedwatchlist',
    format: 'json',
	origin: 'https://en.wikipedia.org',
    wlowner: 'yourUsername',
    wltoken: 'yourWatchListToken' (will have to grab this manually, no automated way I think)
}, e => console.log(e));

SD0001 (talk) 15:39, 19 June 2019 (UTC)[reply]

I am getting a not logged in error (I am logged in). Just a guess but using BotPasswords and lgname, lgpassword, lgtoken, it should work. --qedk (t 桜 c) 15:43, 19 June 2019 (UTC)[reply]

Oh yeah, didn't notice the error earlier. SD0001 (talk) 15:56, 19 June 2019 (UTC) Updated above. now works. SD0001 (talk) 16:03, 19 June 2019 (UTC)[reply]

Yeah, getting not logged in error too. Trying to follow mw:Extension:CentralAuth/API#centralauthtoken to be logged in, and:

api = new mw.Api();
token = await api.get({action: 'centralauthtoken'}).then( token => { return token.centralauthtoken.centralauthtoken });
watched = await $.get('//meta.wikimedia.org/w/api.php', {
	action: 'feedwatchlist',
	format: 'json',
	origin: 'https://en.wikipedia.org',
	centralauthtoken: token
}, e => console.log(e));
var serial = new XMLSerializer();
var watchedString = serial.serializeToString( watched );
console.log(watchedString);

gets a bad token error. I mean, you should be able to be logged in on the other wiki and access the watchlist that way (the wltoken is really for accessing another person's watchlist and you'd need to manually enter the token for every wiki..). Galobtter (pingó mió) 16:32, 19 June 2019 (UTC)[reply]

You have to use login via POST (works on all sites) or use the wluser/wltoken method (limited to the watchlist wiki), that's all the API supports. --qedk (t 桜 c) 16:58, 19 June 2019 (UTC)[reply]

Galobtter, are you getting not logged in error even after entering the wltoken (of the target wiki, in this case meta)? That shouldn't happen. SD0001 (talk) 17:47, 19 June 2019 (UTC)[reply]

SD0001, I tested the version before it was edited to add wltoken; haven't tested with wltoken but definitely that should work, but it doesn't actually log you in ofc. Galobtter (pingó mió) 18:00, 19 June 2019 (UTC)[reply]

@QEDK: you marked this as resolved, but I converted it to a link - another problem came up. The foreign api part is working, but I can't retrieve the watchlist token for the foreign site (it always returns "+\") - can anyone help? The full code is at User:DannyS712 test/watch.js, and I added comments to clarify my intentions --DannyS712 (talk) 23:06, 20 June 2019 (UTC)[reply]

@DannyS712: Are your session cookies being sent to the "foreign" site? I think you need to set xhrFields: {withCredentials: true} for the $.get() request in getToken() for that to happen. Alternately, use ForeignApi for that part as well, which (I'm guessing) does this for you. Suffusion of Yellow (talk) 00:53, 21 June 2019 (UTC)[reply]

@Suffusion of Yellow: I switched to the ForeignApi for getting the token, and now I'm getting a token, but it keeps raising the error bad_wltoken when I try to use it DannyS712 (talk) 01:20, 21 June 2019 (UTC)[reply]

@DannyS712: Ok, it looks like the "watchlist token" in your preferences is not same one that's returned by api.php?action=query&meta=tokens&type=watch. I can't find a way to retrieve the first one for a foreign site. But, oddly, I tried removing the wlowner and wltoken parameters entirely, at it worked! I even have third-party cookies blocked. So I'm guessing that the centralauthtoken that's automagically added by ForeignApi is the only token that's needed. Suffusion of Yellow (talk) 02:28, 21 June 2019 (UTC)[reply]

@Suffusion of Yellow: thanks so much, to you and Galobtter and QEDK - see version 1.0 of the script: User:DannyS712/Global watchlist! DannyS712 (talk) 03:22, 21 June 2019 (UTC)[reply]

Looks great! When I was testing using the 'watchlist' list API, it didn't have any more necessary provisions, and it worked fine for me (and it looks like it still does), hence my edging you on to use this one which doesn't need hardcoded tokens. --qedk (t 桜 c) 05:32, 21 June 2019 (UTC)[reply]

DannyS712, nice work! Galobtter (pingó mió) 17:27, 21 June 2019 (UTC)[reply]

Is this meant to be an alternative to CrossWatch? I believe mw:User:OriHoch was hoping to get that working again.[8] Whatamidoing (WMF) (talk) 18:45, 21 June 2019 (UTC)[reply]

I have had a *large* number (almost half my edits) of incorrect "Edit Conflicts" over the last week or so. In these cases, often no one has edited the article in months, but my edit comes up as an edit conflict between the current version and my change. I wasn't seeing this prior to last week. I'm running Google Chrome, though I'm not sure that affects things.Naraht (talk) 15:12, 19 June 2019 (UTC)[reply]

+1 --qedk (t 桜 c) 16:39, 19 June 2019 (UTC)[reply]

Is it possible that you double-clicked the "Publish changes" button, thus sending the save request twice and so edit-conflicting with yourself? One of my old mice was faulty, the left button developed a bounce which caused a number of unwanted double-clicks. --Redrose64 🌹 (talk) 20:02, 19 June 2019 (UTC)[reply]

Naraht, I've seem some, one a minute ago to my own subpage User:Sphilbrick/Fram. Definitely not a conflict. I don't think I double-clicked, but will pay close attention next time S Philbrick(Talk) 12:47, 20 June 2019 (UTC)[reply]

Naraht, And I got another one, while fixing a typo in my past reply. S Philbrick(Talk) 12:49, 20 June 2019 (UTC)[reply]

Happens with me too, occassionally. Some undeniably because of double presses, but I am immediately aware when I do that and this issue occurs even with just one click. Sometimes, just my own diff is shown in the edit conflict resolver. --qedk (t 桜 c) 14:36, 20 June 2019 (UTC)[reply]

Occasionally doesn't surprise me, and getting them <5% of the time it would be reasonable. Getting them *half* the time, OTOH is a bit odder.Naraht (talk) 15:56, 20 June 2019 (UTC)[reply]

I'd like to know if there is any bot or tool that can help me finding old vandalazing editions in a WP file history. Thanks. --Jotamar (talk) 23:56, 19 June 2019 (UTC)[reply]

I was wondering if there was a way to access DEFAULTSORT from module code? The page Wikipedia:Comparable Lua functions to wikitext#Technical metadata has no information for this specific issue, and Template:DEFAULTSORT says not to use the template, which means that I can't use frame:expandTemplate. Is there any other way? --Gonnym (talk) 08:43, 20 June 2019 (UTC)[reply]

Solved using frame:preprocess{text = "{{DEFAULTSORT:" .. sortKey .. "}}"}. --Gonnym (talk) 09:38, 20 June 2019 (UTC)[reply]

Better would be to use frame:callParserFunction( 'DEFAULTSORT', sortKey ). See the manual for details. Anomie⚔ 22:00, 20 June 2019 (UTC)[reply]

Resolved

Not sure where to report this, but the Flickr upload tool doesn't seem to be working. Thanks! Magnolia677 (talk) 10:39, 20 June 2019 (UTC)[reply]

Ah, it's been moved to [9]. Magnolia677 (talk) 16:31, 20 June 2019 (UTC)[reply]

But still not working. Magnolia677 (talk) 19:25, 20 June 2019 (UTC)[reply]

Magnolia677, I've never heard of that tool, but have you tried c:Commons:Flickr2Commons? GMG^talk 19:27, 20 June 2019 (UTC)[reply]

@GreenMeansGo: It's a wonderful tool that lets you enter a Flickr URL, and then it sucks the information from Flickr and enters it onto a Commons upload page. It even flags questionable copyrights. I'll try the Commons site you mentioned. Cheers. Magnolia677 (talk) 20:29, 20 June 2019 (UTC)[reply]

Hello everyone, What should i do to create an mediawiki extension on ours Wikipedia? To learn me, please advice me with [10] Thanks! ⇒ AramTalk 18:42, 20 June 2019 (UTC)[reply]

mw:Manual:Developing_extensions --qedk (t 桜 c) 18:52, 20 June 2019 (UTC)[reply]

I assume ئارام بکر is inquiring about how to enable ORES extension on their home Wikipedia, not about coding new extension. To enable ORES on your wiki, you have to make a request on Phabricator and link to local community consensus for that. Read mw:How to report a bug for the step-by-step guide and see example of similar request. – Ammarpad (talk) 05:47, 21 June 2019 (UTC)[reply]

The LaTeX math tag gives a generic "syntax error" if any non-ASCII unicode characters are present,

Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "http://localhost:6011/en.wikipedia.org/v1/":): {\displaystyle x+1±y}

and requires a command instead (\pm here),

${\displaystyle x+1\pm y}$.

This behavior isn't generic to all online LaTeX implementations (e.g. Stack Exchange's happily accepts any unicode character). But I occasionally run into very long formulae with this error, and it can be difficult to trace the cause. It also impedes normal editing and formula creation for those who haven't memorized the LaTeX command for every character.

Given that unicode keyboards are ubiquitous, even on phones, could the parser be modified to produce a helpful debugging error that identifies the first out-of-range character and suggests the right LaTeX command? Or better yet, can we simply modify it to accept unicode characters? —wing gundam 19:38, 20 June 2019 (UTC)[reply]

Accepting Unicode characters is basically phab:T50032. --Izno (talk) 20:38, 20 June 2019 (UTC)[reply]

Hmm outright accepting unicode characters would be nice. There are even some latin/greek characters like ƛ (used in physics) that are literally impossible to display in wikipedia math tags right now (compare ${\displaystyle {\bar {\lambda }}}$). Is this planned? —wing gundam

The age of the task is more than a few years old. I guess it's non-trivial. We probably should have some page about how specialist (or hard) things don't really get worked on unless the WMF gets to it. --Izno (talk) 00:41, 21 June 2019 (UTC)[reply]

I often come to WP articles on my phone from Google searches, and I want to find the relevant snippet in the article but all the sections are collapsed. Currently I just tap expand on every one, from bottom to top then I use the mobile browser find feature. Would be nice if there was a single button to expand all. --LaserLegs (talk) 23:15, 20 June 2019 (UTC)[reply]

If you look at the very bottom of the page, there should be a link to "Desktop view" and that's what I look at when I read Wikipedia on my phone. You have to expand the sections you want to read because a lot of information is crammed into a small screen but I prefer it to the mobile version of the site. Liz ^{Read! Talk!} 23:27, 20 June 2019 (UTC)[reply]

This is available in mobile settings. Navigate to Special:MobileOptions and toggle the button for "Expand all sections." Note: the option is only visible on mobile, you won't see it if you follow the link on desktop even if mobile subdomain is explicitly requested. – Ammarpad (talk) 05:37, 21 June 2019 (UTC)[reply]

I have an insanely large number of pages on my Watchlist because I opted for adding every page I edited on to it (think twice about doing this). So, over the past year, I have tried several times to edit it. I always get a failed message for Special:EditWatchlist stating:

Wikimedia Error

Our servers are currently under maintenance or experiencing a technical problem. Please try again in a few minutes.

See the error message at the bottom of this page for more information.

If you report this error to the Wikimedia System Administrators, please include the details below.

PHP fatal error:

entire web request took longer than 60 seconds and timed out

I admittedly have an old laptop and sometimes the page times out when it tries to load any random page from Wikipedia. I just reload the page and, ta-da! No problem. But I've gotten this error message every single time I've tried to edit my Watchlist. I did a quick search of the archives to see if this was a recurring problem and nothing from the first 20 search results popped out as being similar to my problem.

So, is this likely my old computer, the enormous size of my Watchlist or do editors generally not bother editing their Watchlists? If there was an alternative way of removing pages, that information would be welcome, too. Thanks in advance. Liz ^{Read! Talk!} 23:25, 20 June 2019 (UTC)[reply]

@Liz: try to edit it using this link. — xaosflux ^Talk 23:28, 20 June 2019 (UTC)[reply]

If you can read it, but can't save it you can try this link: Special:EditWatchlist/clear to delete your entire watchlist, then you can recreate it in that 'raw' format above by pasting it back in. — xaosflux ^Talk 23:30, 20 June 2019 (UTC)[reply]

There's also User:Anomie/unwatch.js, which adds an unwatch button ("(diff | hist)" to "(diff | hist | unw)") next to entries on your watchlist. It's not good for mass removal, but does the job for stuff that actually shows up in your watchlist. Eman235/talk 02:56, 21 June 2019 (UTC)[reply]

@Eman235: This is built into MediaWiki now. There's an "Add direct unwatch/watch markers (×/+) to watched pages with changes" option in Special:Preferences#mw-prefsection-watchlist. Not to downplay Anomie's script, which I enjoyed for many years :) — MusikAnimal ^talk 03:46, 21 June 2019 (UTC)[reply]

Anomie's script has a nice little sorting option though. Headbomb {t · c · p · b} 04:15, 21 June 2019 (UTC)[reply]

The error is server-side, so it's not the fault of your computer. The fix is being tracked at phab:T220245. the wub "?!" 19:33, 21 June 2019 (UTC)[reply]

I would like to use this script when reviewing pending changes. However, when I see the pending changes, it only shows the diff, not the article with the changes implemented. Can an editor edit the my script so that it shows both the diff and article with the changes implemented? I don't know how to do it myself so I am asking for help. Interstellarity T 🌟 10:08, 21 June 2019 (UTC)[reply]

Not me, but DannyS712 can. --qedk (t 桜 c) 19:42, 21 June 2019 (UTC)[reply]

Something changed in the past week or two that makes it difficult to see deleted pages. For example, if I go to Special:DeletedContributions/Peacefulmark, then click on "Draft:Eyeglasses.com", that links to https://en.wikipedia.org/w/index.php?title=Draft:Eyeglasses.com&action=edit&redlink=1 which gets me to a screen where I'm already in the visual editor, with a notice, "Wikipedia does not have a page with this exact title...".

The problem is that if I click the notice box closed, I'm left editing Draft:Eyeglasses.com. There's a line that says, "View or restore 2 deleted edits", but that's greyed out, so I can't click it. The best I've found so far is to then switch to source editing, where the "2 deleted edits" link is now clickable.

Any idea what's changed? As far as I remember, I used to just get dropped into the source editor when clicking on a redlink. Did something change globally to make VE the default? Or is it more likely that I accidentally changed some preference setting? -- RoySmith (talk) 13:31, 21 June 2019 (UTC)[reply]

@RoySmith: after dismissing the banner, in the top right if you click on the pencil icon and change to source editor is it normal again? — xaosflux ^Talk 14:23, 21 June 2019 (UTC)[reply]

The same happened to me but I clicked the article tab and it reverted to the old state and now it does not happen anymore. Weird... Regards SoWhy 14:28, 21 June 2019 (UTC)[reply]

Ah, I'm starting to see what's happening. If you're in the visual editor (no matter what route you took to get there), the "View or restore 2 deleted edits" line is always greyed out. And, what seems to be going on is that it's remembering which editor I used last, and using that. So, if the last thing I edited was using VE, then I get dropped into VE and see the greyed-out link. Under Special:Preferences#mw-prefsection-editing / Editor / Editing mode, there's an option to select "Remember my last editor". I don't have that selected, but it's acting as if I did. I've got "Show me both editor tabs" selected. Changing that to "Always give me the source editor" fixes this problem, except that I do find it useful to have both editing tabs available. I know I can switch back and forth via the pencil icon, but the two tabs is handy. At this point, I'm not sure if how things work has actually changed recently, or if I've just started noticing this. -- RoySmith (talk) 15:42, 21 June 2019 (UTC)[reply]

I've opened T226267. -- RoySmith (talk) 15:44, 21 June 2019 (UTC)[reply]