Wikitech-l June 2022

wikitech-l@lists.wikimedia.org

37 participants
37 discussions

Missing Section Headings
by Marc Riddell 13 Sep '24

13 Sep '24

Hello, I have been a WP editor since 2006. I hope you can help me. For some reason I no longer have Section Heading titles showing in the Articles. This is true of all Headings including the one that carries the Article subject's name. When there is a Table of Contents, it appears fine and, when I click on a particular Section, it goes to that Section, but all that is there is a straight line separating the Sections. There is also no button to edit a Section. If I edit the page and remove the "== ==" markers from the Section Titles, the Title then shows up, but not as a Section Heading. Also, I don't have any Date separators on my Want List. This started 2 days ago. Any thoughts? Thanks, Marc Riddell [[User:Michael David]]

10 11

How to make commits from mirrored Wikimedia repos show up on your GitHub profile
by Bartosz Dziewoński 27 Jun '24

27 Jun '24

I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here. tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.) (Is there a place on mw.org to put this tidbit on?) ------- Forwarded message ------- From: "Brian Levine" <support(a)github.com> (GitHub Staff) To: matma.rex(a)gmail.com Cc: Subject: Re: Commits in mirrored repositories not showing up on my profile Date: Tue, 09 Jul 2013 06:47:19 +0200 Hi Bartosz In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit. The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits. Cheers Brian -- Matma Rex

3 3

Research FAQ gets a facelift
by Dario Taraborelli 25 Jun '24

25 Jun '24

We just released a new version of Research:FAQ on Meta [1], significantly expanded and updated, to make our processes at WMF more transparent and to meet an explicit FDC request to clarify the role and responsibilities of individual teams involved in research across the organization. The previous version – written from the perspective of the (now inactive) Research:Committee, and mostly obsolete since the release of WMF's open access policy [2] – can still be found here [3]. Comments and bold edits to the new version of the document are welcome. For any question or concern, you can drop me a line or ping my username on-wiki. Thanks, Dario [1] https://meta.wikimedia.org/wiki/Research:FAQ [2] https://wikimediafoundation.org/wiki/Open_access_policy [3] https://meta.wikimedia.org/w/index.php?title=Research:FAQ&oldid=15176953 *Dario Taraborelli *Head of Research, Wikimedia Foundation wikimediafoundation.org • nitens.org • @readermeter <http://twitter.com/readermeter>

2 1

bluejeans
by Jeremy Baron 22 Feb '23

22 Feb '23

Hi, On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote: > We will be holding this brownbag in 25 minutes. The Bluejeans link has > changed: > > https://bluejeans.com/396234560 I'm not familiar with bluejeans and maybe have missed a transition because I wasn't paying enough attention. is this some kind of experiment? have all meetings transitioned to this service? anyway, my immediate question at the moment is how do you join without sharing your microphone and camera? am I correct thinking that this is an entirely proprietary stack that's neither gratis nor libre and has no on-premise (not cloud) hosting option? are we paying for this? -Jeremy

9 16

Unsubscribe from mail list
by Arpit Maheshwari 11 Jan '23

11 Jan '23

This is a request to please kindly unsubscribe me from your mailing list

4 4

List related to repositories which haven't mediawiki/mediawiki-codesniffer
by Zoran Dori 10 Jan '23

10 Jan '23

Hello, can someone to update list https://phabricator.wikimedia.org/P10500 which contains repositories which haven't mediawiki/mediawiki-codesniffer. I found in list that much repositories are empty, and repositories which aren't available on Gerrit. So, can someone please update this list of repositories (in mediawiki/extensions) which haven't mediawiki/mediawiki-codesniffer, but at least, contains one PHP file. or to provide me command with which I can update list when I want, so I don't need to request it every time. Best regards, Zoran. P. S.: Happy weekend! :)

4 6

Repository ownership of the Lingo extension
by Zoran Dori 10 Jan '23

10 Jan '23

Hi everyone, I want to notify you that I have, on behalf of the WikiTeq company, made a task https://phabricator.wikimedia.org/T298277 for requesting repository ownership for the Lingo extension. In case that you have any kind of questions, please let me know. :) Best regards, Zoran

3 3

Changes in schema of MediaWiki links tables
by Amir Sarabadani 12 Aug '22

12 Aug '22

