When I upload a picture from Times Square, it should show me Category:Times Square and Category:Broadway and a few others nearby.

I would then select the correct one.

including transcoding to Wikimedia-accepted format

Warning: We have to pay special attention to quality (on-topic, encyclopedic, good technical quality). A 2021 photo+video contest ended up with hundreds of high-quality photos but only one high-quality video.

From https://groups.google.com/forum/#!topic/commons-app-android/-2hqB6oAsF8

If a user presses 'save' without any categories selected, they can potentially be shown a dialog warning them that their picture is likely to be deleted if it is submitted without any categories.

Maybe this could tie in with issue #58 , so this dialog is shown both when back button is pressed and when save button is pressed, if no categories selected?

Sometimes I type a category, and the app can't find it, even though it exists on Commons.

In the settings.
Not sure where the reports are sent.
This kind of surveillance can lead to privacy problems, so better get rid of it if not used for good/measurable purpose.

Actually at our scale we probably don't need usage reports, especially since it is a rather simple app with not many screens/features. So better remove that. And also remove the dead code behind.

Right now, if I type consulate in New-York it will not show Category:Consulates in New York City because of the missing s at the end of consulates and because of the dash instead of a space.

This makes categorization painful, leading to less useful metadata.

This was commented by Revent in my grant proposal announcement at https://commons.wikimedia.org/wiki/Commons:Village_pump#IEG_proposal:_Improve_Upload_to_Commons_Android_app:

