Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for campaigns #545

Closed
AtaZh opened this issue May 10, 2017 · 49 comments · Fixed by #4423
Closed

Add support for campaigns #545

AtaZh opened this issue May 10, 2017 · 49 comments · Fixed by #4423
Assignees
Milestone

Comments

@AtaZh
Copy link
Contributor

AtaZh commented May 10, 2017

Upload campaigns for specific events have aditional fields and automaticaly add templates and categories.
Right now WLE campaign is running, e.g. https://commons.wikimedia.org/w/index.php?title=Special:UploadWizard&campaign=wle-ua

Is it possible to add support for them?

@tobias47n9e
Copy link
Member

tobias47n9e commented May 10, 2017

We are planning to work on this soon. Can you give us some information about what you think important things are that a campaign manager wanta to set, and what participants should see?

Related:
#100
#78

@VojtechDostal
Copy link
Collaborator

things to customize in a campaign as opposed to normal usage of the app:

  1. filter out the results of the "Nearby" feature to display a specific "type" of results either on a map or in a list. (using a query to limit the results?
  2. enable direct upload from the Nearby feature (also crucial to normal usage of the app)
  3. add templates according to the campaigner's wishes (the templates could then include categories)

anything else?

@misaochan
Copy link
Member

misaochan commented Sep 6, 2017

We are discussing the possibility of implementing this at #865 . Copying over my comment from that thread, so that we can discuss it here:

There are varying levels of "support" possible, ranging from simply displaying news/ads for ongoing campaigns, to full integration that allows users to submit photos for the competitions directly through the app. Personally I would start with the former, and wait and gauge the response before trying for the latter. While a central app for submitting WLM, WLE, etc submissions sounds great, AFAIK the winners and perhaps even most of the participants of such competitions tend to primarily use DSLRs and not mobile phones to take their pictures?

My assumption could be incorrect, though, would greatly appreciate feedback on that. :)

@AtaZh
Copy link
Contributor Author

AtaZh commented Sep 6, 2017

While winners (and, right, most of the participants) surely use other equipment to take pictures, we have troublesome regions frome where it would be a blessing for wlm-ua to have even phone-taken picture of a monument. (Not like I am sure that having an app will 100% resolve this, though. Or know anything about other countries.)

@nicolas-raoul
Copy link
Member

[off-topic] @AtaZh Is wikilovesmonuments.org.ua maintained by your community? It seems to have been hacked.

@maskaravivek
Copy link
Member

I would like to take our campaigns implementation forward.

Background

It was initially implemented by @nicolas-raoul and then removed later by @misaochan (Ref #13 and #26)

Current state

As part of WMCZ @ashishkumar468 added support for showing news about campaigns. (Ref #78)

Proposed extension

With our current upload infra, it would be trivial to support in-app uploads for images under a campaign.

  • The JSON in https://github.com/commons-app/campaigns can be extended to add the category and relevant template information.
  • Clicking on the campaign banner can trigger the upload flow and automatically select the relevant category
  • While uploading the picture, the relevant template information can be appended in addition to other information.

I am eager to take this up and can assure you that it won't add any unnecessary complexity to the app.

Why?

  • people who use their smartphone as the primary camera can easily participate in campaigns.
  • would be a good way to promote the app. Along, with upload wizard links people can add commons app deep link.

Opinions @nicolas-raoul @misaochan @neslihanturan @ashishkumar468?

@nicolas-raoul
Copy link
Member

Great, good luck!
So, clicking on the campaign banner would ask you "Do you want to join this campaign?" or something like this, and apply categories/etc to all subsequent uploads? Do you plan a way to upload unrelated pictures, for instance if I am in the middle of a Wiki Love Cats campaign and suddenly I see Obama at the corner of the street?
Or would it had a kind of selector in the upload wizard to choose what campaign or no campaign?
Do you want to handle internationalization/localization in this phase, or will this be a future phase?
Thanks! :-)

@maskaravivek
Copy link
Member

So, clicking on the campaign banner would ask you "Do you want to join this campaign?" or something like this, and apply categories/etc to all subsequent uploads?

The banner can have CTA for uploading ie gallery and camera buttons. If all these buttons can't be accommodated in a single line then we can have an expandable card similar to the nearby list.

and apply categories/etc to all subsequent uploads?

It won't apply to all subsequent uploads. The categories/templates would be added only when an upload is initiated using the campaign banner. Similar to nearby uploads where the wiki data item is linked only from nearby map/list.

Do you plan a way to upload unrelated pictures, for instance, if I am in the middle of a Wiki Love Cats campaign and suddenly I see Obama at the corner of the street?

For uploading unrelated pictures, you would have to go back.

Or would it had a kind of selector in the upload wizard to choose what campaign or no campaign?

wasn't planning to add a selector in the upload wizard. When the user comes on the category screen, the campaign category would be auto-selected but he can deselect it. The campaign template would be appended only if the campaign category was selected.

Do you want to handle internationalization/localization in this phase, or will this be a future phase?

Do you mean internationalization/localization for banner text or something else? Banner text localization and other things for internationalization are important but can be picked as a separate task. :)

