In T432559#12405787, @Pfps wrote:

@Hakimi97
That's odd. From at least 3 July 2026 to 1 October 2026 https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_backend_update contained

"Initial Implementation: WDQS v2, a new endpoint built on QLever, will be first available to a small number of pilot users. The team will work closely with this group to learn where improvements are needed and how we can best support users in independently migrating their use cases. A self-service hub will be published by October 1st. This will include learnings from our pilot group, guidance on how all users of WDQS can migrate their work flows, and documentation on best practices for adapting all Blazegraph dependencies to our new system or alternative endpoints where needed. IN-PROGRESS"

The October date has slipped to November, but it does seem strange that you were not pointed to this timeline.

In T432559#12404888, @karapayneWMDE wrote:

@Hakimi97, at the time of your comment there was no update I could provide beyond "the project page will have the most up to date information". Dates are now available and the update is on https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_backend_update

As of today, these are:

Timeline and key dates

• Wikidata Query Service Days event: October 17 - 23, 2026
• Current phase: Initial implementation. Testing build of new endpoints with pilot group.
• Next milestones: New endpoints become accesible to community by November 1st.

Original Blazegraph endpoints will still be available, but may experience service degradation beginning February 2027.

Could you provide screen recording too at the same time? I think that screen recording might show more on how to replicate the bug.

In T129433#12381620, @SManivannan-WMF wrote:

Jumping in here to say that Baby Globe is a Wikipedia mascot as opposed to a Wikimedia mascot. So this could work if this is only meant for pages related to Wikipedia, but might not be the best option across all Wikimedia projects.

In T432559#12257735, @karapayneWMDE wrote:

@Lucas_Werkmeister_WMDE, IMO as the endpoint will be made publicly available and there is the gui on it, we have achieved the goal of the ticket and can consider this done.

@Pfps , the user agent details are not publicly available; therefore, the doc which details how to use the user agent is also not publicly available. I included the link to the doc for internal tracking purposes. You can follow the publicly available updates for the project here: https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_backend_update

In T437148#12310122, @MusikAnimal wrote:

The outstanding issue of course is there's no simple way to disable CM in this editor. Maybe we could add a toggle button to the currently very-limited toolbar.

In T431347#12309511, @EBlackorby-WMF wrote:

Hey there @Hakimi97 wanted to thank you for making that patch so that anyone who has the same concern can change it easily! We will keep this issue updated if anything changes.

Since no work is on-going, I try to become proactive and use the wrench and screwdriver icon replacing Tools icon. If anyone wants to adapt the code, here is the link https://meta.wikimedia.org/wiki/User:Hakimi97/responsiveVector2022.js

In T426040#12302318, @Samwalton9-WMF wrote:

If I watch a page, opening the popover, and then shrink my viewport, the popover ends up shifting over into the far corner. Perhaps an odd thing for a user to do, but could we instead attach to the three dot Tools menu in this case?

It is very unacceptable for mobile source editing to not include at least a very simple toolbar. Not even mentioning that the edit mode syntax highlighting could not be integrated into this MobileFrontend editor at all, and to this day who are editing Wikipedia without code syntax highlighting? Either scrap this MobileFrontend editor altogether, or add a mini toolbar adapted for this editor.

In T436607#12292735, @Mr._Starfleet_Command wrote:

Unlike for syntax highlighting, I don't think there's a valid use case for having the toolbar preference differ by wikitext/non-wikitext (not that I'd oppose it, but it seems like overkill). There are people who want syntax highlighting just for non-wikitext, but does anyone want a *toolbar* just for non-wikitext? Of course if there are such people, I stand corrected, but it seems unlikely to me.

Hi @MusikAnimal , @TheDJ and @Escargot_rouge , I have tried to add a new Pygments-like theme for non-wikitext code at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CodeMirror/+/1337238 . I can try to add Pygments-like theme for wikitext too if requested, but need some opinions on whether if it is needed or not.

UPDATE: September 6th 2026

In T436607#12277080, @MusikAnimal wrote:

"Bad idea" is a perfectly good response to this task. It's nothing pressing anyway, just meant to be food for thought. CodeMirror does a lot more than "syntax highlighting", with more features on the way, so it's mainly the nomenclature that I guess I am trying to change, and also put into question: What defines an editor? The answer seems to be a toolbar.

Building a new toolbar for CodeMirror would be a lot of work, but would give opportunity for a modern UI refresh, Codex adoption (T209059), and in the case of non-wikitext we can do away with the hacks that currently exist (same issue with CodeEditor, T47850). The idea for a CM toolbar is not new, either (T95148).

In T436158#12259692, @Bugreporter2 wrote:

Does Apache eCharts support error bars?

https://echarts.apache.org/en/index.html

@tstarling Since it was decided that the current solution is to block all public internet traffic except for those within the IP whitelist, should this task be boldly "resolved"?

In T420833#12240963, @LucasWerkmeister wrote:

In T420833#12239970, @Hakimi97 wrote:

I asked ChatGPT 5.6 Sol Extra High

This is basically the same as going “I asked the local arsonist how to prevent house fires”. LLM vendors desperately scraping the web for any source of training input they can get their hands on is the cause of this miserable problem; it’s not going to be the solution.

I asked ChatGPT 5.6 Sol Extra High, and it seems to recommend adding admission challenge (CAPTCHA, Wikimedia/OAuth-based verification, scoped bearer tokens etc), creating separate verified and anonymous capacity pools, block or strongly limit gate expensive URL classes, bring request-pattern controls (like Wikimedia’s production requestctl system) into beta clusters, and disallow the verified traffic to overload the single MediaWiki backend.

In T382824#12229763, @Jan.Kamenicek wrote:

@Samwilson : I can see that T433059 has been closed as resolved. However, this problem still persists, see e. g. https://en.wikisource.org/wiki/File:Can_Grande%27s_castle_(IA_cangrandescastle00lowe_0).pdf . Purging the cache does not help.

@Jan.Kamenicek because the current version of MediaWiki on English Wikisource is still 1.47.0-wmf.15 (rMW1dd200785a62), refer to
https://en.wikisource.org/wiki/Special:Version . The update will be shown on 1.47.0-wmf.16 so please be patient with it.

Another bug that I noticed, let say I add a new portlet on Test Wikipedia ( https://test.wikipedia.org/wiki/User:Hakimi97/common.js ), if I open https://test.wikipedia.org/wiki/Rounding?uselang=de then the page view looks like this:

This is what it looks like after merging the https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1314063 on Test Wikipedia:

In T431347#12121997, @Soda wrote:

I agree with folks that "Tools" is still the best option out of the three. Maybe something more like a tools icon might make sense?

Hi @AnneT , thanks for pinging me.

I have validated that all Growth features-related special page aliases are there on mswiki as intended, so I will close this task now.

In T315893#12126865, @Bugreporter2 wrote:

So local opt-outs can be accommodated I think.

In T315893#12126864, @DLynch wrote:

@Hakimi97 I think you're misunderstanding the technical side of this -- no change has been made to the URLs. They've always (well, for a long time) been flexible about accepting putting spaces around the :, but we haven't changed how we generate them or what we consider the canonical page URLs to be.

In T315893#12126847, @Bugreporter2 wrote:

Maybe, but we should discount objections that are just variations on "it's different!" and are not grounded in principles of computing or orthographic conventions. A lot of people don't like changes at first, simply because it's different, and then complain in vague terms, but once people have become used to it then OK. We need to only consider comments that are specific and relevant.

I still think @DLynch is not getting it. Changing from "Namespace:Title_name" to either "Namespace:_Title_name" (URL link) or "Namespace: Title name" (page title display) is a BIG cosmetic change (or even technical change if URL link change is being considered). Why don't we ask one by one language editions of Wikimedia projects (or perhaps just ask through Meta Wiki) for the final concensus regarding the implementation of it?

Let me reopen this task until it is confirmed that the changes successfully applied to mswiki (latest by this Thursday 16th July 2026). After that I will close the task.

In T368589#12105968, @DTorsani-WMF wrote:

The strongest cases seem to be either the palette or the Aa but were curious what your thoughts are (we realize there will not be consensus) and we're also wondering how Aa would work across non-Latin character languages. If anyone has experience or thougts on that last point especially, please share!

In T431662#12103345, @Urbanecm_WMF wrote:

Hi @Hakimi97, I applied the changes from the description into two patches. Would you be able to take a look at them, please?

In T430854#12097147, @ssastry wrote:

Hi @Jonesey95 we just bumped up the limit a bit higher (1000 -> 1250) to unbreak rendering on a few more pages.

We need a limit. Otherwise the pages timeout or won't render properly. So, the discussion would be around what a reasonable limit is. If you have examples of other pages that are currently broken, we can evaluate what is a suitable limit. while we also fix the rendering issue (the UX that stjn flagged).

It seems like the majority of the English Wikipedia community has leaned towards opposing the proposal of renaming "move" to "rename": https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=1362992673#Rename_%22move%22_to_%22rename%22

In T137291#12090530, @Bawolff wrote:

One thing to consider here, is as scary as the RCE is, there is a sense that the recent charts vuln was more serious in a Wikimedia context, as the RCE is mitigated by shellbox (albeit i wouldn't want to rely on that as only defense) where the XSS vuln in charts had no mitigating factor

Suggesting migration of EasyTimeline extension to Chart extension is a very bad proposal, since Chart extension itself is immature as an extension (does not support as many features as Graph extension did), and I don't believe that the Chart extension is capable of covering all usages of EasyTimeline extension. I am worried that with the current stagnant development of Chart extension, and then just give another few more years of time, the Chart extension would be forced to sunset.

It seems like the bug has been solved:

In T430471#12065648, @Soda wrote:

Re: disclosing personal info, these kinds of onwiki disclosures would typically require signing L37, which does not require the disclosure of personal information on the part of the rights holder. Heck, even the more involved WMF-NDA requires only a valid email AFAIR.

When a link is visited, why should it be stopped displaying as "visited"?

@Niepodkoloryzowany , having the right to investigate which users use a particular gadget seems like a breach of the user's privacy, and as an interface admin, I dislike any situations involving the interface admin right to sign an NDA for accessing users' private information (especially if I need to disclose my real-life legal name and other personal information). Instead, it is better if there is a mechanism for normal users to be able to give feedback through "Preference > Gadget" if there are any associated errors (instead of searching which MediaWiki namespace the gadget is located), and if interface admin(s) need to change/delete any very outdated gadget the interface admins can automatically e-mail or anonymously inform the associated users if needed.

Yup, I can reproduce it after logged out and when under mobile-responsive mode (addition of ?useformat=mobile&useskin=vector-2022 at the end of the links for any Wikimedia projects, let say Wikipedia).

Perhaps this task is related to T379135

In T368589#12054438, @Ponor wrote:

While I don't think the two T's are necesarilly latin-only, the icon should be as simple as possible. So maybe:

This-or-that: large-or-small, light-or-dark ◐

Or another idea might be something like "open book with gear" icon, which might be closer to the wording of "Reading Preferences"

In T368589#12053835, @DTorsani-WMF wrote:

While I do like the Tt idea, and the apps currently use this icon, it is inherently latin character specific, so I wonder what we might need to do for various languages. As an additional note, the Codex docs site uses the configure icon, which could also work and is maybe more scalable.

In T427868#12048993, @Novem_Linguae wrote:

In T427868#12048525, @TurboSuperAAA wrote:

In T427868#12038782, @Chaotic_Enby wrote:

Newspaper and Die coming in:

Newspaper might need more work. I wouldn't have guessed this was a newspaper. To me it looks more like a folder organizer because the width between the front lines and back lines is wide.

In T294188#12041863, @Nardog wrote:

I think y'all are overthinking this. The function of the move feature is already to rename a page. We can swap the current icon for literal and call it a day as far as this task is concerned.

At the current state, let say if the "move" is not replaced with "rename" completely, there are still some wikis that are using "rename". Perhaps a move-rename hybrid icon might be the most desirable answer? Arrow for "move", and text cursor for "rename", as below:

In T294188#12041677, @Repakr wrote:

I think we need to take into consideration before developing a new icon for move that some large wikis use the term "rename" in their translations (like ukwiki and ruwiki).

Or perhaps need to tag Language and Product Localization and I18n ?

Not sure if Content-Platform-Team should be tagged or not since this issue might somehow be related to Language Converter?

For now, what I have done to have a mobile-friendly Vector 2022 skin is to simply use the user script https://meta.wikimedia.org/wiki/User:Hakimi97/responsiveVector2022.js and then the search experience of it becomes not much different to the desktop Vector 2022 skin.

This issue could be solved, but then the min-width of Codex button icons (.vector-header .cdx-button.cdx-button--icon-only) need to be adjusted to 26 px, remove additional padding in logged-in user menu, and the wordmark needs to be replaced with mw-logo instead. Below is my attempt using userscript:

This issue could be solved by hiding other header items when the search box is active, so that search box has more space. Below is the attempt using user script:

In T427868#12038752, @Chaotic_Enby wrote:

Sadly, this one wouldn't work as the outlines try to be 2px thick (to be readable enough at 20px scale), which would prevent us from fitting that much detail. Something like a cogwheel is already hollow enough that the extra weight from it being filled isn't much of an issue (especially as readers will be used to seeing it in that state, and might be more confused by a hollow one). Best, in my opinion, to return to the previous version.

For the icon "Settings", although when enlarge the gear border could be seen, it is almost becoming a "flower" like pattern, which is misleading:

In T429657#12038328, @Ladsgroup wrote:

Because we want newcomers to be less confused. A wiki is not just the old-timers.

How do you measure whether the newcomers would be more or less confused with the word "move"? Do you have any additional data or metric across different language editions of wikis to support this statement?

Regarding the word "move", alternatively we can think of something like "move an item" or "relocation". Something like these icons could be considered:

Allow me to disagree. Why now when this could be done long time ago, and currently almost all of the wiki users have been familiarized with the terminology of "move". And also, would the change from "move" to "rename" be truly guaranteed to not break any "move/rename"-related functionality, because I believe the functionality is used heavily in wiki infrastructure? And also, what icon would be used if let say the "move" becomes "rename"? I am not sure if the design options for "rename" icon would be anything better than "move".

In T427868#12035539, @Chaotic_Enby wrote:

Tried to adapt a few of the old icons to the new outline style. For the Article, Articles, ArticleDisambiguation and ArticleRedirect ones, I made both a version that allows a bit more freedom to match the old style, and a version that follows the new style's guidelines more strictly.

In T399175#12033103, @Bahnmoeller wrote:

Who will change the icon on the different Wikipedias? The volunteers want other things like writing articles.

In T399175#12027997, @Aklapper wrote:

@Hakimi97: https://meta.wikimedia.org/wiki/Tech/News/2026/24 says that "The user interface icon library will be updated later this week or next week."