@misaochan: I have no idea if it has even been addressed, but a minor issue in the past with the mobile apps was editors (presumably unintentionally) uploading 5, 6, or more duplicates of the same image within a couple of minutes, under a numbered series of filenames. A check, of some type, of if the person has previously uploaded the exact same image would be a good thing. (I can't point at an example offhand, since they get speedied quickly). Reventtalk 22:13, 5 March 2016 (UTC)

Do you think this could be fixable @nicolas-raoul ?

Suggested by John Cummings at https://commons.wikimedia.org/wiki/Commons:Village_pump#IEG_proposal:_Improve_Upload_to_Commons_Android_app

@misaochan:, this has a very large potential to increase participation. I wanted ask a question that is outside the current grant request but is related. I know that there has been some previous work on a Wiki Loves Monuments app and could see a clear use for a similar app for Wiki Loves Earth. I don't understand the technical side of Wiki Loves Monuments and Wiki Loves Earth but I can see having an app may help increase the easy of participation for people. Would there be an easy mechanism to have a link somewhere in the front page of the app to contribute to the competitions? I think there are a few advantages of integrating the competitions into a central app rather than having an app for each competition:
If people install the app for the competition it means they can continue to contribute to Wikimedia Commons after the competition has finished
May encourage people to take part in multiple competitions, inccreasing the participation for all of them. E.g someone installs the app for WLE and then continues to add photos afterwards and the app makes them aware that WLM is happening.
Smaller competitions can have contributions by an app without needing to create their own.
Thanks
John Cummings (talk) 13:52, 4 March 2016 (UTC)

Wouldn't it be great that once images are synced they stay available locally even when the internet is off?

If the user's phone is in Japanese, then searching for パリ should return Category:Paris

Better limit ourselves to that, as inculding all languages would create many false-positives.

Including a list of nearby places (wiki articles) which lack photographs can inspire users to upload needed images. In addition it can list pages without high quality images. This feature could be viewed as a photo scavenger hunt.

Wikipedias

The CSV file below is maintained by the https://github.com/alemela/wiki-needs-pictures project and contains the name/latitude/longitude/type of Wikipedias articles that are geolocalized and marked as needing a picture:
https://tools.wmflabs.org/wiki-needs-pictures/data/data.csv

Commons

This is far-fetched, as picture requests are currently in prose, but it is worth checking feasibility every few years.
https://commons.wikimedia.org/wiki/Commons:Picture_requests

Wikidata

We could use the same API calls as https://tools.wmflabs.org/wikishootme/
Unfortunately, a lot of Wikidata items lack an image even tough the articles in various languages have pictures.

Nearby categories that come up are often in two types, some related to a location:

• Xyz street
• National Abc Museum

Some unrelated to location:

• Fire truck
• Man with a hat

The latter categories have a much lower probability of being useful. We could distinguish between both types by checking whether one or two pictures of the same category are also at the same place or not. For instance, other pictures of fire trucks are probably in different countries.

The MediaWiki API only finds images that have been explicitly geocoded, i.e. the Locations template added to the Commons page. The web-based Upload Wizard automatically adds the Location template, but our app doesn't seem to do it. This hampers categorization of future uploaded pics with similar coordinates, as the newly-implemented GPS categorization depends on finding nearby pictures.

AboutActivity currently says "Bugs at Bugzilla", which might have worked once upon a time but now redirects to http://phabricator.wikimedia.org which is a bit too general. Perhaps it might be better to link to the GitHub 'issues' page here instead?

Probably due to starting an upload and then beginning another one before the first one is finalized.

The French Wikimedia team is very interesting in recording sounds, as part of their lingua-libre project ( a project to record French dialects, with many active volunteers https://lists.wikimedia.fr/info/lingualibre ). They have expressed interest in Upload To Commons, and are looking forward to it supporting sounds.

Sound recording would be the best. Selecting sound files is great too.

Would need to embed a rough database of countries/areas borders, or a specialized library if that exists.

Reported by Riley_Huntley on Phabricator (https://phabricator.wikimedia.org/T127624):

https://commons.wikimedia.org/wiki/File:William_Hill_Estate_Vineyards_-_Sarah_Stierch_2.jpg and https://commons.wikimedia.org/wiki/File:Tortoises_at_the_Minnesota_Zoo.jpg show a correct EXIF data, yet "{{According to EXIF data|1969-xx-xx}}" or "{{According to EXIF data|1970-xx-xx}}" will be automatically added to the information template. This has effected 2,000~ files and counting.

It would make the app more recognizable to Commons users.
Also, the current logo that I quickly designed is quite ugly.

A few years ago I used the Wikivoyage logo for the non-official Wikivoyage app and after a few months a WMF lawyer got Google to take down the app. Conclusion: Before using the official logo, better make sure all layers have got the memo.

The app installs fine, I can log in, first sync starts. The file counter stops at 500 and doesn't proceed any further than that (I uploaded almost 1500 I believe) and the info on top says "Waiting for first synchronisation" (translated from Polish, not sure what the English text says).

I can then proceed to take a photo, fill in the title and description (the text below reads "The image will be shared under CCu00A0Uznanie autorstwa-Na tych samych warunkachu00A03.0" - clearly it should be "CC-Uznanie autorstwa-Na tych samych warunkach", or something along those lines; all the license available in settings have wrong names as well). But when I click proceed, an error "Wystąpił błąd Commons." ("A Commons error happened") appears, with an option to send an email. Same thing happens when I try to upload a picture from the ones I took before.

All in all, the app as it is now is unusable right now. I'd be happy to help though, just let me know how.

After importing the project into IntelliJ, there seems to be a namespace problem. In the project file structure on the left, most of the source files are contained within the org.wikipedia.commons package, but in the code they are declared as package fr.free.nrw.commons;

Stack trace:

java.lang.RuntimeException: Unable to create application fr.free.nrw.commons.CommonsApplication: java.lang.NullPointerException: Attempt to get length of null array
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4759)
at android.app.ActivityThread.-wrap1(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1424)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:148)
at android.app.ActivityThread.main(ActivityThread.java:5466)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
Caused by: java.lang.NullPointerException: Attempt to get length of null array
at com.nostra13.universalimageloader.cache.disc.LimitedDiscCache.calculateCacheSizeAndFillUsageMap(LimitedDiscCache.java:73)
at com.nostra13.universalimageloader.cache.disc.LimitedDiscCache.(LimitedDiscCache.java:67)
at com.nostra13.universalimageloader.cache.disc.impl.TotalSizeLimitedDiscCache.(TotalSizeLimitedDiscCache.java:56)
at com.nostra13.universalimageloader.cache.disc.impl.TotalSizeLimitedDiscCache.(TotalSizeLimitedDiscCache.java:45)
at fr.free.nrw.commons.CommonsApplication.onCreate(CommonsApplication.java:109)
at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1014)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4756)
at android.app.ActivityThread.-wrap1(ActivityThread.java) 
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1424) 
at android.os.Handler.dispatchMessage(Handler.java:102) 
at android.os.Looper.loop(Looper.java:148) 
at android.app.ActivityThread.main(ActivityThread.java:5466) 
at java.lang.reflect.Method.invoke(Native Method) 
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726) 
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616) 

When installing the app from scratch, one can log in to Commons. Then the process of scanning uploaded files starts. Yet, it never goes past 500 files uploaded: the text above still says "Scanning", or something along the lines, but the counter stops at 500. When I try to upload a file it crashes (another bug apparently, already reported), but the counter goes one up (apparently it counts failed uploads?)

not sure what is the best way to implement. action toolbar?

