Thank you. I agree that it is not a bug if the problem is a gadget.

I think this is no longer relevant or possible. So I closed this.

I think this is made obsolete by Wikidata. So I have closed it.

I have checked the results from global-search.toolforge.org that I think looked relevant. Unless someone have an idea to check/fix more then I think the only way is to take any remaining pages when they are found on wiki.

I also just noticed pages like https://zh-yue.wikipedia.org/wiki/MediaWiki:Mobile-frontend-editor-license

Thank you!

Thank you.
I agree that all unused messages should be deleted. Both desktop versions and mobile versions.
I also see a benefit in deleting messages that overdrive messages that are in use because there is a risk they are not up to date. If there are any wikis that would really like to have a special version they can just undelete.

On English Wikipedia subpages for https://en.wikipedia.org/wiki/MediaWiki:Copyrightwarning exist for example https://en.wikipedia.org/wiki/MediaWiki:Copyrightwarning/de
If they are replaced by https://en.wikipedia.org/wiki/MediaWiki:Wikimedia-copyrightwarning then perhaps they could be deleted globally.

Thank you very much!
I think global-search will catch many of those that mention 3.0 but it will not catch those that does not use "normal" numbers either as text or link.

Just in case anyone think it is helpful.
Permanent link: https://ru.wikinews.org/w/index.php?title=Викиновости:Форум/Общий&oldid=16754460#Опрос

Thank you for checking this!
I moved the file to retain edit history and to test if the thumb would work on Commons (there are a number of similar files on dewikibooks that should perhaps be fixed).
When I uploaded it with a different name it worked. But when I uploaded on the existing file it not work. That is what confused me.
I have just checked again and now the thumb works so I guess it just took a long time for the system to create the thumb.
So I guess there is nothing to fix. I just need to have patience after uploading a new version of a file.

Just as info I first wrote on German Wikinews on December 18, 2024: https://de.wikinews.org/wiki/Wikinews:Pressestammtisch#c-MGA73-20241218164800-Informationen_zum_Vorschlag_auf_Meta_zur_%C3%84nderung_der_Standardlizenz_f%C3%BCr_Wikin (the same day the RfC was started)

Hi @DreamRimmer thank you! It looks correct to me. You can close it if you also agree things look right. You can also close T382649: Change license on ptwikinews, nlwikinews and rowikinews to cc-by-4.0. I think that if I close it I will be the owner and you were the one that did the work.

@Lolekek or @DreamRimmer you have helped out fixing licenses on Wikinews earlier. Can one of you help here too? Sorry to bother you but since deadline is the deadline January 30, 2025 is getting close I really hope you have time.

In T384614#10490888, @matmarex wrote:

I think these lines in your plan have a mistake:

...

I kinda forgot about this but it is correct than an attacker can import files to Commons but if allow admins or imagereviewers to bypass that then we will eliminate that risk. So if a user want to import a file and the filter prevent that they could get a message "Not allowed. Ask an admin". To assist we could make sure the admin get a warning like "You are attempting to import a file that have naughty stuff in the file history. Are you sure?" If admin clicks yes we could add a new message "You imported naughty stuff. You may want to delete or hide it.".

@matmarex T hank you for fixing license for frwikinews.

Thanks a million! (I may start a discussion again once the change of licenses on Wikinewses are complete. Unless ofcourse someone have a good argument why Wikinewses (still) need a different message than other wikis.)

Thank you, I'm happy to see this getting fixed (even if there are more messages).

@MatthewVernon sorry for the late response. I tried to recrete the problem today and now it works. So I will close this task.

@DreamRimmer I think this can be closed :-)

I can see in https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1106911 that @Jdforrester-WMF
have written on Jan 06 that "This will need to be overridden for frwikinews if you're making this licence change."

@DreamRimmer thank you. I hope you find the time to fix :-)

@DreamRimmer default for wikis is CC-BY-SA-4.0 but there is a default for wikinewses too. It is CC-BY-2.5. The reason fr.wikinews have a manual overwrite on-wiki is that the change was not deployed at January 2 as planned. So they wrote it over manually temporary.

@Aklapper Thank you. I noticed that on https://wikitech.wikimedia.org/w/index.php?title=Deployments&oldid=2256367#Thursday,_January_2 there were planned 4 updates.

