-
Notifications
You must be signed in to change notification settings - Fork 1.3k
File names / titles #230
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
https://commons.wikimedia.org/wiki/File:Milan.png I think this is another indication of the overwrite bug (#228). More than ten versions were uploaded on 6 August under the name "Milan.png" using the app. |
I guess we could leave a message on that user's talk page to try and figure out how it happened? |
I reverted and left a message for now. |
I think it's good idea. Back to the original question, how about making the "title" field optional and hidden by default, and use the description as the Commons file name, maybe capping at 100 character or so? An understandable field name and a hint message might have to be devised, though. (Is "description" confusing when used in this way?) Maybe this is a language issue, but I always thought the pair of a description and a title to be redundant - I end up writing effectively the same into the two fields. (Sometimes an English title and a Japanese description, saying the same thing.) From the Commons editorial perspective, I think people are more permissive towards too long names (such as "Ueno_Park_in_Tokyo._Most_of_these_people_are_playing_Pokemon_Go.jpg") than too short names (such as "Ueno.jpg"). |
Haha I often do exactly the same :-) Using the description as a file name sounded to me strange at first, but I am starting to think it is a good idea. On mobile nobody enters huge descriptions, so better ask for one description, and use it as both title and description. You are right that long file names are actually considered a good thing (I personally believe that URIs should not be descriptive because the meaning of words change, but that is another debate). Capping might actually not be necessary, I have already seen images imported from US libraries that have HUGE filenames, longer than anyone would type on a smartphone. If capping maybe 300 characters would be OK? |
Fed up user entered "ejfjnfjfnddk" as a description: https://commons.wikimedia.org/wiki/File:Edificio_color_de_ladrillo_en_Bt%C3%A1.jpeg |
Yeah, I personally never quite understood the need for both title and desc either, I sometimes leave my desc blank... But is there a reason why a title AND desc are both required in the original (web) upload wizard? Will the Commons volunteers be happy with us making this change? Alternatively, maybe a 'same as title' button for easy copying onto the desc? Though there's still the question of whether we want to auto-read image filenames.... |
Re: the response to your thread... Why do so many people think that the copyvios were caused by this app when it has been debunked over and over (and AFAIK it was the mobile web upload wizard that was the issue)? Where is that information coming from? This is like the 4th different person who has mentioned it... |
Thanks for the link to the old discussion @whym (not sure why your post isn't appearing on here even though I got the email?). That makes a lot of sense, and I agree that pre-filling the title on the mobile app with the image filename would probably be a bad idea. |
I replied. Don't hesitate to post your views there too, you are among the few people who understand the situation from a mobile perspective (I guess many Village pump people never edit on mobile) so better let your voice be heard :-) I also agree that reusing the filename as a title is not a good idea, almost nobody rename their picture files on mobile. |
@misaochan I deleted it because immediately after I too realized that the first part of it was better posted to the Village Pump. Anyway, for completeness, here it goes:
These pointers should belong here:
|
@whym: I don't see your remarks at the village pump, though? Don't hesitate to post there, to influence the consensus. Thanks :-) |
Another idea might be pre-filling (in other words, initially syncing) title with description or pre-filling description with title - I've written about it in more detail at the VP. |
Pre-filling sounds like a good idea to me. |
I had exactly the same problem as reported by @whym with the photos of Milan.
It does not seem to me to be the same bug as #228. This is merely a UI problem. |
Hi @pchampin ,
|
Yes, I think it would be better.
IMHO, the best of both worlds would be the display the modified Title/Filename after the user clicked on "Reuse previous title/descriprion", and let them update the filename it if they want. PS: I was not expecting such quick reaction on such an old bug. Kuddos ;) |
I personally agree with you re: the title/filename, but would saying "filename" confuse users since the default Commons Upload Wizard (as of my last test today) says "Title"? Thanks for your feedback, we really appreciate it. :) |
There is now a plan to add 'caption' into file metadata on Commons (as part of the WMF's Structured Commons initiative). It's in an early phase and we don't know how much of the mockups will be implemented, but I thought it's something to keep in mind. |
Please give users the liberty to use device file names. Otherwise we are forced to use the desktop web page upload form. If you want people to author well-formed file names , then maybe they will do it when they're back in the office, but not when trying to upload from the field, which might even be some war torn area. Anyway they should always still have the choice to use the file names that they have on disc. A filename that includes the date and time etcetera is much better than one where one doesn't even know the names of the plants he's supposed to type in yet because he hasn't got back to the office with time to figure out what their names are. So he's supposed to type in "big plant on little plant", which would cause people to laugh at him for generations to come. |
Do you really rename your pictures on your mobile device? Or do you mean that "DSCF00001467" is more valuable than "big plant on little plant"? In my opinion, "big plant on little plant" is much better than "DSCF00001467".
The Upload Wizard actually forbids names like "DSCF00001467" or "IMG 20160717". Allowing them on our app would most probably attract us criticism from most of the Commons community. |
P_20201006_153656_vHDR_On.jpg has both date and time in it. That's what my cell phone makes. |
I really do not think this is an appropriate file title for a Commons upload? @jidanni If you feel differently, could you cite a reputable source supporting your suggestion? |
All I'm saying is the app should support the same file names as the desktop form does. If the desktop form says not allowed, only then should the app also say not allowed. |
And in fact the desktop form comes with the filename pre-filled right in it. So the app should at least have an expert mode, which does the exact same thing. Thanks. |
Fine, I guess they'll just keep spending their time trying to make new /regular expressions/ to match all kinds of such file names. But just like the old saying goes a picture is worth a thousand words so it's going to be harder and harder to pack enough information into a small file name to distinguish it sooner or later. (Or, OK, expect the user to "move" the file to a well thought out filename, perhaps weeks later.) Anyway my experience is because I'm a home user with 2m / 64K ADSL there is no way that I could upload any of these pictures anyway without a high-speed cell connection. And that connection is only available in the field, with mosquitoes biting me excetera and no time to fill in fancy details. (Text details filled in later from a home, after full research. (Genus and species.) ( a lot of research, can only do about one image per day.) Also, some users might need to return the photography equipment to the trip organizers and must upload before leaving the field. Yes in theory one could slowly upload via the aforementioned ADSL speeds, however due to (longstanding reported mediawiki) bugs it just won't work. OK thanks for your guys attention. I'll be signing off now... |
I think this can be closed. |
Uh oh!
There was an error while loading. Please reload this page.
Two recent reviews:
and
The text was updated successfully, but these errors were encountered: