Commons:Village pump/Technical/Archive/2020/09

Annotations not working

Is it only me, or are annotations broken for anybody else as well? I neither see any existing annotations nor does the button "Add note" appear. I tried with Firefox and Chromium, under Windows and Ubuntu, logged in and logged out, all the same. --Reinhard Müller (talk) 07:47, 11 September 2020 (UTC)

Seems like it's working again today. --Reinhard Müller (talk) 15:45, 12 September 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Reinhard Müller (talk) 15:45, 12 September 2020 (UTC)

Why is the captions header AFTER the captions box?

This is what I'm talking about, is the view similar for you? (Just look at any pic on commons.)

Seems like putting the cart before the horse to me. (Captions on Commons) --Palosirkka (talk) 08:19, 5 September 2020 (UTC)

Tech News: 2020-37

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Changes later this week

• Normally pages can be moved to a title that has no existing page yet or to a page that has only one revision, which is a redirect to the page to be moved. A new user right allows editors to move pages over one-revision pages that redirect to anywhere. [1]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 8 September. It will be on non-Wikipedia wikis and some Wikipedias from 9 September. It will be on all wikis from 10 September (calendar).
• All MediaWiki API modules will now use watchlist instead of watch. This was inconsistent before. [2]

Future changes

• The Wikipedia Android app team might work on patrolling tools in the future. You can let them know what tools would be useful for you or for less experienced patrollers. See the page on mediawiki.org.
• OTRS will be updated to a new version. This will probably take around two days. OTRS agents will not have access to the system during these days. Emails that come in during the update will be delivered when the update is done. The plan is to start around 08:00 UTC on 14 September. This could change. [3]
• The Wikipedia Android app will send push notifications if users want them. This could help you see for example when someone wrote on your talk page or your edit was reverted. This will need Google Play Services to work. It will also be possible to get the app without Google Play Services but push notifications will not work. Google Play Services is also used to make the app work for Android 4.4 users. [4][5]
• Wikimedia code review could move to GitLab. It would be hosted on Wikimedia servers. You can take part in the consultation.
• Dropdown menus in the Vector skin use a .menu class. This will not work in the future. Scripts can use nav ul instead. .vectorTabs and .vectorMenu will also not work. Some scripts need to be updated. You can read more in Phabricator.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

15:59, 7 September 2020 (UTC)

Redlink color

Tracked in Phabricator
Task T262507

Has anyone noticed that a change in the color of redlinks? It used to be the same as English Wikipedia, which is still #ba0000, but now it appears to be #dd3333. -- King of ♥ ♦ ♣ ♠ 22:47, 9 September 2020 (UTC)

@King of Hearts: Yes! It's kind of strange. — Draceane ^talk_contrib. 10:37, 10 September 2020 (UTC)

SVGs with textpath

Hi! I realized that the textpaths on this SVG I traced and uploaded don't display in the PNG that shows on pages. How can I fix this? Font compatibility is not the problem as far as I can tell. DemonDays64 (talk) 05:46, 12 September 2020 (UTC) (please ping on reply)

Μακεδονία

Why are the images overunning the container and the nominal translations collapsing EVEN after I close up the mismatched tags? Suggestions? ShakespeareFan00 (talk) 16:55, 12 September 2020 (UTC)

@ShakespeareFan00: which images? DemonDays64 (talk) 18:41, 12 September 2020 (UTC)

Subsequqnt to the above request User:Izno provided a repair. ShakespeareFan00 (talk) 18:42, 12 September 2020 (UTC)

Big files upload

I have been trying to upload these five big files but failed. Can anyone help to upload? Please upload using the original name and I will fill in the details. They are in public domain.

Download link: https://pan.baidu.com/s/1Q2-PhHpYflSCS4UTVTN72w code: sp9w

--維基小霸王 (talk) 06:14, 8 September 2020 (UTC)

@Fæ: Would you help please? --維基小霸王 (talk) 14:23, 8 September 2020 (UTC)