@DreamRimmer Are there any issues with this and the update of fr.wikinews? I think they were supposed to be updated this morning?

Thank you for the update. The reason I asked about December 30 was that a few days ago it was "open" per https://wikitech.wikimedia.org/w/index.php?title=Deployments&oldid=2256282#Monday,_December_30_2

I'm sorry to see this getting complicated. There have been more than a year to discuss. Anyway if January 1 is not an option perhaps make the change the same time as ptwikinews, nlwikinews and rowikinews change? That should be on December 30.

As far as I understand it then it is no longer possible to find duplicates on Commons the old way. So it is probably a whole new code that is needed. So perhaps its better just to close this request?

As written above it is now possible to get links to Commons using wikidata so I'm not sure it is still a good idea to push commonscat templates to lots of wikis anymore. So perhaps its better to close this taks now.

Seems to be similar to the issue I had in T382715: Error using FileImporter and undelete file on Commons because of "local-multiwrite/local-public...is in an inconsistent state within the internal storage backends"

Thank you @DreamRimmer !

Updated. Change of nl and ro was added to the other ticket so the comment below is no longer relevant here.

If and ONLY IF for some reason this is not getting deployed soon then there are other Wikinews that would like to change their license too per https://en.wikinews.org/wiki/Wikinews:2024_Copyright_license_upgrade/other-Wikinews. But I do NOT want to delay anything.

Ooops. Sorry. I undeleted the file and it worked fine.

French Wikinews would like to be added to this request and change to CC-BY-SA-4.0 (so BY-SA and not BY like English Wikinews) the same time as German Wikinews per https://fr.wikinews.org/w/index.php?title=Wikinews:Salle_caf%C3%A9/2024/d%C3%A9cembre&oldid=890985#Info_about_suggestion_on_Meta_about_change_of_default_license_for_Wikinews

Hi @Gerges I have notified all communities per https://en.wikinews.org/wiki/Wikinews:2024_Copyright_license_upgrade/other-Wikinews and have since May/June 2024 tried to get a response from all communities.

Sorry to ask but hewikinews would also like to change to CC-BY-4.0 per https://he.wikinews.org/w/index.php?title=%D7%95%D7%99%D7%A7%D7%99%D7%97%D7%93%D7%A9%D7%95%D7%AA:%D7%93%D7%A1%D7%A7_%D7%97%D7%93%D7%A9%D7%95%D7%AA&oldid=50087#%D7%A9%D7%93%D7%A8%D7%95%D7%92_%D7%94%D7%A8%D7%99%D7%A9%D7%99%D7%95%D7%9F_%D7%9C%D6%BEcc-by-4.0

@Lolekek yes please! Thank you!

@Lolekek you helped fix ar.wikinews. Any chance you can also help with this?

As info a similar change was made at https://phabricator.wikimedia.org/T372730

I have been asked to request that pl.wikinews also change to CC-BY-4.0 the same date https://pl.wikinews.org/w/index.php?title=Wikinews%3AKawiarenka&diff=341453&oldid=341452

In T54971#10259963, @Koavf wrote:

... Sorry if I'm just slow, but are you talking about Beta Wikiveristy or Multilingual Wikisource? ..

It looks to me as this is solved per https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-PermissionOTRS.js/Archive_1#Add_P6305_SDC_statement so perhaps we can close this?

At some point I made a script as a test to see if it was possible to locate files also on Commons. It started as a one-time-run on a tiny wiki. Then another one... I also tried it on a larger wiki like uk.wiki that have 115 k files. It works but you have to configure it manually for each wiki and I imagine that it creates some traffic on the server so it should pobably not be run too often.

There are two different problems mentioned here as I understand it:

Okay I understand that there are some concerns about the content of beta.wikisource. So if sitelinks are allowed then at some point someone will add links to content on beta.

Thats why it should ask the uploader to chose the right license. If we do not trust the uploader knows the license then we should have the upload form block for users that are not admins or license reviewers for example. Or we could have the option "Not sure so I need help to chose the right license".

I do not think FileImporter should prevent files by blocked users to be uploaded. But it could be a good idea to add a warning like "Hey the uploader is blocked. Are you sure you want to move the file?"

Another: https://commons.wikimedia.org/wiki/Special:Undelete/File:Matsudo_in_Chiba_Prefecture_Ja.svg