My plan is to add this feature with minimum changes so that we do not add any extra complexity to the flows. After #888 and #1092 we can start handling more complex scenarios. :)

@nicolas-raoul
Copy link
Member

Ah, gallery/camera buttons on the banner is a good idea indeed! :-)

@misaochan
Copy link
Member

Sorry I missed this. It sounds like a great idea, @maskaravivek ! :) We should hardcode a dummy campaign in the development branch to test the flow before we release it, though.

@domdomegg
Copy link
Member

Sorry I missed this. It sounds like a great idea, @maskaravivek ! :) We should hardcode a dummy campaign in the development branch to test the flow before we release it, though.

Have created #2793 which I'll work on.

@neslihanturan
Copy link
Collaborator

Hey all, finally this is happening :) Today I worked on some mockups and ideas about how to implement WLM. Here they are:
Use Case

  • My suggestion is keeping this feature location independed. Whether the user is at that country or not, if searched area has an active campaign, user should be able upload through app.

  • After a search at a place where WLM is active occured, we can display a banner with LEARN MORE button included. So that user can learn if they haven't yet.

  • You can see my suggestion for displating markers of monuments in mockups. If there is no image at all, we can display WLM icon. Otherwise we can display the image that the monument already have.

  • I suggest adding WLM filter as a place type so that users can display only monuments if they like to.

  • After user started upload process(please ignore the photo of my cat, it is a monument), we should auto-fill title and description according to a suggested format (any suggestion from experienced Commons users?).

  • We should autoselect categories for WLM if we have access to such information

  • On latest upload screen we should include a notice about the user is joining to the contest to make it clear. We should include that a template will be added and we should add it accordingly.

  • Bonus: Since most of the time WLM contests have a tag to use on social media annually (ie. #WLM2020), we can ask people to share their contribution. (ie. Hey everyone I just made a contribution to WLM via Commons Android App. #WLM2020)

You can see the whole flow with mockups below.

wlm_mockups

Technical appoach and possible issues

  • After a nearby search is made, check if is there any WLM contest in between current dates in searched country.
  • Add a variable to Place class to describe this place is one of monuments (or we can keep this information in place type field)
  • Add another variable to Place class to include thumbnail if there is any
  • I hope there is a nice way to get the templates (according to countries)
  • I hope there is a nice way to get categories choosen for contest.
  • I hope renewing the tag for share button won't be a big deal.

Metrics

  • We can display metrics for uploads that both have WLM and UploadVİaMobileApp categories.

@misaochan
Copy link
Member

misaochan commented Feb 2, 2021

Yup, we are super stoked to be working on implementing WLM integration into the app for WLM 2021, as part of our new project grant! :) Integration of other types of campaigns are not in scope for the time being, but we should be able to generalize more in the future.

Generally speaking, this is the process that we intend to go through:

  1. Designing mockups and discussing implementation details
  2. Submission of our proposed mockups and implementation plan to the WLM international and national organizers. Lodewijk recommended that we create a wiki page with our proposed mockups, and ping them on the WLM mailing list for input.
  3. Take their feedback, redesign and rediscuss as needed
  4. Implementation by July so that beta testing can be done
  5. Release to production by the end of August, in time for WLM 2021 to start on 1 Sep

Thank you for the quick and detailed mockups, @neslihanturan !

  • My suggestion is keeping this feature location independed. Whether the user is at that country or not, if searched area has an active campaign, user should be able upload through app.

I don't think this is our call to make, we should ask the organizers what they think about this. I will ping them and ask.

  • After a search at a place where WLM is active occured, we can display a banner with LEARN MORE button included. So that user can learn if they haven't yet.

I like the idea of a banner, and the one in the mockup looks great! I think that searching for the active countries is excessive complexity however, as AFAIK most countries hold WLM at the same time every year (with the exception of 2020 due to Covid). For instance, what happens if someone is searching at the boundary between 2 countries, 1 with WLM active and 1 with WLM inactive? Personally I would just have the banner up all the time and everywhere during Sep 2021, saying something like "It's Wiki Loves Monuments month! (Learn more)". If the user is browsing a country that isn't participating in WLM, there will just not be WLM markers up for them.

  • You can see my suggestion for displating markers of monuments in mockups. If there is no image at all, we can display WLM icon. Otherwise we can display the image that the monument already have.

I think that WLM encourages multiple submissions for each monument, I don't think they discourage submissions if there is already a picture up (pinging @nicolas-raoul @VojtechDostal for comment on this). Therefore for WLM specifically I would vote to always display WLM icon.

  • I suggest adding WLM filter as a place type so that users can display only monuments if they like to.

I like this idea, but I think it would be more visible to have it as a "Place state" chip next to Exists and Needs Photo.

  • After user started upload process(please ignore the photo of my cat, it is a monument), we should auto-fill title and description according to a suggested format (any suggestion from experienced Commons users?).

Love the cat. ;) The monuments that are curated for WLM would already have the recommended title and description in their Wikidata properties I believe.

  • We should autoselect categories for WLM if we have access to such information

Yes, from Wikidata.

  • On latest upload screen we should include a notice about the user is joining to the contest to make it clear. We should include that a template will be added and we should add it accordingly.

Great idea, I agree.

  • Bonus: Since most of the time WLM contests have a tag to use on social media annually (ie. #WLM2020), we can ask people to share their contribution. (ie. Hey everyone I just made a contribution to WLM via Commons Android App. #WLM2020)

Nice!

Metrics

  • We can display metrics for uploads that both have WLM and UploadVİaMobileApp categories.

Yup, exactly.

It may also be worth noting that we were discussing on the WLM mailing list as to which data source was to be used - the monuments database (that is co-maintained by Jean-Frederic) or Wikidata. Jean-Frederic himself, alongside Maarten Dammers/Multichill and several others, have voted quite unanimously for Wikidata. https://lists.wikimedia.org/pipermail/wikilovesmonuments/2020-July/009263.html

@nicolas-raoul
Copy link
Member

Uploads are always welcome, "Needs picture" or not, WLM or not :-)
From my point of view I think that showing WLM points with no picture yet in a more visible way would be ideal, but showing them all the same way is reasonable too, if it is easier to implement/maintain.

@neslihanturan
Copy link
Collaborator

Thank you for the quick and detailed mockups, @neslihanturan !

  • My suggestion is keeping this feature location independed. Whether the user is at that country or not, if searched area has an active campaign, user should be able upload through app.

I don't think this is our call to make, we should ask the organizers what they think about this. I will ping them and ask.

AFAIK it is allowed to join WLM, whether you are at the place or not. You can upload pictures taken beforehand.

