Oh yeah, that looks a lot more awful. Thanks!

Looks like there won’t be QA, so going ahead and marking as resolved.

This is a very short page information page about a not existing page. Are you sure you wanted to link to this?

@Nikerabbit has T106131#1481833 been fixed in the meantime? If not, that’s probably a Translate bug.

If it’s blocked by T39617, then T39617 is by definition a subtask, not a parent task.

Then never set it. There are tons of user preferences that can be overridden through URL parameters (UI language, skin, whether to show preview when starting to edit etc.), yet none of these are automatically added to the URL, without the user doing anything. Now that visual diffs are default on most wikis (T314588), the only way to prevent VisualEditor from rewriting my URLs is entirely disabling JavaScript on WMF wikis, which I don’t want to do (or overriding history.replaceState and hoping that I don’t run into a race condition, but that’s even more hackish). If you want users to know about this parameter (which, as @Schnark said, should be very very rarely needed), you could add a help link and explain the parameter on the help page.

Not exactly the same, but I’m pretty sure they have the same root cause.

I think the language converter should skip all content that’s marked up using the HTML lang attribute to be not in the language-converted language, be this attribute added by Translate, another extension, a template, or directly by the editor.

It looks like you decided to open a separate ticket. However, I don’t see that said ticket – neither did you link to it, nor did you link from that one here. Where is it?