Because it creates a second shortcut in the Android launcher.

Probably as was done here:
bvibber/apps-android-commons-old@ed2cec4

Plus removing dead code.

A "GPS" button could be shown if the picture does not have coordinates info already. Getting the coordinates automatically (with a preference to disable that feature for privacy reason) would be OK too.

A map showing the location would be wonderful, even more so if it allows to touch the real location (GPS is often wrong, or I might want to pinpoint the object itself rather than the location I shot it from)

As seen below, many results are "X in 2006"
Such categories have very low chances of being about the current year, so better filter them out.
We could filter all categories that contain one 4-digits number that starts with "19" or "20".

Notify when a user talk message is received, or when a picture is nominated for deletion or modified etc

This is important so that users get notified of feedback like "Please don't upload pictures of recent copyrighted paintings" or "Where was picture X taken?" or "Please categorize using X rather than Y" or "Please provide better description".

Pictures reveal a lot about a person, much more than is visible.
An evil dictator with a small software team could easily compare all EXIF camera serial numbers found on Commons to the serial number of all devices sold in the country.

So, how about an option to remove information which is not really needed by Commons?

What we must leave:

• The image itself
• Latitude/Longitude where the picture was taken
• Date/Time when the picture was taken

What we can delete: All of the rest? In particular:

• File name
• Camera serial number
• Camera manufacturer/model/resolution/software/serial number
• Camera settings such flash/ISO/shutter/focal/quality

When looking for a category, it is hard to get the right level.

For instance let's say I want to find Office buildings in Manhattan, New York City but my search only gets Buildings in New York by city and High-rise office buildings in Midtown Manhattan. One is too broad and one is wrong (my pic is not in Midtown).

In such a case, it would be incredibly useful if I could, for each category proposed:

• Drill down, to reveal sub-categories
• Drill up, to reveal categories of this category

In the UI, it could be a "zoom" button on the left that launch a drill down/up popup.

After uploading a new picture, occasionally the new pic replaces some of the other pics in the list. Scrolling up and down past the replaced pic sometimes changes it back to the original, but sometimes not. Clicking on the replaced pic to go to the details still takes you to the correct page with the original pic.

Issue is found from version 17 of the app onwards (release version), however I haven't tried the previous versions.

I've uploaded screenshots of the problem. It's a bit hard to see, but the first screenshot is of the new upload (French onion soup), and the second is of the pic further down the list (Hobbiton) that gets replaced by french onion soup.

How about placing small headers to show why suggestions are made?
Prototype:

--- Nearby ---
Trafalgar Square
Buckingham Palace
--- Guessed from name ---
Demonstration
Climate change
--- Recent ---
Roti prata
Rendang

When I take a picture, I know already what type of suggestion will be correct. For instance if the last upload was of the same thing, I know I must select everything in "Recent". If I am in a famous place but photographing something unrelated to this place (for instance a vehicle) then I can ignore all "Nearby" suggestions. Etc. Having sections will thus make selection faster.

It could also allow making the suggestions list a bit longer without it feeling too long?

It would be great if I was proposed the item Elephant when I take a picture of an elephant.

There are some APIs for this, not sure if any is usable for free.
The API would provide a few words such as {elephant, zoo} and we would perform a Wikidata item search on these words and add the resulting items to the list of suggestions.

In using an online service, the feature should probably be opt-in since the privacy policy of the API will most probably be incompatible with the Wikimedia privacy policy.

The message "waiting for first sync" stays displayed for longer than seems necessary?

@misaochan is it related to the new code?

USER_COMMENT=when uploading a photo application has been crashed .why this problem ? i unistall and reinstall app but problems not solve ?please fix it.
ANDROID_VERSION=5.1.1
APP_VERSION_NAME=1.8
BRAND=samsung
PHONE_MODEL=SM-J200G
CUSTOM_DATA=
STACK_TRACE=java.lang.NullPointerException: Attempt to get length of null array
at fr.free.nrw.commons.upload.MwVolleyApi$Query.toString(MwVolleyApi.java:199)
at fr.free.nrw.commons.upload.MwVolleyApi$QueryResponse.toString(MwVolleyApi.java:186)
at fr.free.nrw.commons.upload.MwVolleyApi$LogResponseListener.onResponse(MwVolleyApi.java:112)
at com.android.volley.toolbox.JsonRequest.deliverResponse(JsonRequest.java:65)
at com.android.volley.ExecutorDelivery$ResponseDeliveryRunnable.run(ExecutorDelivery.java:99)
at android.os.Handler.handleCallback(Handler.java:739)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:145)
at android.app.ActivityThread.main(ActivityThread.java:6946)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1404)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1199)

