This edit, apparently using the Android "suggested edit" feature, changed a valid short description of "none" to something undesirable. The tool should not suggest editing a short description that already exists.
Talk:Wikimedia Apps/Android Suggested edits
Hello @Jonesey95,
We appreciate you raising this concern.Ensuring the accuracy and appropriateness of suggested edits is a priority for us, and we are actively working to improve this aspect of our Android app experience.
The Wikimedia Apps/Suggested edit page has been removed and you cannot currently reach help page from the app.
Hello @Afaz,
Regarding the removal of the Wikimedia Apps/Suggested edit page, we now have separate pages for Android suggested edits and iOS suggested edits.
Regarding the inability to reach the help page from the app, I would appreciate it if you could send a screen recording video demonstrating what happens when you try to access the help page. Please send the video to android-support@wikimedia.org. Thanks.
The guidelines for descriptions state that they should not begin with capital letters. However, the app prompts me to capitalize my article descriptions.
I agree, this need to be clarified. I have adopted the Short Descriptions as my WikiGnome calling, in part. Over 12 yeas, I made thousands of edits (12k+ total), many of which were for SD's in en- and ru- Wikipedias. The rules I follow, and recomend, are: on En-wiki, short descriptions start witth a Cap letter. On RU-wiki, always with a lower case, unless it's a proper name or similar. That is the de facto format for almost every page I see.
https://www.wikidata.org/wiki/Help:Description#Capitalization is not in line with what appear to be common best practices + a long-established and closely followed policy by hundreds of editors.
I second the question/proposal whether such should be revised along the lines of the generally accepted principles and to eliminate any confusion, as my colleague had indicated above.
I will be happy to do what is best for the community. In which forum can this be discussed and weighed on by Admins and Stewards?
Cheers,
~~~~
Thank you, @Of the universe.
Wikidata description norms and English Wikipedia norms contradict each other, yes. Unfortunately.
okay, my personal confusion is resolved then. Thanks
The guidelines on the suggested edits main page also says lowercase:
"Article descriptions ...are not capitalized unless the first word is a proper noun."
Should this be changed/removed?
I'm talking about this section: Wikimedia Apps/Suggested edits#Tips for creating article descriptions
Aligned with what? Descriptions generally shouldn’t be capitalized anywhere except for the English Wikipedia. Either describe what the majority does (lowercase), or explain that “sorry people, you should write it lower case everywhere, except for the English Wikipedia, which decided to do it differently”. Aligning with one wiki against hundreds of others is not acceptable, even if that one happens to be the largest.
@Tacsipacsi, we're talking about alignment between the app and the page about the app: The app has a "suggested edits" functionality which prompts the user to capitalize English article short descriptions. The page about the app's suggested edits functionality (which we are on the talk page for) states that short descriptions should *not* be capitalized. These two things are out of alignment.
A "Wikidata description" and a "Short description" are not the same thing. For many Wikipedias, the article description defaults to the description held in Wikidata. On the English WP, the Short description is not fetched from Wikidata, but is part of the article itself. Wikidata descriptions are not capitalised. Short descriptions start with a capital letter. As such, the app should provide advice that depends on which WP is being edited and this article still needs to make this difference clear.
I came here to resolve this as well. It's confusing on Android. If you read the instructions, you're told not to capitalize the first word unless it is a proper noun. Then when you attempt to actually write the caption, it automatically prompts you to capitalize. I'm surprised this thread has been here two years as of this writing and there has not been a fix. Here is a screenshot with highlighting. https://drive.google.com/file/d/1EnCUANosRqCjk0t6ol0v_g6OCNimykqb/view?usp=sharing
Thanks. I went ahead and clarified the guidelines.
I see that this feature has graduated to having people make short descriptions directly. One thing I notice is that the character limit is 250, and the counter at the bottom goes X/250 as you type. While I guess in some rare cases it'd be necessary to have a short description that long, our target is 40 characters or less. I'm a bit concerned that having the 250 absolute limit display, without any information about the 40 target, will make people think that their description is a fine length so long as it's under 250. Would it be possible to adjust the design here to nudge people toward not going over 40 unless they really need to?
@JTanner (WMF) and @RSchoenbaechler (WMF), I think you should take this into consideration.
Does it really have to add every edited page to the Watchlist? At least set it to expire after the maximum duration (6 months), if it have to.
And it (most likely) adds also pages that wasn't even modified (ex. when all suggested links were incorrect, and there's no entry in page history).
I've been trying to recreate this issue, and failing. Could you please just confirm that this is not a general watchlist setting you have activated, adding pages you edit to the watchlist? See the preference towards the bottom at w:pl:Specjalna:Preferencje#mw-prefsection-watchlist.
I have only two options set, rest options (related to watchlist) is unset:
*Add pages I create and files I upload to my watchlist
*Add new files I upload to my watchlist
I did a Link suggestions test run, and none of the pages were added to watchlist (including one page with all links rejected).
After checking my watchlist for pages that I edited by Link suggestions:
One page without history entry (I remembered that page because two common words were suggested to be linked to two TV series):
https://pl.wikipedia.org/w/index.php?title=Gia_Carangi&offset=&limit=500&action=history
With history entry (one from Aug, rest from Dec 2021):
https://pl.wikipedia.org/w/index.php?title=Wolne_Pa%C5%84stwo_Orania&action=history
https://pl.wikipedia.org/w/index.php?title=Marek_W%C3%B3jcik&action=history
https://pl.wikipedia.org/w/index.php?title=Konstantin_Mamontow&action=history
https://pl.wikipedia.org/w/index.php?title=Jeronimas_Milius&action=history
https://pl.wikipedia.org/w/index.php?title=D%C5%BCummuah&action=history
https://pl.wikipedia.org/w/index.php?title=Daniel_Bryan&action=history
https://pl.wikipedia.org/w/index.php?title=Carlos_Chagas&action=history
Oh, this may have been already fixed - https://phabricator.wikimedia.org/T289547 - or it's just a date coincidence.
Ah, great. Thank you!
RIT RAJARSHI (talkcontribs) @Johan (WMF)
Interestingly, there is a very similar feature (Suggested tags) (https://commons.wikimedia.org/wiki/Commons:Structured_data/Computer-aided_tagging) which I can access from desktop. It would be very helpful if the "suggested translation"s
I am running across a lot of images, where the suggestions are bad and instead of skipping I want to exclude the image from sugestions to other people so that we can handle it on Wiki in a more accurate fashion. As an experience user I would like more confidence that if I skip it doesn't send the image to someone very likely to add bad tags.
Hi WMF folks! I just downloaded the Android app to try out this feature, and I have some feedback (mainly on the article descriptions feature, which is the one I've tried so far).
Overall, the design looks very modern and clean, so I hope it'll entice newcomers to start editing.
With the metrics at the top, it's very cool to see the editing streak count. The contributions count was confusing, though, since it said I only had 4500 edits, and I had to click through to infer that it was talking about only in the past 30 days and only in suggested edits areas. It also told me that my 0 image caption contributions had been seen 3000 times in the past 30 days, so something funny is happening there. Granted, this is more of an experienced editor problem, and we're not the target audience, but still, I could see someone not being happy when their count starts mysteriously dropping after a month of going up, or branching out to trying normal editing and wondering why their count doesn't go up from it. Why limit to 30 days and not including lifetime edits? Also, it'd be better (if processing power allows) to include the views for a page only in the days since someone made the edit there; someone who just edited a page hasn't had their work seen by those in the past.
Going into the suggested edit feed, it's confusing and limiting to not have the entire article available. One of the first articles I got was Richard Pennycook, which gave me a first paragraph of Richard John Pennycook CBE (born February 1964) was chief executive officer of the Co-operative Group.This wasn't enough, since to get to the standard [Nationality] [occupation] format for the short description, I needed to either see CBE spelled out as "commander of the order of the British empire", which didn't happen until farther down the page, or be able to click through on it. I didn't see any option to open the rest of the page (it took me a bit to figure out that you need to click "add description" first, then the tab at the bottom). I encountered a similar issue with Army Distinguished Public Service Medal, where I needed to be able to click through to confirm that it was an American military award. For Sir Thomas Taylor, 2nd Baronet, of Kells, not having the birth/death dates in the parentheses was a problem, since the preferred short description of Anglo-Irish politician (1686–1757) required them. People are going to want to have a description in mind by the time they click "add description", so I'd suggest either adding a way to view more from the initial screen, or making people click "add description" first before showing them any article text. Context is really important, so it'd be good to allow people to read more with only one click, not two, and to have it on the same page rather than opening in a new tab.
Beginning a short description with a (capitalized) nationality is an extremely common practice, so it was a little disconcerting to have it yell at me with a brown warning triangle every time that happens, even if it then let me publish anyways. I'd suggest loading a dictionary of proper nouns (or at least nationalities) into the software so it stops doing this.
Once I initially clicked the blue arrow, it took me a minute to realize I was just looking at a preview and needed to tap it again to save. Short descriptions don't require previewing, so I think this should just become one step.
I noticed that the descriptions were only being saved to Wikidata, not Wikipedia. This was after I had read the "your edit is live on Wikipedia" message (which is technically false), so it took me a sec to figure out what was happening. As you're likely aware, short descriptions on Wikipedia/Wikidata is an area that's had some controversy and is in some amount of flux due to the (imo deeply misguided) choice to fork the systems a while back. I'm guessing that you're having folks save to Wikidata because the descriptions there are less standardized than on Wikipedia (which really enforces the "short" part), which makes some sense, but also I predict that eventually the systems will be reunited, so it'd be good to train people how to just add short descriptions directly on Wikipedia. Currently, I couldn't easily find any guidance on what actually makes a good description, which newcomers will likely need.
Some of the pages in the feed seemed pretty minor, or likely to have short descriptions added automatically at some point. I'm curious how the feed is selected; are more trustworthy editors (as measured by experience/reversions) given more important pages? Is the feed tailored based on reading history, or are there plans to allow filtering it to specific categories?
I'll stop there for now since this message is already way longer than I thought it'd be, but I hope the above is useful!
I just checked out the other types of suggested edits, so some feedback on those.
For image captions, it's insanely hard (even as an experienced editor) to add good captions for images that don't already have thorough documentation. If they're in a different language or don't have good data (meaning a useful description), they should not be being surfaced. The only two possible outcomes are (a) editors get frustrated because they can't seem to help out, or (b) they take wild guesses about what the image is or otherwise add a caption that does more harm than good. This task could be useful for some images that have a thorough description but no caption, but it shouldn't go beyond that.
For image tags, I was often able to add very generic tags, but it was much harder to add specific tags, which are what would actually be useful. For instance, for commons:File:Gemeindebau Laaer-Berg-Straße 32.jpg, I was able to tag "apartment building", but we have a million pictures of apartment buildings. I lacked the context (from knowing German or being able to see the location metadata) that would've allowed me to tag the city as well or the specific building, which would be much more useful. As above, I'd suggest not surfacing photos that are described only in a foreign language. People will still probably be able to add something for such photos, but it's unlikely to be useful, and to the extent it removes photos from untagged categories, it could in some cases be worse than doing nothing.
Also, at one point I added some tags, published, then realized there was another one I should add. It should be possible to go back and make corrections or add further tags.
Thanks for reading all this feedback, and again, I hope it's helpful!
@Sdkb We're in the process of evaluating the work on suggested edits so far, so this is very appreciated. I haven't had time to properly read and think about it just yet, but we will take this into our considerations, and maybe get back to you later to follow up if we have questions.
You can see for example https://phabricator.wikimedia.org/T271727 for some of the work on the Commons tags.
I stumbled on this example of how a user with apparent issues went on a brief spree: https://www.wikidata.org/w/index.php?title=Special:Contributions/Piely01pi&offset=&limit=500&target=Piely01pi Commons:Administrators' noticeboard/User problems#Piely01pi
I can’t see how we (Wikimedia communities collectively) could have responded differently, and hope the person is getting whatever help they need in real life. Unfortunately a tool that allows users to make numerous, small, rapid, beneficial changes also allows numerous, small, rapid, detrimental changes.
Are you monitoring reversion rates, and who is watching the Wikidata Recent Changes feed for Suggested Edits tag?
Yes, we are monitoring reversion rates, people who get reverted will also get the tool disabled. However, this hasn't been quite enough; we're taking a close look at suggested edits for both Wikidata and Commons.
when you click add tags, it covers the description when there is a lomg list of results preventing you from being able to provide the specific tags required for depicts. Also, please remove the tag "forehead" its crap and turns out to be rather racist: i have only seen it on people of color.
Also please turn off architecture and hairstyle: these are getting applied to everything which makes them useless.
Apparently Forehead is sexist too: https://commons.wikimedia.org/w/index.php?title=Special:Search&limit=20&offset=40&profile=default&search=haswbstatement%3AP180%3DQ41055&advancedSearch-current=%7B%7D&ns0=1&ns6=1&ns12=1&ns14=1&ns100=1&ns106=1
The tags are automatically suggested by the Cloud Vision API, and we only display the tags with the highest confidence scores. We do not do filtering of the type you are suggesting. Regarding the description being sometimes covered, this is a known issue, and is a limitation of Android. It cannot be changed.
This post was hidden by Julle (history)
@Sadads There's no app-specific workflow for this, but as far as I understand we should be affected by the blacklist Keegan talks about in a thread you're involved in over at Commons, which probably makes more sense than trying to solve this specifically on the app side instead of in general.
@CGauthier (WMF) That is a different standard than what is set on Commons per the structured data team, and you should make sure that you have the right end points per @Johan (WMF).
Moreover, as for the search: that is exactly one of the problems that the team on Commons is trying to address with their upcoming overhaul: making sure that the rest of the contextual metadata is available for folks who are adding depicts statements (they aren't tags btw -- they never have been tags, and the use of tags as a concept trips up new users, and is deceptive).