User talk:Krinkle

"Avoid namespace numbers above 10,000. These are reserved for future use."

Can you give any detail what you meant by "future use"? Is there some WMF project in the works that will use numbers in this range, or was it maybe meant as a more nebulous "we don't really need these yet, but we might some day" thing, or something else? 「ディノ奴千？！」^{☎ Dinoguy1000} 13:38, 30 July 2019 (UTC)

We might need them someday. It's there so that developers won't interpret the advice as "pick a random number between 5000 and 9007199254740991". But rather put a more reasonable limit on it, which might get extended one day after a discussion to another reasonable limit. --Krinkle (talk) 14:43, 30 July 2019 (UTC)

Aah! Fair enough; that's about what I figured. Though personally I'd be somewhat surprised if we ever actually get to that point; it seems like much fewer extensions are being written these days which add namespaces than were written in the past... 「ディノ奴千？！」^{☎ Dinoguy1000} 16:06, 30 July 2019 (UTC)

My message on T20493

I was wondering what you thought of my suggestion on the Unify the various deletion systems thread.

My suggestion was made in response to specific sites that I know of where RevisionDelete is not generally available to local Administrators, as it is generally reserved only for TOU violating issues.

And in response to my belief that there ought to be an extension to the traditional deletion system allowing for individual or multiple revisions to be deleted and moved to the archive table, as opposed to being limited to deleting all revisions and then restoring the wanted revisions. If such an ability were to exist, I would imagine it sharing the same pages as the traditional deletion ability, via ?action=delete.

But if the page deletion system and the revision deletion system were to be merged together, how will we be able to find a way to please those sites that prefer not to give Administrators the ability to selectively delete revisions by default? ― C.Syde (talk | contribs) 05:13, 1 August 2019 (UTC)

Thanks, I've replied at https://phabricator.wikimedia.org/T20493. --Krinkle (talk) 13:23, 1 August 2019 (UTC)

new wiki ideas

i have many. any idea where i can start a new wiki project? thnx. Baozon90 (talk) 22:46, 3 October 2019 (UTC)

About Compatibility

Hi. Since you removed the page Compatibility from translation, all of the existing translation pages were deleted. e.g. Special:Undelete/Translations:Compatibility/1/es --Shirayuki (talk) 01:43, 19 October 2019 (UTC)

@Shirayuki:

They were not deleted, they were converted to regularly editable pages, with the shared tables as templates. I made sure every translation was preserved, such as for Spanish at Compatibility/es. I did this on 3 October 2019. Please undo your changes as they have caused the translations to actually be hidden, as you can see in this diff which shows the Spanish page has now become English. --Krinkle (talk) 19:51, 19 October 2019 (UTC)

Username change on phab

Hello, Krinkle!

You're the only phabricator admin I know... how do I request a username-change on phabricator and also for git? Thank you. —Aron Man.🍂 edits🌾 11:25, 24 January 2020 (UTC)
Pinging @Krinkle: . —Aron Man.🍂 edits🌾 13:20, 6 February 2020 (UTC)

@Aron Hi, I can't help you directly. Please file a task on Phabricator and wait for an admin to help you. --Krinkle (talk) 18:39, 6 February 2020 (UTC)

Thanks! That's what I was looking for. —Aron Man.🍂 edits🌾 21:13, 6 February 2020 (UTC)

Help wanted

Hoi Krinkle,

Zou jij me kunnen helpen met een simpele extensie? Zie mijn overlegpagina voor de details.

Bedankt. --RenéV (talk) 20:23, 1 February 2020 (UTC)

Hoi! Ik heb op je overlegpagina een antwoord achter gelaten. --Krinkle (talk) 18:43, 6 February 2020 (UTC)

Discussion continued

Hello, Krinkle!

I think it's better to discuss this on-wiki, not on the Gerrit patch, as it is not a technical discussion. Continued from: Patch 579245.

> You mentioned that cleaning this up is "low priority" and can be done later. That is in my opinion the definition of technical debt.