Took a look, but though I can see the contents online, I cannot download the files without installing baidu weird apps on my computer. In the light of recent increases in Trojans, not going to do that.

However without having to touch these myself, I can point you to this likely source of the problem which makes uploading pdfs or djvu files of large sizes potentially un-uploadable.

I could also customize my IA uploader time-boxing process which endlessly keeps on forcing the WMF servers to try to accept the documents, however that is not guaranteed to work for some files, plus it would have to wait on me being interested in making a version which takes a local list of files, which is of limited use. --Fæ (talk) 19:09, 8 September 2020 (UTC)

@Fæ: Can you download from Google Drive? https://drive.google.com/file/d/10X_UDkzhl0k0WpBPEDqp-0FF9jadAPqr/view?usp=sharing, https://drive.google.com/file/d/19AntN1HavChxiO0s1Qb_-P2N1JBag6hl/view?usp=sharing, https://drive.google.com/file/d/1LdArETdrWrl-G8sE0JaHNbGftGKWJG9T/view?usp=sharing, https://drive.google.com/file/d/1mNoIsMksFqzoOZosbjIE0H-Y1ITnTLLW/view?usp=sharing, https://drive.google.com/file/d/1n_T5yzzTDNkcecz08OZIRZDyRTdMO25I/view?usp=sharing

Notably, two of the files are the only left in my batch of Category:Scans from the China Academic Digital Associative Library. After your help, my complete archive downloaded from baidu will be completed upload.--維基小霸王 (talk) 13:20, 9 September 2020 (UTC)

Will do a test. Not sure any will be up-loadable due to WMF server bugs. It'll take a while, even locally caching a file is taking a long time. Keep in mind my antiquated computer (follow link if you want to support me getting a second hand laptop from the WMF). --Fæ (talk) 15:22, 9 September 2020 (UTC)

Thanks! Supported. --維基小霸王 (talk) 01:42, 10 September 2020 (UTC)

Failing so far, sequential upload runs already lasting over 90 mins a time. It seems fairly likely the cause is T254459 which probably will stop most multi-page files that are 'large' depending on exact encoding method. If exceptionally valuable, it may be worth re-compiling the documents in a way that the WMF servers might find easier to process. See this residual log for some large files that did eventually get uploaded, though the largest to succeed recently was 1,706MB. I cannot safely run more than two in parallel due to memory and potential for over-heating issues.

1. File:CADAL06200030_嘉興府志.djvu 1,731MB
2. File:CADAL06200072_杭州府志.djvu 1,128MB
3. File:25资治通鉴.pdf 1,135MB
4. File:CADAL06200076_處州府志.djvu 870 mb
5. File:20宋史.pdf 831 mb

Update Adapted programme to run through these sequentially, so only attempting one at a time. Each time-out or failure it moves to the next in a loop. An alternative for you to examine is manually processing these documents to break up the file into sections, perhaps keeping the sub-section files down to 100MB. In the past I have manipulated PDFs with Libre Open Office, which has a archive compliant PDF export built-in. It's an awkward work-around but seems to be effective for individual files. --Fæ (talk) 10:31, 10 September 2020 (UTC)

May be I should try to split the files. --維基小霸王 (talk) 00:35, 11 September 2020 (UTC)

There have been 8 completed upload attempts for every file, of which half have been for more than an hour long time-box. This uses a chunked upload with chunk size of a smaller than normal 400000 (400K), to limit issues from connection problems. This is the same configuration as the IA books uploads. As size is not necessarily of itself the reason these do not get accepted, I'll let it continue for a while, but it seems unlikely that any will be uploaded given the WMF server bug. --Fæ (talk) 07:11, 12 September 2020 (UTC)

@Fæ: Thank you for your efforts. I have uploaded these files after splitting them. --維基小霸王 (talk) 12:22, 14 September 2020 (UTC)

They are on loop 19, though I noticed that at least one of these gave up after no attempt due to some sort of connection drop out. Haven't stopped it yet, I'll probably abandon the process this evening. --Fæ (talk) 13:07, 14 September 2020 (UTC)

