Last modified: 2012-07-17 23:24:08 UTC
The current app just uploads dummy text. It should add templates with information about the name, monument ID, description, license, etc. See https://commons.wikimedia.org/w/index.php?title=File:%22Haus_zum_Falken%22_in_W%C3%BCrzburg.jpg&action=edit for an example. Template info: Template Name: Information Details: Desc, date uploaded, author name Template Name: self Details: License info for the particular campaign (pick up from current campaign data) Correct WikiLovesMonuments tracking category. Pick up from Campaign Data. Some category for tracking uploads from the Mobile app.
Based on https://commons.wikimedia.org/wiki/Special:ApiSandbox#action=uploadcampaign&format=json&ucprop=config I think you want to use the following fields: * idField, data to add in the description field of information. Substitute $1 with the id * autoCategories, list of categories you need to add * defaultCategories, list of categories you also need to add * autoWikiText, wikitext to append at the bottom
Maarten, are you sure idField goes into the Description field? Elke previously talked about a new field called Campaign ID. I am not clear on how we create a field on Commons that is used only by WLM. Opening new bugs for license info and our own default categories.
I've begun work on this but have a few things that need some clarification, stemming from some ignorance around prior development on the app and how things are expected to work. I'm working off of formatUploadDescription() in upload.js, which looks like it was initially put there as proof of concept/placeholder/whatever for future use - which is saving a bunch of work (thanks Brion!). There is some disconnect, however, between what it's looking for in campaignConfig and what I assume I should be using for campaignConfig, which is the campaigns object defined in campaigns-data.js. * Will a campaign always have only one possible license? * CAMPAIGNS doesn't actually seem to be used anywhere at the moment - is it's structure rigid or can we make some changes? Like making the campaign name or id a key for accessing the rest of the campaign data? I'm tempted to just store the campaign name in prefs when the user selects a campaign. * Similarly, there appears to be some campaign data missing from the campaign structure we're storing - like the campaign ID and other idField info, and autoWikiText. Should we just replicate the data structure coming back from the campaign api? * More on the idField stuff - am I supposed to be using 'idFieldLabel', 'idFieldLabelPage', or 'idFieldMaxLength' for anything? I should be able to wrap this up once these questions get resolved.
Please note other related bugs: 38283 - WLM App license info from uploadcampaigns API 38285 - Title and description fields needed on Upload Info screen 38286 - Mobile default categories for WLM App image upload Since a Description field needs to be shown to the user, and to maintain consistency with the Upload Wizard conventions, perhaps we should not call this field the "description" field. With Upload Wizard I believe it was called Campaign ID field.
or maybe it's idField. In any case, ID is the monument ID, which seems to not be in the UploadCampaigns configuration info. Instead, the ID template that is in the configuration info uses a $1 presumably for the monument ID. Here is the latest from Elke: > 1) Do we have to enable a field called Campaign ID, which gets added to the > record of the photo on Commons (in addition to Title and Description)? Maybe we will even have 2 fields, if this Bug will be completed: https://bugzilla.wikimedia.org/show_bug.cgi?id=37303 However, the principle is the same: the field gets the id parameter (in the Wizard, either manually or per URL query string). Our app would need to fill the (known) ID value into a field that contains exactly the template which exists in the respective Upload Wizard campaign. (We still pull campaign information via API, right? In my understanding, you need to pull this information from the campaign configuration) The basic categories: * The localized city name is "Köln", next level "Nordrhein-Westfalen" * The Category on Commons: "Cultural heritage monuments in Cologne" -> however, we have sub categories here. If something is unclear in the category handling, we should add the best possible (i.e. most exactly) maintenance category: Category:Maintenance for Wiki Loves Monuments in ... * Germany * Cologne Category:Maintenance for Wiki Loves Monuments in ... * Switzerland * Kanton Wallis * Zermatt
I've modified Yuvi's python script for capturing campaign data to use the full json output coming from the campaign API. This has multiple benefits, like providing some flexibility if data structures change (esp if new fields get added), and ensures that we have easy access to data we may need without having to further edit the script. Before I commit it, I wanted to make sure I'm going down the right path and not screwing anybody up. You can see the changes and the resulting output here: https://gist.github.com/3091602
The gist looks great :)
Talked this over with Arthur on Skype. Things are clear now. It's almost done :-)
This is done in https://github.com/wikimedia/WLMMobile/pull/51
Updated pull request at: https://github.com/wikimedia/WLMMobile/pull/53
Merged https://github.com/wikimedia/WLMMobile/commit/5389af2696203a80b5fba73d57a3157e4e8cb9c5
