Hi devs,
recently I had a discussion on IRC on how badges for site links should work. After some time I realized that there is a general design issue with their implementation.
The original idea of badges is to replace the FA/GA templates on Wikipedias. This makes sense as it is centralized data which is used in every Wikipedia. On Wikidata we can place that the article about XXX on enwiki is a good/featured article and this will be shown on every Wikipedia having a corresponding article. So basically, we are just removing the {{Link GA|en}} or {{Link FA|en}} template and adding this information to Wikidata. You can see that this is the last step away from the old interwiki system.
However, there are proposals to badges that go far beyond this original idea. Even the yet written implementation has such issues. As everybody will easily understand, an article can be either ga or fa or none. However, it cannot be ga *and* fa together. Thus one sitelink should only be connected to a maximum of one badge. In contrast, the implementation allows more than one badge, even worse, it allows an infinite number of badges. Other proposals want badges to support templates concerning meta information of the local article. However, this information do really *not* concern other Wikipedias. Or can you imagine a Wikipedia that wants to display a "this article needs sources" icon next to the (probably not existing) fa icon? This example makes clear that such meta information that has no value to another Wikipedia than itself should not be stored on Wikidata, too. Wikidata is a place for central data, not any data. For the Wikipedias' internal meta information the working categories work really fine today and there is no reason to force this system into Wikidata without any benefit to Wikidata or the Wikipedias themselves.
So finally, my proposal is to only support one badge per sitelink. And also to only support badges that make sense to have at a central point and that will be used by more than one Wikipedia. I think this makes the ui easier to understand and the code not relying on super-huge config list showing all possible meta information that could be stored as badges resulting in another huge statement system, but even worse.
Please keep this concerns in mind when deciding how the badges should work.
Best regards, Bene*
I don't know about the current implementation, but from reading your mail, what you are proposing sounds just as limiting as what you are describing as current implementation.
It sounds like what you really want is basically a configurable two dimensional array where the first dimension represents different kind of badges. The second dimension then holds all badges within that group. Now you can only choose one badge of each group per site-link. Done. This way you would still allow different kind of badges than fa/ga. This would also consider non-wikipedia use cases for wikibase usage.
Cheers, Daniel
20. Januar 2014 04:50:57 Bene*:
Hi devs,
recently I had a discussion on IRC on how badges for site links should work. After some time I realized that there is a general design issue with their implementation.
The original idea of badges is to replace the FA/GA templates on Wikipedias. This makes sense as it is centralized data which is used in every Wikipedia. On Wikidata we can place that the article about XXX on enwiki is a good/featured article and this will be shown on every Wikipedia having a corresponding article. So basically, we are just removing the {{Link GA|en}} or {{Link FA|en}} template and adding this information to Wikidata. You can see that this is the last step away from the old interwiki system.
However, there are proposals to badges that go far beyond this original idea. Even the yet written implementation has such issues. As everybody will easily understand, an article can be either ga or fa or none. However, it cannot be ga *and* fa together. Thus one sitelink should only be connected to a maximum of one badge. In contrast, the implementation allows more than one badge, even worse, it allows an infinite number of badges. Other proposals want badges to support templates concerning meta information of the local article. However, this information do really *not* concern other Wikipedias. Or can you imagine a Wikipedia that wants to display a "this article needs sources" icon next to the (probably not existing) fa icon? This example makes clear that such meta information that has no value to another Wikipedia than itself should not be stored on Wikidata, too. Wikidata is a place for central data, not any data. For the Wikipedias' internal meta information the working categories work really fine today and there is no reason to force this system into Wikidata without any benefit to Wikidata or the Wikipedias themselves.
So finally, my proposal is to only support one badge per sitelink. And also to only support badges that make sense to have at a central point and that will be used by more than one Wikipedia. I think this makes the ui easier to understand and the code not relying on super-huge config list showing all possible meta information that could be stored as badges resulting in another huge statement system, but even worse.
Please keep this concerns in mind when deciding how the badges should work.
Best regards, Bene*
Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Hey :)
On Sun, Jan 19, 2014 at 10:50 PM, Bene* benestar.wikimedia@gmail.com wrote:
Hi devs,
recently I had a discussion on IRC on how badges for site links should work. After some time I realized that there is a general design issue with their implementation.
<snip>
So here's my view on this: * Wikidata is not just a place to store information that is useful to at least 2 Wikipedias. It can store stuff that is useful for only one of them or even none of them. * Badges like "this article needs copy-editing" or "this article needs sources" or "this article needs expansion" are information about one specific article. However they are not just useful for that one Wikipedia. There are plans for tools that will for example give you suggestions like "You are on this article on English Wikipedia. The article on the same topic in German (which we know you also speak) needs expansion. Do you want to have a look?" To do this in a useful and non-painful way this information needs to be stored centrally in Wikidata and not in cumbersome templates.
Therefore: * We should allow more than one badge per sitelink. * We can start with supporting just one badge per sitelink.
Cheers Lydia
On Mon, Jan 20, 2014 at 6:13 PM, Lydia Pintscher < lydia.pintscher@wikimedia.de> wrote:
- We should allow more than one badge per sitelink.
- We can start with supporting just one badge per sitelink.
I agree with your two points. Since badges don't need statements, just associated items to any given page, would it be possible to adapt the "alias interface" to tag sitelinks with badges? GUI-wise, is more or less what is needed to fulfill those requirements, a second row for each of the sitelinks that lists all the badges (actually items) associated with a given article in a language.
If there the sitelink list grows too large, it could be hidden, with a 4th column "Badges" (next to "Language-Code-Linked page") with a text "X badges" (expandable, similar to statement sources). Not sure if I expressed myself correctly or if it is feasible, I could draw a mockup if wanted.
Anyhow, I just hope that the performance issues are fixed before spending too much time on badges... I still get the "unresponsive script error" every time...
Micru
On Mon, Jan 20, 2014 at 7:19 PM, David Cuenca dacuetu@gmail.com wrote:
Anyhow, I just hope that the performance issues are fixed before spending too much time on badges... I still get the "unresponsive script error" every time...
Being worked on, yes :) It is however not just one fix but several. Some of them might be finished before badges are released and others after. You should see continuous improvements with the next deployments.
Cheers Lydia
On Mon, Jan 20, 2014 at 7:27 PM, Lydia Pintscher < lydia.pintscher@wikimedia.de> wrote:
Being worked on, yes :) It is however not just one fix but several. Some of them might be finished before badges are released and others after. You should see continuous improvements with the next deployments.
Nice :) About the badges, is there already a solid UI design or would you want some proposals?
Micru
20.01.2014 19:19, David Cuenca:
On Mon, Jan 20, 2014 at 6:13 PM, Lydia Pintscher <lydia.pintscher@wikimedia.de mailto:lydia.pintscher@wikimedia.de> wrote:
* We should allow more than one badge per sitelink. * We can start with supporting just one badge per sitelink.I agree with your two points. Since badges don't need statements, just associated items to any given page, would it be possible to adapt the "alias interface" to tag sitelinks with badges? GUI-wise, is more or less what is needed to fulfill those requirements, a second row for each of the sitelinks that lists all the badges (actually items) associated with a given article in a language.
If there the sitelink list grows too large, it could be hidden, with a 4th column "Badges" (next to "Language-Code-Linked page") with a text "X badges" (expandable, similar to statement sources). Not sure if I expressed myself correctly or if it is feasible, I could draw a mockup if wanted.
Hi, I am not sure if you got the point which I criticize. While with some effort we could create an interface on Wikidata supporting several badges [1] we are still facing a problem on the client. How should we choose the badges that should be visible on Wikipedia against those that aren't relevant in the "in other languages" section? I know, one answer is to add another config variable, but this is only a short solution because it will end up in adding another config and even one more so that we finally will have content in the code base. This is something we should really avoid.
Also there exist some mockups already on Commons [1] [2].
[1] https://commons.wikimedia.org/w/index.php?title=File:Site_link_badges_edit_i... [2] https://commons.wikimedia.org/w/index.php?title=File:Site_link_badges_edit_i...
Best regards, Bene
On Mon, Jan 20, 2014 at 7:43 PM, Bene* benestar.wikimedia@gmail.com wrote:
Hi, I am not sure if you got the point which I criticize. While with some effort we could create an interface on Wikidata supporting several badges [1] we are still facing a problem on the client. How should we choose the badges that should be visible on Wikipedia against those that aren't relevant in the "in other languages" section? I know, one answer is to add another config variable, but this is only a short solution because it will end up in adding another config and even one more so that we finally will have content in the code base. This is something we should really avoid.
I don't see so much of a trouble in configuring that client-side (for instance, allowing only badge FA/GA in the sidebar). In the end, it is the same as with statements: all of them are stored in Wikidata and then each Wikipedia decides which ones to use and how.
Also there exist some mockups already on Commons [1] [2].
Quite good! Maybe it is missing the number of badges stored.
Micru
wikidata-tech@lists.wikimedia.org