In T281974#8110157, @Xaosflux wrote:

In T281974#8110129, @alexhollender_WMF wrote:

In T281974#8110113, @Xaosflux wrote:

I think a "design spec" problem above is that "coordinates" are data (user generated content), not meta-data - why are they in the meta-data section?

hmm, maybe there is a better term we could use aside from metadata? I wasn't sure what to call that stuff...

I think that is fairly accurate - most of that is things about the "page", not about the "subject of the page" - so it is metadata. Unlike "coordinates" which is content about the subject of a page that is.

@Xaosflux - that's a good point. Although I suppose that even though they're user generated, from the perspective of viewing the article it makes sense for them to appear together, coordinates can sort of be considered meta-data about an article that has a location, similar to how the star is meta-data about an article that has certain quality. It's not a perfect match - one is still related to the content of the article itself rather than the state of the article, but I feel like this is the argument that got them the positioning at the top of the page in the first place vs simply being shown in the infobox.

I'm fully with @Xaosflux here — the major distinction is things about the page vs. things about the topic, and coordinates are clearly about the topic, compared to protection icons/GA and FA stars/etc. which are about the page. One way to conceptualize it: If Wikipedia didn't exist, would this thing still be relevant? If so, it's about the topic, not the page.

I think it's okay to separate this somewhat new discussion of "should coordinates be considered metadata, and if not where should they be displayed?" from the initial discussion in this task about resolving the issues where coordinates and indicators are overlapping other contents. I realize it might seem silly to move coordinates twice, but I think it might simplify things to first move coordinates just below the page titlebar underline, into the page toolbar (which is like a ~10px move), and then start a separate discussion if people think there might be value in moving them even more.

(Hopefully not contradicting myself too much here by adding a note about the second discussion, which again I think can happen in a separate task — I think we should keep in mind that coordinates are, at least in most cases, redundant. They are shown at the top of the article, and within the Infobox. I think in order to have a good discussion about where to put them we should first collect data regarding clicks to the two different coordinates links).

In T281974#8115543, @alexhollender_WMF wrote:

I think we should keep in mind that coordinates are, at least in most cases, redundant. They are shown at the top of the article, and within the Infobox.

It depends on the wiki. On huwiki, for example, yes, there are hardly any coordinates not repeated in the infobox. On enwiki, in contrast, there are quite some. With naïve regexes:

• Title+body coordinates (title position redundant): ~700k in mainspace
• Title-only coordinates (title position not redundant): ~400k in mainspace

(there are also a few body-only coordinates, but they’re irrelevant for us). There are certainly false positives and false negatives, but I hope the magnitude is correct. While technically true (more than the half), I wouldn’t call 60-65% “most cases”.

Just for clarification: the templates used to display coordinates or page related issues (featured, protected... whatever) are community mantained just because there's no better way to do this. There are some wikis that are struggling to show coordinates, or just have the modules and templates ready. It is community mantained, but it is not mandatory to assume that it will be like that in the future.

Wikidata, for example, has a native way of marking featured content, and this is automatically shown in the interwiki links. The same technology could be used to show a star (or whatever we decide that should be the default icon, and consistency here may be interesting) whenever we want. I think that just before the title is great, because it adds a very interesting information layer to the article title itself. Also the protection should be linked to the "Edit" button, and should be shown automatically. Currently, we don't have templates for showing that in most of the wikimedia projects.

Coordinates are something that could be just shown as in dewikivoyage, at the end of the title bar. Or below. Whatever it is better. But is the moment to think out of the box and make things happen for the better. Any change will have conflicts, but we have to think on all the wikimedia projects that will benefit, and not in the 5-10 wikiPedias that have technical people to do this stuff.

I suppose an overall design question is is: how much design should be specific to this data point that is only useful for projects with pages about geographical locations? From the examples above, "featured content" is quite generic and can represent the quality of any sort of page; indicators such as protection status are inherent to mediawiki pages; but "coordinates"? Not even "most" pages (2ish percent) on hosted Wikipedia's have a use for that, even if only looking at "encyclopedia articles" it's under 1/5th of pages.

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?