I understand your point. In my experience in the Wiki sphere "later" more often than not means never. I'm trying to get some years old tasks solved that fell victim of "later". However, that's not how I work. Priority means there is sequence, but very little gaps between the steps. I don't have the comfort of a "no consensus now" solution, that's a failure in a for-profit setting.

> When managing a project of this size, one cannot just hope someone will clean it up later.

"Follow-up." I haven't heard many people use this word around. I see this as cultural issue originating from the wiki model. There's something to be learned about finishing what we started.

> However, it is part of the responsibility for a patch contributor to apply that feedback and not leave the code in a worse state than before.

We have different practices and focus. I never remove a hashbang, as it is the equivalent of the magic number / type specifiers at the start of files. For this reason as I've said I don't endorse removing it, it's your decision and responsibility.

Anyway, thank you for finishing and merging this patch. I appreciate the quick response this time, this is how I imagined you would do your cleanup if you find it important.

> As written, this patch leaves an unused hashbang behind. It is not hard to imagine that a future contributor will follow the path in package.json, and open the script, and once there, (wrongly) assume that the hashbang is used, and that they can change it. For example, they could write the script in php, update the hash bang, test it, and later find that it breaks from package.json.

Thank you for the explanation of the "technical debt" issue you see with leaving the hashbang as it was.
I'm sure the CI build - right after said contributor submitted the patch - would fail to run the php script with sh and the contributor would need to fix package.json in the second patch set already. I think such fixes are normal and usual as many tests only run in CI, therefore I don't find that a problem in any sense, nor a debt. This is the reason why I don't share your concern. I hope this makes my point of view understandable.

> It's great that you want to contribute, and there is a lot to do.

Unfortunately, I don't experience the "great" part. In my experience volunteer effort is handled in a counter-productive way, often times unappreciated and sometimes even disrespectfully. The opposite that I usually experience while contributing to open-source.

> However if you are not prepared to also do the clean up required, then we cannot accept your contributions unless you collaborate with another volunteer that will, or that the work aligns with something I can spend more time on to finish your patch.

I think this fundamentally misinterprets my modus operandi. I do significantly more cleanup than many of the developers I have met and observed their work. In this case there was a disagreement of what should be cleaned up and the importance of it.

If you observe my contributions you might notice that I prompty apply all feedback and also do extensive research of discussions going back years to find out what the purposes and plans were. Please recall when I've cited you from years ago in another task. You won't meet many contributors, who does such extensive research to find all the requirements for a solution. I hope you appreciate that. I don't have bad feelings about your comment, I reckon I wasn't either as nice to you as you are usually.

> But please consider this when you interact with open-source maintainers in the future.

I will and I hope my perspective will be considered too.

—Aron Man.🍂 edits🌾 23:00, 15 March 2020 (UTC)

Rebasing

Continued discussion from gerrit about commit messages not copied to master branch when jenkins-bot merges patches not based on HEAD.

Myself, previously:
> My concern with jenkins-bot merging instead of rebasing the patch is that the commit message is lost from the master branch. Every time I have to look for the merged patch in git and that takes time, unnecessarily. It makes much harder to browse the history effectively. I think jenkins-bot could be persuaded to rebase instead and keep the commit message.

Looking at the CLI the effect is emphasized

Krinkle:

> I suspect that might be an issue with the tools or configuratin of the git viewer you use. }}

A fun image to demonstrate this: Rainbow-colored lines replace the useful information.

I'm sorry if my comment could be misunderstood, I'll try to explain better. This is not an issue with the tools. If you visit a merged patch that wasn't rebased on HEAD, you'll see something similar to: https://github.com/wikimedia/mediawiki/commit/7ef1f1d865431a6f8f041f5e2ea83ce5aa0cd1ff

Can you tell in a blink: - who made the patch? - with what reason? - where is the commit comment?

If you have a good git gui - I use Fork (available on Mac, highly suggested ;-) and GitExt - you can step through the commits with one keypress and read the commit message, thus gain an understanding about what's going on in a few seconds. Very efficient.

But not with patches that read only: 'Merged "some patch title"' by a bot. I do more and deeper research in the git history than people usually do, therefore I understand this did not come up as a pressing issue. However, I ask you to understand this issue and think about it on a relaxed day.

