Aditya implemented everything :-)

With artificial intelligence chips now being embedded directly on devices, and AI-based upscaling becoming routine, our average JPG upload will soon be artistic rather than reliable encyclopedic content.

Implemented and merged into master branch, huge thanks to Aditya!

"none of the main upload tools (Pattypan, url2commons) support SDC"

Thanks!
Would you mind explaining in a few words how you plan to cache API results? You can add this information to the "Implementation Strategy" section.

@Pheonix10 Thanks!

Great proposal, thanks!

Thanks for this very well-written proposal, especially the implementation part is great!
The tasks are rather ambitious, but your technical implementation details and your timeline are convincing.

Looks pretty good!
No need to divide time in durations smaller than a week.
Minor correction: "commons" as the name of the website should always be uppercase: "Commons".

Thanks for applying!

First feedback on this proposal:

Mentor here, I confirm that this GSoC is still open.

Thanks Gabrielchl, perfectly accurate answer!

Yes, it is done, thanks!

@Pavithraes Done, thanks! :-)

@Aklapper Here is an example of a "Wikimedia Commons image page": https://commons.wikimedia.org/wiki/File:Milgram_Experiment_v2.png

T213031 is only about "Wikimedia Commons image pages".
On the opposite, the present issue is for "Wikipedia articles".

In T235936#5588446, @Masumrezarock100 wrote:

This is likely an issue with Facebook problem not Mediawiki.

Implemented and successfully tested, not merged yet because of ongoing work on a library.

Here is my use case, just to illustrate the usefulness of having a SPARQL endpoint.

I stumbled upon this bug on commons.wikimedia.org right now.
I can confirm the bug is fixed on commons.wikimedia.beta.wmflabs.org thanks, looking forward to the release.

@Cparle : Wonderful! Here are our issues related to SDoC: https://github.com/commons-app/apps-android-commons/issues?q=is%3Aissue+label%3Astructured-commons+is%3Aopen

@JeanFred
Yes, both issues describe the same feature.
This issue has been created 4 months before the other one.
Feel free to close whichever you want :-)

Let's say I want to find all battlefields of history, and I am only interested in those in Russia (Q159).

Thanks for working on this!

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