commons-app
Append " (2)" instead of " 2" when filemame already exists
Currently, when the caption chosen would result in a filename that already exists on the server, the app appends " 2"at the end (or changes to " 3" if that already exists too, etc).
While it works well, it sometimes results in a different meaning. For instance in the screenshot below, "Ebisu 2" is not the same geographical location as "Ebisu" so the filename conveys an incorrect meaning.
It also often happens with time indications, for instance "Zenpukuji river, October" becoming "Zenpukuji river, October 2". The meaning changes to affirm that the picture was taken on the second day of October, which is probably untrue.
I believe that putting the number within parenthesis would drastically lower the number of changed meanings.
Example:
If a user uploads a picture with caption "Zenpukuji river, October", the filename becomes "Zenpukuji river, October" because there is no such filename yet on Wikimedia Commons.
Later, if a user uploads a picture with caption "Zenpukuji river, October", the filename becomes "Zenpukuji river, October (1)" because the filename "Zenpukuji river, October" already exists.
Later, if a user uploads a picture with caption "Zenpukuji river, October", the filename becomes "Zenpukuji river, October (2)" because both filenames "Zenpukuji river, October" and "Zenpukuji river, October (1)" already exists.
etc
This issue does indeed occur. Could you assign it to me?这个问题确实存在。可以分配给我吗？
Hi, I have made some attempts, and it seems that this issue has been fixed, as shown in the figure. Now, if the user enters a duplicate caption when uploading, a number in parentheses will be added after the title to differentiate it. If you could assign this issue to me, I can submit a PR.
Hi, I would like to request the assignment of this issue (#5876). I have implemented the fix to append random hashes in parentheses instead of directly at the end of filenames, which helps prevent changes in meaning. I have tested the fix on my Realme Narzo 20 and confirmed that it's working as expected.
I am eager to contribute further and would appreciate it if you could assign the issue to me.
Looking forward to your feedback!
Thank you,
Sujal
@nicolas-raoul After merging this commit, the build has failed. Can someone investigate the issue to determine why it failed and let me know if any actions are required to fix it?
Do you mean in main? Somehow coverage calculation is broken in main I believe, don't worry it is not because of this PR. :-) Unit tests are passing on main, I just ran them now on my computer.