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.

I am seeing an similar issue on is.wiki at https://is.wikipedia.org/wiki/Kristín_Á._Ólafsdóttir . Can create an seperate bug if needed.

In T316559#8523516, @Theklan wrote:

I understand what the purpose is (telling the reader that some pages shouldn't have interwiki links). But... why? Why shouldnt a talk page be linked to another talk page? In which way is this good for our strategy? I would understand that the opposite is the good practice.

In T314620#8177537, @ovasileva wrote:

Seems like our next step would be to define a list of namespaces that allows for translation. Maybe something like:

@Intodesa: (intentionally using simple english) So, the issue clearly is that the page can not be linked to Wikidata. But, there is an issue underneath that one, which causes the page not to be linkable. Not sure to what extent, tho. In order to fix this, we need an namespace called "ကာရန်" in an seperate task, an task like T314023, just for "ကာရန်" instead of "Appendix" or "အဆက်လက္ကရဴ". That also means there needs to be an discussion on mnw.wiktionary on this namespace, just like there was one with Appendix.

In T47212#8484695, @VirginiaPoundstone wrote:

Looks like the boolean [[ https://www.wikidata.org/wiki/Wikidata:Property_proposal/thumbnail_sharpness | mimic property proposal ]]is not getting support.

In T256959#8440940, @Soda wrote:

I personally think this is the way we should implement this task:

• Implement a mechanism that allows Thumbor to retreive the dpi value if present in as a URL parameter and use it to render the image via Ghostscript (for example: /War_and_Peace.djvu/page1-1536px-150dpi-War_and_Peace.djvu.jpg should/could render the image with size 1536px and a dpi of 150) (This step is identical to what @Vlad.shapik is implementing)
• Write code to teach mediawiki-core's DjvuHandler (and also the PdfHandler extension) that the dpi value exists and that it can be used while fetching images
• Have ProofreadPage read the dpi value from somewhere and then pass it to MediaWiki core (my instinct would be to use a Index: page parameter for storage, since that is how ProofreadPage already allows users to set the resolution of the image).

In T26768#8445891, @VZpolodov wrote:

ImageMagick fixed the issue. Apprently it was a one == vs != mistake violating the documentation.

gAMA chunk is no longer written in SVG case.

https://github.com/ImageMagick/ImageMagick/commit/b51609986ae9d40ed0ea68bd8698a90f6d498b1f

So regenerate all?

Added a request to create a property, that specifies if sharpness should be used, as per the discussions of this task and the sister tasks of this task. See https://wikidata.org/wiki/Wikidata:Property_proposal/thumbnail_sharpness. Chose an item type property given the available property types, https://www.wikidata.org/wiki/Special:ListDatatypes. The property will not allow other inputs than yes (Q6452715) and no (Q1814990). The logic here is if "sharpness = Q6452715" then sharpness should be applied. There will be at least 1 to 2 weeks until the property gets created.

In T256959#8440628, @ShakespeareFan00 wrote:

Why can the DPI value for a given PDF or DJVU not be stored in the database directly as I indicated in my original suggestion ( I.E in the image links table.)?

The front-end at Wikisource can then just query the relevant field in the image links table, to supply to thumbor. (AS a fallback most likely, given that with the OSD changes, there was a suggestion elsewhere to support direct access to scanned images on reputable external sites like Hathi and Internet Archive.)

In T256959#8440164, @ShakespeareFan00 wrote:

The concern I have is that there would need to be a way for Wikisources to read the DPI value. I'm not sure if structured data would do that, as I wasn't sure ti was possible for one wiki to read project data from Commons directly.

The team that maintains the software that would be used for the front end is https://www.mediawiki.org/wiki/Structured_Data_Across_Wikimedia . The Wikidata team at Wikimedia Germany can also answer your technical questions, it is lead by Lydia Pintscher. In the following text I am going to explain the basics.

Possibly related: T256959, as in the linked bug might be an subtask.

Last time I checked the deletion processes across WMF wikis, 5 years ago, they where like so:

As far as Lua Wikidata calls go, you want to avoid mw.wikibase.getEntity, or at least suffix it, so it only fetches badges or whatever you are after in each case (f.x. not local entity = mw.wikibase.getEntity()). That is because it, unsuffixed, fetches the whole item. For statements you can use either mw.wikibase.getBestStatements(id, property)[1] - which skips statements that are ranked as being outdated/incorrect or mw.wikibase.getAllStatements(id, property)[1] - which gives you all statements. Looking at Module:Wikidata on es.wikipedia, that does mean changing the calls to the module aswell.

For the time Lua uses see https://grafana.wikimedia.org/d/000000139/scribunto?orgId=1&var-wiki=commonswiki
It will propably peak after the save as the pages move over to the new version and then normalize. So, compare the time after the save to when it was last edited.

Modified from F34933267

In T275319#7947012, @Krinkle wrote:

Question: Is there specific and limited concrete use case here that happpens to require a slightly higher limit to work? That is, is there some new structure or content type that has evolved that basically always needs a larger size to work, but is limited?