Tech

Tech Forum

Tech News

Tech Ambassadors

Wikimedia Technology

Wikimedia Product

MediaWiki

For faster (real-time) interaction, join the #wikimedia-tech IRC channel.

Archives

---

2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021

A place to talk about tech related to a Wikimedia wiki.

Have a technical wiki question? Ask here. This can include for example:

• requests for new tools, scripts, and bots;
• help with CSS or JavaScript;
• API help;
• and data collection help (including database queries).

Ask a question

Please sign by entering four tildes (~~~~) or by clicking on the signature icon ; this will automatically produce your name and the date.

Problem with accented french characters sort

Hello, I have tried several things to resolve the problem I am having, but without success. My pages starting with É end up at the end of other pages, which is wikimedia's default sort order. How to sort, so that the É are considered as E? I tried to reenter the line mw.config.set ('tableSorterCollation', {'É': 'E', 'é': 'e', ​​'ä': 'ae', 'ö': 'oe', 'ß': 'ss' , 'ü': 'ue'}); in my common.js, but it doesn't work, just like I declared $ wgCategoryCollation = "uca-fr"; in my Localsettings.php, but it doesn't work either ... I have the same problem with words that are in capitals like AKTO, which are found before other words and therefore not well sorted ... Can you help me please ? Thank you very much. Benoit -- 07:08, 21 March 2021 (UTC)

Are you talking about a Wikimedia wiki or your own MediaWiki installation? What page content language are you using? Nemo 07:49, 21 March 2021 (UTC)

My own Mediawiki installation. I'm very sorry, I'm a beginner on Mediawiki. By the way, I don't know if I post my question in the good place for it...

It's a wiki for training organization in France because we have so many interlocutors that the small structures (like me), we are lost. You can see the problematic page here. At the start and at the end of the sort.

https://forma-wiki.fr/index.php/Sp%C3%A9cial:Toutes_les_pages

Thank you very much.

This page is for tech questions related to Wikimedia Foundation wikis, although sometimes people are kind enough to help those in need with other questions. A better target board might be mw:Project:Support desk. Killiondude (talk) 23:04, 21 March 2021 (UTC)

Reflinks down

Hi all. Reflinks have been down for about a week now which is impeding the ability to edit freely. Would anyone be able to assist with fixing it please? When you run it, the script comes up with:

<type 'exceptions.MemoryError'> Python 2.7.6:

Mon Mar 29 18:15:47 2021 A problem occurred in a Python script. Here is the sequence of function calls leading up to the error, in the order they occurred.