> As an example, you'll see here https://github.com/wikimedia/mediawiki/commits/master virtually all of those are done with merge commits. That is our chosen practice which has some benefits and some downsides. Please follow those practices for now.

I'd be interested in the benefits and downsides you're aware of, to understand the constraints here, but I think we were talking about different things: There is no "practice" in this, patches randomly - depending on activity - get either merged or fast-forwarded.

—Aron Man.🍂 edits🌾 21:45, 29 June 2020 (UTC)

Hey, Krinkle!

Did you receive this message? Did I manage to clearly explain the problem?

If this needs more discussion on phab, please inform me of the tags to add and I'll make a ticket.

I hope this could be improved as simply as adding the equivalent of `--rebase` to jenkinsbot merging. Please point to the source code and repository where this should be found.

Thank you! —Aron Man.🍂 edits🌾 11:24, 2 July 2020 (UTC)

@Aron: I understand you may be used to using Git differently. The concept of a merge commit is native to Git. This means it offers various benefits whilst also therefore being a recognised concept that most if not all Git interfaces can hide or skip when appropriate. For example, git blame and git log ./directory/file operations generally ignore merge commits by default, automatically. The same applies to GitHub's versions of these as well (file history and file blame).

The repository-wide histories do show them by default, which I find useful. However every Git CLI and UI I've used also have options to hide them. If that is your preferred way of showing the logs, I recommend you use those options. See also git-config and Git/aliases. --Krinkle (talk) 19:00, 24 July 2020 (UTC)

@Krinkle: Hi again!

As the GitLab transition has been torpedoed and seemingly abandoned or delayed for an unknown time, this issue became relevant again. I'm concerned that the advice you gave about git aliases has nothing to do with this issue as the list of commits to show in git cli is independent of the length of git commands and GUI clients don't use git aliases. `abbrevCommit` is also irrelevant, the issue is not whether the commit id is 10 or 40 char long. I wonder how that relates to this issue for you. I also wonder how you use Git if you believe I use it "differently". Different from what and in what way?

Generally I'd like to ask you to understand the problem I've detailed above and instead of giving advice that's hardly useful or necessary, you could introduce your workflow and tools that you use to mitigate this issue when browsing or searching the git history for information that can be anywhere within a few hundred commits (that's maybe a few weeks' worth of changes), without any exact clues to heuristically speed up the search - by which I mean a linear search is necessary.

I assume what you meant by using git differently is that I do research that goes this far and deep and probably nobody else at WMF does. Going this deep is the reason why I find the cause and origin of certain decisions and issues. I'm happy to teach this technique if I'm asked, on the other hand I'd like to ask you to make applying this procedure easier. As I've detailed before it does not take much to increase developer productivity significantly.

I also wonder why it is so hard to communicate this issue. If you could give any advice how I could present this issue more clearly, I'd appreciate.

Regarding the support of merge commits: as far as I'm concerned that's baseline in tools nowadays. The problem in this case is not git blame and history continuity, but the overwhelming noise that merge commits generate by 1) missing the relevant information from the original commit 2) creating 10-20 parallel branches (in the very active core repo) just for individual commits that's redundant (the exact duplicate except for the commit message) with the merge commit. This is what I described as rainbow-colored spaghetti that you can see in the screenshot. Without merge commits (with commits rebased on HEAD before merge) that would be a single line of consecutive commits without duplication. I think there's no need to further explain how simpler that would be to comprehend and handle for all developers.

Thank you for reading this. —Aron Man.🍂 edits🌾 17:51, 19 August 2020 (UTC)

RTRC translations

Hello Krinkle,

I would like to report a bug in RTRC. At the moment, atleast for me, translations are not visible in RTRC. From what I gather from the DevConsole it seems to fail because a header is missing (see below). I think that might be because the domain changed from tools.wmflabs.org/intuition to intuition.toolforge.org

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://tools.wmflabs.org/intuition/api.php?domains=rtrc&userlang=nl. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://tools.wmflabs.org/intuition/api.php?domains=rtrc&userlang=nl. (Reason: CORS request did not succeed).

