For clarity, I'm removing the EditCheck tag as the issue here isn't directly related to whether that project exists or not.

Thanks. It's a fairly visible issue, and so more reports a likely before the next deployment train on next Thursday. So maybe let's keep this open until the fix is deployed.

Also present in Special:Tags where it's hinted that tag-contenttranslation-v2 message starts with a redundant space.

Seems related to recent actions taken in T376814.

I guess this is no longer relevant. We haven't experienced replication failures for a while, since switching the replication tool and subsequent updates in 2022. Also current sync lag is less than about 1.5 hour, which is significantly more frequent than "< 3 days" sync lag target set above.

@MBH: possibly you opened some (other) image on the same page via MediaViewer before opening the map?

Translator's note: label "More" is apparently hardcoded and cannot be translated.

From task description:

This task, IMO, must apply to the FileImporter extension, the...

See T311203.

The icon displayed on the second image is apparently an old version of the building icon (see here), not the current home icon which is different. Icons were updated in 2022. T316779 mentions that old icons were cached and had to be removed. @awight, any idea if old cached icons perhaps weren't removed on some server or on either cluster?

I see recent changes include 8caf710 where ambox styles were restricted to Minerva skin. So for now just do the same with infobox and hatnote styles?

In T282027#9851010, @Jdlrobson wrote:

/.../ the main issue here is legacy Vector /.../ I've reopened the other ticket and separated these two tickets by skin to make this clearer.

In T228546#6884394, @TheDJ wrote:

Right, so I know what the reason is, I think. The idea behind not having holes for geomasks was that holes with more than 1 of those thick red line holes, make for very messy shapes that often heavily obscure that part of the map, especially for the thumbnails.

I'm not sure I agree.. but that was the reason.

In T305121#9848982, @The_Equalizer wrote:

Also not autopositioning if multiple points are used on a thumbnail. See Module_talk:Mapframe#Second_point_does_not_show_up

To me names seem mostly up-to-date, including the Edugundlapadu village example.

In T195318#9787765, @TheDJ wrote:

In T195318#9787762, @Pikne wrote:

How about special-casing Serbian to use sr-Latn?

This probably can be done via fallbacks.json...

I think this is the better approach indeed. It seems much simpler and future proof.

If rule 3 is removed, what would be the result for English users for locations with a non-Latin name field, no name:en field, and a "Latn" name? That is certainly common in Serbia...

This is no longer reproducible after various fixes were applied in related tasks, right?

In T70320#5249102, @Tacsipacsi wrote:

And still, now here.

This was further addressed two years ago by the tech staff in 6098d3f.

In T228812#5368645, @MSantos wrote:

... we use Kartotherian, with mapnik + tm source and styles using CartoCSS and OSM database.

much shorter duration, like 7 days, might also be desirable

Aside: do you have links handy to 2-3 edits that show the above happening?

In T300942#8151596, @Sdkb wrote:

We made some adjustments to the wording, stored here (see the talk page), so I'm not sure there's all that much else to do.

Purge right was removed a few months ago in dcaf840.

I suppose to some degree at least Kartographer could draw from MultimediaViewer on how to handle long/stylized captions.

From merged task T271627#6738943:

FWIW, this is the work Maptiler/OpenMapTiles is doing for using Wikidata labels in the maps

This is likely due to the usage of width=100%

A map from Wikimedia Commons is NOT rendered in a browser for the property 'geoshape' with datatype 'Geographic shape'. There is a link to a Wikimedia Commons map instead of an image of a map.

it looks like only relations with specific tags are shown on the map

Some individual ways with QID also can be retrieved, including the Bryant Park example in the docs, but others currently don't work due to a regression, see T311203.

This makes me wonder, how did this came to be that these language names are maintained in multiple places, or is it even intentional?

I'm no longer sure why I figured that this one relates to the placement of neighbouring labels. It also occurs on tile boundry, and so the root cause is likely the same as in that other task. Closely packed labels might somehow contribute to this issue but I don't really know.

That's another case of T312938: Multiple overlapping OSM area relations with the same QID are imported as a single polygon with unwanted hole(s).

I notice that patches here make use the nullish coalescing operator (??). In some older browsers, possibly including some browsers of Grade A support, this seems to break most of site JavaScript.

Update: It was not the Name property. Gonna test now if it was the altitude or the other change

A working example is https://www.wikidata.org/wiki/Q122936541#P3896

So by "fails" you mean that mapdata isn't diplayed on a map next to Commons link in this Wikidata item page? To me it seems that item pages just aren't set to display this data (using mapframe or otherwise). If I'm not missing something in browser console then it doesn't try to load respective jsondata on this page nor on any other item page with P3896 statement.

What exactly is not working on Wikidata as expected? Where is this jsondata query used? Is there an example page?

Most tasks relating to these undeployed styles were closed/declined long ago so I'm closing this one too.

See T195318. We have been considering it might be better to simply ignore suffixed language keys.

I'm closing this one as originally reported examples work now. About the remaining regression there's T311203: Geoline referencing individual way(s) with a QID renders empty map.

Just recently we run into this again and fixed it in one place, see https://gerrit.wikimedia.org/r/901538. Is this the reason for the 400? I.e. is this a duplicate of T331977?

It seems this issue no longer comes up. Thanks!

I suppose it's still worth pointing out from original task description that full screen mapframe map (its dynamic content) wasn't broken. So what we might ask for here more specifically is to treat the data in more uniform manner, i.e. take either approach:

1. if this GeoJSON was invalid and shouldn't be expected to work then break the map entirely (also in full screen), or
2. if Kartographer can skip bad features in GeoJSON and still show the rest of the data then also add this capability to snapshot service.

In browser console these 400s have the following response: Cannot read property 'coordinates' of null. The map data for all of these three examples include features that lack geometry ("geometry": null) which I assume breaks snapshot image. So I suppose the image would appear if JSON data was cleaned up and these particular features were removed from it?

It doesn't seem to occur anymore. I suppose it was fixed as part of the work done in subtask. Please reopen if I miss something.

This doesn't seem to occur any more. Please reopen if miss something.

Assam example is mainly about a tagging error in source data, introduced a couple of weeks ago. I now fixed it (see OSM history), and tiles are expected to update within a few days, too.

In T333318#8906256, @akosiaris wrote:

In T333318#8900126, @AntiCompositeNumber wrote:

is there a specific reason the tile viewer at https://maps.wikimedia.org/ was broken?

Misconfiguration. This specific one is fixed, we still have a few pending items though.

And when Q16887380 got redirected then Q28813620 in turn got double redirected (as it had been redirected to Q16887380 a little earlier). By now a bot has fixed the double redirect in Q28813620. So was double redirect in a class tree enough to break the mw.wikibase.getReferencedEntityId call?

It looks this issue is there since 1.41/wmf.6 branch. Does it relate to T333160?

This should be fixed now. Around the time when this task was created some replica map servers were out of sync.

It looks this is actually specific to access=private key not amenity=parking. T334413 has an example where a garden is rendered the same.