Page MenuHomePhabricator

Admin levels empty due to no campaign information (e.g. license)
Closed, ResolvedPublic

Description

Certain admin levels are still empty - this is now due to the fact that
window.CAMPAIGNS contains no information on how photos should be uploaded for
these campaigns.

The admin levels are Canada, Chile, Denmark,Ghana, India, Ireland, Israel,
Serbia, Slovakia, Ukraine, United Kingdom - all display no monuments.


Version: unspecified
Severity: blocker

Details

Reference
bz39568

Related Objects

Event Timeline

bzimport raised the priority of this task from to Unbreak Now!.Nov 22 2014, 1:03 AM
bzimport set Reference to bz39568.
bzimport added a subscriber: Unknown Object (MLST).

Note this is not just top levels..

the campaign us-ca is not currently supported by app so throwing away Montgomery Block

A monument has a country field e.g. 'us-ca' that has no entry in window.CAMPAIGNS

In confirmPhotoUpload this is expected to load the config:
(
WINDOW.CAMPAIGNS[ curMonument.country ].config
)

this errors out breaking the upload process

It appears that that is because of how generate_campaigns.py works - it compares what it gets back from http://commons.wikimedia.org/w/api.php?action=uploadcampaign&format=json&ucprop=config against http://commons.wikimedia.org/wiki/Commons:Monuments_database/Campaign_names?action=raw, the latter of which appears to maybe be missing some campaigns, eg ca. This page appears to have been manually maintained by a former team member. We need to investigate an alternative approach.

(In reply to comment #2)

A monument has a country field e.g. 'us-ca' that has no entry in
window.CAMPAIGNS

In confirmPhotoUpload this is expected to load the config:
(
WINDOW.CAMPAIGNS[ curMonument.country ].config
)

this errors out breaking the upload process

I am confused about this particular problem as us-ca is not a country, nor is there a WLM campaign called us-ca (in the monuments database, the field 'country' confusingly maps to campaign, not the actual country). If there is a monument where country=us-ca, then there is a problem with that monument's data.

Another likely contributing factor to this problem is that there monuments in the monuments_all table associated with 14 campaigns that do not exist in the uploadcampaigns api - which means, we have no campaign information for them, even though we're attempting to display those monuments in the app. The offending campaign codes are:

dk-bygning
dk-fortids
es-ct
es-vc
gh
ie
in
it-88
it-bz
mt
sct
sk
ua
us-ca

I presume this would cover:
Some of Canada (is that what us-ca is supposed to map to??), Denmark, Ghana, India, Slovakia, Ukraine, Ireland, and UK (sct).

The remaining affected countries that Jon mentioned and the possible reasons why they are having issues are:
Chile - we are not capturing campaign data due to the issue I initially raised (Chile is not in the campaign whitelist page that Yuvi had been maintaining)
Israel - same as above
Serbia - I can't actually find any monuments in the database who have adm0='cs' so not sure about this one

Israel,Serbia

philinje wrote:

And strangely, in beta 2 the monuments do appear in those countries, though in many cases there were no addresses.

US-CA is not a country or campaign, so there must be some other bug.

If this is about campaigns not being fully defined in Special:UploadCampaigns, let's figure out a workaround, such as:

  • use CC-BY-SA 3.0 by default
  • include a category for the country, such as "Ghana not defined"

According to Maarten:

dk-bygning (7057)
dk-fortids (31320)
Ah, Denmark with the two systems. I think we have two campaigns, but not the right name. I'll ask them to rename it to wlm-dk-bygning and wlm-dk-fortids . That would fix it, right?

es-ct (28532)
es-vc (2730)
Pfff, Spain, ehhhhhhh, would need to ask around

gh (51)
Ghana just needs to be created.

ie (619)
Ireland is not participating

in (2733)
2700+ items? Cool. We just needs to create the campagin.

it-88 (20)
it-bz (4814)
Hmmm, need to ask around.

mt (115)
I don't think Malta is part of WLM this year.

sct (47663)
Scotland is not part of WLM this year

sk (16002)
Slovakia is not part of WLM this year.

ua (17435)
Campaign just needs to be created

us-ca (742)
I'm pretty sure I created that campaign. Just needs to be created

So it sounds like there's a mixture of campaigns that have not yet been created in the API, and campaigns that do not exist for this year.

A few lingering questions:

*) Who will be coordinating getting the campaigns created for the API?
*) By when can we expect to have the above campaigns created?
*) Will campaigns continue to get added throughout the contest?
*) In the event that we have monuments associated with a campaign that
does not exist (eg Scotland) what should the behavior be in the app?
Right now we are not showing any monuments for which we have no
campaign data. However, because of how we generate the
countries/regions for regional based browsing, we are currently
exposing countries/regions which may not be associated with an active
campaign (and brainstorming quickly, I can't think of a quick/easy way
to change that behavior).

I think an easy way to solve this problem is to move the 'whitelist' of campaigns from the page that Yuvi has been maintaining and put it in a static file in the app. In reality, the whitelist is really only useful for mapping campaign codes (eg it-bz) to human-readable campaign names (since those aren't available anywhere else, afaik). Once the whitelist is moved to the app, we could make the script that captures campaign data a little smarter - have it select only campaigns that are currently enabled (which we can determine from data coming back from the API), and have it use the whitelist to ascribe the human readable name to the campaign if it is available. That way the 'whitelist' will not block enabled campaigns from being present in the app. This should be a pretty quick fix to implement.

philinje wrote:

Will this fix the problem of monuments appearing in the app because they are in the DB, but there is no campaign and so they should not appear?

philinje wrote:

Sorry, just read comment 9 again. Never mind.

  • Bug 39772 has been marked as a duplicate of this bug. ***