Could you please take a look at this when you have the time? Thanks in advance. Kind regards, Wiki13 _talk 07:21, 8 July 2020 (UTC)

As of 2 days ago the translations started to work again, so you can ignore this message. --Wiki13 _talk 12:53, 11 July 2020 (UTC)

GUC Tool error, or?

Hey there. I'm looking at the Mass Message tool contribs.

(diff | hist) 16:51, 10 Jul 2020 . . ua.wikimedia.org . . MediaWiki message delivery (talk | contribs) . . Обговорення:Вікімедіа Україна (→‎Announcing a new wiki project! Welcome, Abstract Wikipedia: нова тема) (current)

(diff | hist) 16:51, 10 Jul 2020 . . pl.wikimedia.org . . MediaWiki message delivery (talk | contribs) . . Dyskusja:Strona główna (→‎Announcing a new wiki project! Welcome, Abstract Wikipedia: nowa sekcja) (current)

(diff | hist) 16:51, 10 Jul 2020 . . no.wikimedia.org . . MediaWiki message delivery (talk | contribs) . . Wikimedia:Samfunnet (→‎Announcing a new wiki project! Welcome, Abstract Wikipedia: ny seksjon) (current)

(diff | hist) 16:51, 10 Jul 2020 . . nl.wikimedia.org . . MediaWiki message delivery (talk | contribs) . . Wikimedia:De kroeg (→‎Announcing a new wiki project! Welcome, Abstract Wikipedia: nieuwe subkop) (current)

These entries are about a message I sent. However, for some reason, the rest of the messages I sent in that batch is missing from the log, and you can verify following any link in here that the message was indeed sent out correctly. What gives? Should I report this issue elsewere or to someone else? TYVM! Elitre (WMF) (talk) 13:30, 13 July 2020 (UTC)

@Elitre: GUC shows at most 20 results per wiki. Perhaps that explains the missing entries? If not, please file a task on Phabricator under GUC. --Krinkle (talk) 19:12, 24 July 2020 (UTC)

I will. GUC shows (or at least should) all the results when ordered by date. TY, Elitre (WMF) (talk) 08:55, 28 July 2020 (UTC) PS: https://phabricator.wikimedia.org/T259454. Elitre (WMF) (talk) 08:23, 3 August 2020 (UTC)

A problem

Hello Krinkle. Since you are an active MediaWiki admin who you speak Dutch, I am writing to you. Also, since I know you from Meta, it isn't difficult to find an user who speaks Dutch. @Baris6161TURK: , this user translates the messages for different languages here, on Meta, Wikidata, Translatewiki etc. According to the different accounts of this user, I will say that his native language may be Turkish, but even the Turkish messages he wrote on Translatewiki and Turkish Wikipedia were corrupted. At the beginning of 2020, we (users of Turkish Wikipedia) had determined that these were machine translations. And because the translations were unfortunately wrong, different users on Turkish Wikipedia tried to reverted translations from different projects. I think these are still machine translations, as he is making translations for many languages ​​in the world. I haven't checked the translations as often as before, but the user says he speaks Dutch. Translations:ORES/91/nl Translations:ORES/91/en Is this translation correct for Dutch? If many of these translations are wrong, something needs to actions for this user. Because there are hundreds of thousands of translations here. Uncitoyen (talk) 08:48, 14 February 2021 (UTC)

@Uncitoyen: The translation at Translations:ORES/91/nl looks good to me. I would argue it is even superior to the original English source, and do not believe it to be a machine translation. Thanks for asking! --Krinkle (talk) 19:19, 5 March 2021 (UTC)

Date

[1] What was the meaning behind the creation of the date type? Did the developers intend that all contributors to articles, in templates in all wikis, write the date only in ISO? How do you see the situation if, due to the support for templatedata of only one format, the wikis forcibly cleaned up all other natural formats and forced users to enter only the ISO format? Sunpriat 16:43, 9 May 2021 (UTC)

TemplateData describes a subset of possible template interactions, specifically to improve VisualEditor, and (indirectly) to improve the experience of article contributors, article reviewers, and template editors.

