File names / titles

[misaochan]

Two recent reviews:

Need more userfriendly app I am a regular user of commons but I faced several problem. it doesn't allow to upload multiple photos, can't read the file name, always ask for it. and after uploading when I browse the photos from desktop I saw an message that it doesn't belong any description but I already add the description.

and

File naming and overwrite alert. The app has issues with filenames. It does not ask for a file name. It does not use the file name stored on device. Instead use the title of input form for file name. I discovered the bug when I uploaded several images of Milan. The files uploaded without any errors. When I visited commons with a browser I recognised (I) the app has replaced Milan.png several times. The app should show the file name and alert, suggest rename when overwriting an existing file.

1. I agree that there is a bit of confusion with the 'title' field, should we rename it as 'desired filename on Commons' or something similar? Because pictures on Commons don't actually have a 'title', right?
2. Automatically reading filename from device: Is this something we want to implement? I would have thought that it'd be a bad idea since most pics on phones have random gibberish filenames, but two people have asked for it now? Do people really bother to rename files on their phones?

[whym]

I discovered the bug when I uploaded several images of Milan. The files uploaded without any errors. When I visited commons with a browser I recognised (I) the app has replaced Milan.png several times. The app should show the file name and alert, suggest rename when overwriting an existing file.

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.

[misaochan]

I guess we could leave a message on that user's talk page to try and figure out how it happened?

[nicolas-raoul]

I reverted and left a message for now.

[whym]

I guess we could leave a message on that user's talk page to try and figure out how it happened?

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").

[nicolas-raoul]

English title and a Japanese description

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?

Just for reference, here is how the web wizard does:

[nicolas-raoul]

Fed up user entered "ejfjnfjfnddk" as a description: https://commons.wikimedia.org/wiki/File:Edificio_color_de_ladrillo_en_Bt%C3%A1.jpeg

[misaochan]

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....

[nicolas-raoul]

I just asked: https://commons.wikimedia.org/wiki/Commons:Village_pump#Using_description_as_title:_Is_it_OK.3F

[misaochan]

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...

[misaochan]

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.

[nicolas-raoul]

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.

[whym]

@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:

My personal take is that mobile makes things a bit different - I didn't mean to suggest titles are redundant for every environment, to be clear. I believe Nicolas didn't too, but his post on the Village Pump might appear like a general question, mobile or desktop. (This might be more so to the eyes of the other Commons editors who are not subscribed here.)

On desktop, files might have descriptive names more often than on mobile. I think this is why we don't prefill the title field with the local name on this app, while the web wizard does (which is catered to desktop).

These pointers should belong here:

Relevant documentation:

• https://commons.wikimedia.org/wiki/Commons:File_naming for title
• https://commons.wikimedia.org/wiki/Commons:First_steps/Quality_and_description for description

Also, an old discussion by the app's developers:

• https://phabricator.wikimedia.org/T47453

[nicolas-raoul]

@whym: I don't see your remarks at the village pump, though? Don't hesitate to post there, to influence the consensus. Thanks :-)

[whym]

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.

[misaochan]

Pre-filling sounds like a good idea to me.

[pchampin]

I had exactly the same problem as reported by @whym with the photos of Milan.

• I wanted to upload two photos of the same location.
• I didn't know that "Title" was actually the filename
• So reusing the same title and description (as suggested by the app!) sounded like a good idea
• I ended up erasing the first image with the second one: https://commons.wikimedia.org/wiki/File:The_Pinnacles.jpeg#filehistory
• At no point did the application warn we that I was modfying an existing image rather than uploading a new one.

It does not seem to me to be the same bug as #228. This is merely a UI problem.

[misaochan]

Hi @pchampin ,

1. Good point re: the title. Do you think it would be a better idea to rename our "title" field to "filename"?

2. Reusing the same title and description is offered by the UI because overwrites are supposed to be prevented by the app (clearly, not in some cases). For people uploading a large number of related files, we thought it would be simpler for them to allow them to upload everything with the same title and then have our app automatically add "_2" or "_3" to the filenames. Do you think we should require the user to do it manually?

[pchampin]

Good point re: the title. Do you think it would be a better idea to rename our "title" field to "filename"?

Yes, I think it would be better.

Reusing the same title and description is offered by the UI because overwrites are supposed to be prevented by the app (clearly, not in some cases). For people uploading a large number of related files, we thought it would be simpler for them to allow them to upload everything with the same title and then have our app automatically add "_2" or "_3" to the filenames. Do you think we should require the user to do it manually?

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 ;)

[misaochan]

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. :)

[whym]

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.

[jidanni]

Please give users the liberty to use device file names. Otherwise we are forced to use the desktop web page upload form. Sure, give as many warnings as you want but still allow us this option. Otherwise we are forced to type gibberish file names, much less valuable than the ones from our disk, because it's raining and we have to upload quickly before we get off the mountain where there is cell coverage.

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.

[nicolas-raoul]

[...] much less valuable than the ones from our disk [..]

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". Taking real-world example, what name below is most useful?

• https://commons.wikimedia.org/wiki/File:Dscf_(259503377).jpeg
• https://commons.wikimedia.org/wiki/File:Plant_in_the_forest_at_Institute_for_Nature_Study.jpg

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.

[jidanni]

P_20201006_153656_vHDR_On.jpg has both date and time in it. That's what my cell phone makes.

[misaochan]

P_20201006_153656_vHDR_On.jpg

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?

[jidanni]

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. The app should not be changing policies on its own.

[jidanni]

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.

[nicolas-raoul]

Precisely, the Upload Wizard does not allow such filenames: The Upload Wizard is the recommended tool to upload on desktop. Other upload tools exist, some with basic HTML upload fields which indeed keep the original filename, but they are not examples to follow. If you manage to convince the Upload Wizard developers to allow such filenames, we can consider. An "expert mode" would unfortunately increase the burden of maintenance, which is already high. Thank you for your understanding.

[jidanni]

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...

[nicolas-raoul]

I think this can be closed. Everyone: if you think that filenames should be used as a caption or description or other, please explain why here, and post real world examples. Thanks!