Tech News: 2020-38

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Problems

• The Wikipedia apps briefly showed pages without CSS last week. This meant they looked wrong. It was quickly fixed but cached pages without CSS were shown for a few hours. [6][7]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 15 September. It will be on non-Wikipedia wikis and some Wikipedias from 16 September. It will be on all wikis from 17 September (calendar).

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

16:17, 14 September 2020 (UTC)

tiffinfo command failed: '/usr/bin/tiffinfo' '/tmp/phpUgvD6T' 2>&1

I tried to upload the tif I got from https://phil.cdc.gov/Details.aspx?pid=12505 "Click here for hi-resolution image (7.96 MB)". Uploadwizard tells me the error code in the section title. Can someone knowledgeable upload the photo for me? Thanks!--RZuo (talk) 16:57, 14 September 2020 (UTC)

@RZuo: There's a reason that TIFF has the nickname "Thousands of Incompatible File Formats". Instead of breaking out the hex editor and trying to figure out what exactly was wrong with the encoding and if it could be fixed, I just converted the file to JPG. File:Partial Deletion of Short Arms of 5.jpg. --AntiCompositeNumber (talk) 17:26, 14 September 2020 (UTC)

How to remove watermark layer in PDF using Python?

I want to remove watermark layer in PDF using Python. The watermark layer is an image inserted to every page. Some times text were inserted. They can be removed by Acrobat but it's not realistic for a huge number of pages. Is there a way to remove automatically using Python? This has to be done in WMF server with limited RAM.--Public domain book uploader (talk) 06:28, 15 September 2020 (UTC)

VICbot

It has come up at VIC that User:VICbot is not working. Its operator, Dschwen has been largely inactive for the past couple years. Anyone around that might be able to take on this task? Ongoing discussion here: Commons_talk:Valued_image_candidates/candidate_list#Problem_in_VI_:_news_of_the_day — Rhododendrites ^talk |  21:06, 16 September 2020 (UTC)

Deletion requests tag template

"Do not delete this tag until the deletion nomination is closed." This is a wrong expression. It should be: "Do not remove this tag until the deletion nomination is closed." I do not know where to find and edit the template. Can one of my followers kindly take the initiative please? Thanks in advance. --E4024 (talk) 15:24, 19 September 2020 (UTC)

@E4024:  Done in Special:Diff/464999764 --AntiCompositeNumber (talk) 15:54, 19 September 2020 (UTC)

Tech News: 2020-39

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

• There is a new tag for reverted edits. For example you can see it in the recent changes feed or in the article history. It is added to edits when they have been undone, rollbacked or manually reverted to an older version of the page. [8][9]

Changes later this week

• The number of times you can do something in a period of time on wiki is limited. This could be the number of edits per minute or the number of users you email in a day. Some users are not affected by all limits because of their user rights. They could soon see the limit even if it does not affect them. [10]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 22 September. It will be on non-Wikipedia wikis and some Wikipedias from 23 September. It will be on all wikis from 24 September (calendar).

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

21:25, 21 September 2020 (UTC)

IIIF developments -- office hours *today* (21st) and tomorrow (22nd)

(copied over from COM:VP)

A few weeks ago, ticket phab:T261621 quietly got opened on Phabricator, "Support the addition of the IIIF API for Wikimedia projects regarding content partnerships"

"The WMF platform team is working on implementation of a IIIF API (International Image Interoperability Framework) for the Wikimedia projects and WMSE will provide support around the needs from our content partners."

As a first step towards this, WMSE has announced two GLAM & Culture team Office hours, on the subject of "IIIF on Wikimedia Commons"

The first office hour is *today* (Monday 21st Sept) at 3.30-4.30 pm UTC (4.30 pm UK time).

"We will be joined by staff and members of the IIIF consortium and Evan Prodromou, Product Manager in the Foundation's Platform team. Evan is scoping a potential implementation of International Image Interoperability Framework (IIIF) on Wikimedia Commons and he is very interested in potential GLAM use cases."

The meeting will then be run again tomorrow (Tuesday 22nd Sept) at 11.30am-12.30pm UTC (12.30 pm UK time):

"We will be joined by staff and members of the IIIF consortium and Jason Evans will share his experience with IIIF at The National Library of Wales."

The WMSE team are particularly interested to hear about GLAMs' experiences with IIIF; what IIIF capabilities on Commons could be most useful to them; and, therefore, what capabilities and use-cases it would be most useful to prioritise development around.

More about IIIF in a moment, below, but I just wanted to get this up a.s.a.p. in case anyone who is interested managed to see it in time. Zoom links via the announcement on meta. Jheald (talk) 14:38, 21 September 2020 (UTC)

For background, see to start with c:Commons:International_Image_Interoperability_Framework. Jheald (talk) 14:52, 21 September 2020 (UTC)

IIIF had its origins with several national libraries and leading university libraries in the USA and Europe, who found themselves making available high-resolution images of content such as illuminated manuscript pages, each institution through their own viewer, that they were either having to maintain and develop independently as individual siloed applications, or that were proprietary solutions that they were getting locked into. So IIIF was born, to develop some standard APIs for serving images and providing metadata relating to them, that (i) would allow multiple standard viewers and other apps to be developed, all of which would be able to access content from all of the institutions, and (ii) would be able to go further than that, and allow content from different institutions to be combined -- a paradigm case being eg to present a virtual illuminated manuscript as it would have been as a single entity, even if its pages were now spread out across a dozen institutions across the world.

Although there are also further APIs now, two fundamental APIs are the Image API which allows an app to request a page (or part of a page, or tiles of a page) at the particular resolution it would like; and the "Presentation API", which allows the metadata for images or groups of images to be described.

Some of this we already have small test implementations of -- for example the Commons panorama/zoom viewer is essentially a small off-the-peg IIIF-aware browser app running against a IIIF stack on toolserver, which efficiently sends the zoom-browser the image, or the part of the image, that it wants, at the resolution it wants it, without the browser app ever having to download the full entire image (which might be enormous), or having to handle any of the server-side back-end.