My thinking with ISO is that it is a simple and popular format.

This is easy to generate for programs, such as when selecting a date visually in VisualEditor it can insert this date for you into the template (nobody has to write it by hand there, consistent with other aspects of VisualEditor; and allowing native interfaces such as on your phone where there is a built-in date selector that we can use).

This is easy to process inside a template. For example, if I develop a template or Lua module, this is a simple format to parse and perform calculations on. It is then also easy to convert to other formats, for example convert 2011-04-01 to localised "1st Apr. 2011" or "11 years ago", based on what the community and users of that template want to be displayed.

This is easy to learn and write for wikitext contributors. It doesn't matter which article, which wiki, which template, this format can become more common and thus you do not need to know exactly the conventions of every template. I can just enter this one and it will work and become the right format. This seems better than having to check, understand, learn, and remember hundreds of different ways of entering a date for each wiki/language/template.

This is easy to review for patrollers. When reviewing a diff, it can be time consuming to have to check the rendering or local wiki template documentation to know what something means. For example 01/02/03 could mean many different things, and depending on whether this is American or European, and what wiki and which template, it could mean something different. I'd much rather review the wikitext using ISO to avoid ambiguity. Of course, there is also the visual diff option for reviewers that prefer this.

TemplateData is optional and you can choose whether to get these benefits by choosing "date" instead of "text" as the parameter type. If your community prefers not to get these benefits (yet) for a specific template, you can use the default "text" format instead and explain your special format in the documentation. This will always be supported. As far as I'm concerned, there will never be a requirement to adopt this feature. Krinkle (talk) 20:36, 21 March 2022 (UTC)

Residence

Hi, thank you for your contribution to the Wikipedia, I was wondering how to put more info to the 'infobox person', for example, want to put information about person's 'residence' (place). Infobox person had the information, but now it was disappeared, can you introduce hot to put manually ?

Filter 86

Can I ask why that was disabled? I appreciate it wasn't perfect but I was targeting a very specific kind of spam that was going though the usual Filter 12, and it was somewhat working, albeit with some false positives (which is why I disabled its brother filter 87). The comment you gave wasn't clear on what the exact issue was. Thanks in advance. Leaderboard (talk) 11:48, 16 May 2021 (UTC)

Last editor for MediaWiki:Vector.css

Do you know why these styles are hiding out in vector.css? At least two of those groupings look like they could/should be in the sitewide gadget (sup/sub and support desk), and probably the third grouping too. Izno (talk) 23:30, 25 June 2021 (UTC)

Hover with js or css

Hello Krinkle! I need a hint or a direction with an issue I am having. I have been using hover, implemented in common.js, with this code:

$('.hover-bgc').hover( function() {
    $(this).attr("data-hover-bgc-original", $(this).css("background-color"));
    var parentSpec = $(this).parent('.hover-bgc-parent').attr('data-hover-bgc-child');
    var newColor = ((typeof parentSpec !== typeof undefined) && (parentSpec !== false)) ? parentSpec : $(this).attr('data-hover-bgc');
    $(this).css({ "background-color" : newColor});
}, function() {
    $(this).css({ "background-color" : $(this).attr('data-hover-bgc-original') });
});

Can this be optimized? If it would be better to use css instead of js, may I have an example to follow? Regards, --ManosHacker (talk) 16:47, 3 October 2021 (UTC)

I'm sorry but I can't help you. Consider asking general questions for JavaScript and web development on StackOverflow or elsewhere within a chat community or support forum of your choosing. Krinkle (talk) 20:38, 21 March 2022 (UTC)

Description of Extension:OATHAuth

I have a question regarding this edit. Could you explain, please, what "By default, this includes a time-based one-time password (TOTP) implementation that user's configure on their phone or in a desktop app" means? Because it does not make sense to me. Users do not configure Extension:OATHAuth on their phones/PCs, they configure third party TOTP client apps. jdx ^Re: 00:08, 21 March 2022 (UTC)

