Hi guys,
I added a comment on bug 40810 but I also want to send it here to reach more people.
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.
Best regards, Bene*
It would be great if the badge info could be accessed through the lua api, and then let the clients decide how they want to display the information with templates or whatever other method. On the left sidebar with only one (default) badge is usually enough.
Cheers, David
On Sat, Feb 1, 2014 at 1:44 PM, Bene* benestar.wikimedia@gmail.com wrote:
Hi guys,
I added a comment on bug 40810 but I also want to send it here to reach more people.
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.
Best regards, Bene*
[1] https://www.wikidata.org/wiki/Wikidata:Development_plan
Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
It seems to me that allowing any number of batches is the way to go. We have followed the approach of "allow everything, let the community impose constraints" for most other things. Restricting this to a singe batch in the data model seems a bad idea to me.
That being said, I think it would be fine if the UI would only allow for adding/setting a single batch for now.
-- daniel
Am 01.02.2014 13:44, schrieb Bene*:
Hi guys,
I added a comment on bug 40810 but I also want to send it here to reach more people.
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.
Best regards, Bene*
[1] https://www.wikidata.org/wiki/Wikidata:Development_plan
Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
On Sat, Feb 1, 2014 at 1:44 PM, Bene* benestar.wikimedia@gmail.com wrote:
Hi guys,
I added a comment on bug 40810 but I also want to send it here to reach more people.
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.
That was an oversight in the development plan document. I corrected it. Several badges per sitelink need to be supported at least in the future. We can start with one.
Cheers Lydia
Am 03.02.2014 14:50, schrieb Lydia Pintscher:
On Sat, Feb 1, 2014 at 1:44 PM, Bene* benestar.wikimedia@gmail.com wrote:
Hi guys,
I added a comment on bug 40810 but I also want to send it here to reach more people.
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.
That was an oversight in the development plan document. I corrected it. Several badges per sitelink need to be supported at least in the future. We can start with one.
Cheers Lydia
Hi Lydia,
I would be glad if you explained a bit further how this feature will work on client. There needs to be a mechanism to select which items are visible in the interwiki links section and which are not. This will perhaps be a setting on the client. However, even if we say, only FA and GA badges should be shown in the article, it can still come to collisions when a sitelink has two badges which are both specified in the client's config. How should this cases be handled?
Best regards, Bene*
On Mon, Feb 3, 2014 at 8:37 PM, Bene* benestar.wikimedia@gmail.com wrote:
Hi Lydia,
I would be glad if you explained a bit further how this feature will work on client. There needs to be a mechanism to select which items are visible in the interwiki links section and which are not. This will perhaps be a setting on the client. However, even if we say, only FA and GA badges should be shown in the article, it can still come to collisions when a sitelink has two badges which are both specified in the client's config. How should this cases be handled?
We could always show the first or last in the config.
Cheers Lydia
Hey,
Wiadomość napisana przez Lydia Pintscher lydia.pintscher@wikimedia.de w dniu 3 lut 2014, o godz. 20:44:
On Mon, Feb 3, 2014 at 8:37 PM, Bene* benestar.wikimedia@gmail.com wrote:
Hi Lydia,
I would be glad if you explained a bit further how this feature will work on client. There needs to be a mechanism to select which items are visible in the interwiki links section and which are not. This will perhaps be a setting on the client. However, even if we say, only FA and GA badges should be shown in the article, it can still come to collisions when a sitelink has two badges which are both specified in the client's config. How should this cases be handled?
We could always show the first or last in the config.
I'd go with only FA/GA for sidebar, the only config would be to indicate under which items on Wikidata they are. FA would be preferred over GA. Other badges would be accessible via Lua and it would be up to the communities how to use them.
Or even just create some Lua module that would insert current templates used on Wikipedias based on data from Wikidata. Then no configuration on clients would be needed and transition would be seamless. Bene* suggested earlier that then communities could decide not to use Wikidata for badges, but actually they requested that feature. Also imposing decisions on them is not that nice.
I don't know though what performance impact that might have.
Regards, Michał
Am 03.02.2014 22:32, schrieb Michał Łazowik:
Hey,
Wiadomość napisana przez Lydia Pintscher lydia.pintscher@wikimedia.de w dniu 3 lut 2014, o godz. 20:44:
On Mon, Feb 3, 2014 at 8:37 PM, Bene* benestar.wikimedia@gmail.com wrote:
Hi Lydia,
I would be glad if you explained a bit further how this feature will work on client. There needs to be a mechanism to select which items are visible in the interwiki links section and which are not. This will perhaps be a setting on the client. However, even if we say, only FA and GA badges should be shown in the article, it can still come to collisions when a sitelink has two badges which are both specified in the client's config. How should this cases be handled?
We could always show the first or last in the config.
I'd go with only FA/GA for sidebar, the only config would be to indicate under which items on Wikidata they are. FA would be preferred over GA. Other badges would be accessible via Lua and it would be up to the communities how to use them.
Or even just create some Lua module that would insert current templates used on Wikipedias based on data from Wikidata. Then no configuration on clients would be needed and transition would be seamless. Bene* suggested earlier that then communities could decide not to use Wikidata for badges, but actually they requested that feature. Also imposing decisions on them is not that nice.
I don't know though what performance impact that might have.
Regards, Michał
Hey, I agree with everything said. Also having a "rank" of badges seems to be a good idea. However, I am not sure if Lua can handle the other badges because then a lua template would have to be inserted on *every* Wikipedia page. For the future, we must think about another mechanism so that badges like "citation needed" are added automatically, too. Maybe some lua scripts will be available on all pages by default?
Best regards, Bene
Am 03.02.2014 20:37, schrieb Bene*:
I would be glad if you explained a bit further how this feature will work on client. There needs to be a mechanism to select which items are visible in the interwiki links section and which are not. This will perhaps be a setting on the client. However, even if we say, only FA and GA badges should be shown in the article, it can still come to collisions when a sitelink has two badges which are both specified in the client's config. How should this cases be handled?
In that case, both badges would be shown. The idea is: "if it IS wrong, it should LOOK wrong". Having both badges on the same page violates a convention. The convention should not be enforced by the software but by the community (possibly with the help of bots, common.js, etc).
I would propose to add a css class for each badge that applies to a given language link. Per default, these classes would do nothing. Each client wiki can then define site CSS (or JS) to make some badges visible.
Am 03.02.2014 22:48, schrieb Bene*:
Am 03.02.2014 22:32, schrieb Michał Łazowik:
Or even just create some Lua module that would insert current templates used on Wikipedias based on data from Wikidata. Then no configuration on clients would be needed and transition would be seamless. Bene* suggested earlier that then communities could decide not to use Wikidata for badges, but actually they requested that feature. Also imposing decisions on them is not that nice.
I don't know though what performance impact that might have.
Regards, Michał
Hey, I agree with everything said. Also having a "rank" of badges seems to be a good idea. However, I am not sure if Lua can handle the other badges because then a lua template would have to be inserted on *every* Wikipedia page. For the future, we must think about another mechanism so that badges like "citation needed" are added automatically, too. Maybe some lua scripts will be available on all pages by default?
This sounds way too complicated for a baseline implementation. As I said earlier, I would suggest this: on the client, for each language link, add a css class for each badge that applies to that link. Period. I see no need to do more for now.
"Automatic" badges could be done via a bot, based on templates (or perhaps page_props). Thinking about how badges and page_props relate is actually interesting, but I don't think it's relevant for the initial implementation.
Lua could be used to push things to page_props (I don't think that is possible right now, but I think that can and should be added). But as I said, implementing "automatic badges" is completely separate from the task of making badges visible on the client.
Am 04.02.2014 12:21, schrieb Daniel Kinzler:
Am 03.02.2014 20:37, schrieb Bene*:
I would be glad if you explained a bit further how this feature will work on client. There needs to be a mechanism to select which items are visible in the interwiki links section and which are not. This will perhaps be a setting on the client. However, even if we say, only FA and GA badges should be shown in the article, it can still come to collisions when a sitelink has two badges which are both specified in the client's config. How should this cases be handled?
In that case, both badges would be shown. The idea is: "if it IS wrong, it should LOOK wrong". Having both badges on the same page violates a convention. The convention should not be enforced by the software but by the community (possibly with the help of bots, common.js, etc).
I would propose to add a css class for each badge that applies to a given language link. Per default, these classes would do nothing. Each client wiki can then define site CSS (or JS) to make some badges visible.
Interesting, so in your opinion the actual display of items should happen via the common.css? I think this can work though I don't know if we should leave this implementation detail to the local wikis. At least, it would prevent another config to be added to the client which is very recommened from my side. Also the wiki could rank the badges easier. (New css properties override old ones.) Thus I support your idea leaving this to the client wikis.
Another question, however, is which tooltip title should be added to the badges sitelink. We could use the description of the wikidata item but I am not sure if we can access it easily from client. However, it would provide an easy way to translate the tooltip without some hacky mediawiki messages.
Best regards, Bene*
Am 05.02.2014 18:00, schrieb Bene*:
Am 04.02.2014 12:21, schrieb Daniel Kinzler:
Am 03.02.2014 20:37, schrieb Bene*:
I would be glad if you explained a bit further how this feature will work on client. There needs to be a mechanism to select which items are visible in the interwiki links section and which are not. This will perhaps be a setting on the client. However, even if we say, only FA and GA badges should be shown in the article, it can still come to collisions when a sitelink has two badges which are both specified in the client's config. How should this cases be handled?
In that case, both badges would be shown. The idea is: "if it IS wrong, it should LOOK wrong". Having both badges on the same page violates a convention. The convention should not be enforced by the software but by the community (possibly with the help of bots, common.js, etc).
I would propose to add a css class for each badge that applies to a given language link. Per default, these classes would do nothing. Each client wiki can then define site CSS (or JS) to make some badges visible.
Interesting, so in your opinion the actual display of items should happen via the common.css? I think this can work though I don't know if we should leave this implementation detail to the local wikis. At least, it would prevent another config to be added to the client which is very recommened from my side. Also the wiki could rank the badges easier. (New css properties override old ones.) Thus I support your idea leaving this to the client wikis.
Another question, however, is which tooltip title should be added to the badges sitelink. We could use the description of the wikidata item but I am not sure if we can access it easily from client. However, it would provide an easy way to translate the tooltip without some hacky mediawiki messages.
Best regards, Bene*
In addition to the previous message, we still have to decide on one badge if we want to add a tooltip title. However, I don't think it makes sense to add a config variable only for the tooltip. Do you have any idea how to fix this?
Am 05.02.2014 22:40, schrieb Bene*:
Am 05.02.2014 18:00, schrieb Bene*:
Interesting, so in your opinion the actual display of items should happen via the common.css? I think this can work though I don't know if we should leave this implementation detail to the local wikis. At least, it would prevent another config to be added to the client which is very recommened from my side. Also the wiki could rank the badges easier. (New css properties override old ones.) Thus I support your idea leaving this to the client wikis.
I think that it's up to the local wiki to decide which badges to show, and how. Being able to manage this on-wiki seems like a good idea.
Another question, however, is which tooltip title should be added to the badges sitelink. We could use the description of the wikidata item but I am not sure if we can access it easily from client. However, it would provide an easy way to translate the tooltip without some hacky mediawiki messages.
Best regards, Bene*
In addition to the previous message, we still have to decide on one badge if we want to add a tooltip title. However, I don't think it makes sense to add a config variable only for the tooltip. Do you have any idea how to fix this?
A bit of JS code could set the tooltip based on the css classes. Access to the label associated with the badge would be possible by querying wikidata, but it would be nicer if we could somehow cache that info along with the page content. Otherwise, it would have to be fetched for every page view on wikipedia... not good.
-- daniel
wikidata-tech@lists.wikimedia.org