(If you don’t work with links tables such as templatelinks, pagelinks and so on, feel free to ignore this message) TLDR: The schema of links tables (starting with templatelinks) will change to have numeric id pointing to linktarget table instead of repeating namespace and title. Hello, The current schema and storage of most links tables are: page id (the source), namespace id of the target link and title of the target. For example, if a page with id of 1 uses Template:Foo, the row in the database would be 1, 6, and Foo (Template namespace has id of 6) Repeating the target’s title is not sustainable, for example more than half of Wikimedia Commons database is just three links tables. The sheer size of these tables makes a considerable portion of all queries slower, backups and dumps taking longer and taking much more space than needed due to unnecessary duplication. In Wikimedia Commons, on average a title is duplicated around 100 times for templatelinks and around 20 times for pagelinks. The numbers for other wikis depend on the usage patterns. Moving forward, these tables will be normalized, meaning a typical row will hold mapping of page id to linktarget id instead. Linktarget is a new table deployed in production and contains immutable records of namespace id and string. The major differences between page and linktarget tables are: 1- linktarget values won’t change (unlike page records that change with page move) 2- linktarget values can point to non-existent pages (=red links). The first table being done is templatelinks, then pagelinks, imagelinks and categorylinks will follow. During the migration phase both values will be accessible but we will turn off writing to the old columns once the values are backfilled and switched to be read from the new schema. We will announce any major changes beforehand but this is to let you know these changes are coming. While the normalization of all links tables will take several years to finish, templatelinks will finish in the next few months and is the most pressing one. So if you: - … rely on the schema of these tables in cloud replicas, you will need to change your tools. - … rely on dumps of these tables, you will need to change your scripts. Currently, templatelinks writes to both data schemes for new rows in most wikis. This week we will start backfilling the data with the new schema but it will take months to finish in large wikis. You can keep track of the general long-term work in https://phabricator.wikimedia.org/T300222 and the specific work for templatelinks in https://phabricator.wikimedia.org/T299417. You can also read more on the reasoning in https://phabricator.wikimedia.org/T222224. Thanks -- *Amir Sarabadani (he/him)* Staff Database Architect Wikimedia Foundation <https://wikimediafoundation.org/>

1 2

Neuer Baustein "AhG"
by Siegfried Schmitt 02 Jul '22

02 Jul '22

Der neue Baustein {{AhG}} soll anzeigen, an welchen Stellen in der Wikipedia gerade eine Ad-hoc-Gruppe aktiv ist. Eine Ad-hoc-Gruppe kann als eine Art "task force police" verstanden werden, also eine schnelle Eingreiftruppe, die problematische Texte bearbeitet. Jeder Autor sollte diese "Vorlage:AhG" an beliebigen Stellen in der Wikipedia einsetzen können, sobald er ein Problem erkannt hat, das er nicht alleine lösen kann. Das Bildschirmfoto im Anhang zeigt die Anwendung des neuen Bausteines "AhG" auf einer typischen Seite, die dringend überarbeitet werden muß. Jeder Admin kann den Baustein einsetzen, um schnell ein Einsatzkommando zusammenzustellen. Grüße Siegfried -- Siegfried Schmitt Mathystr. 14-16 76133 Karlsruhe GERMANY Telefon: +49 721 358577 Mobilfunk: +49 1515 7525144 Siegfried.Schmitt(a)web.de

2 4

Feedback needed: Draft gadget/user script policy
by Jon Robson 01 Jul '22

01 Jul '22

[If you don't write gadgets, user scripts or work on MediaWiki code feel free to ignore this message] Hey all! Given the hackathon this weekend, now seemed like a good idea to talk about us having a policy for code we write for gadget and user scripts developers and as gadget and user script developers. TDLR: I am proposing a policy to guide developers and authors of these kinds of scripts. I would like people to read through my first draft <https://www.mediawiki.org/wiki/User:Jdlrobson/Extension:Gadget/Policy#Polic…> [1] and give me feedback on the talk page. Please feel free to share on wiki. *What is being proposed* A policy page that would be editable on wiki and linked to from the editing interfaces on gadgets, to guide both parties on how to write code that's sustainable and less prone to breakage. *Why is this needed?* Despite gadgets and user scripts (which will be referred from now on as wiki-based code) being a key component of MediaWiki projects, up until now frontend APIs (e.g. how wiki-based code should interact with source control provided code) have been ill-defined leading to misunderstandings between engineers and wiki-based code developers when wiki-based code break. This also leads to code rot, where developers do not feel empowered to make changes as it's unclear how their changes will impact wiki-based code developers. On top of this, when wiki-based code breaks it's not clear who can and will fix them. To solve this a policy I have been pushing for some time to make the contract between MediaWiki developers and wiki-based code developers explicit and less confusing. I hope on the long run a policy would restore trust and good faith between the two parties. *How can you help?* To contribute to the policy please use the discussion page to raise concerns, suggestions, removals or additions. *What's the deadline?* I'd like to have all feedback gathered by 30th May 2022 [1] https://www.mediawiki.org/wiki/User:Jdlrobson/Extension:Gadget/Policy#Polic…

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l June 2022