Vicuna does this, and it is vital.
It should absolutely be implemented in the upload wizard too.

Thanks everyone! :-)

Pull request merged, thanks! It should be released in 2.9

@Aklapper: Yes a working prototype was created by @Nes in Barcelona :-)

User story:

Here is a long list of images that are often used as stub/portal/etc icons, and can thus be considered as unrelated to the topic of the article: https://www.wikidata.org/w/index.php?title=User:Magnus_Manske/FIST_icons&action=raw
It is kept up-to-date by FIST/WDFIST users, including me :-)

@Edgars2007: Yes, looks great! The only problem is that its data has not been updated since May 2017.

Any microtask you performed on the Commons mobile app maybe?
Or if not, on other Wikimedia software?
Thanks! :-)

I don't think "Add and implement option download metadata to a separate .txt, .xml or .json file" is really needed on mobile.

it's sub-categories -> its sub-categories

Is there any difference between "Improvements based on the feedback received from mentors, other community members, Testing, Bug fixes, Writing documentation. Release app in Google play (at least in alpha)" and "Phase I evaluation"?
Is there a reason why Phase II is in the opposite order?

@Diddypod I don't think anonymous users can upload pictures?

The UI sounds reasonable.

Familiarising featured images scrollable activity -> Familiarizing myself with the featured images scrollable activity
There are two "Review 1"

The link "Pull down gesture removal for Map View" seems broken.

Me: It would be very convenient if we had a tool to cut paper.
A: We could use a thermonuclear quantum laser for that. Closing as duplicate.
B: Sorry guys, we cannot have a thermonuclear quantum laser.
Me: Wait, closing as duplicate was a mistake in the first place, I don't need a thermonuclear quantum laser... How about plain old scissors?

User story:

User story:

It was for another account, newly created.

Nice job with the caption field!
Captions totally make sense, as it is important to have a sort of multilingual label that described the file and can be edited.
It makes the uneditable and untranslatable filename/title field redundant, so I removed it in this wireframe:

@Etonkovidova A notification appeared, I clicked on it and it lead me to a page saying "There is nothing".

It is not obvious indeed. My little story:

From the user's point of view, it is not a complex problem, and only the UI makes it complex.
If the UI was 1. Select "century" 2. Select the century from a dropdown list, then there would be zero chance for mistake.
The dropdown list would need "More..." buttons to go arbitrarily far in the past and future, so implementation sounds a bit complex, though.
Cheers!

@Nemo_bis Many of our users created their account via the app, and have no idea what MediaWiki is. As a consequence, for them creating a Github account is probably easier than figuring out how log into Phabricator:

@Nemo_bis Yes, being user-friendly to new translators is one of our top priorities.
Especially those who have never heard about issue tracking/XML/WMF/etc. (people who only know Wikipedia, Commons, and the Android app, as users)

As a community-maintained app, we use what we deem to be the most convenient platform, and right now this is Github, by a very large margin.

Personally I don't see banner is not a big issue on diff pages.
If we have them, the beginning of the "Revision" section would probably be the most sensible place, though.

Not happening anymore, thanks!
Now the shadow is only like a pixel too long:

[...] reasons why the Commons uploaders were [...]

I suggest you create a new issue at https://github.com/lyrk/Commons detailing your offer.

Just some thoughts:

Great idea!
Magnus Manske just suggested it for the Commons app too: https://github.com/commons-app/apps-android-commons/issues/259

Fixed, thanks all :-)

@Bawolff It is a joke right? Our app launches a category search and gives the results to the user as category suggestions. Because of the present bug the server gives us trash categories, which means the server needs fixing.

This is an urgent issue.

I am such a wiki editor who adds and maintains lists.

As a conclusion, I just noticed this comment on the talk page of https://commons.wikimedia.org/wiki/Commons:Mobile_app :

@Niedzielski as per my email last week all seems complete, so let's close it :-)

It should be moved to the Commons page, and merged into the similar list that exists there already.
Maybe leave a link "For the list of features, see here"

Mostly the features list. The "Reports" paragraph can be removed too, I guess, we are not fond of user spying.

I think they serve different purposes, the mediawiki.org page being about the development project, while the commons page is a user guide. Much of the information would need to be moved around indeed: Removing "user guide" stuff from the first one, which is out of date anyway. The Commons page can keep a short history paragraph, but most of it should go to mediawiki.org I guess. Also, each one should link to the other.

You can let #3 as is indeed.

@Nemo_bis Actually we have a separate issue about how we would like to revert to using the Wikimedia Commons logo instead of the current ugly logo (that I drew as a replacement to avoid the kind of legal problems that caused another of my apps to get banned from Play Store): https://github.com/nicolas-raoul/apps-android-commons/issues/68
So yes, access to the logo would be great. Request created per your suggestion: https://phabricator.wikimedia.org/T127791

On that wiki page, I see the following:

I did not know it was possible. Done now, thanks! https://phabricator.wikimedia.org/T127678

@Krenair: After the WMF announced they would no longer support the app, forking it was the obvious thing to do.
I have no control over gerrit (I think). On Github I was able to fix bugs, push releases, write wiki documentation, without having to bother anyone.

Writing dev documentation for developers would be great, I guess it could be either a .md file in the app source code, or a page in Github wiki.
It would describe the rationale of the categorization suggestion strategy, and the API calls with sample request/response for each API used.

getLastKnownLocation sounds like it might not get the correct location.

Good idea!

Related: https://github.com/nicolas-raoul/apps-android-commons/issues/8

Fixing 'repeat categories' is higher priority I would say.