As a reminder we have no coordinates in the mobile site (T91481) for more or less the same reason so hopefully any change has the benefit of fixing mobile.
Also related: T292617

Somehow, the solution given to floating elements in the left is broken: T317922

Coords on en.wiki appear to have moved up ever further, and are now overlapping the article toolbar:

@Xaosflux see above: looks like the hackaround inside https://en.wikipedia.org/wiki/MediaWiki:Vector-2022.css needs revising again.

The issue of coordinate location came up on the Vector2022 office hours today. I wasn't paying full attention to that particular discussion, but the gist was "absolute positioning is not a good thing" :-)

It certainly is not, I'd think that ideally as "coordinates" are content about the subject of an article (not meta-data about the page itself) they could possibly be targeted at the top of the "content area". These 'areas' didn't layout this way until v2022 so there is of course a collision there still.

(enwiki hack changed to -0.5em as immediate workaround)

Last change (the watchlist star) breaks (again) the alignment of ORES quality prediction at euwiki.

This is also broken at cawiki: https://ca.wikipedia.org/wiki/Categoria:Ciutats_d%27Hisp%C3%A0nia

This is still happening.

This is still happening, making a mess in the right of the articls.

In T281974#8470232, @Theklan wrote:

This is still happening, making a mess in the right of the articls.

Hey @Theklan — are you asking us to fix the coordinates? I'm unfortunately not sure it's something we can control. I believe most of the fixes thus far have been done by volunteer developers. Is it possible for you to locate someone who has worked on the coordinates template on your wiki?

Yes, I'm asking the team who broke the design to unbreak it.

Is not about the coordinates, is about the position of the quality assesment, that has been moving from left to right with every new deployment (the last one, two months ago, when the little black star was placed there).

Not sure if the conceptional arguments ever got resolved? Something like a "quality assessment" is certainly meta-data, it is something "about the page"; but coordinates aren't about the "page", they are generally "about the subject of this page" -- meaning they aren't really meta-data, they are content.

No, it never got solved. And it doesn't seem there's a plan for even talking about that.

In T281974#8470997, @Xaosflux wrote:

Not sure if the conceptional arguments ever got resolved? Something like a "quality assessment" is certainly meta-data, it is something "about the page"; but coordinates aren't about the "page", they are generally "about the subject of this page" -- meaning they aren't really meta-data, they are content.

Good point. Although it's hard to tell at what point it becomes a bigger discussion, better suited for another task. I totally agree with you about coordinates being content (not metadata), and I think the coordinates should be in the infobox (which in many cases they already are, but then are repeated at the top of the article again), which would resolve this issue. On the other hand I think this task is scoped more tightly, and is about making sure the coordinates (in their current location) aren't overlapping with other elements.

My apologies if adding the diagram to the top of this task complicated things.

@Theklan I think you could be bold and set a new example on your wiki by removing the coordinates from the top of the article and making sure they are always included in the infobox. I think it would help move the conversation forward.

I don't think "page design" at the mediawiki level should depend on the presence or absence of an "infobox". For example I just went to a random page, about a place https://en.wikivoyage.org/wiki/Onuma_Quasi-National_Park - coordinates could be useful content to present to a reader there, but there is no "infobox".

Ok, I have taken a couple of hours to see if the problem here is that English is not my first language and I'm not communicating exactly where the problem is. It may be the problem, I don't know whether I'm using the best words to describe it. I will try again, from the beginning.

The design in Vector (legacy) allowed to have three kind of contents added to the title. We could have things related to the consideration of the article (indicators) that are meta-information. We could have things related to the article itself, like coordinates, and we could have a place to show the ORES quality assesment. In Vector (legacy) we had this distributed in this way:

As you can see in the image, we have these four elements distributed in four sectors. The upper left sector is the title. The upper right sector are the indicators. The lower left sector is the quality. And the lower right sector is for coordinates.

When Vector 2022 was launched, this sections needed to change because the language switcher went to the place where indicators were placed. You can argue that indicators weren't there by design, because there wasn't any place designed specifically to have them. So, no need to mantain there in the place the communities have been deciding (mostly by legacy and intuition, because there was a free slot there, not by a democratic process of deciding where to put every single item). You may be right, and my point is not about that discussion.

So, the design team decided to move the indicators to the place where the coordinates were "living", making them part of the article content in some way. There are other solutions, as Wikidata has showed us and we can see easily in the language switcher: indicators are properties of the article, so they can be moved to the title for stars and to the edit button for lockers. I will come again later with this.

So now, we have coordinates and indicators sharing the same space, in the lower right section:

What's the problem then? I am asking about the coordinates? NO. Again: NO. I'm not asking about the coordinates. I'm not. I'm asking about the section in the lower left, that is used for many things in different wikis (in Basque Wikipedia, for the ORES assesment) that has been moved ALSO to the lower right. You can see it again here:

The lower left section has disappeared three times in the process. We have looked for workarounds, but every time a new "feature" is added to the middle bar, it goes again to the right. This is not a decision made by the Basque community, nor a css error, nor someone messing around. This is a decision made by de design team to move something from the left to the right.

I am here spending my volunteer time (I should be know cooking the lunch for my family) just to say that the lower left section SHOULD return, because now we have THREE different things competing for the same space: indicators, coordinates and quality assesment.

Let me know if there is something wrongly explained, and I'll try to rewrite it.

Now, I could open a new discussion to explain why adding the indicators to the title section, and not below that is better. This is an opinion, is not like the upper section, that is a BUG.

My opinion on this is that quality stars, edit-locks and this kind of templates have been mantained by the community, but are not sitewide. If I protect an article for editing, the system automatically protects it, but a lock symbol is not added automatically. I have to do it by hand. It would be way better if the process itself would add the lock symbol to the edit button, so the protection status of every articles is known, up-to-date, and independent of the community having the correct templates, css editing rights or whatever needed. Don't think on English Wikipedia. Template:pp (https://en.wikipedia.org/wiki/Template:Pp) exists ONLY in 73 languages.

The language selector also gives us quality assessments from other wikipedias. We can see two different stars by default, coming from Wikidata. Ironically, I can know if an article is featured in English or French, but I can't see if it is featured in the language I'm reading if the users don't add a template that doesn't exist in 150 languages. So, we could do this better.

The last discussion is about coordinates. The template:coord in English was created in 2007, 15 years ago. It exists in 248 languages, somehow. It is used in articles without infoboxes. And we don't need to assume that every Wikipedia is going to use an infobox with inline coordinates and that this is the best solution. It can be good, but 80 languages don't have an infobox template.

My opinion is that every thing should have a place, and that the design team is responsible for that. But, again, this is an opinion section. What I'm asking here is to solve the BUG.

Thanks.

In T281974#8470232, @Theklan wrote:

This is still happening, making a mess in the right of the articls.

Two weeks with this bug.

@Theklan thank you for taking the time to explain all of that, and once again I apologize for the frustration and extra work this has caused you. First, to make sure I understand the specific issue you're describing above:

this is what you want	this is what is keeps happening

In T281974#8473735, @Theklan wrote:

The lower left section has disappeared three times in the process. We have looked for workarounds, but every time a new "feature" is added to the middle bar, it goes again to the right. This is not a decision made by the Basque community, nor a css error, nor someone messing around. This is a decision made by de design team to move something from the left to the right.

Firstly I will say that it is fully our fault (the WMF web team) for messing up the location of coordinates, page indicators, and the ORES scores. However regarding the position of the ORES scores moving from the bottom-left to the bottom-right, this was not "a decision made by de design team". In other words, I think the movement of those elements is more or less happening by mistake. Of course this doesn't really make it any better, but I just want to let you know that we are not intentionally trying to change some layout decision that you have made. Some communities display the "From Wikipedia..." tagline there, but for any community that doesn't have the tagline there they should be free to put any indicators, ORES scores, or anything else in that area.

In summary:

• Our team has messed up the location of coordinates, indicators, and ORES scores in the process of developing Vector 2022
• Our team should have had a better plan from the beginning regarding how we would fix the layout of these elements. Instead, since these elements are in the "content" area (which individual communities/volunteers have more control over), versus the "interface" area (which the foundation has more control over), we've assumed/hoped that volunteers would step in and fix them. This was perhaps an unfair burden to place on volunteers.
• I am going to bring this up again with the web team and try and come back with a clear plan for how to handle this going forward
• Further discussions of the most appropriate locations for these elements should happen in a separate task. This task is just for making the most simple & critical fixes so that the layout isn't broken, and no elements are overlapping each other.

Thanks @alexhollender_WMF for trying to understand the core of the problem. You are right with the "this is what you want" image, the ORES quality should go in the left, as described there. We have been making some css tricks (some of them are documented in this task) but a stable solution would be the ideal thing here.

About the discussion for all this items, let me know when you open the separate task. I think we have to think out of the box here, and define what is the ideal solution, something that will be useful especially for the technically under-represented communities.

12 days have gone since the previous aknowledgement of the error. It is still happening.

I appreciate the ability to have indicators to the right of the title. I see two specific feature requests in @Theklan's examples above:

• naming + maintaining a style that will place things to the right of the title
• naming + maintaining a style that will place things in the 'tagline' area below the title

Do these fit within the scope of this ticket? Do they deserve a separate one?

Anything that clarifies such styles / reduces the chance that future changes will mess with them / reduces the need for different language projects to duplicate one another's css work, would be welcome.

This is still happening... and taking too long.

Related: T331131

related T331545

In T281974#8567498, @Theklan wrote:

This is still happening... and taking too long.

Still happening. Is there any move to solve the issue?

This is still happening.

This is still happening at Basque Wikipedia.

But not only: https://en.wikipedia.org/wiki/Gran_Sasso_raid

I don't see the problem on eu anymore, are you still using your js solution? What's a current example?
en:wp has been using absolute positioning and not tagging coords as an indicator; needs to switch.

In T281974#8813290, @Theklan wrote:

But not only: https://en.wikipedia.org/wiki/Gran_Sasso_raid

English has had a minor hackaround that was made more problematic recently due to the Zebra transition work. T335625

In T281974#8814801, @Sj wrote:

I don't see the problem on eu anymore, are you still using your js solution? What's a current example?

Exactly the same problem, exactly with the same examples (T281974#8473735). It's been more than 4 months since there was an "apologize" message here (T281974#8505980) and nothing has changed.

The "Kalitate neurketa" section should be floating on the left. Still happening.

I see, thanks. I was confused by the different overlapping threads in the discussions above.

It seems to me the original issue has been addressed: there is a spec for how to tag coordinates & indicators in a way that reliably lays them out without overlap. By default, that lays out all indicators in the part of the page Amir originally proposed.

It might be more helpful to close this as resolved and open more specific tasks for aspects that came up in the discussion:

1. Creating a similar class for things that should render in / next to the tagline (like the former eu.wp layout)
2. Helping wikis migrate to this indicator model / scoping the needs of wikis with workarounds + related downstream bugs (e.g.: en, de, eu wikipedias; T310064, T331131, T331545, ...)
3. Exploring alternatives that make coordinates + protection-status first-class elements of skins (T12347, T292617)

Whatever, if what was working works again. After some months with this broken by a decision from the design team, any advance towards solving it is welcome.

We (@TheDJ @Dreamy_Jazz) fixed this during the hackathon with the following edits:

• https://en.wikipedia.org/w/index.php?title=MediaWiki%3AVector-2022.css&diff=1156129014&oldid=1154048793
• https://en.wikipedia.org/w/index.php?title=MediaWiki%3AModern.css&diff=1156127423&oldid=972680770
• https://en.wikipedia.org/w/index.php?title=MediaWiki%3ACologneblue.css&diff=1156127288&oldid=813458633
• https://en.wikipedia.org/w/index.php?title=MediaWiki%3AMonobook.css&diff=1156123302&oldid=1098443565
• https://en.wikipedia.org/w/index.php?title=MediaWiki%3ATimeless.css&diff=1156125663&oldid=1069323210
• https://en.m.wikipedia.org/w/index.php?title=Module:Coordinates&diff=prev&oldid=1156130168
• https://en.m.wikipedia.org/w/index.php?title=Module:Attached_KML&diff=prev&oldid=1156130170

Hopefully this is helpful for other projects who still need to fix this.

Good, but this is still broken at Basque Wikipedia, and is not solved with css changes. The design team broke it and should unbreak it.

@Theklan to be honest I'm not 100% sure what you are considering broken and expecting us to fix. If you are unhappy with the layout and want the ORES quality indicators on the left and the coordinates on the right, but that's something you have control over, not us - that's easily fixed by you adding .mw-indicators { display: flex; width:100%; } to your MediaWiki:Vector-2022.css but you've said this is not solvable by CSS changes. I think you've misunderstood Alex's message in T281974#8505980 - my understanding of that message was Alex was attempting to express empathy for your situation and the trouble we may have caused you in the development of the new skin and the decisions we've made. If things are broken, we need to work together to fix them, just as I did with English Wikipedia admins on T281974#8869238.

If the .mw-indicators { display: flex; width:100%; }` rule is not sufficient, we may need to also update euwiki's templates using T281974#8869238 as guidance.

This task is about converting coordinates to indicators which euwiki is somewhat doing (the JS hack we added a while back was meant as a temporary solution until enwiki was updated).

How about you create a new ticket just as @Sj suggests, rather than to keep commenting on this ticket and let's try to find a solution together? I'm taking some time off over the next 2 weeks but I'd be happy to reach out to you when I'm back on Telegram and work towards a solution together.

Thanks for the solution, @Jdlrobson . It solves partially the problem, as they are loaded and moved wildly. The distance between items is also suboptimal.

It may be the problem that English is not my main language, but when @alexhollender_WMF wrote T281974#8505980 I perfectly read this:

I am going to bring this up again with the web team and try and come back with a clear plan for how to handle this going forward

I have been waiting for a solution till yesterday, when this partial solution came. It wasn't so difficult, and no need to spend five months asking for it.

Regarding waiting for 5 months and Alex's unkept promise, I'm not sure how helpful it is to keep continuing this conversation. Let's just remember we're all human here and want the same thing and complaining/blaming seems counterproductive. For this kind of thing, in future, I suggest using discord/IRC/Telegram/wiki talk pages for nudging rather than a Phabricator ping. Counterintuitively, commenting on Phabricator tickets from my experience usually slows things down rather than speeds things up as it leads to important context getting buried in the discussion.

Back to the main problem here, "they are loaded and moved wildly." - this is because euwiki is using JavaScript to add the coordinates. When we did this together I explained it was a temporary short term fix (T281974#7657210) as we both didn't know the appropriate template edits that were required. However, now we do know the proper fixes thanks to the help from English Wikipedia interface editors. If you apply the corresponding edits detailed in T281974#8869238 we can remove that JavaScript and this should work smoothly as it does on English Wikipedia. For now t[[ https://eu.wikipedia.org/w/index.php?title=MediaWiki%3AVector-2022.css&diff=9301553&oldid=9301496 | his edit ]] should help a little, but this is not a long term fix.

So in summary:

• Please apply the changes to templates on euwiki as done on English Wikipedia in T281974#8869238
• Delete https://eu.wikipedia.org/wiki/MediaWiki:Vector-2022.js

If after the above the issue is not fixed or you encounter any problems, please feel free to reach out to me directly.

Thanks for the advice on changes. It worked nearly perfect. Do you know what parameter should be changed to get the coordinates before the logos?

In T281974#8883687, @Theklan wrote:

Thanks for the advice on changes. It worked nearly perfect. Do you know what parameter should be changed to get the coordinates before the logos?

@Theklan did you solve how to move coordinates before logos?

Yes, that is solved.

@Theklan I have similar problem (see T376723) so my question is actually how it was solved?

I don't remember all the steps now, but I think @Jdlrobson helped with some css (??)