Thank you for your reply. I copied the name from Commons and pasted it to the file on ro.wiki. It works when I paste it into a wikilink but not when I paste it into the NowCommons template. So I do not think it is Windows or Edge that makes the error?

When I meet this problem I usually edit the local file page and add the template I want the file to have on Commons and edit the configuration to accept this template.

Commons have a bot that will try to fix dates. There is no guarantee that dates on a specific wiki always uses the same format. So I think it is better to leave the converting to the bot on Commons instead of making the code of FileImporter more complicated. I can of course not forbid the team to implement it but I would support if they decide not to do it (to close this as not done).

I have not testet it but if it is only possible to move a page if there is also a file involved then this might work.

I made the change above and I believe the issue have been solved.

Several of the files in https://ja.wikipedia.org/wiki/Category:FileImporter_error have the same problem.

It is correct that it would be possible for an attacker to upload bad stuff to xx.wiki and then import it to Commons. But FileImporter only works for AutoConfirmed users? So an attacker would have to make many good edits on xx.wiki and Commons before it will work?

In that case I prefer that we add information during import (template or category) instead of blocking for all imports.

I made https://www.mediawiki.org/wiki/Extension:FileImporter/Data/wikitech.wikimedia but it will only work if the file has a formal license template like GFDL, Cc-by-sa-4.0 or MIT for example.

I added some help on https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Move_files_to_Commons/Configuration_file_documentation and hope it is better.

I like FileImporter and I thinks it is a bad idea to block it on some wikis. If good users verify that files are good then those files should be possible to move to Commons.

I can't reproduce this error. Is it still a problem or can it be closed?

I think the best solution is to add text to [[:de:Vorlage:Bild-PD-alt-100]] or [[:de:Vorlage:NoCommons]] telling the user what to do. That way we do not have to make the code more complex and it is a wiki problem that needs to be fixed on wiki.

Yes all files should be possible to move. Once it is moved it is up to local wiki to decide if the file should be deleted or not. If another wiki wants to use the file I see no reason why we want to prevent them to do so.

It seems that structured data breaks old revisions. Not just for random files but for ALL files. So soon we have 60 million files on Commons where the old revisions are broken.

I wanted to copy some text from the old edit and add it to the current page.

NO! If I understand this correct the request is to make a multiedit where the file page and the structured data is changed with one edit!

Filepages are now deleted on Commons and the files are now imported with succes. No problems! So it was just a temporary issue.

I was importing many files very fast so that may have been the cause of the problem. I never had problems like that before so if logs show nothing special its okay to close this and spend the time om something else. The easy solution is to delete the broken pages on Commons and try the import again.

The original request is about filenames in the edit summary. So the link will always be [[:c:File:<name on Commons>]]. The benefit of a clickable wikilink is that it is much faster to navigate to the new location. Personally I have never thought the long edit summary was a problem but I can see the benefit of a wikilink I can click on. (I just realized that this is an old ticket. I thought it was related to one about making edit summary shorter on source wiki)

I just moved 50 files from ja.wiki, 10 from vi.wiki and 10 from lv.wiki and no problems! Thanks for fixing! I love you guys/girls! :-)

I don't see a big need for that. You can just import the file and use HotCat after the import. I would like the import to be as fast and easy as possible.

This should perhaps be in another post so just ignore it if not useful here: I tried to import https://ja.wikipedia.org/wiki/ファイル:コバギボウシ_Hosta_albo-marginata.JPG before FileImporter crashed but the import failed because there is a broken/missing file in filehistory. So I had to upload it "manually". I did not bother to file a bug because there is hopefully not many broken files like this.

Same with this file https://commons.wikimedia.org/wiki/File:Annamie_Paul_in_Toronto_Regent_Park.jpg

It is possible to [https://commons.wikimedia.org/w/index.php?title=File%3AEhime_pref_Hojo_highschool.jpg&type=revision&diff=433591068&oldid=433591067 change stuff] while importing and it still gets tagged as edited by FileImporter ;-)

Perhaps there still is a problem per https://phabricator.wikimedia.org/T253952 ? An image not showing up.

I think it would be nice if bot(s) did not crash when they find a non-excisting wiki or if there is a link to a wiki that is not yet supported fully.