I like the idea of a banner, and the one in the mockup looks great! I think that searching for the active countries is excessive complexity however, as AFAIK most countries hold WLM at the same time every year (with the exception of 2020 due to Covid). For instance, what happens if someone is searching at the boundary between 2 countries, 1 with WLM active and 1 with WLM inactive? Personally I would just have the banner up all the time and everywhere during Sep 2021, saying something like "It's Wiki Loves Monuments month! (Learn more)". If the user is browsing a country that isn't participating in WLM, there will just not be WLM markers up for them.

Good idea, and will be simpler to implements

I think that WLM encourages multiple submissions for each monument, I don't think they discourage submissions if there is already a picture up (pinging @nicolas-raoul @VojtechDostal for comment on this). Therefore for WLM specifically I would vote to always display WLM icon.

I agree, thumbnails may discourage people from uploading. Lets make all of them with WLM logo.

I like this idea, but I think it would be more visible to have it as a "Place state" chip next to Exists and Needs Photo.

Hmm, place type is more visible indeed. However there is few space there. If we add one more filter as WLM, it may go two lines. But we can live with it.

  • We should autoselect categories for WLM if we have access to such information

Yes, from Wikidata.

What I meant was categories like "Images from Wiki Loves Earth 2020", "Images from Wiki Loves Earth 2020 in Turkey". I am not sure if they are listed at somewhere or if do they rely on a standard. Also, I am not sure if Wikidata items has a category information necessarily. This is an example item from Wiki Loves Earth 2020 in Turkey:
https://www.wikidata.org/wiki/Q1278759 (there is no campaign related category at all)
https://commons.wikimedia.org/wiki/File:Eber_Lake.jpg (there are campaign related categories)

  • On latest upload screen we should include a notice about the user is joining to the contest to make it clear. We should include that a template will be added and we should add it accordingly.

Great idea, I agree.

Meanwhile I learned from my local community that every year a different template is being used (the same one for all countries) with language code next to it. For example: {{Wiki Loves Earth 2020|tr}}

It may also be worth noting that we were discussing on the WLM mailing list as to which data source was to be used - the monuments database (that is co-maintained by Jean-Frederic) or Wikidata. Jean-Frederic himself, alongside Maarten Dammers/Multichill and several others, have voted quite unanimously for Wikidata. https://lists.wikimedia.org/pipermail/wikilovesmonuments/2020-July/009263.html

Agreed.

@neslihanturan
Copy link
Collaborator

neslihanturan commented Feb 8, 2021

According to latest discussions, here is the final (for now) mockups:
wlm_mockups_english

Here is the commons upload: https://commons.wikimedia.org/wiki/File:Commons_Android_Application_Wiki_Loves_Monuments_entegration_mockups.png

@misaochan
Copy link
Member

The mockups and implementation plans are being discussed at https://commons.wikimedia.org/wiki/Commons:Mobile_app/WLM currently. We will take community feedback until 8 March, at which point we will modify the plans/design as needed and re-post the finalized plans.

@misaochan
Copy link
Member

misaochan commented Mar 17, 2021

Finalized plans for WLM 2021

Scope: Users should be able to upload photos for the WLM competition via Nearby, with the monument ID and appropriate template attached. We should complete implementation by 1 July 2021 to allow time for testing.

Implementation:

(See mockups above for reference)

  1. During WLM month, we will have a banner that informs the user about WLM, and WLM monuments will appear as special pins on Nearby map. Wikidata must be queried for these places based on the existence of monument ID (P2186) - all WLM monuments should have such an ID. There will be no country restrictions, everyone can view and upload pics for any country regardless of their location.
  2. The user can also filter for these monuments via the new "WLM" place state chip. There should be an additional field in the place details section that displays the address of the monument, if it exists in Wikidata (P6375).
  3. Once the user selects a pin, they will be brought through our usual upload workflow. In the "media details" step, the caption and description will be auto-filled. The caption will use the monument name as usual, the description will use the monument name + address if exists (P6375).
  4. In the "Categories" step of the upload workflow, suggest Commons categories as usual.
  5. Before the final submission step, when the user is selecting their media license, they will be informed again that their photo will be included in the WLM competition.
  6. After they tap "Submit", the photo will be uploaded with the monument ID attached (P2186). This ID should be placed in the appropriate template, e.g. https://commons.wikimedia.org/wiki/Template:Cultural_Heritage_Russia .
  7. (Optional) Similar to other photo-sharing apps, users can be offered an option to "share" their contribution on social media, perhaps with relevant hashtags added (e.g. #WLM2020).

Testing & publicity:

  • Figure out how to test this in a sandbox prior to WLM 2021
  • Invite people to do beta testing after implementation complete
  • Fix bugs and release to prod by 15 Aug 2021
  • Notify national organizers and do publicity push
  • Collect metrics for final report

@ashishkumar468
Copy link
Collaborator

Hi @misaochan , Quick question around this - as far as I understand, we will be using this API - https://heritage.toolforge.org/api/ to get the monuments around an area. An entry in the response looks like this
{"country":"in","lang":"en","project":"wikipedia","id":"N-AP-102","adm0":"in","adm1":"in-ap","adm2":"","adm3":null,"adm4":null,"name":"Nandavaram Temple including the sculpture of Subrahamanya","address":"","municipality":"Nandavaram","lat":null,"lon":null,"image":"","commonscat":"","source":"\/\/en.wikipedia.org\/w\/index.php?title=List_of_Monuments_of_National_Importance_in_Andhra_Pradesh&oldid=1016582495","monument_article":"","wd_item":null,"registrant_url":"","changed":"2021-04-26 07:11:48"}

I am not able to figure out the upload part - as in using what entity-identifier will we be querying the wiki-data for these entries?

@nicolas-raoul
Copy link
Member

nicolas-raoul commented Apr 27, 2021

I believe Nandavaram Temple including the sculpture of Subrahamanya is only a row in a list article so it has no Wikidata item. We could create a new Wikidata item, but doing it right would be hard due to many edge cases. So, if there is no Wikidata item then I think it is not needed to link to/from Wikidata: instead just embed the template together with the value N-AP-102 when performing the the upload, as described by Josephine at step 6 above.

@misaochan
Copy link
Member

misaochan commented Apr 28, 2021

Hi @ashishkumar468 , as mentioned at #545 (comment) , the WLM coordinators have recommended that we not use the monuments database as our source, but rather Wikidata. In the mailing list discussion that I linked, the comments from Multichill and Jean-Frederic were:

I consider the monuments database legacy. I wouldn't build new things on
top of it. If countries want their monuments to be visible in the
Commons app (and other places), they should invest time into migrating
to Wikidata.

and

I would like to strongly +1 what Maarten said, as current/ex co-maintainer
of the monuments database.

We have tried our best so that the tools already built on top of the
monuments database keep running ; but new things should not be built on it.

(While there is some support for harvesting Wikidata datasets into the
monuments database, that was only ever meant to ease transition to Wikidata
for folks highly dependent on legacy tooling (such as ErfgoedBot)).

Finally, there have been reports of the monuments DB harvesting behaving
weirdly ; and neither André nor I have the capacity to look into it. In
short, at the moment, I can offer little guarantee that the monuments DB
would actually be up to date.

So I believe that rather than using https://heritage.toolforge.org/api/ , we are to query Wikidata for items where a monument ID (P2186) exists, instead. I can confirm on the mailing list if you like. What do you think @nicolas-raoul ?

@VojtechDostal
Copy link
Collaborator

@misaochan I haven't read this whole discussion but I agree that Wikidata are superior to monument lists. As for P2186 as the filter for monuments, please be aware that this will only work for countries which use this identifier property:

Bez názvu

For example, as you can see, this will not work for Czechia because we don't use P2186 in our monuments - we have official identifiers such as P4075. Is there an official policy by WLM organizers that we should adopt P2186, eg. by copying over values from P4075? If yes, I'll happily do that - such harmonization might be a good idea - but I'd like to know what is the community standpoint on that.

@misaochan misaochan mentioned this issue Apr 29, 2021
4 tasks
@misaochan
Copy link
Member

If anyone is interested in following the discussion, it is at https://lists.wikimedia.org/pipermail/wikilovesmonuments/2021-April/subject.html , or you can subscribe to wikilovesmonuments@lists.wikimedia.org for updates. For the time being there is a wide range of different opinions, so I'll give it a bit more time to see if a trend emerges.

@misaochan
Copy link
Member

So, we got a lot of good ideas from the responses, however some of them (e.g. Magnus's suggestion of a new tool acting as an interface, or Platonides's suggestion of the Wikidata table) are beyond our scope as Android developers, and we are also very rapidly approaching our end of June beta testing deadline. :/

I'm thinking that for this year, we should move ahead with P2186, otherwise we risk not having anything at all by the time WLM rolls around. Then in the future (would be a great GSoC project I reckon) we could add enhancements that would include more countries in our map, like the suggestions above, or Philip's suggestion of letting the user choose their identifier if needed.

@misaochan
Copy link
Member

Edit: Additionally, #3410 is slated for release in the same version as WLM, so I guess that could be a stopgap measure for experienced users for the time being.

@misaochan
Copy link
Member

It seems that the WLM community is largely split on whether P2186 or P1435 should be used as the property identifier (mailing list discussion). The benefits of P1435 are that it is a tried and tested method (used by other tools e.g. Monumental) and appears fairly future-proof, but the disadvantages are that it is a broad designation which includes sites that aren't eligible for WLM (e.g. natural heritage sites). The benefits of P2186 are that it offers national organizers more control over which sites they do or don't want to be included in the map (as mentioned by the national organizers themselves), however some members of the community feel that it is a "hack" that should be deprecated soon and that they want the community to move away from using it.

I think we should carry on with our work and keep an eye on the community discussion. Regardless of which one is chosen, switching to the other later should be fairly simple.

ashishkumar468 added a commit to ashishkumar468/apps-android-commons that referenced this issue May 22, 2021
- Add query for monuments
- Make API call to fetch monuments
- Attach the list of monuments with nearby places response and render the monumens on the Map along with other nearby items
@misaochan
Copy link
Member

misaochan commented Jun 7, 2021

Update: I held an office hour with WLM organizers on 27 May. Turns out there are more complications with using one property identifier than we foresaw, and the WLM organizers feel very strongly about this.

Stephen La Porte mentioned that he might be able to help out by creating a .json file for us with the desired property for each country, which they would maintain for us. We accepted and are now in the process of hashing out the finer details.

As this change involves a different property identifier for each country, that means the SPARQL query would vary depending on the search coordinates. Due to this, we are going to postpone #3410 to the next release, to minimize potential conflicts and difficulties with debugging.

@misaochan misaochan added this to the v3.1.0 milestone Jun 15, 2021
@ashishkumar468
Copy link
Collaborator

ashishkumar468 commented Jun 23, 2021

Hi @misaochan, I had some more doubts

The caption will use the monument name, as usual, the description will use the monument name + P131 (location) + address if exists (P669, P670).

Now that we would be fetching the properties from the JSON, should we expect the properties for the P31(location) and that for the address (P669, P670) to change too?

Similar to other photo-sharing apps, users can be offered an option to "share" their contribution on social media, perhaps with relevant hashtags added (e.g. #WLM2020).

If we do implement this, what exactly would the shared content look like?

@misaochan
Copy link
Member

misaochan commented Jun 23, 2021

Hi @ashishkumar468 ,

Now that we would be fetching the properties from the JSON, should we expect the properties for the P31(location) and that for the address (P669, P670) to change too?

The JSON would only give us a list of which property identifier we should search for. In the example that Stephen gave us via email, {"ie": ["P2186"]}, this means that if the address is in Ireland, we would only display that point on the map as a "WLM point" if a P2186 value exists for it. Then {"in": ["P1435"]}, means that if the address is in India, we would only display that point on the map as a "WLM point" if a P1435 value exists for it.

Basically the JSON only replaces the search for P1435 or P2186, by telling us which identifier is needed for each country. Everything after that point, i.e. the captions and descriptions, remains the same as planned. For the time being, while we wait for the JSON, we can just use P1435 and implement everything else first.

If we do implement this, what exactly would the shared content look like?

Actually I think we can give this a skip for now and only implement it later on if there is time, since it's optional (and also nobody was particularly interested in it when I talked about it during the WLM office hours, lol). Better to focus on other things first.

@misaochan
Copy link
Member

From the wlm mailing list,

Extended timeline: Many organizers welcomed the extended timeline last year. Though we will be continuing that this year, but not exactly as we did last year. National organizers have the opportunity to choose a different range of dates for their national competition. You can pick any range of 30 or 31 days within the period of September-October 2021 as your upload dates. That means that one country does not have to use the same upload dates as another. This will allow flexibility according to the situation in various countries.
The last date for all uploads is 31 October 2021, and any uploads beyond that date will be ineligible for consideration.

So now instead of 1 "WLM month", there are 2 months and countries can pick any 30 days in those months for their contest.

This will be tricky to implement, but I guess we can just display the WLM markers from 1 Sep to 31 Oct.

@ashishkumar468
Copy link
Collaborator

Hi @misaochan , I had a question around templates, so from the link you've added, a sample template looks like

{{Cultural Heritage Russia
|id       = <!-- номер на сайте культурного наследия -->
|title    = <!-- название памятника -->
|place    = <!-- Расположение — город, район, область, точный адрес -->
|built    = <!-- датировки - год(ы) постройки/перестройки -->
|approved = <!-- документ о постановке на гос. охрану -->
|category = <!-- регион для детальной категоризации -->
}}

The other things we can get from the query response, but what about this, "Cultural Heritage Russia", how do we decide what goes in this for different monuments at different locations?

@ashishkumar468
Copy link
Collaborator

From the wlm mailing list,

Extended timeline: Many organizers welcomed the extended timeline last year. Though we will be continuing that this year, but not exactly as we did last year. National organizers have the opportunity to choose a different range of dates for their national competition. You can pick any range of 30 or 31 days within the period of September-October 2021 as your upload dates. That means that one country does not have to use the same upload dates as another. This will allow flexibility according to the situation in various countries.
The last date for all uploads is 31 October 2021, and any uploads beyond that date will be ineligible for consideration.

So now instead of 1 "WLM month", there are 2 months and countries can pick any 30 days in those months for their contest.

This will be tricky to implement, but I guess we can just display the WLM markers from 1 Sep to 31 Oct.

Hi @misaochan . Do you mean to say we completely hide the markers for WLM if the date is not between 1st Sep to 31st Oct?. Also will we not be showing a banner on home screen those days?

ashishkumar468 added a commit to ashishkumar468/apps-android-commons that referenced this issue Jul 5, 2021
- Add query for monuments
- Make API call to fetch monuments
- Attach the list of monuments with nearby places response and render the monumens on the Map along with other nearby items
@misaochan
Copy link
Member

misaochan commented Jul 5, 2021

Hi @misaochan . Do you mean to say we completely hide the markers for WLM if the date is not between 1st Sep to 31st Oct?. Also will we not be showing a banner on home screen those days?

Yes exactly. Or rather, we revert to the existing state of our Nearby map outside those dates. Take care not to just "hide the WLM markers" as some of them are the same as existing Nearby pins, so they should just revert to normal pin status. I would probably approach this by not running the additional WLM query at all outside those dates,

It would be nice if there was a way for us to test without changing system date. Perhaps just a boolean flag whose value that we can toggle when debugging.

@misaochan
Copy link
Member

Hi @VojtechDostal and @nicolas-raoul , we've encountered a couple of issues that we hope you can help us with.

  1. Do you know which templates should be attached to the upload for a WLM upload? Does it differ from country to country, or can we just use a broad template like https://commons.wikimedia.org/wiki/Template:Wiki_Loves_Monuments_2020 ?
  2. How do we find the monument ID? Given that we are using Wikidata rather than the monument DB nowadays, is the Wikidata QID synonymous with the monument ID?
  3. Is it possible to get a sandbox "monument" that we can use to test our implementation end-to-end?

Thanks a lot. :)

@nicolas-raoul
Copy link
Member

nicolas-raoul commented Jul 5, 2021

Sorry I have no insight on 1 and 2.
About 3: Feel free to turn a sandbox item such as https://www.wikidata.org/wiki/Q15397819 into a monument by copying properties from an existing monument, I don't think anyone will notice :-)

@misaochan
Copy link
Member

Hmm, okay, thanks. Looking at https://commons.wikimedia.org/wiki/File:Queensland_-_Stanthorpe_Post_Office_-_20210425163522.jpg which was uploaded through Monumental, there seems to be no WLM template added at all, which is rather perplexing? I'll ask on the mailing list...

ashishkumar468 added a commit to ashishkumar468/apps-android-commons that referenced this issue Jul 8, 2021
- Add query for monuments
- Make API call to fetch monuments
- Attach the list of monuments with nearby places response and render the monumens on the Map along with other nearby items
@misaochan
Copy link
Member

misaochan commented Aug 16, 2021

Unfortunately the JSON tool by volunteers did not materialize. I suggested to the WLM organizers, and they accepted, that we will simply follow Monumental's strategy, which is to simply filter for certain properties everywhere, and display the union of it - https://github.com/hatnote/monumental-wlm/blob/master/src/components/main/map/map.js#L139 .

@VojtechDostal , I just realized that we can do a bit better than that and just add P4075 manually to the query, for Czechia. It should be a one-line change. Will you guys be participating in WLM 2021? If you are, will you be interested in having us add that property?

misaochan pushed a commit that referenced this issue Aug 18, 2021
* Integrate WLM
- Show monuments in maps along with nearby

* BugFix in Monuments
1. Single preference for monuments and campaigns
2. Expand collapse chips container in nearby
3. Typo fix in Monuments card in Nearby
4. If a nearby place is a monument as well - do not show them separately, show it as a monument instead
5. Bug fix, monument radius, use the same one as that of nearby

* More bug fixes
1. Possible NPE in nearby
2. Added column location_address in BookmarkLocationDao
3. Bug Fix - Display Date in WLM card
4. WLM card on click takes to nearby

* Use lowercase country code in WLM uploads

* Bug-Fix, WLM Campaign Icon

* 1. Updated monuments query to use any of the following properties for monuments - [P1435, P2186, P1459, P1460, P1216, P709, P718, P5694] 2. Append WikiData QID to descriptions template

* Updated WLM Banner String, Handle NPE in contributions callback

* Added nearby-monuments query log lines

* Handle WLM Query exception : - if an exception is thrown in WLM query, continue showing the nearby items if that succeeds

* Fix BookmarkLocationDaoTest

* Added Column Address in BookmarkLocationDaoTest

* Use fallback description as usual nearby pins even for WLM pins, instead of relying on P6375

* Test fix in BookmarkLocationDao

* Updated template for WLM, removed redundant feilds

* Fixed WLM template

* Removed categories from WLM template

* Fixed BookmarkControllerTest

* Fixed BookmarkLocationFragmentUnitTest

* fix ModelFunctions

* Fixed BookmarksDaoLocationTest

* Fixed WLM template
@misaochan
Copy link
Member

Reopening this as there is a bit more work to be done before campaigns can be released.

@misaochan misaochan reopened this Aug 18, 2021
@misaochan
Copy link
Member

misaochan commented Aug 18, 2021

Due to its complexity, I have listed the current task list/timeline for the actual WLM release. For reference for @ashishkumar468 , @neslihanturan , and anyone who is interested:

@misaochan
Copy link
Member

https://commons.wikimedia.org/wiki/File:Haight-Ashbury_2.jpg uploaded today with the full implementation. Public beta coming up real soon! :)

@misaochan
Copy link
Member

Out in beta. Great job everyone! 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants