Yep. There is a precedent for this. There is an edit link in Wikidata bridge when Wikidata statements are used in Wikipedia. On top of that, multiple community templates do the same in that situation.
If there will be no link, then undoubtedly someone will create a template with a link to the chart on commons. Then it will become common practice to use said template with every chart invoke. Or the chart extension could just add that link itself.

Seems relevant:
https://stackoverflow.com/questions/54265699/how-to-align-the-x-axis-name-label-to-the-end-of-the-x-axis
https://github.com/apache/echarts/pull/9273
If that is not enough, then custom ticks are also a thing as an indirect fix.

This is stalled on T179769. Minor wikis are not going to change magic links while any VisualEditor change can change them back to magic links. It should be an obvious non-starter.

Can reproduce with the following steps

It is orders of magnitude harder to move graphs from the original wiki to commons, than to have them in the data namespace on the original wiki. This is especially true if the move is done with a bot. This mostly effects the datapoints, the design is often shared between hundreds or thousands of graphs.

In T137291#10063272, @Bugreporter wrote:

Another potential replacement of EasyTimeline would be T334372: Add support for inline SVG.

In T337139#9911986, @Quiddity wrote:

Hi @Snaevar (or anyone), given that the proposed parser function hasn't been merged yet, I'm wondering if you have any suggestions on how to most clearly help the editors who might need some guidance?

Ideally, I think we could write something like this, but I'm not sure if it's accurate enough, or detailed enough:

Editors who work with multilingual SVG files can add language tags to the SVG's labels. If the SVG contains labels that use a hyphenated Wikimedia specific language code that doesn't match the BCP47 standard, such as zh-classical, then those labels need to be changed to use the BCP47 code instead, such as lzh.

The way I see it "simple" is for all languages, so it could be simple German, simple French, simple Spanish, and so on. Using it for simple English only would not be appropriate. I do agree that using "simple" as an example is not that great. I got "en-basiceng" from https://en.wikipedia.org/wiki/Codes_for_constructed_languages, but I have also seen "en-simple".

I think users need to make some fixes here. The conclusion is clearly to use standards.

In T362441#9711433, @Stefan-Orvar-Sigmundsson wrote:

Camel case is not how we write things normally, but this is just a technical approach since a literal translation here does not result in a compound noun but an adjective+noun combination.

Hi,
I would like to add Icelandic Wikipedia (is.wikipedia) to the list.
Community consensus: https://is.wikipedia.org/wiki/Wikipedia:Potturinn#Heimildalausar_greinar:_EditCheck

I was able to find 60% of my queries by visiting "https://superset.wmcloud.org/sqllab/?savedQueryId=" urls from my browser history. I have those back through saving "a new query". Trying to save those by updating them did not work; I got a "Your query could not be updated" error.

This was addded in T87261, which asked for a gray box.

The largest thing here would be having the current namespaces as aliases, especially in the Template and Module namespaces. This will create a massive mess otherwise, although it will only be for a while.

The projects that we have are small and often inactive for long periods.

Not true with Wikipedia and Wiktionary, but the rest, yes. Speaking of which, there has been NO discussion of this in the Icelandic projects. Agree with the required conseus.

In T270736#9664317, @DLynch wrote:

MediaWiki:Visualeditor-quick-access-characters.json actually has something close to this already, albeit in an extremely undocumented fashion -- you can add source:true to a given character/replacement, and it'll only be shown when you're in source mode.

Fixed on wiki. Thanks for the information.

There is something weird going on. An auto-confirmed, non-sysop can not see the link. The manual says

If $wgUploadNavigationUrl is set to a url, the link is always shown, regardless of the user's permissions.

Either that is a lie or the change was not applied correctly. It could be that I am forgetting something, but nothing is pointing me in that direction. Uploads are limited to sysops on is.wikibooks. I have a theory that only sysops can see it.

MediaWiki-extensions-IPReputation seems to be the exact project. It seems to use the risk data from spur, https://docs.spur.us/data-types?id=risk-enums. Spur and stopforumspan do not track the same thing. According to a security researcher, there definitely are groups that do lower risk level stuff like spamming, but not higher risk stuff like spur tracks. There are also groups that do both. LTA (Long term abusers/vandals) reports created by users on WMF projects show the same thing.
As for handing the task over to the team responsible for iPoid and IPReputation, they clearly allready have their hands full.

Template:License template tag is also in FileImporter:
https://gerrit.wikimedia.org/g/mediawiki/extensions/FileImporter/+/7df62d4fb3d6b49c7d96ed13045031af0632e3f3/tests/phpunit/res/IntegrationTests/detailRetriever.json line 277

There is an false positive here. When the about.com domain was added to the Global Spam list, it was said that old versions of the domain where fine. (https://meta.wikimedia.org/wiki/Talk:Spam_blacklist/Archives/2023-04#about.com ) So, if an user archives an already present about.com link, they would be, under this bug, blocked from editing. That is problematic.

Sometimes new editors copy articles from one title to another because they do not know how Special:MovePage works, and are in fact fully unaware of it's existence. It is an false positive for an copy-paste copyvio check.

Icelandic Wikipedia here. We mostly use English Wikipedia styles, with a handful of styles from spanish wikipedia.

Not that my opinion has any weight, but I have some opinions on this. I think that a lot of these ideas can be done with Vega5. Since Vega4 it has supported layers, and that unblocks potentials that where not possible with Vega2. The map provided by JTanner is doable, probably even with Vega2 (although Vega2 will not be used). I am conserned about the number of dots though, Europe would probably be better as an one highlighted area, as WMF projects rarely use map closeups, but there are third party tools users can use to reduce the number of the dots. The route-map is also doable in Vega5.

In T17294#9556621, @Bugreporter wrote:

Blocks of expired temporary accounts make no sense (but admins may tend to use indefinite block for VOA) and they will inflate the database and confuse users. So some proposed ideas:

• Prevent blocks of temporary accounts for more than the lifetime (one year in Wikimedia wikis)
• Prevent blocks of already expired temporary accounts
• Automatically purge blocks of temporary accounts upon expiration

Maybe just block them?

Icelandic ISBN numbers are also a problem. They are managed by the National library (https://landsbokasafn.is), which does not have an search engine for them. They are added to "Global register of publishers" (https://grp.isbn-international.org), but that only shows publishers, not books, and is thus inadequate for Wikipedia use.
Prior to WorldCat's removal from Citoid, they showed up just fine.

In T354002#9425231, @Anoop wrote:

Stalled until tasks mentioned in T229953#5398372 are resolved

In T343131#9485825, @Jarekt wrote:

Another way to reduce size of transclude table used in the past was to run a bot job of substituting template redirects. Does anybody have a good SQL query to see if we have any templates with often used redirects? I run many such bot jobs in the past but not in the last decade or so.

In T343131#9469309, @Bugreporter wrote:

Some more specific templates (more to add): [...]

• https://commons.wikimedia.org/wiki/Template:SDC_statement_exist and https://commons.wikimedia.org/wiki/Template:SDC_statement_has_value: They are just wrappers of module invocations and only used in other templates instead of directly in file description pages. The templates using them may instead invoke the module directly. [...]
• https://commons.wikimedia.org/wiki/Template:Description: Warpper of a module and itself is only wrapped by templates such as https://commons.wikimedia.org/wiki/Template:En. Template:En should instead directly invoke the module.

Those need an function that accepts arguments, not frame. For example, https://commons.wikimedia.org/wiki/Module:SDC_tracking needs "function p._SDC_statement_exist(args)", "function p.SDC_statement_exist(frame)" will not work.

All of those icons are in codex, their names are (from top to bottom):
cdxIconMoveLast ltr version, cdxIconInfoFilled, cdxIconHeart, cdxIconSuccess, cdxIconTag rtl version, cdxIconTrash, cdxIconDoubleChevronStart rtl version.
They are all the largest variants of the icons, 20px.

The solution here is fine, but the problem is non-existant. It is a classic case of an solution looking for a problem.
In W3Cs standard (the same organization as was behind HTML4) alternative text is supposed to be short. See https://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G94
Also https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Accessibility/Alternative_text_for_images#Basics says the same, so the editor is trying to violate the rules of the project he edits the most to. It so happens that the creator of this ticket pointed out the latter point out to me, so I know he has no valid argument here.
Let's not waste more time than necessary.

The problem is that button is not in the Page namespace - random example: https://en.wikisource.org/w/index.php?title=Page:Stories_by_Foreign_Authors_(German_II).djvu/1&action=edit

Things missing (probably not exhaustive):

• Green button in "Set filters" under the "Set filters" link on the special page - or decide to use a blue one
• Date picker for "Set filters" under data range - T91148

AutoWikiBrowser has an database scanner using the dumps. Just pointing it out, seems relevant.

<span class='cdx-button'>Button text</span>

on a wiki page gives incorrect background color and color of the border. Tested on old vector skin.

It would be nice to have the "Perennial sources" list under the community config page so it can be turned off on the small and medium sized wikis, most of which do not have one.

As for inserting the characters from the perspective of medium and small wikis, it would be best to add them to "special characters" in the editors, preferrably all three (Wikieditor, VisualEditor, 2017 wikitext editor).

Might want to send a message to Arjunaraoc user talk page at https://te.wikisource.org/wiki/%E0%B0%B5%E0%B0%BE%E0%B0%A1%E0%B1%81%E0%B0%95%E0%B0%B0%E0%B0%BF_%E0%B0%9A%E0%B0%B0%E0%B1%8D%E0%B0%9A:Arjunaraoc since he is the only interface admin on that project and that te.wikisource was mentioned in T340682

It would be nice to fetch the first page thumbnail up on visiting the Index page, using the same method as with the "Page" namespace. The "Page" namespace preloads 1024px for the previous and next page. That way, an user can upload PDF/DjVu, create an index and the first page is ready when the user saves the index.

Confirmed. 1024px is pre-fetched from looking at the previous page in the "Page" namespace. It does preload 1024px even if you use an higher resolution. Making it dynamic/calculated from the users resolution would fix the issue.

If I create the json page, I get blocked with the error message "JSON should be an array". There is "{}" in the edit box by default, I did not add to that.

Looked at Recent activity on my account and saw nothing. That is despite me having around 30 saved queries. I have alpha and OAuth rights.

Looked at my browsers networking tab, loaded the same wikipage in "Page" namespace on wikisource and switched my resolution around, with these results:

I would suggest keeping ladsgroups patch, but limiting the max to 10, instead of 50.

In T337139#8896763, @IKhitron wrote:

Looks like it's not just hyphenated codes, the "simple" has the same problem.

In T270855#8921612, @nathanielcwm wrote:

Debian 12 has libjxl 0.7 integrated into its repositories.

And Apple has recently announced support for the format in Safari 17, since the last time this issue has been commented on: Google has dropped support for jpeg xl in Chrome, Firefox's implementation is still not ready.

Thumbor uses the following font packages:
https://phabricator.wikimedia.org/diffusion/THMBREXT/browse/master/.pipeline/blubber.yaml$31

In T337649#8917000, @KTT-Commons wrote:

As a normal user who know nothing about the subliminal coding, I'd like to report that the problem seems to be alleviated for the past few days. At least I don't need to push the button for some 10 or 15 times, and in general it only takes 2-3 times for Google OCR to identify the text. Did you changed something for the OCR gadget?

In T336595#8888955, @sbassett wrote:

Vega-Lite would also not pass a security review at this time.

I think Vega-Lite could replace `<graph template="MediaWiki:Piechart.vega">` and make it unnecessary. It already defines graph types, and a user can not really change those that much. I think the graph template suggests an Vega-Lite change, without mentioning Vega-Lite.

A lot of the "Filter effect" tags Cmglee used changed programming languages into rust in 2.43.2.

In T336595#8873886, @Milimetric wrote:

My proposal is to work together on a new version of the Graph extension. We can start with a simple set of charts: bar, line, pie, and world/country maps. I have to migrate Wikistats 2 from an old UI library to Codex.

I think a lot of the issues can be fixed with better documentation and UI changes. Created an specific task for documentation, so only covering UI here.

1. Provide two layouts, one without the dashboard, charts and dataset menu and one as-is. (maybe with an pre-written superset css, redirect to "https://superset.wmcloud.org/superset/sqllab/?standalone=1" upon login in superset or whatever other method). Having all of the menus for newbies is going to be an overload of information.
2. Provide the links given in quarry under "database tables" in superset. There is for example an site for looking up wikis and pairing them with clusters, like enwiki - s1 ( https://db-names.toolforge.org/).

Looked at the documentation of all three and liked metabase the most, mainly because it seems easy to get cached results.
Plus, joining like shown on https://www.metabase.com/docs/latest/questions/query-builder/join , is easy for newcomers.

True, EasyTimeline is more reliable and stable, but it is also relying on a software, ploticus, that was last released 10 years ago. Last time the servers where upgraded, ploticus was compiled specifically, and that is not something WMF does regularly. Apparantly the author of ploticus moved on to datadraw, another non-interactive graph software. That one is in python, server side and outputs SVGs. IMO a change like that would still need to happen.

I am getting a CORS error on https://mediawiki.org/wiki/Template:Graph:Lines for the first graph. The graph is supposed to get datapoints from Wikimedia Commons using the https method. Browser: Firefox 113.0 on Win10. I am not seeing an error on Template:Graph:PageViews on the same website.