However, the zoom viewer has proved flaky (eg it's currently down at the moment I think), because it relies on keeping (i) a separate image-service running (ii) on toolserver, and (iii) handling all its cacheing. So rather than a separate stack, the hope is that this will now be provided centrally, built out from MediaWiki's existing image-scalers and image-caching system, which should make it (a) much more robust, (b) much more likely that the image will be in cache, so that (c) there should be much better guaranteed availability, with images hosted on Commons (and images hosted on other MediaWiki users' platforms) fully available as part of the IIIF universe, that any/all IIIF browser/viewer/app will be able to use.

Apart from image/book browsers and viewers, "Map Warper"-type tools for the georeferencing of old map images are another kind of application that can really benefit from the ability to get just the part of the image they want (or tiles of it), at just the resolution they want, without having to handle the whole entire image (which can often be very big). Some modern georeferencing applications eg those from Klokan now use IIIF exclusively to manage accessing the relevant parts they want of the underlying old map images. Having everything available via IIIF API also makes it easier for other apps to be constructed, without having to deal with the massive underlying images; and to combine views of images all coming from different places on the net.

Official Commons support for the IIIF Image API should also make it easy to e.g. define and display a crop of a particular part of a high-resolution image to display on a Wikipedia article, without that crop having to be specifically saved as a separate image on Commons.

A second key API is the presentation API used to make available metadata describing an image or a group of images.

As a toy example already running, a user tool exists to generate a simple IIIF manifest from the Wikidata item for a painting, and its associated Commons image.

• So for example Wikidata item The Coronation of Napoleon (Q1231009) is associated with Commons image File:Jacques-Louis David - The Coronation of Napoleon (1805-1807).jpg.
• From the Wikidata item, this is the IIIF manifest generated by the tool: https://wd-image-positions.toolforge.org//iiif/Q1231009/P18/manifest.json
• And then this IIIF manifest can be given to any one of a number of standard IIIF viewers, for example Mirador: https://mirador.toolforge.org/?manifest=https://wd-image-positions.toolforge.org//iiif/Q1231009/P18/manifest.json

ALSO: Code at sciencestories.io that can take a Wikidata Qid, and make an IIIF manifest of all the images in the corresponding Commons category, eg: http://www.sciencestories.io/Q34091?moment=2

ALSO: Code by Tom Crane [11] (blog) to make an IIIF manifest for images in a Commons category, eg: [12]

Mirador can then display the metadata about the image, which is made available under the "(i)" button on the top right; and also some simple annotation info that was provided, which is toggled on by the "speech bubbles" button on the top left. Both of these are currently just generated from what is available in the Q-item, and just for this single painting; but it's possible for the metadata presented to be quite a lot more complex than this, and also to contain info on a whole set of images (eg images for a whole book, including different page ranges and page sequences; or, for us, for example, all of the images in a category, or set of categories, perhaps).

Various standard IIIF tools exist that can consume such metadata "manifests", and allow the user to edit together a new manifest -- eg perhaps pulling together all those manuscript leaves; or to package metadata together about a particular collection of objects; or to make an authored presentation about the images. (Capabilities sometimes called a cross between PowerPoint and Photoshop, but working with images located on and their home services and drawn from them, rather than copied into the final document).

Jheald (talk) 15:07, 21 September 2020 (UTC)

UPDATE:

• Homepage for the WMF IIIF effort is here: mw:Core_Platform_Team/Initiatives/IIIF_API (just a stub at the moment)
• It's being led by the API team, so the initial focus is to use this as a first case of trying to extend the APIs that MW supports, to start to try to make existing WM content additionally available through standard APIs already in use in the outside world, rather than bespoke APIs that have been created specifically given MW's own internal needs. IIIF with its heavy applicability to the GLAM sector was seen as a natural place to start.
• The initial "minimum viable product" might be just Level 0 of the image API -- i.e. packaging access just to whole images. A first stab might be available in Q1 2021, that could then be the basis for further iterative improvement. Anything that would take more of a hack into the MW media code -- eg crops, tiles, crops of rotations, etc -- would be further down the list to be done, perhaps a lot further down the list.
• That said, the API team hadn't known about the IIP-Image service on Toolserver, that (sometimes) supports Zoom viewer. There is a possibility that this could be taken in house, running the service with full managed reliability, and straightaway delivering IIIF Level 2 functionality. ((Though presumably there could be issues with managing a separate code stack, parallel to the MW stack, with its own set of images and intermediates to cache. These are still to be evaluated, since the service has only just come to the team's attention. On the other hand, it might provide a baseline L2 implementation that could then be transitioned part-by-part to use more and more of the MW stack, rather than its own. But given this is being led by the API team rather than the Media team, to what extent would that be something they would want to take on?))
• There was considerable interest from attendees in code that could process supplied IIIF manifests on the upload side, and use these to create appropriate Wikidata / SDC / Commons file-page metadata. (And/or to make such pre-existing manifests available (and more visible) in parallel to Commons's own metadata).
• There was also some input from attendees on the value of generating at least a basic IIIF manifest for each Commons file, as the URLs for such manifests are the standard thing to give to IIIF applications, for them to work with or present the given files. ((Given a manifest for each file, perhaps a gadget could then be created reasonably easily, to put together a combined manifest for all the files available in a Commons category, or used on a Commons web-page?))
• Use-cases, and feature discussion, can be presented to the team on the talk page mw:Talk:Core_Platform_Team/Initiatives/IIIF_API
• A more complete read-out from the sessions will be pulled together. In the meantime, the Etherpad for today is at https://etherpad.wikimedia.org/p/zRJ6XC5Ne6iGkPI8pv5G

Jheald (talk) 18:18, 21 September 2020 (UTC)

Do you remember that the COM:VP/T was hotly debated, but in the end the 'technology' village pump was created? This looks like a topic that would be of interest there, but of not much wide interest here. --Fæ (talk) 10:11, 22 September 2020 (UTC)

Accordingly cut and pasted to here. Jheald (talk) 10:25, 22 September 2020 (UTC)

Even if it is still a little bit silent here I still guess that people would like if there would be IIIF image server for Commons photos for dynamical cropping/rotating instead of just for scaling. There would be a lot of use cases for that in local wikis too. --Zache (talk) 13:27, 22 September 2020 (UTC)

@Zache: Yes, that was certainly a use-case that people talked about a bit yesterday. Less about it today, but User:salgo60 (I think) did talk about the en:generation loss you get by constantly making new derivative copies -- not just a loss in image quality, but also an increased distance from the original accompanying metadata: so that the copy's metadata is more likely to be garbled; is certainly likely to be not as complete; and will not benefit from metadata improvements made to the original (also vice-versa, the original will not benefit from metadata improvements to the copy).

So for all of these reasons, as well as avoiding the work & duplication of uploading, describing, and managing the derivative image, it would be nice just to be able to specify a crop of the original. And it would help with tracking how the original was being reused.

BUT: extending the wiki Image: image syntax to specify dynamical cropping/rotating would require some work, which may be more than API team may be considering. So if this feature would be valuable, it is worth making a case for in discussions about what to prioritise and try to get resources to make happen. Jheald (talk) 14:24, 22 September 2020 (UTC)

UPDATE: CALL2

• Jason Evans (User:Jason.nlw) on National Library of Wales as an example of how GLAMs can use both IIIF and Commons/Wikidata together to advantage. IIIF now the primary way NLW makes content available. NLW has also made extensive uploads to Commons, and Wikidata items for collection items.
  • Export/public reuse: IIIF manifest URL (P6108) links a Wikidata item to a manifest at NLW. SPARQL queries on Wikidata make it easy for 3rd parties to find collection items of interest; get the NLW manifests for them, and present them using the manifest descriptions + images served by IIIF.
  • Metadata improvement: Over lockdown, Wikidata image positions tool used to identify *where* in an image each thing it is said to depict can be found. This info then added to NLW's manifests. Or SPARQL allows a manifest to be created showing eg just the hats in images in the collection.
  • Internationalisation: Description of items using Wikidata properties and Qids allows for easy internationalisation, eg to/from Welsh. Used by NLW's bespoke multilingual tagging tool, which runs off IIIF service, in English and Welsh. Also allows internationalised descriptions in IIIF manifests.
  • Potential for more automated import to Commons. Like yesterday, interest in Commons uploads with file-pages made directly from existing IIIF manifests (and WD items/SDC statements). DPLA has some running Python code.
• David Haskiya: Value for smaller GLAMs in having Commons as a free IIIF hosting service. Managed by WMF, so little tech input needed from them. And would open up all sorts of nice tools, again with little tech input. See outline here
  • Others added: not just of interest to small GLAMs. Groups within large GLAMs may have no spare budget, or not be able to support something public-facing.
• Many tools may use IIIF service as an image source (and may output to IIIF manifests) -- eg Recogito (transcription), Klokan (map georeferencing)
• Etherpad https://etherpad.wikimedia.org/p/zRJ6XC5Ne6iGkPI8pv5G : top half is today, yesterday is below.

— Preceding unsigned comment added by Jheald (talk • contribs) 17:15, 22 September 2020‎ (UTC)

YoutubeReviewBot

For some reason, YoutubReviewBot is not reaching File:Catullus 63 (Attis), Latin recitation, Galliambus.webm and doing its checks. I have added {{Licensereview}} to the page. I've also left a note at User talk:Eatcha. Can anyone see why the review isn't taking place? JimKillock (talk) 19:24, 22 September 2020 (UTC)

Big Query Request...

@Fæ:

Hi, can someone make a list of all the Post 1925/6 works in this category? Category:Books in the Library of Congress

This is so I can check author names against the relevant CCE renewal listings... Thanks.

If someone also wants to note, if there are works listed without a suitable date for the metadata it would be appreciated.

Prompted by the inclusion of: File:Yammy buys a bicycle, (IA yammybuysbicycle00brya).pdf In a recent upload. ShakespeareFan00 (talk) 17:13, 22 September 2020 (UTC)

Search for incategory:Books_in_the_Library_of_Congress insource:/publication date = 19(2[7-9]|[3-9])/

If you get regex timeout messages, then it can be done in simpler multiple ranges, like incategory:Books_in_the_Library_of_Congress insource:/publication date = 19[3-9]/ or incategory:Books_in_the_Library_of_Congress insource:/publication date = 193/, which reduces the 'either this or that' complexity for the search tool.

This presumes that publication date will be consistently formatted, you may find it is not. However while earlier dates may include estimates shown with square brackets like "[1890]", the later dates don't seem to.

BTW the ping did not show in my notifications. --Fæ (talk) 12:06, 24 September 2020 (UTC)

@Fæ: - Nothing unchecked in the mentioned category: but more than a few entries by tweaking the query : incategory:FEDLINK_-_United_States_Federal_Collection insource:/publication date = 19(2[7-9])/ insource:/library_of_congress/ - https://commons.wikimedia.org/w/index.php?search=incategory%3AFEDLINK_-_United_States_Federal_Collection+insource%3A%2Fpublication+date+%3D+19%282%5B7-9%5D%29%2F+insource%3A%2Flibrary_of_congress%2F&title=Special:Search&profile=advanced&fulltext=1&advancedSearch-current=%7B%7D&ns0=1&ns6=1&ns9=1&ns12=1&ns14=1&ns100=1&ns106=1

And .. 821 for the remainder of the twentieth century - incategory:FEDLINK_-_United_States_Federal_Collection insource:/publication date = 19[3-9]/ insource:/library_of_congress/ Most of these can probably be kept, but it does need someone to check the CCE vigorusly for renewals.. ShakespeareFan00 (talk) 16:56, 24 September 2020 (UTC)

I've not checked for the National Library of Education historical textbooks yet though. ShakespeareFan00 (talk) 16:56, 24 September 2020 (UTC)

Showing wrong coordinates

May I know why Category:Saint George Church (Isfahan) is showing different coordinates (32°38'24"N, 51°39'0"E) than ones inserted into Wikidata (32°38'34"N, 51°39'9"E)? --Orijentolog (talk) 07:40, 24 September 2020 (UTC)

Seems like it is solved. --Orijentolog (talk) 18:03, 24 September 2020 (UTC)

What is going on with today's PotD?

Nardog (talk) 11:10, 24 September 2020 (UTC)

@Nardog: I don't know what you're referring to. What's the issue you see with the file? – BMacZero (🗩) 02:39, 28 September 2020 (UTC)

The thumbnail didn't show at the time. The original file and versions in other sizes were fine. When I tried to open the thumbnail's URL, it returned a 403 error. 503 would have been understandable but 403? It was weird. Nardog (talk) 14:10, 28 September 2020 (UTC)

Tech News: 2020-40

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

• Admins can now see links to diffs of deleted revisions on Special:AbuseLog. This uses the interface of Special:Undelete. [13]
• Editors are automatically added to some user groups. For example editors are added to autoconfirmed users when they have edited enough times and long enough. Abuse filters can hinder users from automatically getting user rights for a period of time. They can also remove rights user have. Wikis can now ask to change how long this period of time is for their wiki in Phabricator. It is currently five days. [14]

Problems

• Last year some abuse filters stopped working because of a new change. If they tried to use variables that were unavailable for that action they would fail. This has now been fixed. [15]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 29 September. It will be on non-Wikipedia wikis and some Wikipedias from 30 September. It will be on all wikis from 1 October (calendar).

Future changes

• You can't see the language links to other language versions from the talk page or history page. They are also not shown when you edit an article. This could change. It is not decided if for example the history page should link to another history page or to the article. You can take part in the discussion in Phabricator.
• The link colours could change. This is to make the difference between links and other text more clear. You can read more in Phabricator.
• In your preferences you can choose to get different notifications on the web or by email. You will see Apps as one of the alternatives later this week. This is because the Android and iOS Wikipedia apps will use push notifications for those who want them. You can see the preferences on the test wiki. The goal is to have push notifications on Android in October and on iOS in early 2021. [16]
• You can soon put pages on your watchlist for a limited time. This could be useful if you want to watch something for a shorter time but don't want it on your watchlist forever. It now works on mediawiki.org and will come to more wikis later. You can read more and see when it will come to other wikis.
• You can see what Wikimedians think are the best new technical tools this year. You can also nominate them.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

21:23, 28 September 2020 (UTC)

Blurry thumbnail

Puerto Varas

Gallery thumbnails of this file seem to be blurry, although the file itself has a good quality. What can be causing that? I've tried to purge cache and I've made a null edit, but nothing helps. — Draceane ^talk_contrib. 19:42, 8 September 2020 (UTC)

• 

• The original is a little blurry, the camera is focused somewhere on the grass right at the bottom of the photo. However, for me the thumbs are no more blurry than would be expected from downsampling any photograph. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 14:48, 3 October 2020 (UTC)

Does a category redirect also need a page redirect?

I've long been under the impression that categories should be redirected with {{Category redirect}} and not with #REDIRECT, but I've never seen someone add both. The most obvious reason not to include the latter would seem to be that it is less clear that a redirect has taken place and obscures any files that may be mistakenly categorized under the redirected name. If a hard redirect is preferable, why would that not be built into the template? I'm surprised not to find any clear guidance on this. — Rhododendrites ^talk |  21:58, 28 September 2020 (UTC)

@Rhododendrites: I've heard that it causes some glitches to have a hard redirect. Don't know much though. There's some stuff on Phabricator to eventually fix it (but it's apparently made no progress in 15 years, like most things I've come across there…). DemonDays64 (talk) 01:53, 9 October 2020 (UTC) (please ping on reply)

Tracked in Phabricator
Task T5311

Thumbnail image different from actual file

I've got a technical question about File:Sumit Pathak.jpg. The image shown on the file's page and the one show as thumbnail in the file's history don't appear to be the same; however, if you click on the thumbnail, it displays the same file as shown on the page. This doesn't appear to be a case of COM:OVERWRITE; so, I'm wondering why this is happening. I thought it could be a cache issue, but once again only one version of the file seems to have been uploaded. For some strange version the thumbnail being displayed is different from the actual file that was uploaded. -- Marchjuly (talk) 06:07, 22 September 2020 (UTC)

Update: The file in question was deleted per a DR; so, I guess there's no longer any issue. If, however, anyone has an idea as to why something like this might've happened, then I'd be interested to know. -- Marchjuly (talk) 00:05, 17 October 2020 (UTC)

@Marchjuly: What you describe is usually caused by a cache invalidation issue. There was another version of the file that existed, and it's quite possible that the thumbnail for that version got stuck in a cache somewhere and didn't get properly invalidated when that version was deleted. That could be at the Varnish/ATS HTTP cache layer or the Swift media storage layer. Without having seen the problem live, there's no way for me to nail down what happened. In the future, it's best to report thumbnailing bugs on Phabricator and tag the Thumbor project. Phab tasks are much more likely to be seen by those who can investigate and fix problems (including me). --AntiCompositeNumber (talk) 01:16, 17 October 2020 (UTC)

Thanks for that AntiCompositeNumber. I asked the admin who deleted this file if they saw the same thing, and apparently the thumbnail was showing an another file with the same name previously deleted as a copyvio. So, perhaps the what happened was as you described above. If I come across something similar to this again, I bring it to the attention of the Thumbor project. -- Marchjuly (talk) 09:04, 17 October 2020 (UTC)