Would it be smart to perform a category search on the file name (that the user just entered) and show a few matching categories (if any) below the nearby categories? Often people take care to write very descriptive names, so we could guess and potentially avoid the user a lot of typing.

Like the traditional Commons upload, this app is subject to "vandalism", which in this case is not destructive, but uploading pictures that are not meant to illustrate wiki sites, but only as inside-jokes, to repulse viewers, or as a result of total boredom.

Non-exhaustive list of subjects that might not be wanted:

• Selfies of non-notable people
• Some body parts (Commons: "Images depicting male nudity are regularly nominated for deletion")
• Totally black or extremely fuzzy pictures

The difficult thing is to save Commons volunteers' time while not establishing our own censorship either. Maybe "tagging" such pictures with a particular category?

Thanks Justin for the idea!

In the categories selection dialog, when I start typing "flapja" I get two choice: "Flapjack" and "Flapjack image". None of these categories exist on Commons, the only real choice is "Flapjacks".

I tried selecting "Flapjack", and as a result the image is attributed that wrong category, resulting in a red link.

That category does not even seem to have been renamed recently, so I am not sure what is going on: https://commons.wikimedia.org/w/index.php?title=Category:Flapjacks&action=history

I had never searched for that category (or any with a similar name) before.

Where the request for categories from Commons seems to be made: https://github.com/nicolas-raoul/apps-android-commons/blob/master/commons/src/main/java/fr/free/nrw/commons/category/CategorizationFragment.java#L169

The same (mostly, I think?) request on the API sandbox: https://commons.wikimedia.org/wiki/Special:ApiSandbox#action=query&list=allcategories&format=json&acfrom=flapja&acdir=descending as you can see results are "Flap Jack" and "FlapJack Image". Not sure where "Flapjack" came from.

By Hallibut:

I can then proceed to take a photo, fill in the title and description (the text below reads "The image will be shared under CCu00A0Uznanie autorstwa-Na tych samych warunkachu00A03.0" - clearly it should be "CC-Uznanie autorstwa-Na tych samych warunkach", or something along those lines; all the license available in settings have wrong names as well).

to paste for similar image

For users/anybody to localize the app into languages they know.

Asked at https://translatewiki.net/wiki/Support#Former_WMF_app_now_community-maintained,_where_to_crowdsource_localization?_49961 , answers:

If the repository is active, the project can certainly be re-enabled here. These days are quite busy, you may want to send a patch against the "translatewiki" repository in gerrit yourself. --Nemo
It doesn't matter whether the app is community maintained or not. What is important that the translations end up in front of the users, i.e. for mobile apps there needs to be regular releases. --Nike

Seems like we need to mimick what Vicuña for instance is doing here: https://git.wikimedia.org/tree/translatewiki.git/master/groups

I mistakenly pressed the back button, and now no way to add categories

WikiMiniAtlas can be used to show Commons pictures on a map.

We could take latitude/longitude from the GPS and open wma.wmflabs.org in the default browser.

URL syntax details: http://webapps.stackexchange.com/a/86266/1374

While it is not directly about uploading, I believe it is still on-topic for this app, as people might want to check covered subjects before uploading their own similar (and probably lower-resolution) pictures.
Not sure where in the UI that would fit.

No obvious way to log out

Non-Wikimedians who witness an important event may become aware of the app and install it in a hurry to upload their pictures. But anonymous upload is not allowed by Commons ("You must be logged in to upload file"). In such case, better make whatever we can to make account registration as fast and straightforward as possible. Embedding that within the app would be the best. For reference, the web site registration form looks like this:

Problems:

• Some users who want to report a bug go to Google, search for the app's project page, and find https://github.com/wikimedia/apps-android-commons which links to now-defunct Bugzilla. Result: no feedback for us, and frustrated users.
• When I advertise the app, I get negative feedback saying "Why do you advertise the fork rather than the original?" (example).
• https://github.com/wikimedia/apps-android-commons says "our actual code is hosted with Gerrit" which scares away most potential contributors. And for those who don't give up and go search Gerrit, no code is actually there. It can be hard to find our fork.

Solution: https://github.com/wikimedia/apps-android-commons should be modified this way:

• Github project description: This project is now maintained by volunteers at https://github.com/nicolas-raoul/apps-android-commons
• Content of file README.md:

Initially started by the WMF, this app is now maintained by volunteers at https://github.com/nicolas-raoul/apps-android-commons
Please report any bug there.

When clicking on a picture.
Either fix or remove