Page MenuHomePhabricator

Make a user configurable "property visibility" dialog for the infobox
Closed, DeclinedPublic


After a lot of lengthy discussions on nowiki we still can't decide what to show in a rather simple infobox for biographies. Given that this is our first real attempt to use statements from Wikidata in infoboxes at nowiki it seems impossible to continue along this approach. We need another way to do this.

Realizing that the problem is basically different opinions on what is important, and then what should go into the infobox, the solution would be to make the infobox configurable for each user. The more or less obvious solution would be to do something similar to the sitelinks, creating a preference dialog of some kind.

screendump sitelinks dialog.png (548×801 px, 82 KB)

The actual sitelinks dialog in use for the main page at nowiki.

Instead of showing the available languages the dialog would show the available named data, or from the Wikidata entry the labels for the statements. That would make it possible for the user to choose what to show in the infobox. It would be some local data that the infobox could show, and that would be augmented with data from the Wikidata item, but then limited to the user specific configuration.

There must be a general configuration for anonymous users, but I think it would be nice if they can change the configuration from that through a session-specific configuration.

The TemplateData would name the default data to add locally, and would not depend on the (possibly learned) infobox configuration.

I think the way to do this is to track the users configuration for classes or specific attributes that are found on the actual child of $content, and then show only those fields within the infobox that goes above a relative threshold compared to the commonly learned values, or explicitly set to visible by the users themselves. Anonymous users only use the commonly set values as their default, but can override that.

The commonly learned values should be learned from /changes/ and not from views, as that makes it less likely to be stuck on a unsatisfactory value.

The common values goes in a table with fields for /template/, /prop/, and /change/. The /template/ is a class or attribute specific for the template. The /prop/ is a class or attribute specific for the row. The change is an increase or decrement, possibly weighted by the user type.

Dividing the /template/ and /prop/ over two columns makes it possible to estimate visibility for props from new and previously unseen templates.

TemplateData could be used to set a default value for visibility. It could be set both as some kind of weight and as a forced visibility. The forced visibility should only be used for obvious fields, otherwise it will only reignite the discussion about what should be seen in a default infobox.

Event Timeline

jeblad renamed this task from Make a property selector for the infobox to Make a user configurable property visibility dialog for the infobox.Mar 1 2016, 2:41 PM
jeblad renamed this task from Make a user configurable property visibility dialog for the infobox to Make a user configurable "property visibility" dialog for the infobox.Mar 1 2016, 4:16 PM

Note that this will have implications for T114251, because that RFC only describe a fixed layout for the infoboxes

Lydia_Pintscher added a subscriber: Lydia_Pintscher.

I am sorry but we are not going to introduce this massive amount of complexity for very little gain.