/home/dispenser/public_html/cgi-bin/webreflinks.py in () 1489 <script src="/~dispenser/resources/reflinks.js" type="text/javascript"></script> 1490 """) => 1491 main() 1492 finally: 1493 wikipedia.endContent() main = <function main> /home/dispenser/public_html/cgi-bin/webreflinks.py in main() 1406 """) 1407 bot = ReferencesRobot(site, generator, always, limit or 20) => 1408 bot.run() 1409 1410 if __name__ == "__main__" and wikipedia.handleUrlAndHeader(): bot = <__main__.ReferencesRobot instance>, bot.run = <bound method ReferencesRobot.run of <__main__.ReferencesRobot instance>> /home/dispenser/public_html/cgi-bin/webreflinks.py in run(self=<__main__.ReferencesRobot instance>) 871 Runs the Bot 872 """ => 873 deadLinks = codecs.open(listof404pages, 'r', 'latin_1').read() 874 socket.setdefaulttimeout(30) 875 for page in self.generator: deadLinks undefined, global codecs = <module 'codecs' from '/usr/lib/python2.7/codecs.pyc'>, codecs.open = <function open>, global listof404pages = '404-links.txt', ).read undefined /usr/lib/python2.7/codecs.py in read(self=<open file '404-links.txt', mode 'rb'>, size=-1) 666 def read(self, size=-1): 667 => 668 return self.reader.read(size) 669 670 def readline(self, size=None): self = <open file '404-links.txt', mode 'rb'>, self.reader = <open file '404-links.txt', mode 'rb'>, self.reader.read = <bound method StreamReader.read of <open file '404-links.txt', mode 'rb'>>, size = -1 /usr/lib/python2.7/codecs.py in read(self=<open file '404-links.txt', mode 'rb'>, size=-1, chars=-1, firstline=False) 472 data = self.bytebuffer + newdata 473 try: => 474 newchars, decodedbytes = self.decode(data, self.errors) 475 except UnicodeDecodeError, exc: 476 if firstline: newchars undefined, decodedbytes undefined, self = <open file '404-links.txt', mode 'rb'>, self.decode = <built-in function latin_1_decode>, data = '$100,000 Challenge\thttp://thefoolsparadise.com/d...ts Applications to Theorem Proving\t404\tNot Found\n', self.errors = 'strict' <type 'exceptions.MemoryError'>: args = () message =

/home/dispenser/public_html/cgi-bin/tracebacks/webreflinks_MemoryError_1491_u3mvZh.html contains the description of this error.

If anyone can assist that would be great. The C of E (talk) 18:20, 29 March 2021 (UTC)

@The C of E: What are reflinks? How to reproduce somehow somewhere? Where's that output above from? Please provide some context. --AKlapper (WMF) (talk) 07:41, 30 March 2021 (UTC)

@AKlapper (WMF): Apologies, I thought everyone knew about the editing tool. It's something that automates the filling in of bare links in references. This is the tool here. At the moment if you try to run it on a page, you get the above code. It has been mentioned on the English Wikipedia's technical page as something that badly needs fixing. The C of E (talk) 07:45, 30 March 2021 (UTC)

Whoever operates the website at http://69.142.160.183 (probably Dispenser) needs to be contacted; as far as I understand that's not a Wikimedia domain/website (https://reflinks.toolforge.org/ would be). --AKlapper (WMF) (talk) 09:42, 30 March 2021 (UTC)

en.m.wiktionary Header sections always not collapsed and always expanded

This is on one of the biggest and oldest projects on Wikimedia.

On mobile site, the header sections which are usually collapsed on other wikis, always appear expanded on this wiki.

Our readers are complaining about this issue. Sections can be very long and always-expanded sections are hard to read. Links to a section don't position correctly, because the link first goes to the section, then all sections expand after that which makes useless the positioning that happens just before.

Would like guidance on what is causing this, and what can be done to correct this behavior. 119.56.97.84 17:35, 31 March 2021 (UTC)

Answer at wikt:Wiktionary:Grease pit/2021/March#Wiktionary:Information_desk/2021/March#Always_minimize_all_sections_(mobile_version) (I’d appreciated if you’ve given the link, though). —Tacsipacsi (talk) 19:46, 1 April 2021 (UTC)

@Tacsipacsi: So it was a change on Phabricator. Thank you very much for getting the decision for us. And also for visiting our forum (sorry that I did not think to bring it back).

For us, would need a look on how many pages this seriously affects (as a percentage), to decide if something needs to be done. I do note that it affected your reading wikt.

Mobile view has been more neglected even though more people are reading on mobile. It is sad when many editors still stay with desktop view because mobile view is still difficult to use. 119.56.100.135 07:05, 2 April 2021 (UTC)

If there is community consensus to change an existing configuration setting for a Wikimedia website, then please see Requesting wiki configuration changes how to proceed (plus include a reference to phab:T63447). Thanks! --AKlapper (WMF) (talk) 12:17, 2 April 2021 (UTC)

en.wiktionary Lua errors happen often on Long Pages

This is a big WM project.

Often on en:wiktionary:Special:LongPages, the pages on this list end up with Lua memory errors partway down the page.

It happens for some people and some times, and not for others. Quite often enough to be concerned.

Can the situation be improved? The community tech forum is at Project:Grease pit.

Thank you119.56.97.84 17:43, 31 March 2021 (UTC)

This sounds like phab:T165935 and phab:T267708. The situation can be improved by having shorter pages, more performed Lua modules, or maybe maybe by updating the Lua stack on Wikimedia servers (I'm not sure about the latter, would need investigation). --AKlapper (WMF) (talk) 12:13, 2 April 2021 (UTC)

Allowing interface admins to delete sitewide CSS/JS/JSON

On Chinese Wikipedia, interface admins are not required to be an admin. And we find that both user groups are needed to delete a CSS/JS/JSON page in MediaWiki namespace. That's weird. Since allowing admins to delete such pages seems impossible according to previous Phabricator tasks, is it reasonable if we allow interface admins to delete them? Here is the related discussion. Lt2818 (talk) 16:34, 7 April 2021 (UTC)

@Lt2818: The deletion right applies to all pages, so if you give interface administrators right to (un)delete CSS/JS pages, they will be able to do so with any other page: articles, help pages etc. (Normal admins should be able to (un)delete JSON pages, as they are considered to be safe.) I don’t know if system administrators are willing to do this, but if you voted on this (and not only on allowing them to do so with CSS/JS pages), then I don’t know why they would reject your request. (By the way, as far as I see, all but one interface administrators are administrators as well, so I don’t think this to be a serious issue.) —Tacsipacsi (talk) 23:34, 7 April 2021 (UTC)

@Tacsipacsi, adding further permissions to the interface-admin group is prohibited by the sysadmins according to Limits to configuration changes. I guess MediaWiki could be patched to further granularize deletion permissions and add a user right that lets users delete sitewide CSS/JS/JSON pages, assigning them to the interface-admin group globally. I am not a developer so I am not sure if that is desired, and if so, whether it'd be easy to do or a total pain. Best regards. —MarcoAurelio (talk) 11:06, 8 April 2021 (UTC)

@MarcoAurelio and Lt2818: Actually that document doesn’t state that interface editing rights should not be given to normal administrators, although I’m pretty sure that’s the case… Anyways, nothing there forbids the creation of a “deleter” user group, which could be given to interface admins who are not admins. Of course, the considerations about the lack of namespace restriction still stand.

I think it should possible to create a namespace-restricted deletion right (e.g. when this comment saying This code [i.e. the method responsible for the deletion form and authorization] desperately needs to be totally rewritten is resolved), but it will likely cause some headaches—for example, it’s not enough to control whether one can delete, it should also control whether one sees the delete tab, whether they can see deleted revisions with all their links, whether they can restore (links should be cared for here as well) etc. —Tacsipacsi (talk) 19:44, 8 April 2021 (UTC)

Interface admins were not intended to be a standalone group. They were thought of as admins with some additional rights. Ruslik (talk) 11:28, 8 April 2021 (UTC)

@Ruslik0: Why do you think so? Interface administrators doesn’t state anything like this. Also, before the introduction of interface admins, several wikis had an interface editor user group, which was exactly what interface admins are today—rights to edit all pages in the MediaWiki namespace, but no other admin rights. The two have simply nothing to do with each other except for both being highly trusted groups—normal admins mostly work with people (requests for deletions, blocks etc.), while interface administrators work with code. For example I happily do interface administrator tasks on huwiki, but I don’t want to become an admin (although I was asked several times), as I don’t want to take the responsibility of working with people at that level. —Tacsipacsi (talk) 19:44, 8 April 2021 (UTC)