In T253764#11529024, @Ladsgroup wrote:

the benefit of sorting in a nice way doesn't outweigh the cost of maintaining this extension in production (and translations, etc.)

In T412532#11485497, @Dragoniez wrote:

	"checkuser-tempaccount-specialblock-ip-target": "See temporary account contributions at [[Special:IPContributions/$1]].",

Should we localize the special page name in this message on the UI?

In T413034#11487204, @TheDJ wrote:

Not the same as the linked ticket.

One cause I’ve seen this in the past that had this effect, was there being a hole in the shape, causing the inverse to cover the entire earth. Another is, when there are multiple nested shapes. shape-inverse doesn’t like that

In T413557#11486298, @Romaine wrote:

The problem is solved now. What did cause it?

In T228812#11485868, @Nux wrote:

T145226 seems to be fixed.
San Fran label seems OK too: https://maps.wikimedia.org/#12/37.7751/-122.4102

This is probably only because particular label nodes have been moved, and their current location doesn't happen to be near tile boundary. May become broken again if they will be moved.
https://pewu.github.io/osm-history/#/node/26819236
https://pewu.github.io/osm-history/#/node/3009663643

This JSON data includes two MultiPoint features. It appears that static map (snapshot) doesn't support these properly, only one marker is displayed per multiple coordinates of each MultiPoint feature.

In T408884#11413427, @elukey wrote:

After a chat with Yiannis, the following commit was highlighted https://github.com/wikimedia/osm-bright.tm2/commit/e5b7a05b692199238ce54eb8e2e879331256d7ae. We added it while transitioning to the new kartotherian/mapnik versions, but we lost the context on what it was meant to resolve.

As per T407246, for Wikimedia's use case $2 in this particular message is either "10 minutes" or "24 hours". Then maybe it wouldn't be too difficult to use and maintain two new Wikimedia specific messages for these particular durations?

This is quite annoying and confusing indeed, in particular the welcome bots spam that follows. I probably would have thought twice before enabling this tool/keeping it active, had there been some sort of warning about this side effect.

They say that they repooled codfw, but Grafana reports several weeks sync lag for it. If I get it right, as per last patches referenced in T381565, they are about to reenable OSM replication for codfw servers. I guess ideally particular servers should catch up before their data is served to end users?

Thanks. So I'm closing this one as given example is no longer an issue, and the underlying data import problem is already tracked in a separate task.

This makes me wonder. Since March the foundation requirement is enforced by other means, it is no longer technically possible to use IA rights without having 2FA enabled (T150898#10689383). So didn't the motivation to grant given right to bureaucrats drop off with this?

There are overlapping OSM relations, 2978650 and 1059668, that reference the same QID and are not treated right during import. It seems you already reported these a few years ago: T305312.

It seems that neighbourhood and suburb currently have equal precedence:
https://github.com/kartotherian/osm-bright.tm2/blob/master/labels.mss#L210
So I guess it's sort of random which of the two gets rendered if placed close to one another.

In T388303#10809333, @mxn wrote:

superroute is not universally used within OSM because it stems from a bug in one of the editing applications. The older and more common convention is to simply nest multiple type=route relations inside another type=route relation. I suspect the geoline service would benefit from supporting such “route superrelations” in general, regardless of the type=* tag.

@ArthurTaylor, could you please check if your patches caused T390949.

In T340143#10709783, @B222 wrote:

According to the OSM answers my problem is not related, nor is the rendering of the N31 aqueduct (in the same map) as a bridge related. All these bugs may be about wrong rendering of styles however.

I'm happy to report that digits in question are rendered correctly again. Possibly it was resolved with new fonts mentioned in T384530.

Interestingly, it does seem to work for the Appalachian Trail, which is also a superroute

GRAMMAR seems to work now, probably it was resolved with ff7b937.

This leaves it a bit unclear what exactly should be supported here. A relation of relations of linear features is often a relation of either type superroute or route_master (see also T312572). It may be desirable to treat these two the same way in our import mapping. Fetching member relation geometries for other types of relations is probably less likely desirable.

There are two separate issues.

The first example in the start editing dialog seems to work now. In Finnish in particular this is because GRAMMAR was removed from message translation as a workaround. But it also works in my language (Estonian) that still uses GRAMMAR in this message.

What about "Wiki pattern" accompanying already existing "Title pattern"? I'd find it useful.

Oh, right, this is why via code search I couldn't find where exactly is old message name still used. I suppose it's no big deal then. Thanks for doing the backport anyway.

VisualEditor message editcheck-falsepositives-link was renamed here. Now red links appear for this message: https://et.wikipedia.org/wiki/Eri:Viimased_muudatused?tagfilter=editcheck-references-activated

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