.whitespace-wrapper doesn’t sound very stable. Isn’t there an mw- prefixed class?

When we know that the depicted can be proposed in Wikimedia Commons, I expect an OOUI simple message asking something like:

How does this image represent [ENTITY LABEL]?
Buttons: [Normally, or not particularly] · [Main subject]

I still think T241524: Parser function for loading gadgets is the way to go, not this. If a template with a template gadget has a sandbox, there are two options:

Codex dialogs are modal, i.e. you can’t do anything on the page before you interact with them. If T364664 was the right decision, and most of the time people don’t want to recover changes, using a modal popup would make their lives more difficult – currently, if you don’t want to interact with the recovery notification, you can just start editing and ignore it; this would not be possible with a modal version.

In T374794#10196825, @GMikesell-WMF wrote:

Derived Requirement

Ensure that Babel boxes maintain readable text color when switching between night mode and automatic mode in the Vector 2022 skin, with appropriate text and background contrast.

Thanks in advance!

• Per https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1075626/comment/95b7c0df_3bc3c623/ update documentation to accept Node as well as Element so that DocumentFragment can be used.

IMPORTANT: We would like to use the file structure /front-end/src/locale/{iso}.js, would this work ?

In T328171#10186694, @Urbanecm_WMF wrote:

However, I do not think that multilinguality is something decided at the beginning of a wiki, and then never changed. In fact, this comes from how the community actually makes use of the wiki.

This may come as a surprise to users who use both the New Topic Tool and other interfaces, especially such long after the introduction of automatic topic subscriptions in the New Topic Tool, so I think it definitely merits a Tech News item before the config change is deployed.

In T263513#10152210, @thiemowmde wrote:

• List the shortcuts that can be used to link to each namespace.
• Make sure the special page can list all localized aliases, not only the first one.

@Jdlrobson Why did you create a new task and merged in a three-year-old one instead of updating the old one with a new description? This makes comments harder to follow.

