[go: nahoru, domu]

Page MenuHomePhabricator

Other projects sidebar duplicates content in corpus of text
Closed, InvalidPublic

Description

Editors add Sister project boxes, e.g. "There is other content available on Wiktionary" and Sister project links boxes, e.g. "Find more about San Francisco at Wikipedia's sister projects [...list...]", and Sister-inline links, e.g. "Media related to Cat at Wikimedia Commons"
e.g.

Now on certain pages we are duplicating this content which causes bloat to the html which should be as thin as possible.

I think the side bar is great - is there some way we can consolidate these two things and remove the need for in-article boxes that take up much needed real estate in mobile?

Event Timeline

I've edited the description to clarify which templates are being discussed, and give examples. :-)

Now on certain pages we are duplicating this content which causes bloat to the html which should be as thin as possible.

I agree that we want to unbloat HTML, and that examining redundant duplication is worthwhile.
However, I think the visual prominence of the template'd versions of these links is very useful and important.
It's already difficult to encourage users to visit our sister projects, where much related content exists, and we want to make that easier and more frequent. Removing the old/established convention of templated boxes, and leaving only the links in the sidebar - which, I would guess, most readers don't look at very often or very closely - would make it even less likely that they'll travel from enwiki:James_Joyce over to https://en.wikisource.org/wiki/Author:James_Joyce

I think the side bar is great - is there some way we can consolidate these two things and remove the need for in-article boxes that take up much needed real estate in mobile?

I'm confused on this point... AFAICT, those templates do not show up in mobile. I checked the mobileweb and the android app, and the boxes are not displayed in either, though the inline links do appear.

If anything, I'd suggest we add them to mobile!

I've edited the description to clarify which templates are being discussed, and give examples. :-)

Now on certain pages we are duplicating this content which causes bloat to the html which should be as thin as possible.

I agree that we want to unbloat HTML, and that examining redundant duplication is worthwhile.

This is all I'm asking in this task.

However, I think the visual prominence of the template'd versions of these links is very useful and important.
It's already difficult to encourage users to visit our sister projects, where much related content exists, and we want to make that easier and more frequent. Removing the old/established convention of templated boxes, and leaving only the links in the sidebar - which, I would guess, most readers don't look at very often or very closely - would make it even less likely that they'll travel from enwiki:James_Joyce over to https://en.wikisource.org/wiki/Author:James_Joyce

Have we ever done any analysis to see if people click on them or is this based on personal opinion?

Sister project boxes may display information that's not easily automated. Even several links to the same sister project, when relevant.

Closed per above.

Above where? I think we all agreed that we've some duplication or, at best, inconsistency to fix.

The sidebar and the templates have different uses, as said above. There is some overlap in functionality, but the report summary is otherwise incorrect.

Either way, this is not a valid MediaWiki report: if some wiki-specific functionality is superseded by MediaWiki, then

  • said functionality needs to change, not MediaWiki;
  • such change needs to be discussed and implemented locally.

The templates can be altered locally to change their output or display based on sitelinks on Wikidata, if there is consensus to do so.

Other unrelated issues were conflated in this report and should be addressed separately:

  • the degradation of sidebar functionality by MobileFrontend;
  • the MobileFrontend hacks to override some site-specific content;
  • the alleged impact on HTML size of some specific template.