@Karankulx I am not sure what you are talking about, but if you want to create a proposal, please create a new task. By the way, color manipulation before upload is not desirable. Thanks!

Are you aware of the document https://github.com/commons-app/commons-app-documentation/blob/master/android/Students.md?

@Aman7531 Would you mind adding links to the pull requests (or at least one link, for the pull request you are most proud of)?
Thank you!

Thank you! Based on your screenshot, I added steps at the 7th bullet of https://github.com/commons-app/commons-app-documentation/blob/master/android/Students.md#how-to-apply

Thank you for asking! Would you mind sending a screenshot of the form so that we can be 100% sure to have the right choice?
At https://www.mediawiki.org/wiki/Google_Summer_of_Code/2022#Improve_the_picture_selector_of_the_Commons_Android_app we wrote Expected size of project: 350 hours, Difficulty rating: mediumbut without seeing the form I am not 100% sure how that translates to.
Thanks in advance!

Great proposal, the work is well explained, there are even screenshots, the schedule makes sense.
Just a few very minor typos:
After marking some images -> After selecting some images
Not for uploaded images -> Not for upload images
Implementaion -> Implementation
Rest work -> Rest of work
Activies -> Activities

Yes, if done losslessly then blur+rotate+crop is well enough for a GSoC.
You can keep "Implement Update Depicts" as a bonus task "if time allows".

Please be aware that AndroidMediaUtil is probably harder to use, and might even need some modifications. Feel free to modify your schedule to allow some buffer, for instance I would suggest not doing contrast change and EXIF, and leaving more time for both unit tests and final code review.

Thank you for the detailed proposal, with screenshots and a timeline.

@srishakatux 350 hours medium sounds like the best choice indeed, thanks!

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.