Last modified: 2014-11-04 22:49:24 UTC
Hebrew Wikipedians would like if Wikidata supported some metadata about the sitelinks, particularly good and featured article status. Currently there are templates in many wikipedias that add stars or symbols next to the interwiki link to indicate the corresponding article in that other language is a featured article.
If a volunteer picks this up, it would need some discussion before you start on that. We would explain how to go about for it.
*** Bug 36735 has been marked as a duplicate of this bug. ***
If the discussion of which Denny speaks relates to community approval, I think we're well past that. This is something that both the local Wikidata and the broader WMF communiutues have asked for several times, and while there's no formal RfC (that I can find) there's been plenty of commentary (incl. support) and no opposition.
(In reply to comment #3) > If the discussion of which Denny speaks relates to community approval I believe Denny is referring to the technical implementation.
Hi I am willing to volunteer to take on this. Denny, Can we connect via IRC to talk about how to implement this?
Vatsala: Just try #wikimedia-wikidata on Freenode IRC in European office hours.
Andre/Denny - I was there today - Will be there tomorrow and day after as well.
Did you manage to talk to Denny? If not please ping him (Denny_WMDE) and/or me (Lydia_WMDE) on freenode in the channel #wikimedia-wikidata. It'd be great to have someone working on this.
Hi Lydia, I havent been able to speak to Denny. I shall come online at the next opportunity. For this week(till Saturday) does US tine zone work for you? I live in India, but currently I am at a client's place for an assignment. Let me check the european time difference and will let you know when I can be on irc next.
Alternatively, Let me if around 4.30 pm European timezone works for you. Vatsala (In reply to comment #9) > Hi Lydia, I havent been able to speak to Denny. I shall come online at the > next opportunity. For this week(till Saturday) does US tine zone work for > you? > I live in India, but currently I am at a client's place for an assignment. > Let > me check the european time difference and will let you know when I can be on > irc next.
Vatsala, also feel free to Email me at denny.vrandecic@wikimedia.de Basically what I want to say is: * the way how sitelinks are saved already allows it to be extended from { 'site' : 'enwiki', 'title' : 'Berlin' } to { 'site' : 'enwiki', 'title' : 'Berlin', 'badge' : ['FA'] } (I am not completely sure on the exact names of the fields) So, what needs to happen is: * extend the structure of sitelinks in the above way (suggestion: use an array of things, so we can have orthogonal 'badges' like 'FA', 'stub', etc.) * extend the API to edit badges * extend the UI to display badges * extend the UI to edit badges * extend the client to display badges I hope this helps.
Hi Denny Thanks for this. This helps. I will take a look at this and come back again by Monday Tuesday.
(In reply to comment #12) > Thanks for this. This helps. I will take a look at this and come back again > by > Monday Tuesday. Hi. Are you still working on this?
I think this should be implemented like qualifiers (or like source but I don't think we need grouping) for each sitelink. Only implementing badges doesn't make sense. If implemented like link attributes badges would be a property with an item datatype, and it would link to items for FA or similar quality descriptions.
That is, we don't need grouping within each sitelink, but we obviously need grouping for each sitelink.
Change 72725 had a related patch set uploaded by Michał Łazowik: (bug 40810) Extend SimpleSiteLink by badges. https://gerrit.wikimedia.org/r/72725
Change 72842 had a related patch set uploaded by Michał Łazowik: (bug 40810) Extend SiteLink by badges. https://gerrit.wikimedia.org/r/72842
Change 72725 merged by jenkins-bot: (bug 40810) Extend SimpleSiteLink by badges. https://gerrit.wikimedia.org/r/72725
Change 72842 abandoned by Michał Łazowik: (bug 40810) Extend SiteLink by badges. Reason: Just learned this is deprecated... https://gerrit.wikimedia.org/r/72842
Huh? Deprecated? Someone mind clueing-in those of us who are out of the loop?
That's the reason for abandoning some code. I added badges support to a class that is deprecated, so it's not needed. The current class is already modified, see comment 18. However this is only a small chunk of what is to be done.
Change 74676 had a related patch set uploaded by Michał Łazowik: (bug 40810) Add badges support to Item https://gerrit.wikimedia.org/r/74676
Should be there a set of allowed badges? If yes then should there be a interface to modify it?
(In reply to comment #23) > Should be there a set of allowed badges? Yes. > If yes then should there be a > interface to modify it? Maybe just allow any arbitrary item (a featured article would use [[d:Q16467]] or [[d:Q16465]] for example), or a have admins maintain a list of items in a MediaWiki: namespace page.
(In reply to comment #24) > (In reply to comment #23) > > Should be there a set of allowed badges? > Yes. > > > If yes then should there be a > > interface to modify it? > > Maybe just allow any arbitrary item (a featured article would use > [[d:Q16467]] > or [[d:Q16465]] for example), or a have admins maintain a list of items in a > MediaWiki: namespace page. Would it be too radical to suggest a "Badge:" namespace? For starters, it'd be able to have its own content model, instead of some ugly MediaWiki: namespace hack.
(In reply to comment #25) > (In reply to comment #24) > > (In reply to comment #23) > > > Should be there a set of allowed badges? > > Yes. > > > > > If yes then should there be a > > > interface to modify it? > > > > Maybe just allow any arbitrary item (a featured article would use > > [[d:Q16467]] > > or [[d:Q16465]] for example), or a have admins maintain a list of items in a > > MediaWiki: namespace page. > > Would it be too radical to suggest a "Badge:" namespace? For starters, it'd > be > able to have its own content model, instead of some ugly MediaWiki: namespace > hack. A MediaWiki namespace hack would be much preferable to creating a new namespace. It's a much simpler option.
Just skimmed this discussion, but why does that have to live in the site links? Property "Article batch", pointing to the Wikidata item for the badge page(s). Add a qualifier to indicate language(s) where the badge was given. Maybe I'm missing some complication here?
It will make most sense from a logical point of view to connect the badge directly to the site link so the badge is removed or moved together with the link. A badge isn't a property of an item itself, but of the page of the link.
Could this also be used to mark links to redirects?
Yes, I think so.
Change 80000 had a related patch set uploaded by Michał Łazowik: SimpleSiteLink: make badges poing to Items https://gerrit.wikimedia.org/r/80000
Change 80000 merged by jenkins-bot: SimpleSiteLink: make badges point to Items https://gerrit.wikimedia.org/r/80000
Change 74676 merged by jenkins-bot: (bug 40810) Add badges support to Item https://gerrit.wikimedia.org/r/74676
Change 81934 had a related patch set uploaded by Michał Łazowik: Extend api to get badges https://gerrit.wikimedia.org/r/81934
Change 81934 merged by Jeroen De Dauw: Extend api to support getting badges https://gerrit.wikimedia.org/r/81934
See a related proposal: https://www.mediawiki.org/wiki/Extension:ArticleStatus
This should be linked here, too: https://gerrit.wikimedia.org/r/#/c/82637/ (Extend API to support editing badges)
I have a related use case that generalizes the GA/FA proposal aw well as the ArticleStatus proposal. I would like to be able to annotate individual articles with: (1) arbitrary article-level annotations, including but not limited to: * FA * GA * stub * Protection status * Article-level cleanup flags like {{refimprove}}, {{POV}}, {{notability}} (2) add qualifiers to these annotations to specify the start time or time range and potentially a rev_id as a source for these statements This would stretch the scope of the current notion of a badge but I'd like to hear if time qualifiers for badges are on the near horizon. Having these annotations represented in a structured format on Wikidata would allow people (or applications) to run queries like: give me all French Wikipedia articles in chemistry that have been flagged within the last year as stubs or as missing references.
Hi Dario Taraborelli, at the moment a badge is only a simple item which thus can also only contain one piece of information. If I understand your idea right, you want to have badges as a kind of statement system which works same as the statements of an item. I think this requires some thinking how useful this would be and especially how this could be implemented in the ui. Also I think this isn't so high priority. Because your approach goes wide beyond the current implementation a new bug would perhaps be the way to go.
(In reply to comment #39) > Hi Dario Taraborelli, at the moment a badge is only a simple item which thus > can also only contain one piece of information. If I understand your idea > right, you want to have badges as a kind of statement system which works same > as the statements of an item. Right. I agree that to have the kind of flexibility we need, sitelinks likely need to be able to have statements. E.g. in addition to real-world statements about a real-world object https://www.wikidata.org/wiki/Q2 (Earth), there need to be statements about the "English Wikipedia article on Earth".
(In reply to comment #40) > Right. I agree that to have the kind of flexibility we need, sitelinks > likely need to be able to have statements. To be clear, I mean this flexibility is probably required if Wikidata is to be a full representation of status items like Dario mentioned (protection, cleanup, etc.). This is relevant to GettingStarted, which uses such "needs cleanup" data. In the meantime, we have ideas for more incremental approaches that do not require such a new statement system.
I discussed this in-person with SWalling on Friday. Wikidata will be able to attach badges to articles. This will cover things like "this article needs copy-editing" and so on. It will only be on a page basis and not more granular. It will also not have more than a badge - so no qualifiers or anything like that for badges. This is enough for Getting Started per our discussion.
After discussion on IRC we decided that badges can only be some items which are specified in the config, together with an icon. This is because once it only makes sense to have some kinds of items available that might also be badges and additionally we need an icon to be displayed on Wikipedia which can not be provided by a single item. Thus there will be a config variable containing a set of items + icons that are allowed to be used as badges.
Change 108337 had a related patch set uploaded by Bene: Reduce badges to items listed in config https://gerrit.wikimedia.org/r/108337
Change 108337 merged by Addshore: Reduce badges to items listed in config https://gerrit.wikimedia.org/r/108337
We still need to discuss how the badges should work in general. At the development plan [1] it says "Each sitelink can have zero or one badge attached to it." This does not match the current implementation which allows multiple badges. So the implementation needs to be changed to only supporting one badge. However, if we decide to keep the option of multiple badges we face some other problems. First, the ui gets harder to be implemented on Wikidata. This is not a real problem though. But a real problem is that we cannot determine which badge we want to display on the client. The only option I see to solve this issue is either to create another config variable (very ugly) or to only allow one badge as stated in the development plan anyway. [1] https://www.wikidata.org/wiki/Wikidata:Development_plan
(In reply to comment #46) > We still need to discuss how the badges should work in general. At the > development plan [1] it says "Each sitelink can have zero or one badge > attached > to it." This does not match the current implementation which allows multiple > badges. So the implementation needs to be changed to only supporting one > badge. > > However, if we decide to keep the option of multiple badges we face some > other > problems. First, the ui gets harder to be implemented on Wikidata. This is > not > a real problem though. But a real problem is that we cannot determine which > badge we want to display on the client. The only option I see to solve this > issue is either to create another config variable (very ugly) or to only > allow > one badge as stated in the development plan anyway. > > [1] https://www.wikidata.org/wiki/Wikidata:Development_plan I would really really like to have support for multiple badges. Can we just whitelist certain badges for display? Start with Featured and Good Article, and if someone wants a badge displayed they can request it. Most of the other badges people have mention seem to be the kind that we won't want displayed on site links, etc.
I believe that data items are not the right place to host 'badges', basically because the quality rating does *not* belong to the sitelink, but to the wiki article itself. Badges should be on the client-side (Wikipedia for featured articles, Commons for featured pictures, etc.) so allowing to rate every pages, including those without a connected Wikidata item (think also to non-WMF wikis that don't have a data repo). I think of an extension that would allow sysops and 'quality rating administrators' to edit quality status of pages; then such badges would be displayed in the 'Other languages' section, when linked from another language version.
(In reply to comment #48) > ... > I think of an extension that would allow sysops and 'quality rating > administrators' to edit quality status of pages; then such badges would be > displayed in the 'Other languages' section, when linked from another language > version. That looks like FlaggedRevs to me.
Another use case for badges: Importance rating https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_1.0#Statistics It was suggested as a property, but badges could handle it better: https://www.wikidata.org/wiki/Wikidata:Property_proposal/Generic#Wikipedia_Importance
And yet another use case: Wikiproject scope https://www.wikidata.org/wiki/Wikidata:Property_proposal/Sister_projects#WikiProjects Currently that information is stored on talk pages (together with importance rating and quality assessment)
I've updated what's the current plan to my understanding: https://www.wikidata.org/wiki/Wikidata:Development_plan#Badges
I moved the list to https://meta.wikimedia.org/wiki/Wikidata/Development/Badges
Change 149918 had a related patch set uploaded by Bene: Add good and featured badges to config https://gerrit.wikimedia.org/r/149918
Change 149928 had a related patch set uploaded by Bene: Add good and featured article badges to testwikidata https://gerrit.wikimedia.org/r/149928
Change 149928 merged by jenkins-bot: Add good and featured article badges to testwikidata https://gerrit.wikimedia.org/r/149928
Change 149918 merged by jenkins-bot: Add good and featured badges to config https://gerrit.wikimedia.org/r/149918
