I just saw T171310. This is a duplicate.

Note that this will cause breakage on elwiki once the translation makes it there. It would be nice if someone fixed it before that happens. We should probably just revert my translation change somehow.

@jhsoby There are some sites that use U+00B7 (MIDDLE DOT) to substitute U+0387 because of the normalization but to me it just looks wrong. The middle dot is too low. So the ideal fix would be to allow us to use U+0387. If you don't want to then U+00B7 will have to do but it's not ideal.

Since   loads correctly, I attempted to work around the issue by changing · to the equivalent ·. We'll know if that worked in a week I guess.

Note also that https://translatewiki.net/w/i.php?title=MediaWiki:Semicolon-separator/el looks correct.

· is supposed to be U+0387 (GREEK ANO TELEIA). See also https://en.wikipedia.org/wiki/Talk:Semicolon#Middle_dot_and_ano_teleia for why I think U+00B7 cannot be used.

No, that's not always expected. On the English Wikipedia, [[Wikipedia:Articles for deletion]] is supposed to link to https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion which is the same as https://en.wikipedia.org/wiki/Project:Articles_for_deletion, not to mainspace as "Wikipedia" is the name of the project namespace. On meta, it's supposed to link to https://en.wikipedia.org/wiki/Articles_for_deletion in mainspace as "Wikipedia" is the interwiki prefix for the English Wikipedia. Both of these are expected and correct. Therefore, when the link [[Wikipedia:Articles for deletion]] shows up in Special:GlobalContributions, its destination should depend on where the edit was made. If the edit was made on the English Wikipedia then it should lead to Project:Articles for deletion. If it was made on meta it should lead to Articles for deletion on the English Wikipedia.

In T398108#10995931, @STran wrote:

I think this is a separate issue and may be expected behavior? I'm not immediately aware of how you'd declare to the parser that you want <wikiId>: to be interpreted as that and not as part of a page title but it sounds like it should be discussed independent of this task.

In T398108#10992895, @STran wrote:

Triaging this to the nice to have column for now as that's where we've prioritized the other namespace problems although we were able to do a good-enough fix for the other issue while waiting to see if we can do something more robust.

In T398108#10992895, @STran wrote:

Would it be preferable if there was no link formatting at all and instead just plain text, @Warudo? It might be a possible solution for now, assuming comments don't tend to link out. It might be a possible solution for now, assuming comments don't tend to link out.

Apparently this has been added to the Android app since the last time I checked here. However, the implementation appears to be buggy since the link to top is added to the edit summary even if other parts of the article have been edited. For example https://en.wikipedia.org/wiki/Special:Diff/1295508800 is an edit in the Excitebike article that has top in the summary even though both the lead and the "Gameplay" section were edited.

It's a custom namespace on the English Wikipedia, yes. I think that makes "Allow customizing who can move pages in a custom namespace" an accurate description of my feature request.

A problem my suggestion has in its current state is that MediaWiki:Scribunto-doc-page-header also appears in doc pages that don't exist. My proposal as suggested would add every possible title to the category, which would be pretty bad. For this reason I propose that the categorisation kicks in only when the page exists.

Stjn is right. The issue only affects the 2017 wikitext editor.

Ideally, this would apply to soft redirects as well, but that sounds difficult from a technical standpoint.

This issue is more general than just categories. It also makes it impossible to find all the templates that transclude a particular template as is discussed here. This is an issue that can potentially affect all XfD venues since it apples to every link that is between includeonly tags. An example of this is Template:Deleted template, currently at TfD, where WLH missed two of its uses that were between includeonly.

This also applies to desktop since someone might change the URL by hand to point to the lead as suggested in an English WP help page.

I checked a few more. The Japanese, Korean and Farsi WPs all have the gadget too. I stopped checking after that.

"Τορ" would be pronounced "Tor" in Greek. Just because the letters look similar does not mean they perform the same function. In any case that's irrelevant. I used Greek as an example because it's my native language. The Chinese WP also has the Gadget and no such argument can be made for their writing system. If you're still concerned, how about you ask those editors themselves. I think that their inclusion of the gadget in their WPs shows that your concerns are overblown.

The html does not say id="top" anywhere so #top is ignored.

Isn't even in the current default skin

This is false, I tested Vector2022 while logged out and the anchor is there. (EDIT: To add to this, I tested the example you provided as well and it scrolled up, so your own example debunks what you said)

Yes, I think that's mostly right. The gadget is completely irrelevant to this issue as it's not what's creating the edit button on mobile (afaict it has no effect on the mobile layout AT ALL). I only brought it up as an example of the correct behavior. Note that what you're describing also happens on desktop when you click on any other edit section link. The gadget is only emulating desktop's normal behavior.

However, this all seems to be something that your gadget is handling, not part of mobile.

In T362467#9711511, @Xaosflux wrote:

There is no actual section on the page called "top" - and no one else would be able to follow it using that link. However, this all seems to be something that your gadget is handling, not part of mobile. Have you checked with the gadget maintainers?

I've already specified above I'm referring to Mobile Web (EDIT:I did not actually, but I thought I did. I'm sorry about that) So, as you can see in this edit when editing a section, a link to that section is added to the beginning of the edit summary. However, when I edited the lead by using its dedicated button, no such link was added. Instead, no section was added at all as if I was using the "Edit full page" button (like I did here). Here's an example of an edit to the lead section on desktop (done with the gadget I mentioned above). As you can see, a section link to the "top" section is added, which when clicked takes you to the top of the page, aka the lead section.

The same thing also happens in the Windows version of Firefox (I tested 67.0.4) when using the mobile wikitext editor. Once again, Chrome is unaffected.

I don't remember the original description.