Olga: possible blocker for wikidata so we might want to reach out to WMDE to get this prioritized.

If I remove Vector 2022’s limitations on the page container’s width in dev tools, then the sitelinks move to the side again:

(Edit: In the screenshot, I disabled the padding as well as the max-width, but it turns out disabling the max-width is enough on its own, you can leave the padding as it is.)

Is the restriction on the page width relevant for Wikidata? I thought it was aimed at large amounts of prose, like Wikipedia articles. Could it just be turned off by default?

In T316797#8378718, @Lucas_Werkmeister_WMDE wrote:

If I remove Vector 2022’s limitations on the page container’s width in dev tools, then the sitelinks move to the side again.

Unfortunately, simply removing the max-width of .mw-page-container would cause the content of entity pages to overflow their margins, and make them become excessively wide. Further adjustments would be needed. Here's a screenshot with an exaggerated width (>1800px) so the effect is easier to perceive:

I would try to find a more localized and scalable solution, probably related to adjusting min-widths and breakpoints. I'm currently working on a design proposal: it'd be great to get help to validate its feasibility 🙏🏻

In T316797#10394206, @Arian_Bozorg wrote:

This seems to be fixed now

Still visible here. Try narrowing your screen a bit more, e.g., until 'View history' is above the sitelink box?

Hi Mike, can you give me some details of the browser and the width of the screen?

In T316797#10410059, @Arian_Bozorg wrote:

Hi Mike, can you give me some details of the browser and the width of the screen?

Firefox on Mac, latest versions. For the width, see the task description - 'Make sure screen is < 1570px'.

Project chat for reference: https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2024/05#Could_we_switch_the_default_interface_skin_to_Vector_2022%3F

Sharing this user style that may be helpful

@media ( min-width: 1600px ) {
    .wikibase-entityview.wb-item {
        display: flex;
        flex-flow: row;
        gap: 8px;
    }
    .wikibase-entityview > * {
        float: none;
        overflow: scroll;
    }
    .wikibase-entityview-main,
    .wikibase-entityview-side {
        max-width: none !important;
    }
    .wikibase-entityview::after {
        content: none !important;
    }
    .wikibase-snakview {
        display: flex;
        gap: 8px;
    }
    .wikibase-snakview * {
        margin: 0 0 0 2px !important;
        position: relative !important;
        width: auto !important;
    }
    
    .wikibase-entityview-side {
        min-width: 366px;
    }
    .wikibase-statementgroupview {
        overflow: scroll;
    }    
    .wikibase-snakview-value {
        display: flex;
        max-width: 140px;
        white-space: nowrap;
        overflow: scroll;
        text-overflow: ellipsis;
     }
}

FWIW limited width can be disabled on certain namespaces ($wmgVectorMaxWidthOptionsNamespaces and VectorMaxWidthOptions), and probably doesn't make sense on item pages e.g. https://www.wikidata.org/wiki/Q1

WMDE: Let me know if you need any help working out how to fix this.

In T316797#10566092, @Jdlrobson-WMF wrote:

FWIW limited width can be disabled on certain namespaces ($wmgVectorMaxWidthOptionsNamespaces and VectorMaxWidthOptions), and probably doesn't make sense on item pages e.g. https://www.wikidata.org/wiki/Q1

I was just thinking the same thing – given that limited width is (IIUC) mainly motivated by legibility of long lines of prose text, and the desktop Wikidata UI already limits the width on its own anyways, I think it would make a lot of sense to disable the width limitation in the Item, Property and Lexeme namespaces. (Maybe EntitySchema too, but I’m not so sure there.) I think this wouldn’t completely solve the issue here, but it would already help for some screen widths.

@Lucas_Werkmeister_WMDE strangely my bad. This is already configured:
https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/1d43603d85f7b7e00aeeb7f1a8199dae6a0bd5bc/wmf-config/InitialiseSettings.php#2405

Ignore my last comment. It's already defaulting to as wide as Vector 2022 supports. If I recall correctly, the reason we don't support different widths on different pages is to provide consistent placement of the menu items. The width only applies when menus are closed, and here we're specifically concerned about the content when the menus are open.

T316797#10566092 seems like the best approach here. I'd suggest we try it out in [[MediaWiki:Vector 2022]] first while Wikidata.org defaults to legacy Vector to get some user feedback unless there any major objections.

Any objections to trying this out in MediaWiki:Vector-2022.css first? If I don't hear any by Tuesday next week, I'll apply this with the intention of feedback for this task.

FYI I added some code, limited to users who've disabled max width, and have both menus pinned. While it does have some readability bugs at resolutions close to 1600px I suspect the power users with large screens will prefer this to the status quo in the interim period until this bug can be addressed properly. Please revert my change when a better fix is in place:
https://www.wikidata.org/w/index.php?title=MediaWiki:Vector-2022.css&oldid=2326454407

In T316797#10644445, @Jdlrobson-WMF wrote:

FYI I added some code, limited to users who've disabled max width, and have both menus pinned. While it does have some readability bugs at resolutions close to 1600px I suspect the power users with large screens will prefer this to the status quo in the interim period until this bug can be addressed properly. Please revert my change when a better fix is in place:
https://www.wikidata.org/w/index.php?title=MediaWiki:Vector-2022.css&oldid=2326454407

FTR, I can’t revert that – apparently the Wikidata Staff group doesn’t even have permission to edit that page (let alone delete it). Please move that CSS to Gerrit (probably Wikibase, or possibly Vector?) where we can properly review it.

Judging by this screenshot (from this report; screenshot shows this item), I don’t think the 1600px threshold is ideal. 1750px or 1800px seems to work better in local testing (so that qualifiers aren’t squished as much).

Please move that CSS to Gerrit (probably Wikibase, or possibly Vector?) where we can properly review it.

I am not set up to develop Wikibase locally and this is only intended as a short term fix so I won't be pushing it to Gerrit (Wikidata shouldn't be relying on Vector classes IMO to address this issue)

The proper fix here IMO is to make that interface response by redoing the CSS completely to use flexbox and drop all the fixed margins in the current design.

I’m not talking about the proper fix yet, I’m interested in your short term fix. The way in which you’ve chosen to install it makes it editable for only very few people (the interface admins, global interface admins, and a handful of other global groups) to edit it, and specifically, no Wikidata developers at WMDE are able to edit it. This is not a sustainable state of affairs – it’s absurd that I should have to file edit requests to fix the CSS.

My team and I currently don’t have a local Wikibase development setup. However, you’re welcome to copy that code and push it to Gerrit—I’m just not sure which module would be the best fit.

I’d be happy to be accountable for coordinating and remove this code from MediaWiki:Vector-2022.css once we have a solution in Gerrit.

Change #1129869 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] Remove long-deprecated wikibase.common ResourceLoader module

https://gerrit.wikimedia.org/r/1129869

Change #1129870 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Jdlrobson):

[mediawiki/extensions/Wikibase@master] Add workaround for sitelinks on Vector 2022

https://gerrit.wikimedia.org/r/1129870

@Lucas_Werkmeister_WMDE I can probably get this backported this afternoon (and remove the associated site CSS) if you can get it merged (and want me to do that!). Just let me know!

I’ve tested the patch locally and it seems to do the right thing – if you can review it that sounds fine to me (otherwise I can try to find a reviewer in the team).

In T316797#10657558, @Lucas_Werkmeister_WMDE wrote:

I’ve tested the patch locally and it seems to do the right thing – if you can review it that sounds fine to me (otherwise I can try to find a reviewer in the team).

I don't have a developer environment for Wikidata setup and don't feel comfortable merging code blindly (particularly if I'm backporting it :-)) so reviewer in your team would be great!

(I’d be fine with letting this roll out via the train, FWIW.)

Change #1129869 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Remove long-deprecated wikibase.common ResourceLoader module

https://gerrit.wikimedia.org/r/1129869

Change #1129870 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Add workaround for sitelinks on Vector 2022

https://gerrit.wikimedia.org/r/1129870

I've removed the code in https://www.wikidata.org/wiki/MediaWiki:Vector-2022.css ! Thanks all!