I think your confusion may be around the meaning "on your phone", which perhaps you interpret as "the settings panel of your phone operating system". I think "on your phone" simply means somehow somewhere using one's phone. The fact that is is an app and that its developer may be a third-party to the phone OS vendor is insignificant, and perhaps even confusing (considering e.g. Google is a not a third-party to Android, for their Authenticator app.)

Alternatively, since you state "users do not configure Extension:OATHAuth", perhaps you instead are highlighting that the verb "configure" should refer to the TOPT client being configured and not the backend software implementation, since end-users are generally not sysadmins.

I've modified the sentence to hopefully avoid both of these confusions. Krinkle (talk) 20:21, 21 March 2022 (UTC)

Now it sounds better, however IMO still is confusing, or at least is not precise. By this includes I understand Extension:OATHAuth includes and by that allows user I understand that allows end user. What directly allows an end user to generate 2FA one-time passwords is a TOTP client running on their phone/PC. And that client has not much in common with Extension:OATHAuth. The only thing a user has to do is to synchronize their client with Extension:OATHAuth running on their wiki. IMO the sentence should just sound: By default, this includes a time-based one-time password (TOTP) protocol implementation that allows to generate 2FA one-time passwords. Although I am not a native speaker… --jdx ^Re: 07:37, 22 March 2022 (UTC)

Thanks. I agree we improved the sentence. I think the current phrasing is accurate and simple. I aim to be accurate and simple in the leading paragraph of an explaination. It is not my intention to be unprecise, but I do think it is good to, when needed, sacrifice precision first.

About "the user (does not) generate codes on their device", I consider this a paradox (or dilemma). What does it mean to "do" something? If I send a letter, do I really send it? Someone could wrote it for me, and then someone else submit it for me to the postbox, and another company of people empty the box and transport it to a delivery person. The same for email. Do I send an email? Or my phone does? Or the software on the phone? Or the CPU? Or my cellphone carrier? Or my email provider company? Or their employees? Or the mail server they operate? Or the software library used within their mail server?

When humans perform actions, we are an actor. All the world is a stage. There is a neverending layer of actors that are acting on your behalf, or as extension of you. In the end, it's all electrons traveling through the vacuum of space, looking to have their adventure and find the meaning of life. I wish you the best on your journey. Krinkle (talk) 15:00, 22 March 2022 (UTC)

Invalid template Template:Gerrit repository request

I give a request for a new repository, and I found that your template is broken - it generates invalid links to Phabricator. I can do repair, but first want questioned you if I can do it. Want (talk) 09:11, 3 March 2023 (UTC)

I've fixed the usage instead (the phabricator parameter asks for the project, not for a task). Can you check now, @Want? Martin Urbanec (talk) 23:46, 5 March 2023 (UTC)

Manual:Wiki family

Hi there! I see that you have improved the manual and I was wondering if you could help me. I am in the process of creating a wiki farm, after reading the manual, there are some things I don't quite understand. I'm trying to use the Separate settings files method. If I'm not mistaken, I have to rename the LocalSettings file for each wiki and include the wiki ID, and then create a new LocalSettings (again, for each wiki). But I don’t understand what information should be on the new LocalSettings file. I also don't know where the code displayed after the 4 steps should be at.

Thank you so much. 186.188.144.85 23:59, 17 March 2023 (UTC)

"and then create a new LocalSettings (again, for each wiki)" This portion is incorrect. After running the installer several times (and renaming each auto-created settings file), you create only one "real" LocaLSettings file in total.

I suspect the mistake you made is to download several copies of the MediaWiki directory, otherwise I am not sure how you can even create multiple files named "LocalSettings.php" because there can only be one file with that name.

The end-result should look like this:

• /var/www/mediawiki/
  • includes/
  • extensions/
  • index.php
  • api.php
  • (etc)
  • LocalSettings_foo.php # Step 1 & 2
  • LocalSettings_bar.php # Step 1 & 2 (again)
  • LocalSettings_quux.php # Step 1 & 2 (again)
  • LocalSettings.php # Step 4

Krinkle (talk) 20:16, 18 March 2023 (UTC)

SITESUBTITLE