Scribunto takes extra steps to avoid modules accessing any part of the wikitext outside of the current {{#invoke:}} call (in particular, to avoid one module call passing data to the other one). In light of this, I find it quite unlikely that this feature will be ever implemented…

Then maybe a better column should be created, for example “Miscellaneous special pages”? I find this confusing.

I think using “Vector” and “Vector-2022” is confusing, making me wonder if “Vector-2022” is some part of “Vector”. While the technical skin names are vector and vector-2022 for legacy reasons, the UI names (e.g. in preferences) are “Vector legacy (2010)” and “Vector (2022)”, so you should use those both in the Tech News entry and the task description (or, if you want to keep it short, “Vector-2010” and “Vector-2022” may still be clear choices, but bare “Vector” is definitely not).

The alias-based approach may work when the original language is English, but likely won’t if it’s anything else (why would an enwiki template have Portuguese aliases?). Maybe a TemplateData maps mapping? In case of citation templates, the existing Citoid mapping could also be reused.

Actually, it’s broken in MediaWiki core. If I do a null edit to the rescate (język hiszpański) section (which doesn’t create a new, pending revision and thus doesn’t trigger the FlaggedRevs banner), I get redirected to rescate#rescate_({{język_hiszpański}}), which doesn’t take me to the just-edited section either (although it’s not visibly broken, but that’s just because it has no visible output). (I’m not sure why you added the MediaWiki-Internationalization tag, but it doesn’t seem right to me.)

The above screenshot is in Hungarian, but I can reproduce it even after setting my device to English. Your screenshot shows that there are some articles in the list – this scenario wasn’t broken originally (see the description), so I’m glad you didn’t break it now. 🙂

Will the “inactive” duration be a command-line parameter, similarly to “blocked for a long time”? What value do you plan to use? (I’d say one or two years; a few months of inactivity without being blocked may simply mean that the user is busy IRL, but haven’t given up returning to the wiki yet.) Does “blocked globally” mean that there’s at least one wiki the user is indefinitely blocked on, or does it take only global locks (and not blocks!) into account?

I tried to replicate the issue:

1. went to Special:Translate;
2. clicked on Export, which took me to Special:ExportTranslations;
3. selected a group, namely Help:Authority control;
4. selected a language, namely Croatian (hr);
5. selected Export in native format;
6. pressed Fetch;

but I got an error message about the specified export format not being supported, not an empty JSON file. Please be more precise.

@Nikerabbit why did you move this to the Tux column? I don’t think it has anything to do with Tux; it’s a simple OOUI select on a page other than Special:Translate.

In T331818#8686456, @Wangombe wrote:

Checks to be run include:

composer fix
composer test
php phpunit 'path/to/unit'

For the unit tests, we can focus on the tests that changed or simply run all unit tests. Integration tests are not in scope due to the time it takes to run them.

Do shell scripts in Git hooks work on Windows?

Thanks!

In T267444#8146864, @Tacsipacsi wrote:

Looks good. One minor thing is that you left out the language selector + new topic in sticky header case, which actually already exists, but the buttons are just the other way round. I think you should align the third mockup with this, as it’d be confusing if the buttons switched place when one starts to scroll down.

In T331667#8684338, @Varnent wrote:

Basically adding to dropdown menu list of languages an option for all languages already entered.

From https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/896148/comments/93cb9ef7_58d658fd:

The issue “2.” has been fixed indeed. The issue “3.” has been improved but not fixed: now the empty state text now appears at the middle of the screen, which avoids the overlap on sufficiently large screens with sufficiently short descriptions. However, if the description gets really, really long, or the screen is very small, they can still overlap (empty state text highlighted with yellow background):

Yes, this is a valid concern. Although it complicates the logic only for cross-wiki users (and developers), as a single wiki would either have topic containers in mainspace or not, probably cross-wiki users are overrepresented exactly among the users who try to understand how topic containers work. However, my second proposal (only show topic containers in $wgExtraSignatureNamespaces namespaces, dropping the mainspace check entirely) wouldn’t be more complicated than the logic you proposed – both add one condition compared to the currently deployed logic.

Just to make sure, you mean all existing translations of a particular page, not all pages of a whole wiki (and neither non-page aggregate groups, like those on translatewiki.net), right?

T331679 not really, but 26d5d44 did answer my above question. (However, the question I asked in that Gerrit change went unanswered, about which I’m quite disappointed. I didn’t – and don’t – think it justified a −1, but I do think it needs an answer.)

In T331635#8681176, @Esanders wrote:

Let's move that discussion to another task.

In T331635#8680952, @Esanders wrote:

I think the UI is pretty clearly labelled.

I don’t think so. These are the exact copies on enwiki:

• Label: Show a tab on this page to add a new section
• Help text: You can force the display of an extra tab besides the "Edit source" tab on this page which will make it easy to add a new section, or force it to not appear if it otherwise would.

Neither of these mention talk pages at all (not to mention that the DiscussionTools terminology is consistently “topics”, not “sections”, so if this thing uses “section”, one can even assume that it’s specifically designed to be used on non-discussion pages).

In T301212#8680331, @gerritbot wrote:

[mediawiki/skins/Vector@master] Allow wikis to customize whether Vector skins share user scripts and styles

I like 2 the best, but I’d leave out the horizontal lines – the appearance of an extra vertical line plus the large reply buttons make IMO clear enough where one comment ends and the next one starts.

By the way, maybe it’s a good idea to add a tracking category to pages using __NEWSECTIONLINK__ in namespaces not in $wgExtraSignatureNamespaces so that editors can easily notice them. And to rethink the VisualEditor UX, as 15 out of these 16 enwiki pages got their __NEWSECTIONLINK__s in VisualEditor edits.

Wikipedia articles should indeed not have __NEWSECTIONLINK__ and DiscussionTools, but mainspace pages of meta-wikis (like Meta-Wiki 🙂) can. If mainspace is in $wgExtraSignatureNamespaces, I think it’s safe to do visual enhancements in mainspace as well. Maybe even other namespaces should have visual enhancements only if they’re in $wgExtraSignatureNamespaces (and __NEWSECTIONLINK__ is present)?

That paragraph is about permanently blocked users, while those who can translate after the block expires are those who are only temporarily blocked, so it’s not even relevant. The relevant sentence is

Users blocked for a short duration will not be unsubscribed but will not receive the translation notifications either.

which says that temporarily blocked users won’t get notifications – this is what I disagree with.

DiscussionTools can parse (correctly) formatted dates in signatures. The Talk pages project started 3.5 years ago. Wikibase can’t parse correctly formatted dates. Wikidata started over a decade ago. What’s the difference? The signatures were already there, so the DiscussionTools developers could not tell users “you can understand these screwed-up dates, even if you loudly and unambiguously say you can’t”. Using Hungarian interface, I’ve probably never entered a single “localized” date, only ISO 8601-formatted ones, because what you call localized is not localized and unnatural (I not only write dates YMD, I also think about them YMD, writing down the day before the year takes extra effort). On display, while for most dates, one can finally figure out that they’re screwed up, 1st century AD dates are even worse: when I see 12. január 25, I immediately know it means the 25th of January of the year 12 AD – except that it doesn’t, because it means the 12th of January of the year 25 AD.

I don’t know, maybe we should ask the mentors, @jayvdb @Mvolz @Dave_Braunschweig. I just want this ticket not to be declined on the mere ground that the extension is unused, as it isn’t. I didn’t even notice that it’s about Pywikibot, as neither the title nor the description mention it (and I didn’t check the project tags).

Yes, it is: https://en.wikiversity.org/w/index.php?search=:insource%3Aquiz+insource%3A%2F\%3Cquiz%2F – 1 out of 15 content pages on enwikiversity contains a quiz.

Thanks for fixing this!

The FlaggedRevs rating box is broken on huwiki (https://hu.wikipedia.org/w/index.php?title=4_Vesta&useskin=vector-2022&uselang=en, try to hover over [review pending changes] in the indicator area – the bottom 90% of the dropdown is cut off, only a tiny bit of the border is visible), and I think it’s broken by this (I don’t use new Vector, so I discovered this accidentally, but from what I see in the CSS rules, this task seems to be the culprit). What should I do? Huwiki heavily customized the rating box in Vector.css and Vector.js to achieve something like T197912, so I’m not surprised it’s broken, but overriding even more things probably just breaks something else. The best solution would be if someone volunteered resolving T197912 and I could remove the local customization, but it doesn’t sound like a probable scenario given the number of people who actively work on FlaggedRevs…

I think there are quite a few uses, although probably not the first boxes in the Babel columns – first come the language boxes, which take no parameters, and after them the ones that do take parameters. But let’s see.

I don’t see timestamp links on the said page. Whatever gadget/user script/whatever you use to create them, it’s probably its fault, not DiscussionTools’.

The outdated status communicates to readers (by adding a pink background color) that the translation may not be accurate anymore, and they might want to check out the original version; and communicates to translators (by displaying the message in the “Outdated” tab) that the translation should be reviewed and updated as necessary. What has been changed in this message doesn’t make old translations less accurate and thus doesn’t require manual review by translators (fixing lint errors is not translators’ job, it can be done by any wikignome, without language knowledge), so the translation administrator decided that this source message change should not make old translations outdated, so that readers don’t need to look up the English version just to find out that the translation is absolutely accurate and translators can concentrate on updating translations that are indeed outdated.

And would it be possible to fix it, either by doing a database migration, or by adding a compatibility layer? It’s rare but annoying; it’s not only hard or impossible to read (I don’t remember if it even highlights the actual differences), but also impossible to get rid of – once you’ve opened the diff, you can’t close it, and need to scroll multiple screens between the English text and the translation textbox.

Okay, thanks for making the patch WIP!

This is also a 2023 CWS wish. I think it should not be implemented before the survey concludes, so that any eventual suggestions by the voters can be addressed.

I have also experienced this a few times before, but I didn’t care enough to report it. :)

In T330386#8641505, @Nux wrote:

Here is a video with touch visibility enabled:
https://youtube.com/shorts/CzaVHHAsFpE?feature=share3

It’s private, please make it public or unlisted (or something like that, I’m not sure about the YouTube terminology).

I can’t reproduce it either. Did you touch the screen when it flickered? Maybe your hand trembled, which was detected as many scrolls up (= show the button) and scrolls down (=hide the button). (By the way, it’s the new topic button, not the reply button. I was confused about what you meant before I watched the video.)

• Hard-coded file extensions

There are – rEGAD includes/MediaWikiGadgetsDefinitionRepo.php:272-282 (at 7793a9475f18) silently drops everything that doesn’t end in .js, .css or .json while it classifies pages. The classification is used in rEGAD includes/GadgetResourceLoaderModule.php:46-69 (at 7793a9475f18) – if setting ['type' => 'script'] is appropriate for .vue files, enabling Vue is as easy as changing the regex in MediaWikiGadgetsDefinitionRepo.php (which doesn’t necessarily mean that Vue actually works, just that the file extension barrier is removed).

I don’t see this suggestion incorporated:

In T139898#8629511, @Titanboo wrote:

Lydia told me about this ticket that might relate to a script I concept and wrote with Marchellangelina.

It’s quite distantly related – this ticket is about making it easier to create properties after a property proposal has concluded, while your script makes it easier to create property proposals. T259505: Create a tour/gadget for property proposal application is about starting property proposals, let’s continue there.

In T139898#8629511, @Titanboo wrote:

Hello, everyone.

Lydia told me about this ticket that might relate to a script I concept and wrote with Marchellangelina. The tool still needs to be built but feel free to discuss this.

When I first started editing Wikidata and realizing that there is a need for property, I asked @Fexpr about this and she told me about creating the Property Proposal first.

In the property proposal, there were several things that I found hard to understand, as someone whose journey of editing start from Wikidata first, not from Wikipedia:

• The encapsulation of template. What does it mean?
• The syntax of template
• The element that needs to be filled in the template
• The lack of documentation

Because of that, after creating my own proposal for several identifiers, I think the easiest way to make this accessible for someone whose wiki journey start from being Wikidata editor, is by creating a form that can be filled, so the person doesn't have to tinker with the wiki syntax under that.

The Google Forms consists of variables needed to propose a property proposal, and the script turns the response spreadsheet of the google forms into Wikitext. The Google Forms were still in Bahasa Indonesia and were written by Marchella Angelina and me, supervised by Fexpr as our coordinator.

I realize that in order to do this, there is a need to host this in a place like Toolforge so that it can be useful for everyone. Since the program just requires string manipulation, maybe all the process can be handled from user side? Setting up a server or starting as a Toolforge developer is quite intimidating for me, since I didn't have background in tech. If someone here want to help or continue discussion regarding this, I'll be very happy to be part of this.

Here's the link to the script: https://github.com/MarchellaAngelina/automated-conversion-of-attribute-proposal-fields-into-wikitext

I know it’s only one wiki, but that’s still one more than what I’d expect before calling this done.

Thanks for the fix!

@ppelberg I still see it on enwiki. I don’t think it’s resolved yet.

In T327354#8626589, @GMikesell-WMF wrote:

Section Header Edit - When you click on the section header as seen in the screenshot in the Notes section, Template used dropdown does not show up when there is No Preview but it does in RTP.

This has always been this way, regardless of whether RTP (or live preview) is enabled or not – the templates used in the section appear only once a preview is done (which happens automatically when RTP is enabled). Maybe it’s due to performance issues? When the whole page is edited, the used templates can be got from the templatelinks database table, but it doesn’t have per-section granularity, so probably a parse would be necessary, which may be abused for denial-of-service attacks (the initial loading of the editor is a GET request, which likely doesn’t have as strict rate limits as the previews, which are POST requests).

In T329805#8625159, @Dbrant wrote:

Sure, here are the relevant pull requests:
https://github.com/wikimedia/apps-android-wikipedia/pull/3836
https://github.com/wikimedia/apps-android-wikipedia/pull/3837

Thanks!

Thanks, works for me as well. In what commit/PR did you fix it? There’s no automatic comment from @gerritbot, as you’re not on Gerrit, but it’s still useful to connect tasks with code changes.

In T178356#8619854, @Krinkle wrote:

If there are other significant platform capabilities without a Basic experience, please point the appropiate team to this ticket so that we can plan ahead, e.g. by adding the missing pieces for it to work at the Basic layer.

While this probably makes sense as a default, it should be possible to bypass it (e.g. to link to the English original in a talk page discussion – yes, sometimes talk pages are editable with VisualEditor, and not only when using DiscussionTools).

(I accidentally uploaded an outdated commit message.)

In T328610#8611563, @Jdlrobson wrote:

I'm not sure exactly what you mean about NOOP mode

Let’s take an example. #p-search exists in all WMF-deployed desktop skins (i.e. Vector-2010, Vector-2022, Monobook, Timeless, Modern and Cologne Blue). As long as we don’t care about Minerva (to be honest, I don’t really care about Minerva-on-desktop – although, of course, I do care about Minerva-on-mobile), the following code works as expected (the result doesn’t necessarily look nice, but it’s usable):

$('#p-search').append('<input type="button" value="Foo">')

If the same code runs on Minerva, nothing happens. Neither does it do anything (it can’t append the button to #p-search, it doesn’t exist in Minerva), nor does it throw an error; it doesn’t even log a warning.

With T126962 having been resolved, sections can now be highlighted, which makes the selected section obvious, even if it’s at the bottom of the page: