Commons:Village pump/Technical

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Shortcuts: COM:VP/T • COM:VPT

Welcome to the Village pump technical section
Technical discussion
Village pump/Technical
　Bug reports
　Code review
Tools
　Tools/Directory
　Idea Lab



This page is used for technical questions relating to the tools, gadgets, or other technical issues about Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; recent archives: /Archive/2023/09 /Archive/2023/10.

COMMONS DISCUSSION PAGES (index)
Please note
 

Start a new discussion

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

Request to add Tai Ahom Unicode to Commons[edit]

Moved to MediaWiki_talk:Titleblacklist#Whitelist Tai Ahom alphabet

RSVG rendering preview on user:Rillke/MwJSBot.js not working[edit]

Tracked in Phabricator
Task T345972

When I preview any SVG using User:Rillke/MwJSBot.js, I don't get the RSVG rendering preview to work. It just shows the default File:Bug blank.svg as if the SVG is broken, but they aren't. Am I the only one having this problem? Jonteemil (talk) 16:48, 23 July 2023 (UTC)Reply[reply]

Anyone? Jonteemil (talk) 14:48, 28 July 2023 (UTC)Reply[reply]
@Glrx: Can you confirm or disconfirm this? Jonteemil (talk) 19:11, 2 August 2023 (UTC)Reply[reply]
@Jonteemil and Rillke:
I've been using User:Rillke/SVGedit.js for a time, but I have not paid much attention to the RSVG rendering. I usually do not hit the preview button. When I do, I'm happy to see a local SVG rendering. RSVG departs from the SVG specification in a few places.
The RSVG preview has not worked in a long time. For example, using SVGedit on File:IPv6 header-en.svg (which specifies a width and height) does not produce an RSVG preview.
If I look at the SVGedit code, line 396 does a fetchPreview(val). I presume that obtains the RSVG rendering. That method probably fails, so line 413 substitutes a PNG rendering of File:Bug blank.svg. (An alternative explanation is the preview method succeeds but line 399 image/jpeg is incorrect and causes a failure. I expect RSVG to return an image/png rather than an image/jpeg. Data URL claims JPEG but is PNG. Another possibility is the line 411 timeout is too short.)
Looking further, fetchPreview sends its request to //convert.toolforge.org/svg2png.php. If I go to that website and issue a request for a large (2199×1477) SVG file, I get a 500 Internal Server Error. If I give it a small file, my computer receives a appropriate PNG. I will guess the endpoint functions for at least some files.
That leads me back to guessing something goes wrong inside of line 397 .done.
Glrx (talk) 20:51, 2 August 2023 (UTC)Reply[reply]
@Glrx: Okay, I don't probably use the tool as often as you do but I do it from time to time and I always preview so I don't happen to save anything erroneous. This problem is something that I haven't experienced before so it must be some new change to the code, or the code of another program that the SVGedit tool uses. Do you know of anyone who'd be willing to take a look at fixing this? Jonteemil (talk) 04:46, 3 August 2023 (UTC)Reply[reply]
@Jonteemil and Cmglee:
You load SVGedit from Meta:User:Jonteemil/global.js, but you use Cmglee's version at User:Cmglee/SVGedit.js. That's fortunate because Cmglee is still active; Rillke has not edited in some time. You can ask Cmglee to try changing line 401 to use image/png to see if that fixes preview.
Glrx (talk) 05:32, 3 August 2023 (UTC)Reply[reply]
Thanks for your clear instructions and analysis, @Glrx: I've changed "jpeg" to "png" but the problem persists. I think rsvg previews are broken as with commons:commons_SVG_Checker. Would you be able to debug why commons:commons_SVG_Checker also gives the bug image? Thanks, cmɢʟee ⋅τaʟκ 15:34, 3 August 2023 (UTC)Reply[reply]
@Cmglee:
Thanks for running the test. I'll try looking at the HTTP transfer and see if there are cross origin issues.
The code backing the SVG Checker also uses line 451 image/jpeg:
Thanks again.
Glrx (talk) 17:58, 3 August 2023 (UTC)Reply[reply]
image/jpeg likely isn't the issue as it worked before around 2019. Don't know if Commons_talk:Commons_SVG_Checker#is_it_down? is a useful lead. Thanks too for trying, cmɢʟee ⋅τaʟκ 19:23, 3 August 2023 (UTC)Reply[reply]
@Cmglee and Jonteemil:
I go to Commons SVG Checker, select an SVG file, and then execute the SVG check.
The request to convert.toolforge.org/svg2png.php fails.
Console reports
Referrer Policy: Ignoring the less restricted referrer policy “origin-when-cross-origin” for the cross-site request: https://convert.toolforge.org/svg2png.php index.php:322:8
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://convert.toolforge.org/svg2png.php. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200.
The request fails in the browser because the svg2png does not supply an appropriate Access-Control-Allow-Origin header.
Cannot find tool on toolforge.org.
Guess this is the source
This URL should return the version:
svg2png.php line 35 calls matchOrigin($origin) and emits appropriate CORS access headers if there is a match. I'm confused. The access headers were not emitted, but if no match then no PNG should be emitted (exit is called before calling RSVG). A PNG was emitted. Is there another source? Is PHP or something else suppressing the CORS headers?
I cannot find matchOrigin; I expect it to be in shared/commons.php, but that links to Rillke (which is not 2 dirs up).
Interesting GitHub issue re toolforge and wmflabs (apparently fixed by renaming wmflabs URLs to toolforge URLs around 2020).
line 8 uses old URL:
  • $url = $prot . "://tools.wmflabs.org/$tool_user_name/";
but does not seem to be used for matching the origin.
Glrx (talk) 20:36, 3 August 2023 (UTC)Reply[reply]
@Jonteemil and Cmglee:
I suspect that is not the current source. I can convert SVG to PNG from a non-WMF origin, so I suspect the current source has deleted not only the origin matching test but also the CORS headers.
Glrx (talk) 21:19, 3 August 2023 (UTC)Reply[reply]
@Glrx: Thanks again for investigating. I must admit that your findings are far beyond what I'm familiar with. Pinging @Redrose64: and @JoKalliauer: (may not be active recently) for their opinions, cmɢʟee ⋅τaʟκ 02:22, 4 August 2023 (UTC)Reply[reply]
@Cmglee and JoKalliauer:
Turns out that Johannes cloned convert to make his SVG workaround bot. His clone has the matchOrigin code:
I still cannot explain the failure to supply the CORS headers.
Glrx (talk) 04:12, 4 August 2023 (UTC)Reply[reply]
webservice restart might work
@Glrx and Jonteemil: I do not know why Rillke's rendering does not work, maybe consider reopening phab:T217362.
I assume that Commons:Commons_SVG_Checker might use the same code, which recommends since 2019 to use @Jarry1250: tool: https://svgcheck.toolforge.org/ which works imho flawlessly. (But you have to manually upload the image.)
I assume that 
webservice stop
webservice --backend=gridengine start
would fix it, see wikitech:Help:Toolforge/Web. I also sometimes have to restart webservice for https://svgworkaroundbot.toolforge.org/ to work again.
github.com/JoKalliauer/convert doesn't help in this case, it only converts svg to (less buggy) svg, it does not render svg to png, and the issue with User:Rillke/MwJSBot.js is imho independent on the SVG, therefore it won't help. I use Rillke's code basically as black-box without understanding JavaScript, so I won't be helpful in bug fixing the code, or finding the issue.
I'm basically inactive, and stopped following treads, however I'm happy to get pinged to help. :-)
 — Johannes Kalliauer - Talk | Contributions 07:50, 4 August 2023 (UTC)Reply[reply]

There should be a Phabricator issue (or equivalent) about this toolforge app. It is used in several places, but the behavior of the installed tool does not match the existing (and incomplete) GitHub source. Furthermore, a modification to the tool source (make the web page display the PNG rather than download it: Content-Disposition header) could avoid a lot of uploads at File:Test.svg. Glrx (talk) 23:40, 18 August 2023 (UTC)Reply[reply]

Submitted Phab:T345972 Glrx (talk) 04:27, 9 September 2023 (UTC)Reply[reply]

Similar issue at Commons_talk:Commons_SVG_Checker#Previews_aren't_generated. Glrx (talk) 16:57, 8 October 2023 (UTC)Reply[reply]

Asking for help with the {{POTD viwiki}} template[edit]

Hi. Recently, I've been trying to make the POTD template for Vietnamese Wikipedia (Viwiki) on Wiki Commons, based on the {{POTD bnwiki}}, as A.Savin suggested here. Everything works well, except the link doesn't lead to the local POTD on Viwiki, but the main page of the Viwiki POTD instead. I tried to use this template on this one and see the problem. I don't know why but I guess, it's because of the differences between the two languages.

The Local POTD of the Viwiki is Wikipedia:Hình ảnh chọn lọc/Y/M/d
Example: The Local POTD of August 28th, 2023 is Wikipedia:Hình ảnh chọn lọc/2023/08/28

Thank you!
ABAL1412🇻🇳🇸🇺🇷🇺 (talk ☭) 10:36, 29 August 2023 (UTC)Reply[reply]

I've added code to the English-language version of the template so that the specific date appears when one is provided. See the image page you previously linked to for an example. I don't know Vietnamese so I'm not sure how to do this for the Vietnamese-language version of the template, but you can see what I did in Template:POTD viwiki/en.
One major change I made is that the date format must be in YYYY-MM-DD (for example 2023-08-28). This makes it easier to translate to different languages. I updated the documentation at Template:POTD viwiki/doc in English but not in Vietnamese. I would appreciate any assistance to update the Vietnamese translation.
Anon126 (✉ ⚒) 05:50, 14 September 2023 (UTC)Reply[reply]
Notify ABAL1412. Anon126 (✉ ⚒) 05:51, 14 September 2023 (UTC)Reply[reply]
@Anon126 Thank you so much! I've translated the template into Vietnamese. But when I switch the language setting to English, it still show the text in Vietnamese. - ABAL1412🇻🇳🇸🇺🇷🇺 (talk ☭) 11:16, 14 September 2023 (UTC)Reply[reply]
@ABAL1412: The language-specific version should go on Template:POTD viwiki/vi, not Template:POTD viwiki. I've fixed this, and it should automatically change the language now. Anon126 (✉ ⚒) 11:25, 14 September 2023 (UTC)Reply[reply]
Oh. Didn't know that. Thanks! - ABAL1412🇻🇳🇸🇺🇷🇺 (talk ☭) 11:26, 14 September 2023 (UTC)Reply[reply]
@Anon126 By the way, before the 20th week of 2011, the POTD isn't on Vi Wiki yet, instead, we have Picture of the week. After that 20th week, it has been changed to POTD. Would you please help me to make a template for the Vi Picture of the week? I just want to update all the assessments from Vi Wiki to Wiki Commons.

The link to the Picture of the week page on Vi Wiki is Wikipedia:Hình ảnh chọn lọc/Year/The number of the week.
For instance: vi:Wikipedia:Hình ảnh chọn lọc/2008/Tuần 45
(Note: week is tuần in Vietnamese. The capitalization rule is exactly the same as English, French, etc.)

So far, the Vi Wiki doesn't have the Picture of the year, Quality image, Value image or even Featured image. We only have the POTD, which was Picture of the week before 2011. The first Picture of the week is for the 45th week of 2008. The last Picture of the week is for the 19th week of 2011. Hope that you can help me with this one. Thank you so much! <3
- ABAL1412🇻🇳🇸🇺🇷🇺 (talk ☭) 17:15, 14 September 2023 (UTC)Reply[reply]
For this, I would suggest creating a separate template, something like "Template:POTW viwiki", which takes two parameters, one for the year and one for the week number. Anon126 (✉ ⚒) 04:10, 15 September 2023 (UTC)Reply[reply]

Page scrolls upwards after refresh[edit]

I'm experiencing a UI problem: every time I refresh an image page, after it loads, it slowly scrolls upwards for a while. Here is a screen recording demonstrating the issue: https://archive.org/download/c9sm2/wiki.webm

I'm on Linux Firefox with all addons disabled while troubleshooting. The issue happens in the skins Vector(2022/2010) and Timeless; but not MinervaNeue nor Monobook. When I disable javascript it no longer happens, and by process of elimination I've found that adding this line to uBlock stops it from happening:

commons.wikimedia.org/w/load.php?lang=en&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Cwikibase.mediainfo.statements&skin=vector-2022&version=yvqja

Does anyone know what's going on? –Vuccala (talk) 23:44, 11 September 2023 (UTC)Reply[reply]

I also experience this every now and then, but not consistently (also Firefox on Linux). I’ve only ever experienced it on Commons file pages, so I think it’s caused by Wikibase MediaInfo (which is the wikibase.mediainfo.statements part in your URL). —Tacsipacsi (talk) 14:39, 12 September 2023 (UTC)Reply[reply]
I find I now have to block all of commons.wikimedia.org/w/load.php to prevent it from happened. I have now opened a bug report on Phabricator for the issue: https://phabricator.wikimedia.org/T346591 –Vuccala (talk) 02:46, 18 September 2023 (UTC)Reply[reply]
Update: it is caused by Gadget-Stockphoto.js and I've reported the issue there. –Vuccala (talk) 14:08, 27 September 2023 (UTC)Reply[reply]

Mirror image[edit]

File:Angels Flight is seen from south as buildings are razed in Los Angeles, Calif., 1962.jpg text in image appears mirrored

..... 0mtwb9gd5wx (talk) 17:42, 13 September 2023 (UTC)Reply[reply]
@0mtwb9gd5wx: Sorry, what text you're referring to? Anon126 (✉ ⚒) 04:39, 14 September 2023 (UTC)Reply[reply]
You might have to zoom in to see it, but the funicular car at the center of the photo has a sign on top of it, and there's a liquor store sign in the background above that. Both were visually mirrored, probably because the photographic negative was scanned backwards.
I've uploaded a new version of the image which reads properly. Omphalographer (talk) 20:27, 14 September 2023 (UTC)Reply[reply]

Strange link appearing on page for Category:Test images[edit]

Category:Test images shows a link to the Foundation Wiki sandbox page: foundation:Wikimedia:Sandbox. It seems to originate from {{Wikidata Infobox}}, since it goes away when I remove it (in the preview, not actually applying the edit). But I can't tell where exactly it's coming from, and it doesn't show up when I place it in Commons:Sandbox (which is linked to the same Wikidata item). This is probably a minor issue but I'm wondering where it's coming from and if it's a possible bug in the template. Anon126 (✉ ⚒) 05:43, 16 September 2023 (UTC)Reply[reply]

@Anon126: It is. The problem is that in Module:Wikidata Infobox, foundationwiki needs to be added to the excludedProjects table to indicate that even though its name ends with "wiki", it's not a language edition of Wikipedia. --bjh21 (talk) 08:33, 16 September 2023 (UTC)Reply[reply]

Tech News: 2023-38[edit]

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

  • MediaWiki now has a stable interface policy for frontend code that more clearly defines how we deprecate MediaWiki code and wiki-based code (e.g. gadgets and user scripts). Thank you to everyone who contributed to the content and discussions. [1][2]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 19 September. It will be on non-Wikipedia wikis and some Wikipedias from 20 September. It will be on all wikis from 21 September (calendar).
  • All wikis will be read-only for a few minutes on September 20. This is planned at 14:00 UTC. [3]
  • All wikis will have a link in the sidebar that provides a short URL of that page, using the Wikimedia URL Shortener. [4]

Future changes

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

MediaWiki message delivery 19:17, 18 September 2023 (UTC)Reply[reply]

GLAMorous documentation[edit]

Is there a documentation for GLAMorous? Juandev (talk) 20:17, 20 September 2023 (UTC)Reply[reply]

File:Kobryń, Babrujskaja. Кобрынь, Бабруйская (1930-39) (3).jpg[edit]

The image displayed in file description is different from the only image stored in history (and displayed through File: code). Purge - no change. What's wrong? Retired electrician (talk) 13:55, 21 September 2023 (UTC)Reply[reply]

I'm not sure which image you're referring to. The image I see in the file description is in the "Other versions" section, which links to File:Kobryń, Babrujskaja. Кобрынь, Бабруйская (1930-39) (2).jpg. That image seems to display correctly for me. Anon126 (✉ ⚒) 05:09, 27 September 2023 (UTC)Reply[reply]

Image note not working in a specific image[edit]

Tracked in Phabricator
Task T318486

For other images, image notes work fine, but in File:SR Technics hangar at Zurich International Airport.jpg, the note is not displayed and the "Add a note" button is missing. I thought it may have to do with the placement of the categories (before/after the note), but changing this doesn't repair it, so what might be the issue? Gestumblindi (talk) 20:34, 22 September 2023 (UTC)Reply[reply]

@Gestumblindi: works for me, I see both "Add a note" button and one image note (Lockheed Super Constellation). Firefox 117.0.1, Monobook skin. MKFI (talk) 06:42, 25 September 2023 (UTC)Reply[reply]
Confirm that it's broken for me too. Firefox 117.0.1 with most recent Vector skin. I think this issue may have come up before. El Grafo (talk) 08:22, 25 September 2023 (UTC)Reply[reply]
Indeed: phab:T318486 was reported about a year ago. --El Grafo (talk) 08:30, 25 September 2023 (UTC)Reply[reply]
Im using Firefox 117.01.1 (the most recent version) as well, but "Vector legacy (2010)" skin. Gestumblindi (talk) 18:09, 25 September 2023 (UTC)Reply[reply]

Are bots still uploading Flickr images?[edit]

I just saw this upload from a bot in 2019 and I strongly believe that one is not in the Public Domain, so I wonder if this is still happening. Paradise Chronicle (talk) 22:47, 22 September 2023 (UTC)Reply[reply]

Problematic Flickr uploads with the Flickr2Commons tool are too common here on Commons, with junk or unfree files between uncategorised/mislabeled treasures. I have not seen any files be uploaded by bot-accounts lately though. Anders (talk) 18:08, 27 September 2023 (UTC)Reply[reply]

Tool "PetScan" not working[edit]

In the last 24 hours I have not had access to the "PetScan" tool. Is it just me (in Portugal) or is it global? Thanks JotaCartas (talk) 11:07, 26 September 2023 (UTC)Reply[reply]

Not responding for me either. This is far from unusual for PetScan. It's a tool used by editors, so they always have a super-low priority to WMF. Andy Dingley (talk) 11:52, 26 September 2023 (UTC)Reply[reply]
PetScan just started working aganin, good work JotaCartas (talk) 07:35, 27 September 2023 (UTC)Reply[reply]

Tech News: 2023-39[edit]

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

  • The Vector 2022 skin will now remember the pinned/unpinned status for the Table of Contents for all logged-out users. [5]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 26 September. It will be on non-Wikipedia wikis and some Wikipedias from 27 September. It will be on all wikis from 28 September (calendar).
  • The ResourceLoader mediawiki.ui modules are now deprecated as part of the move to Vue.js and Codex. There is a guide for migrating from MediaWiki UI to Codex for any tools that use it. More details are available in the task and your questions are welcome there.
  • Gadget definitions will have a new "namespaces" option. The option takes a list of namespace IDs. Gadgets that use this option will only load on pages in the given namespaces.

Future changes

  • New variables will be added to AbuseFilter: global_account_groups and global_account_editcount. They are available only when an account is being created. You can use them to prevent blocking automatic creation of accounts when users with many edits elsewhere visit your wiki for the first time. [6][7]

Meetings

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

MediaWiki message delivery 16:49, 26 September 2023 (UTC)Reply[reply]

Wikimaps Warper (can't save, defaults)[edit]

Enhancing999 (talk) 05:07, 27 September 2023 (UTC)Reply[reply]

Temporary accounts for unregistered editors[edit]

Read this in your language • Please help translate to your language • Please tell other users about these changes

Mock up of history page showing old and new username styles. The IP address 172.0.0.1 changes to the temporary account ~2024-23126-086, with an icon for revealing the underlying IP address
Next year, unregistered editors will start using temporary accounts.

In 2024, editors who have not registered an account will automatically begin using temporary accounts. These editors are sometimes called "IP editors" because the IP address is displayed in the page history.

The Trust and Safety Product team gave a presentation at Wikimania about this change. You can watch it on YouTube.

There is more information at m:IP Editing: Privacy Enhancement and Abuse Mitigation.

SGrabarczuk (WMF) (talk) 02:05, 30 September 2023 (UTC)Reply[reply]

Pywikibot file upload API ConnectionError bug[edit]

Half the time, whenever I try to upload files in pywikibot, it gives me a continuous "ConnectionError" immediately after trying to upload it. Every time it retries, the same thing immediately happens. The problem has been happening for me all night, ever since I changed my (physical) location for a brief period. Does anyone know what the cause for this might be?

To be clear, at the same time this happens, pywikibot can do any other kind of API call, including to edit regular pages or to edit Wikidata items, but uploading files is apparently the specific problem...

My Python code is just doing the following: 

file_page.upload(source=file_path, comment=edit_summary(summary, transcription_page_title), report_success=False, ignore_warnings=True)

And I know the file is definitely less than 3 MB. Here's the error it throws me immediately upon firing the upload script (and it will keep "retrying" forever): 

ERROR: An error occurred for uri https://commons.wikimedia.org/w/api.php
ERROR: Traceback (most recent call last):
  File "/Users/bobbybumps/Downloads/code_folder/core_stable_2/pywikibot/pywikibot/data/api/_requests.py", line 688, in _http_request
    response = http.request(self.site, uri=uri,
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/bobbybumps/Downloads/code_folder/core_stable_2/pywikibot/pywikibot/comms/http.py", line 283, in request
    r = fetch(baseuri, headers=headers, **kwargs)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/bobbybumps/Downloads/code_folder/core_stable_2/pywikibot/pywikibot/comms/http.py", line 457, in fetch
    callback(response)
  File "/Users/bobbybumps/Downloads/code_folder/core_stable_2/pywikibot/pywikibot/comms/http.py", line 343, in error_handling_callback
    raise response from None
  File "/Users/bobbybumps/Downloads/code_folder/core_stable_2/pywikibot/pywikibot/comms/http.py", line 448, in fetch
    response = session.request(method, uri,
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/requests/sessions.py", line 587, in request
    resp = self.send(prep, **send_kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/requests/sessions.py", line 701, in send
    r = adapter.send(request, **kwargs)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/requests/adapters.py", line 502, in send
    raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', TimeoutError('The write operation timed out'))

WARNING: Waiting 5.0 seconds before retrying.

PseudoSkull (talk) 10:16, 30 September 2023 (UTC)Reply[reply]

Tech News: 2023-40[edit]

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 user preference for "Always enable safe mode". This setting will make pages load without including any on-wiki JavaScript or on-wiki stylesheet pages. It can be useful for debugging broken JavaScript gadgets. [8]
  • Gadget definitions now have a new "contentModels" option. The option takes a list of page content models, like wikitext or css. Gadgets that use this option will only load on pages with the given content models.

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 3 October. It will be on non-Wikipedia wikis and some Wikipedias from 4 October. It will be on all wikis from 5 October (calendar).

Future changes

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

MediaWiki message delivery 01:24, 3 October 2023 (UTC)Reply[reply]

Template:No source since[edit]

Needs to be replaced in regexp so that the output is Template:File source. NBS (talk) 06:31, 5 October 2023 (UTC)Reply[reply]

Not really, because "No source since" is used on the file page, and "File source" is used on user chat pages. Snævar (talk) 15:25, 5 October 2023 (UTC)Reply[reply]
Snævar, then what do you propose to replace? NBS (talk) 20:27, 10 October 2023 (UTC)Reply[reply]
@NBS Please elaborate: What exactly seems to be the problem with Template:No source since? El Grafo (talk) 10:06, 11 October 2023 (UTC)Reply[reply]

Missing files after file move[edit]

Hi, during moving files earlier this morning, it seems that I and User:TKsdik8900 moved a number of files at the same time. I'm not sure that this is the cause or if there's some other reason why the actual files has gone missing after moving the following files:

Would anyone be able to locate where the actual files went and get them reattached to the respective file pages? TommyG (talk) 09:09, 7 October 2023 (UTC)Reply[reply]

I have tried to restore them from the original Flickr sources or Wayback Machine, but failed to find. I'm sorry for not realising you were working on them. --TKsdik8900 (talk) 09:21, 7 October 2023 (UTC)Reply[reply]
Yeah, there's a number of bugs in the file moving scripts with regards to race conditions and concurrency issues, but I don't think I've encountered this specific issue before. Most others are easily fixable but I have no idea where the files went in this case :-) TommyG (talk) 09:59, 7 October 2023 (UTC)Reply[reply]

Blanking coused by file renaming[edit]

When I renamed File:Blason Louis Nicolas d'Avout (1770-1823).svg to File:Blason Louis Nicolas d'Avout (1770-1823) duc d'Auerstaedt.svg, the automatic edit to replace usage has blanked all the contents of w:Armorial of the First French Empire in w:Special:Diff/1179001857. Was this a bug or something? It might have been caused by our moving files at the same time as above. --TKsdik8900 (talk) 09:43, 7 October 2023 (UTC)Reply[reply]

Internal error when uploading audio file[edit]

I received an error that prevents me from updating the upload of my fileː here. It says [176da193-efc3-43bd-862a-27affe7961fe] 2023-10-07 13:33:01: Fatal exception of type "Wikimedia\Rdbms\DBUnexpectedError". This is the second time this has happened.

I've researched online, and as far as I know don't see the specific factor that triggered this server issue. I use the Brave browser, only have one extension (Google Translate), and the upload is 6.91MB, which isn't that big for an OGG file. Requesting assistance. SuperWIKI (talk) 14:34, 7 October 2023 (UTC)Reply[reply]

Tech News: 2023-41[edit]

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

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 10 October. It will be on non-Wikipedia wikis and some Wikipedias from 11 October. It will be on all wikis from 12 October (calendar).
  • Starting on Wednesday, a new set of Wikipedias will get "Add a link" (Swahili Wikipedia, Walloon Wikipedia, Waray Wikipedia, Wolof Wikipedia, Kalmyk Wikipedia, Xhosa Wikipedia, Mingrelian Wikipedia, Yiddish Wikipedia, Yoruba Wikipedia, Zhuang Wikipedia, Zeelandic Wikipedia, Min Nan Wikipedia, Zulu Wikipedia). This is part of the progressive deployment of this tool to more Wikipedias. The communities can configure how this feature works locally. [11]
  • At some wikis, newcomers are suggested images from Commons to add to articles without any images. Starting on Tuesday, newcomers at these wikis will be able to add images to unillustrated article sections. The specific wikis are listed under "Images recommendations" at the Growth team deployment table. You can learn more about this feature. [12]
  • In the mobile web skin (Minerva) the CSS ID #page-actions will be replaced with #p-views. This change is to make it consistent with other skins and to improve support for gadgets and extensions in the mobile skin. A few gadgets may need to be updated; there are details and search-links in the task.

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

MediaWiki message delivery 14:36, 9 October 2023 (UTC)Reply[reply]

Flip image in Commons[edit]

I know there are tools in Commons to rotate images (CropTool and {{Rotate}}). However, I can't find similar tools or templates to flip (mirror) an image.

Is there a tool or template to flip an image? Or do we need to download the image to flip it in our computer and upload the flipped version again? Pere prlpz (talk) 20:40, 9 October 2023 (UTC)Reply[reply]

rendering of images in high res sometimes fails[edit]

File:Hietzinger friedhof hass 2023-07-18.jpg does display correctly, but in higher resolutions the rendering fails:

  • 3.888 × 5.184 Pixel not properly rotated and cropped.
  • sometimes there is even an error Error: 503, Backend fetch failed and the file does not render at all (as of yesterday).

Yesterday File:Brunnen Bad Weiherburg Detail b.JPG showed similar behavior, but now everything is ok.

&action=purge does not help. Any help appreciated. (see also de:Wikipedia_Diskussion:WikiDaheim/Jury#Anzeigeproblem_im_Vorjurytool - German). Is there a background job with a huge lag that cares for rerendering of such cases? --Christian Philipp (WMAT) (talk) 06:38, 11 October 2023 (UTC)Reply[reply]

Broken text-anchor:end in SVG renderer[edit]

Tracked in Phabricator
Task T97233

What/when has happened with text alignment in the SVG renderer? I've tried to replace sloppy hyphens with real minus signs in File:Butterworth filter bode plot.svg, where it should have been trivial, as all these labels are already right-aligned (using style="... text-anchor:end"), but instead the new rendered SVG file got all the labels left-aligned, breaking everything. Moreover, when I've reverted the file to its previous version, it also became completely broken, even though previously it was rendered with correct text alignment. It there something wrong with that particular file (which is marked "Valid SVG", BTW), or the renderer here indeed broke recently? — Mikhail Ryazanov (talk) 00:02, 12 October 2023 (UTC)Reply[reply]

@Mikhail Ryazanov:
The damage happened in April 2023 when WMF switched from the approximately 3-year-old librsvg 2.40 to the approximately 5-year-old librsvg 2.44.10 in Buster. That lost some bug fixes, so middle and right aligned text elements may now fail. See Phab:T336894 and Phab:T97233.
Frequently accessed files that have not changed since April 2023 display correctly if the pre-April 2023 PNG comes out of the cache. If the image is re-rendered, then the defects show up. That is why reverting did not restore the correct rendering -- the changes flushed the cache of the correct rendering.
Glrx (talk) 00:39, 12 October 2023 (UTC)Reply[reply]
OK, probably related, but doesn't really match the description. Namely, the entire code chunks look like this:
  <g style="fill:none; color:black; stroke:currentColor; stroke-width:1.00" id="g630">
    <path d="M140,348 L158,348 M1197,348 L1179,348 " id="path631"/>
    <g transform="translate(123,357)" style="stroke:none; fill:black; font-family:Times; font-size:28.00; text-anchor:end" id="g632">
      <switch><text id="text633">
        <tspan id="tspan634">−50</tspan>
      </text></switch>
    </g>
  </g>
There is only one <tspan> element within each <text>, and no x/y at all (only transform="translate(...)" in the parent group). Or this bug has a broader scope and also appears when text-anchor:end is inherited rather than applied directly to <text>? Or it doesn't like <switch>?
In any case, is there any reasonable solution for now? (I can edit the file as would be required but don't want to do so by trial and error and clutter the history.) — Mikhail Ryazanov (talk) 01:07, 12 October 2023 (UTC)Reply[reply]
BTW, why did <syntaxhighlight> insert these colons at each line in my comment above? — Mikhail Ryazanov (talk) 01:10, 12 October 2023 (UTC)Reply[reply]
@Mikhail Ryazanov:
You have a #text node before and after the tspan element. Under the rules, leading and trailing spaces should disappear unless you have xml:space="preserve". Try this: 
  <g style="fill:none; color:black; stroke:currentColor; stroke-width:1.00" id="g630">
    <path d="M140,348 L158,348 M1197,348 L1179,348 " id="path631"/>
    <g transform="translate(123,357)" style="stroke:none; fill:black; font-family:Times; font-size:28.00; text-anchor:end" id="g632">
      <switch>
        <text id="text633"><tspan id="tspan634">−50</tspan></text>
      </switch>
    </g>
  </g>
The colons were there because you added them. Colons inside a syntaxhighlight element are not wikimarkup.
Glrx (talk) 01:23, 12 October 2023 (UTC)Reply[reply]
I didn't add the colons myself, but the strange editor that appears after clicking "[reply]" apparently did. I guess, it's also a bug (and I probably should use the regular old code editor instead of these broken "modern" tools...)
Which "#text node before and after" do you mean? The file doesn't use white-space:preserve, so all the line breaks and leading spaces in the SVG source code shouldn't matter. I also don't see any extra elements in the DOM inspector. — Mikhail Ryazanov (talk) 01:37, 12 October 2023 (UTC)Reply[reply]
@Mikhail Ryazanov:
So librsvg 2.44.10 is more broken than I thought — it does not trim. I tried the fix on two "-30" labels in the graph, and it worked.
Glrx (talk) 02:04, 12 October 2023 (UTC)Reply[reply]
Thanks! I've "corrected" the rest, and now it seems to render as expected. Could you please update the bug tracker accordingly (add the case description/workaround or open another bug report, if appropriate)? — Mikhail Ryazanov (talk) 02:23, 12 October 2023 (UTC)Reply[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Technical&oldid=811143434"