Please see "MediaWiki talk:citethispage-content#SITESUBTITLE" regarding your deletion of the page "MediaWiki:sitesubtitle." Nicole Sharp (talk) 00:11, 25 March 2023 (UTC)

Thanks for revert

Thanks for the revert. I tried to do that for all the template imports, and it said NO and showed everything with zero difference. <shrug> — billinghurst sDrewth 23:22, 7 July 2023 (UTC)

phab:T64913

Hello, I am not that familiar with php so I wonder if there is a way to put my draft code into dev environment on wmflabs so that I can debug with web pages online? Hamish (talk) 11:04, 12 July 2023 (UTC)

Manual:Wiki family

Hello, I have a question regarding the “Separate settings files” method of wiki farms. This method shares the same Mediawiki source, but the step 3 says “Repeat step one and two above for each wiki you wish to create.” And the step 1 is the installation of a wiki. I thought I had to install a new MediaWiki copy, but then the wikis wouldn’t be sharing the same source code. Maybe a have to run install.php or something like that instead?

I already figured out that part, but on the $wikis variable, what should I put on the right side when listing the wikis? I've tried the wikiID (DB name), wiki prefix, but it keeps throwing "Unknown wiki".

$wikis = [
    'example.org' => 'examplewiki',
    'one.example.org' => 'onewiki',

Thank you Esteban16 (talk) 04:00, 20 July 2023 (UTC)

hidden rights

I noticed while you were working on rights=purge that we have this curious pattern. So far as I know, there is no such thing as the hidden right. From what I can tell, most of them are correctly marked as hidden gadgets. So maybe something else to clean up. Izno (talk) 23:45, 28 October 2023 (UTC)

That's correct, it does not exist as a right. Therefore, if you limit the loading of a gadget by this right, nobody has this right and thus it will not be visible on Special:Preferences, but can still be loaded as dependency or via mw.loader. In other words, it works exactly the same as the boolean hidden option. I believe that first rights=hidden became popular, and later we recognised the trend by creating the hidden option. If both are set, the old rights=hidden trick can be removed. If only the rights=hidden trick is set, it can be replaced by the native hidden option. Krinkle (talk) 01:07, 29 October 2023 (UTC)

One of your gadgets blocks a Mediawiki option

Hi, today I realized that MediaWiki:Gadget-modrollback.js, which is created by you and imported by some WMF projects, blocks a Mediawiki option. You can find the option by going to Special:Preferences#mw-prefsection-rendering and use the search bar to find "Show a confirmation prompt when clicking on a rollback link" option. I couldn't found the gadget from MediaWiki:Gadgets-definition. And I created T349973, but a user closed it with no reason. You don't need to read all the ticket contents; just read the first and this comment. This page become the last place I mention this. Thanks! Aram (talk) 00:06, 28 November 2023 (UTC)

@Aram I did not create this gadget. I moved it to mediawiki.org to encourage re-use across multiple wikis. You can find the the original history at https://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-modrollback.js&action=history.

Indeed, this gadget and that optional preference are not supported in combination. The "Confirmation prompt" feature is relatively new, and is not interoperable with other modifications. This is a limitation to how browsers and JavaScript work. It is not impossible to implement a new way, but it is not a trivial bug fix either (I think).

I am not planning to add support for this, but feel free to fork, propose, or ask a place such as w:WP:VPT for help from other gadget developers. If someone has an idea for how to support it, and is able to develop a fork of this gadget that works correctly with both this preference on and off, then do let me know. I'd happy to publish their revision here for exposure to all wikis importing it from mediawiki.org. Krinkle (talk) 00:39, 28 November 2023 (UTC)

Thanks for your reply. I posted on enwiki VPT and all a user could do was this. Aram (talk) 16:28, 1 December 2023 (UTC)

Some stroopwafels for you!

Thanks for putting this together, Timo. It was a clear, well structured and accessible presentation that helped me cover a couple of knowledge gaps I had. LGaulia-WMF (talk) 08:17, 15 December 2023 (UTC)

Unclutter script

A recent update to MediaWiki has broken this script again. Is there a way it can be fixed? 1989 (talk) 15:10, 14 July 2024 (UTC)