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.

I am testing fuzzy search in 1.8 and here are a few observations. I don't know exactly what should work and what is too much to ask:

Ah sorry that's the best place indeed! I copy it there.

I am testing fuzzy search in 1.8 and here are a few observations. I don't know exactly what should work and what is too much to ask:

I am not against refactoring in principle, Stephen what do you think?

Yes good!

Yes sure, if that does not prevent pre-22 people from using the app no problem.

Yeah, the others are great!

The procedure says "just looking at the image and image name" so for image 6 for instance "road of Chinawal-Savkheda" could be another guess.

OK!

Ah OK, we have methods A and B then :-)

Yes, use the "Sample generation methodology" to generate 5 more samples.

Yes, I am in talks with him on Github issues.

If on the wiki, I would suggest "on Github issues or below"
on other venues, I would suggest "on Github"

I rooted my phone so I think I can send you logcats if needed.

Stephen will know better than me for the Java part, but one thing needed about this new way to use the API is to evaluate it... sorry it takes time but would you mind adding the necessary paragraphs at https://github.com/nicolas-raoul/apps-android-commons/wiki/Location-based-category-search ? To check whether there are tricky cases where this new idea actually does not work, in such case better realize it now than after implementation.
Thanks a lot! :-)

If your current code fixes the problem, releasing a new version would be
great :-)

I tried the app version 1.4 by uploading this file: https://commons.wikimedia.org/wiki/File:Mori_Tower_Upper_Lobby_2.jpg

Second solution sounds best, if there is no big difficulty with it.

We don't need to store: it is very short-lived cache. No problem if it
disappears every minute.

Indeed that is a very common bug cause in GIS.
OK!

Perfect!

I have seen the Stack Overflow question but I don't see what's going wrong... feel free to start working on caching and come back to this task when more feedback comes.

http://softwarerecs.stackexchange.com/questions/27569/java-data-structure-to-store-geographical-objects-and-retrieve-them-by-area

Did you commit the version that worked and the version that does not work anymore?

Sounds exactly like what we need :-)
It is wonderful that Android has a ready-to-use API for this.
Just call it at the place where a picture is sent to the app or taken/open
from the app, it should not take too long.
After that, don't hesitate to jump to next week's "Implement asynchronous
calls to the APIs to match an uploaded picture's GPS coordinates with
nearby Commons categories" as it is a much bigger step where everything
comes together :-)

Sorry I meant "number of unique categories found".
The number of categories we propose to the user. I think showing like 5~15 propositions to the user is appropriate.

I gave the score formula without thinking about it much, we should not penalize false positive that much indeed:

• A false positive means the user need to scroll a bit more
• A good category not present means that the user has to imagine its name, type the beginning of its name, and skim through a LOT of "false positives" that begin with the same letters.

I also feel that we could accept a larger radius in order to have like 10 proposed categories from which to choose.

if WikiData discovers a category that should be there but that manual categorization failed to find?

No great! :-)

I was not aware of the difference, but it is worth investigating both I
guess.
And yes, as you know we need categories, not pages.

There please thanks!

Ah yes I see the "Announced project on" now!
Would you mind posting to the village pumps above too? Most volunteers
don't read mailing lists.
Yes, full URL would be great, in order to easily check the replies from
time to time.
Cheers!

Where is the "Quick list of URLs" described as a deliverable for this task?
By the way, here are a few places where it would make sense to announce the effort (if sent already just note the URL):

A test Commons instance would not contain enough variety of categories (I remember this was already discussed elsewhere)

I think we should use decimal everywhere, and convert any other notations
we may receive.

Yes great!

10 sounds OK indeed.

Just take the categories that have been manually entered by the community, after completing them if needed (some pictures in Commons are not well-categorized).

The best is to use https://commons.wikimedia.org/wiki/Special:Random/File and only eliminate the files that are not pictures, or that one could not possibly take with a smartphone (ex:satellite, microscope, old pictures).

Manually is to check the usefulness of the algorithms. "Good categories" is defined by what the human user has manually found.

For each picture, you should perform such a comparison:

Yes, for instance if you take a picture at 48.853333, 2.369167 and the algorithm returns Category:Popemobile just because the popemobile happened to pass by and someone uploaded to picture of it at this place.
The "take categories of pictures taken at that place" strategy is one of the most promising, but it will result in a certain proportion of such false positives.

@NiharikaKohli: The schedule of the Outreachy project does not contain many UI changes, only a new preference.

OK! That's Friday 11am for me if I understand correctly.
IRC (what channel?) + Mumble? Or anything you prefer, I let you decide.

Anything within these two slots is OK for me too! :-)

How about using Phabricator only for Outreachy tasks (such as "Write a report") and Github for all technical tasks that could exist even if Outreachy did not exist?

If I understand correctly we still need a primary mentor (I have always been listed as co-mentor by my choice).

For instance, I guess you will post new messages to the Commons/Wikipedia/Wikivoyage village pumps and to one or more mailing lists.So, the URLs to the new created sections or list archive threads will be useful for observers to quickly measure the impact of your community bonding.

Yes that's OK!

@josephine_l: You wrote "weekly progress reports on Phabricator", would you mind making that short daily reports? In my previous mentoring experiences I have found that daily reports are needed to be able to provide tips and potential guidance early enough. Cheers!

I don't think Commons categorization source code can be directly re-used in the Wikipedia app, even though it might share some similarities, for instance the UI might look similar.

Hello, I am the maintainer of https://play.google.com/store/apps/details?id=fr.free.nrw.commons The source code is at https://github.com/nicolas-raoul/apps-android-commons and volunteers are indeed very welcome!

At https://en.wikivoyage.org/wiki/Gin_Gin :

Happens when starting Firefox in Safe Mode (firefox -safe-mode) with JavaScript disabled, not logged into Wikimedia, Firefox 40.0.3

Thanks for working on this :-)

From a user experience point of view, I agree with Tgr that the banner should appear between the diff (or source edit box) and the actual page content, so that the preview is as close to reality as possible.

I guess so :-)
Thanks everyone!

Thanks Bugreporter, nice to see that there is some source code available already!

I have found the reason.
pagebanner is incompatible with the gadget "Add an [edit] link for the lead section of a page" in Preferences.
Disabling this gadget fixes the problem.

I just had it again.

Does not happen on Chromium
Does not happen on Firefox in separate Ubuntu account
Happens in Firefox private window (not logged into Wikimedia)
Happens when starting Firefox in Safe Mode (firefox -safe-mode)

It does not appear anymore :-)

I just asked at the Travellers' Pub for a consensus.

Making banners usually involves resizing the image, and sometimes rotating it a bit. I guess further parameters would be needed for this? At least resizing would be very nice to have.

Now that the Wikivoyage community is unanimous in calling for Sumit's new extension to be deployed, and that the task is listed at https://phabricator.wikimedia.org/T33235, I guess we just need to wait for anyone with the right permissions to actually deploy it?
I guess code review is not necessary as @Jdlrobson has performed reviews already?

I upgraded Opera and indeed it works now.
Both me and another Wikivoyage contributor had this problem, so I guess it would affect quite a lot of people.