There are times when you need to update tvar name/label (accidental duplication, confusing label, changes in wiki's label approach, consistency with rest of page, etc.)

In T328171#10155161, @Ladsgroup wrote:

Is it not enabled yet?

Thanks for finally creating this function! I wish it happened during the messagebox→mw-message-box migration, but it’s better late than never.

In T375763#10180359, @sgrabarczuk wrote:

"~2024-3394 is a temporary account, and it can only be used to make new contributions within a limited time frame. Eventually* (or "after [insert date] at the latest"), it will become inactive and inaccessible. After that, this talk page will not notify the user of new messages."

Actually, that method is called at a single place (line 188), and the return value is forwarded to a method that handles null values, so I guess the fix is to simply change the return value from string to ?string?

In T159262#4932420, @ovasileva wrote:

the remaining tasks open as debt

Between the filing of this task and the actual removal, the extension did see a release, version 2.0.0.9 beta, which claims to make it compatible with PHP 8.1+. So while it may be true that it has fallen into disuse, the statement that it’s not compatible with MW 1.43 anyway due to PHP version constraints, isn’t true anymore. So I think it should be restored for MW 1.43 (and deprecated if you want).

In T374499#10178045, @Jdlrobson wrote:

I think we all share the same end-goal here of easier to maintain code!

Patch demos can contain extensive amounts of test data, which is lost if it gets deleted from one day to the other. Please allow opting out of it – hopefully the opted-out wikis won’t be that many, so there’s still a decent amount of storage win.

Special:Translate (if I understand correctly, both ext.translate.special.translate and ext.translate.editor show message boxes on Special:Translate only) relies heavily on client-side DOM building, so I think rewriting in Vue would also be a solution there. (Especially as it needs design changes due to T371071: Dark mode not compatible with Special:Translate page as well – the more I use it with your temporary skin-invert hack, the more I think it should really be only a temporary hack: the yellow background of the outdated marker is invisibly dark, other colors are just annoyingly slightly different than the actual night mode colors.) Of course, a Vue rewrite is also a long-term solution, I don’t expect it to go out with the next train.

I think there’s some confusion about the wording:

I haven’t got around replying here. Thanks @Jdlrobson for reversing the decision on the style removal (at least for now)!

In T374794#10176548, @Jdlrobson wrote:

You should only need Babel, Minerva and MediaWiki setup to replicate this!

Please note that the above config change was reverted in rOMWC6c73b0a4e03d9fd1fda1d67603af0c705832d9fb.

Unfortunately, the user name itself cannot be used in messages rendered in JavaScript, so the developers will have to add a new parameter, exclusively for usage in {{GENDER:}}.

In T341349#10164007, @Od1n wrote:

When using the visual editor, the hook is fired, providing a $content element that is completely wrong:

In T374499#10149891, @Jdlrobson wrote:

These are not currently marked as a stable interface.

In T373682#10123358, @Bean49 wrote:

<Button> within <a> was perfect. Thanks to @Tacsipacsi we cannot open it in new tab. What was your problem with button within a? It is the recommended method.

Sorry, I haven’t get around replying on T374214. Since that task is now closed, and we’re actually back to where we were when the current task was opened, I think it makes more sense to reply here:

In T319690#10144907, @Jdlrobson wrote:

This is the current behaviour which seems fine.

While I agree with @Aklapper that this task is not “invalid,” I also think that dropping Diffusion mirrors would be a big loss, and in the end users would spend more working it around than what administrators would win:

• The handy links in tasks wouldn’t work anymore (including already-inserted ones!), let that be a commit link (bb1d0aca814d), or a link to a certain file (rMW includes/recentchanges/ChangesFeed.php) or a certain line of a file (rMW includes/recentchanges/ChangesFeed.php:37 (at bb1d0aca814d)). This means having to resort to less useful links in future comments/descriptions, for which readers need more time to figure out what they mean; and even more time trying to figure out what the broken links to Diffusion (which probably won’t even be rendered as links) mean.
• The powerful repository browser. While basic code viewing functionality is present in both Gitiles and on GitHub, Gitiles cannot search for files or code at all, and GitHub doesn’t allow searching for code without logging in, which means having to have a GitHub account and potentially also means going through 2FA (searching for files is allowed on GitHub without logging in). Code navigation by clicking on an identifier is a useful feature of GitHub, but again only for logged-in users – for logged-out users, it works only within a file, which is hardly better than Ctrl+F, especially in languages as dynamic as PHP and JavaScript. (And remember: I’m not arguing for removing the GitHub mirror – the discoverability of GitHub for newbies is unbeatable –, only against removing the Diffusion one.)
• The diff views that are integrated with the rest of Phabricator:
  • Neither Gitiles nor GitHub render Phabricator task numbers as links (the Gerrit code review interface does, but Gitiles doesn’t; the workaround is clicking on the Change-Id – which is rendered as a link in Gitiles, though not on GitHub –, and clicking once again to get to Phabricator; or copying and pasting the task ID), while Diffusion of course renders them.
  • Similarly, the authorship information is more integrated into Wikimedia: if the author/comitter email address is connected to a Phabricator account, it links to that account, from which one can not only find Phabricator comments of that person, but also their Wikimedia (CentralAuth/mediawiki.org) account, so it’s possible to write to the talk page of the author instead of opening a task on Phabricator if that’s more appropriate; in contrast, Gitiles shows whatever one entered in user.name (which may be a fully different name, e.g. a made-up user name used on Wikimedia but full name used in Git) and generates no links, while GitHub links to the GitHub profile if there’s any, and nowhere if there isn’t (Diffusion also links nowhere if there’s no Phabricator account, but that’s less likely).

To avoid losing CSS styling of message Please see https://doc.wikimedia.org/codex/latest/components/demos/message.html#css-only-version for the updated HTML markup you should be using.

I also think that this shouldn’t be enforced, not even with the exception mentioned in T306918#8214905. Labels contain information: that thing is called that way in that language. If Q171353 had a mul label of Esztergom, it couldn’t have a German label of Esztergom, but it could have a German alias of Gran. So is this city called Esztergom or Gran in (present-day) German?

Please note that the check should work the other way round as well, i.e. disallow setting a mul label such that it, combined with the present item’s English description, conflicts with another item’s English label and description. Or another item’s mul label and English description. And of course the same for any other language as well. And this is where things may become tricky performance-wise (although I don’t know how this check is implemented, so I can’t tell for sure): if one changes the mul label of an item with n descriptions, the software needs to check 2n label–description pairs across all items in Wikidata, which is a huge increase from the current one item–description pair. I hope it will be possible to implement this without bringing down Wikidata (especially as one of the reasons for mul was to avoid bringing down Wikidata).

In T371662#10097594, @Bawolff wrote:

I actually thought the DisabledSpecialPage thing would remove it from Special:SpecialPages, but i didnt test and dont really know.

In T223772#10143083, @Jarekt wrote:

1. {{#invoke:DateI18n|Date|year=2009|month=12|day=09|hour=13|minute=20|second=17|lang=en}} is equivalent to {{#timef:2009-12-09T13:20:17|both|en}} - we call it "YMDhms" format

I’d even decline it, since I don’t think this is realistically fixable.

No, I don’t think so – it’s probably something that will never be enabled on WMF wikis, it’s for third-party wikis’ benefit.

Selecting the text character by character makes it clear that the first (rightmost) character is %, the next one is 2, then $, then s – it’s just rendered from right to left. I don’t think we can do much about the display – we can’t use <bdi>, CSS or HTML attributes in a <textbox>, and while Unicode characters could be used to force that bit to render from left to right, those Unicode characters would end up in the translation (or, if we removed them, we would risk also removing those that were inserted by the user manually and intentionally).

There are some templates that use the UI or the page language depending on the context (e.g. UI language on talk pages, page language on subject pages), which wouldn’t be served by this feature if the mode was the property of the template. On the other hand, they are and will continue to be served by the non-translation-aware-transclusion mode, so maybe serving this minority isn’t worth complicating the syntax.

Sorry, typo, fixed. (The link target was correct, only the link text had a typo.)

In T369046#10117408, @Nikerabbit wrote:

In my understanding the raw list option mostly exists for people who have so many pages on the watchlist that managing the list becomes too slow. It seems unlikely that this would be an issue with message groups. It may still be useful for people to "mass subscribe" things by pasting text there, but that feels like niche use case. Maybe we could not have the raw version at first (unless we can reuse code that would provide it for free)?

In T373769#10110688, @Ladsgroup wrote:

I'd say make it a proper dialog that can be closed only via clicking on X or cancel.

Uploaded a patch to fix the first image. I don’t plan to fix OOUI (the second image).

In T263513#10085981, @Quiddity wrote:

• Content-wise: Which aspects/use-cases can we highlight in the prose description? Is there anything else we can helpfully link people to, aside from the Special page itself? (Is there/should there be a docs page?)

In T309440#10103816, @stjn wrote:

Well, previously all of the results were available in those API requests

Per T191156#10080919

It’s way worse on file pages, even with Vector 2022:

In T309440#10100420, @stjn wrote:

It seems like an important regression from how it functioned before.

In T373543#10100978, @Ammarpad wrote:

I think for Topic subscription it's sufficient to just move subscribers to the new page or it should do both for parity with the Page watch and user expectation.

(3 subgroups) definitely looks better than the previous attempts. I think it’s still a bit (but only a bit!) less “nice” than the current display; however, it’s more understandable, so it may be worth it even on its own merit, without considering the position of the watch button. Two points:

In T372214#10058301, @dr0ptp4kt wrote:

Thanks @Nikki . Would the "Pages in this language" dropdown satisfy as a workaround?

So this is why this unfuzzying attempt didn’t work – it resulted in a null edit to Translations:Template:Requests for permissions/Closetime/text/1/en, so the fuzzying threw an exception before succeeding.

Thanks for fixing it!

In T373013#10081120, @Samwalton9-WMF wrote:

Oh I see - when page protection is used no edits are put up for review except for those which are protected, and protection controls both patrolling and visibility of edits.

In T373070#10089584, @matmarex wrote:

Patches are welcome if you want to add that, I'd review them (let's maybe do this in a separate task).

In T263513#10089579, @matmarex wrote:

@Tacsipacsi I haven't paid attention to that before, but now I tried mocking up the alternative table layout, and it results in a lot of line wrapping (given new Vector's narrow content column).

Wikibase (which is not even listed in the description) also uses configurable namespace names for its Item and Property namespaces, and even namespaces not designed to be configurable can be configured by define()ing the namespace ID before loading the extension. Couldn’t the message be specified in extension.json (for not-configurable-by-design namespaces) / a hook (for configurable-by-design ones) instead?

In T263513#6482405, @DannyS712 wrote:

I'm thinking something like

id	Canonical name	Local name	Description	Properties
0	(main)	(main)	Main namespace
1	Talk	Talk	Talk pages for the main namespace
8	MediaWiki	MediaWiki	Namespace controlling the display interface	Namespace protection: editinterface
2302	Gadget definition	Gadget definition	Definitions of site gadgets	Default content model: GadgetDefinition

In T371832#10079802, @SDunlap wrote:

Tool here: https://gitlab.wikimedia.org/kindrobot/phab-please

I see. Then maybe !405 is also of some use.

Instead of replacing the class name in i18n messages, the markup should be moved to PHP to make translation easier (especially into non-Latin-script languages) and the code more maintainable.

I’ve got a notification on translatewiki.net that two new messages are available for translation, namely tpt-cleanchanges-language and tpt-cleanchanges-language-na. However, they’re already translated into Hungarian, simply with the names cleanchanges-language and cleanchanges-language-na. Could the old translations be moved on Translatewiki (using a bot or some other technology) so that translators don’t need to re-translate them?

The Vue version (when running within MediaWiki) uses MediaWiki messages from rMW languages/i18n/codex/en.json. Is it safe for PHP code also running within MediaWiki to directly use those messages? Or, even better, will be there a PHP class in MediaWiki core that generates the necessary HTML (handling disabling/enabling buttons and showing the appropriate message based on its parameters)? Even if there won’t be a PHP equivalent of the Table Vue component, at least an equivalent of the TablePager component would be very useful.

In T369043#10077635, @abi_ wrote:

In T369043#10074095, @Tacsipacsi wrote:

In T369043#10042750, @abi_ wrote:

When the last item is an aggregate group, an icon is added that should highlight to the user that the group is a list:

To me, the meaning of the icon is not obvious at all. I’m not sure if adding the icon is the right thing to do.

Yea, the meaning of the icon is not obvious. If the last item is an aggregate group, it is rendered as a link but that will not work for colour blind users, hence thought of using another icon. Do you think a different icon will be more obvious?

In T371567#10077595, @Ladsgroup wrote:

In T371567#10076504, @Tacsipacsi wrote:

Which new design? How does it look like? Has anyone but you and @Dogu seen it,

It's literally has a video attached in T191156#10055466

Catalyst works quite differently, so I think this could be declined (and the related merge request !405 not reopened in the new repo), as there’s no point in putting so much effort into a deprecated thing.

I guess this could be declined for the old Patch Demo, since the very goal of Catalyst is to make service dependencies easy to use.

I guess this could be declined for the old Patch Demo, since containerization is what Catalyst is about (I’m not sure if it uses Docker Compose under the hood, but it doesn’t matter either).

That part doesn’t annoy me much, but I wouldn’t mind removing the Cancel button either. Although F57282452 shows that there’s another button for reviewers, probably keeping that and removing Cancel wouldn’t be too unbalanced either.

As far as I know, ‘protect mode’ cannot be used on wikis where all articles require review (which is most FlaggedRevs wikis: dewiki, arwiki, ruwiki, huwiki etc.), but Special:Stabilization is able to change the default visibility settings: for example, dewiki shows the latest version of some sandboxes, even though the default is to show the stable version; and ruwiki shows the stable version of some high-traffic pages, even though the default is to show the latest version.

In T191156#10078877, @Ladsgroup wrote:

Tech news time again:

The indicators at the top of articles shown by flagged revs (also known as pending changes) have changed to be more standardized.

Per https://gitlab.wikimedia.org/repos/ci-tools/patchdemo/-/issues/590#note_89788

Per https://gitlab.wikimedia.org/repos/ci-tools/patchdemo/-/issues/590#note_89788

Per https://gitlab.wikimedia.org/repos/ci-tools/patchdemo/-/issues/590#note_89788

Per https://gitlab.wikimedia.org/repos/ci-tools/patchdemo/-/issues/590#note_89788

Per https://gitlab.wikimedia.org/repos/ci-tools/patchdemo/-/issues/590#note_89788

Per https://gitlab.wikimedia.org/repos/ci-tools/patchdemo/-/issues/590#note_89788

Per https://gitlab.wikimedia.org/repos/ci-tools/patchdemo/-/issues/590#note_89788