Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://phabricator.wikimedia.org/p/Tacsipacsi/ below:

♟ Tacsipacsi

Another option is a message could be automatically prepended in the case of a redirect. "(This message was sent to User talk:ABC and is being posted here due to a redirect.)"

I’m pretty sure 99% of the people who want JsonConfig also want Scribunto. So I’d autoselect Scribunto if JsonConfig is selected, but I wouldn’t disable the checkbox, so that the 1% can opt out of it.

The description is outdated, the final decision (at least for now) was "User:{Username}" and its discussion page.... However, what you see doesn’t match that either. But the colors are also different, and Gmina Milejewo is an article, not a user, so I think you’re testing the regular (MediaWiki core) watch feature rather than the feature this task is about (which lives in the CheckUser extension). Step to reproduce this:

What was the original purpose?

See description:

·

,

,

,

,

,

,

,

,

As I described there, I don’t think considering the fallback chain would be a good solution. Instead, I’d imagine some way of indicating from Lua that the Translate hook handler (MediaWiki\Extension\Translate\PageTranslation\Hooks::fetchTranslatableTemplateAndTitle()) should not operate. I don’t know how to pass this piece of information from Scribunto to core to Translate, though.

For example, if a change is rejected an edit is triggered which in turn triggers the usual cache invalidation too.

Thanks for the backports!

Thanks for noting that! If we created a custom message, would the following text make sense?

The discussion page for user "JohnDoe" has been added to your watchlist. Or would it need to say The discussion page for "User:JohnDoe" has been added to your watchlist.

1. In CI we use the composer merge plugin (e.g., what's in composer.local.json-sample in core. Unsure if using composer-merge is faster, but it seems righter.

I agree that allowing named parameters only in some calls to a given method is confusing, so stable interfaces without @stable named parameters shouldn’t be called with named parameters even from core. However, what about interfaces that are unstable anyway, including private methods? In https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1056213/comment/10b6fbeb_b6a81e6b/, @cscott argued against using an $options array and for named parameters when calling a private method. I agree with this; why not?

Apropos MW-1.45-notes (1.45.0-wmf.8; 2025-07-01), shouldn’t this be backported to 1.43 and 1.44?

Given the above, I propose we change the wording of the message to say:

• The user page "{Username}" has been added to your watchlist.
• The user page "{Username}" has been removed from your watchlist.

What should have happened instead?

[…]

• The message should say {Username} and their discussion page...

Funny. There are two MediaWiki\Parser\ParserOutput->getRawText() calls in RefreshLinksJob, both on the same line, so the stack trace isn’t really helpful, and one can only guess which one causes the exception… In any case, both were introduced in rMWa2c6e8ba89e7562242d429d4240ee9e12286d996. @daniel, do you have any idea what went wrong?

Indeed, but it’s not very discoverable: the shortest path I know is going through Special:Translate, where there is a “Message group statistics” tab. 1. It’s not obvious that you need to try to translate in order to get statistics; 2. it’s probably not obvious for outsiders that “message group” is a synonym of “translations of this page” in this context.

I’m not sure I fully understand what you say. So the underlying technology (Kartographer) supports everything we need, only the template/module doesn’t allow us to specify the input? In that case, simply the template should be expanded, no development in Chart is needed. (Personally I always found it strange that we have two ways to show maps, so I’d avoid adding map features to Chart if possible. I can support the capabilities of Kartographer if necessary.)

Thanks @matmarex for adding MediaWiki-extensions-Translate! Is there a way to copy the revert state from the translation unit page edit to the translation page edit? I’m slightly annoyed by my reverts being tagged as “manual reverts” on translation pages; while I can live with that, if we can kill two birds with one stone, and both fix the tag and remove the unnecessary notification, that’d be great. (The code is at rETRA src/TranslatorInterface/TranslateEditAddons.php:93 (at ab3f80ee8dbe), in particular the PageTranslationHooks::onSectionSave() call at the end of the function.)

Makes sense. However, the task description doesn’t reflect this, so please make sure to update it at the end of your exploration (or earlier if you have spare time for it).

I was under the impression that everyone is forced to move to GitLab (https://www.mediawiki.org/wiki/GitLab/Roadmap)

According to the PHPDoc of WebRequest::getVal(),

Yet another reason for me to dislike $wgPageTranslationLanguageList = 'sidebar-only'… Your reasoning makes sense, but on the other hand, the languages list makes it possible to compare the translation state of the current language with that of other languages at a glance. (Especially when the languages aren’t hidden in ULS, i.e. on skins other than Vector 2022 and without compact language links – ULS makes it more difficult to have an overview, as only a few languages are shown at a time.)

And why is it only displayed that way to logged-in users?

I’ve noticed it a few weeks ago, but haven’t got around reporting it before: there’s still one bit not compatible with dark mode – the saving indicator.

Trailing commas in (multi-line) function parameter lists

This should be done in PHPCS, but I suppose it's going to be the one with the most changes. We have long supported and encouraged trailing commas in arrays, and yet we don't even enforce those (and there's plenty of arrays not using them). Check if there's any upstream PHPCS sniff for it, if not I guess we can make one.

Like our current rules for arrays, I think this should not be enforced.

T395366: ifexist usage tracking no longer accessible through UI or API is about exposing it somewhere. (Disclaimer: I’m the author of that task, so I’m probably a bit biased. 😛)

Half of this was done in https://gerrit.wikimedia.org/r/c/operations/puppet/+/1156466, now only the table itself needs to be replicated.

Which probably isn’t needed now due to supported version increases

Nor could you implement the interface, since MediaWiki\Extension\Translate\PageTranslation\Hooks::onSkinTemplateNavigation__Universal() is a static method. (Maybe the class could be refactored to have instance methods, just like any other hook handler class, but that’s definitely out of the scope of the mentioned patch. And also of this task.)

Combined with T395366: ifexist usage tracking no longer accessible through UI or API, this is very bad and urgent. Useful and previously-accessible data is currently COMPLETELY inaccessible for anyone without an NDA signed: no UI, no API, no DB replica. See a specific use case at T14019#10857878.

Good idea! I often see translation admins adding or removing whitespace, probably because they don’t know how to access the form otherwise.

Disagree. Just like a week ago:

I don't know how cache was handled in graphs, I understand that data was cached in the same way you mention. We should have *at least* the same data ingesting methods as we had before. So, if the data should be, for technical reasons, cached for some days, let it be cached.

Given the huge variety of URI routes that Diffusion has I'd very much prefer not to try adding some custom code to add some custom message to the general auth dialog based on the URI which people tried to access before...

Actually, neither of these two examples (French and Basque) require SPARQL – the existing Wikibase Scribunto interface is powerful enough to get the data they need, so T396532: Add support for inline data in charts is enough for them to be rewritable.

Given that regex stuff requires dropping support for that many Safari versions, is it maybe possible to allow all ES2018 features except for the regex ones? (Do Peast and ESLint support such a hybrid approach?) I personally use the spread operator outside of MediaWiki all the time, but hardly ever do I use advanced regex features.

Why isn’t it? Commons Data:*.tab files is exactly what the MVP was built around. (I’m speaking about data sources here, not chart types. Yes, we could also create a list of chart types that were supported by Graph, but the two lists are orthogonal.)

Try to give specific examples of graphs that we can then break down into individual tasks.

• MediaWiki core (8 files) – excluding mw.Uri itself and documentation
  • resources/src/mediawiki.api/index.js (1 matches) – only in code comment
  • resources/src/mediawiki.feedback/feedback.js (1 matches) – only in jsdoc
• mediawiki/extensions/CentralAuth (2 files) – false positive matches (only in jsdoc)
  • modules/ext.centralauth.ForeignApi.js (1 matches)
  • modules/ext.centralauth.ForeignRest.js (1 matches)

What is a talking affordance?

(except those that don't keep sessions open)

I haven’t realized Codesearch can search in specific repos (Diffusion is so convenient for searching in a specific repo that I haven’t needed this); I’ve always used it in “search everything” mode. Is it maybe possible to link it from Gitiles, with the repo selected, both for convenience (one doesn’t have to select a repo from an endless list of repos) and for visibility?

I’ve just used Diffusion yesterday because I didn’t want to log in, and that’s the only view that allows searching code without login (Gitiles doesn’t allow search at all, and GitHub requires login). So it would be a loss if logged-out users couldn’t access it. ☹ But if we have to choose between requiring login and turning Diffusion off completely, requiring login is still less bad.

The only real use case out here seem to be the entries in Special:WantedPages

but I fear that would be a too large burden for many non-binary people, so they would simply not set their gender, and we’re back at the status quo.

Would you rather want not to see what you just wrote? Showing old revision + your reply, i.e. a version that has never existed, would be by far the most confusing, so the only remaining option is not updating anything – but that’s also confusing (looks as if the reply was lost). This is probably why updating both the page and the URL was chosen – you’re simply no longer on an old revision. If you want the page not to be updated, just don’t change it, i.e. don’t reply. ☺

I agree that Navigation popups should make a distinction between “unknown” and “non-binary”. For example, when I want to refer to someone in third person, I first hover over their user name with Navigation popups. If I see “he/him” or “she/her” there, I stop and use that pronoun; otherwise I try harder (e.g. looking at their user page to see if a pronoun is listed there). If “they/them” would appear in the popup, I could stop there in case of non-binary people as well – but only if that “they/them” would always mean “non-binary”, and never “unknown”.

Changing the URL makes no sense especially in such a case because the version of the page you see (the old revision + your reply) doesn't exist anywhere as a permalink.

It’s because {{REVISIONDAY}} and friends ignore the specified revision ID when parsing an interface message.

What do you mean by “page variables”? I don’t think there are any variables containing author/year that could be read out.

@Titanic-jb In case you’re still interested (I’m sorry no one replied in five years): those other classes are part of MediaWiki core; see https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker for how to get started.

https://en.wikipedia.org/wiki/MediaWiki:Citethispage-content can use https://en.wikipedia.org/wiki/Template:Replace to add the backslashes, but the default content of this MediaWiki message also contains BibTeX citations, which are probably also affected, and which can’t use an enwiki template.

renamed

from

to

.

The citation styles are just pieces of wikitext, so the copy buttons (I don’t think they should be links) need to be defined in wikitext, probably using an extension tag. I wonder whether this should be defined in CiteThisPage, or in a separate extension (making the feature available everywhere) – the usefulness of the copy button is not constrained to that one specific special page.

The CiteThisPage extension needs an update to work directly with Parsoid.

The most straightforward fix for this bug is simply not playing with the parser – removing the <citation> hack. So resolving T251860: CiteThisPage should treat magic words for time normally, scrap <citation> tag would naturally fix this bug.

Agreed. However, it won’t work out of the box: you write “{{CURRENTDAY}} & co” and “{{REVISIONDAY}} & co”, but

I've fixed a similar issue on plwiki by just throwing away the hardcoded background value in the styles in favor of CSS variables: https://pl.wikipedia.org/w/index.php?title=MediaWiki:Citethispage-content&diff=prev&oldid=75405133 (this changed the bluish bg to gray but I don't think it's a big issue, especially that in general Wikimedia wikis are nowadays using color scarcely in the UI; by the way, the template I've removed there was also outdated, that's why it got removed).

I believe this is the right way to do it instead of trying to add yet another layer of overrides to some CSS...

I guess to reflect the content: in order to show your just-posted comment, the latest version of the page content needs to be loaded.

Actually, I see value in the behavior of the FunctionComment sniff: I think it makes the PHPDoc block easier to read – the first parameter is listed first in the docblock, the second parameter is second, and so on; there’s no need to read the actual parameter names. So I’d rather align the new sniff with this:

And I scoped this task to (either or both of) the latter two.

(and given the normal sequencing of MW-CS versions, probably won't be for a few months).

I expanded the description to highlight that the current situation is not only confusing, but actively broken on some wikis/for some users. (The link gives many false positives, but the regex search, which would have yielded less false positives, times out for me.)

There are also two patches pending; I don’t think this can be called done without the Scribunto one being merged, as probably most usage in 2025 is Lua usage, not actual {{#ifexist:}} parser function calls, making the current state not very helpful (most existence-checking links are still there) but at least confusing (some are gone).

If this is blocked on T365631, then T365631 should be a subtask of this (and not a parent task), shouldn’t it?

We see (parsoid/legacy/wikitext):

I'm curious: if the hook/element was named something different e.g. Banner and there was a mw.util.addBanner() function and siteNotice was a child element would you feel different?
e.g.

<div id="mw-banner">
   <div id="siteNotice"></div>
   ...
</div>

The "Alternatively" is already implemented on English Wikipedia, since 5 October 2009.

I had trouble getting the form to be shown locally (you know... flaggedrevs...) so the patch is not really tested.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4