Of course, there are visible effects. Without them we haven't noticed this change in sortkey generation.

Here is a possible way to reproduce this on Windows and in Firefox:

There are not only gadgets that hide something on the page. There are also gadgets that add something to the page content. In english and german wiktionary there is the "translation adder" which adds some input fields to make editing of the translation tables easier for editors. This adding of something results in the same effect, that '#'-links don't work correct. But normally the gadgets of a site don't know about each other. And it is good for design purposes that they don't have to. But as a consequence of your advice every gadget, that adds or removes something on the page would have to do an adjustment of the hash fragment. Because the gadgets don't know which one is the last of them to execute, it cannot be done by a single 'extra'-gadget which would run as the last one on the page. I haven't tested it yet, but it could result in a multiple scrolling up and down of the page until the last gadget has ended and viewers - especially those using a slow device - would wonder what is happening.
Couldn't this hash adjustment be done in the wiki-core or vector-2022 code once after all user generated code has run.

In german wiktionary the code is in https://de.wiktionary.org/wiki/MediaWiki:Common.js
It starts at "// Ausklappbare Navigationsleisten"
It ends at " $(document).ready(closedNavBar);"

There is a third scenario when this happens. Suggest you use copy and paste by mouse. Select a word anywhere and use the right mouse button to copy it. Then select the search input field with your left mouse button then click the right mouse button to open your browsers context menu to paste the copied word in the input field. Now, depending on your browsers context menu (depending on where the ''paste'' entry is), the mouse cursor is somewhere below the input field. If you type in some more characters or simply ''enter'' the item under the mouse cursor is selected.

Same here on de.wiktionary.org. It has something to do with 1.39.0-wmf.17 because de.wikipedia.org which still has 1.39.0-wmf.16 looks normal.

This is not a duplicate of T303113. It is the opposite. In short this report means: Do not add a link to "Multilingual Wikisource" on every wiki.

So will the column cl_sortkey of the database table categorylinks ever be fixed or not?

@ifried You are using the JavaScript version of recent changes. I said the symbol is not shown if you select "Use non-JavaScript interface" in your preferences. I am using Firefox 86.0 (64-Bit) on Windows 10. I wonder why this is implemented using this oo-ui-something and not just the Unicode Character 231A (⌚ watch) which should work out of the box.

Works. Thanks.

I noticed this the first time on my Android Tablet. It happend as soon as i opened the page. Because it is Android, i cannot change the size of the window.

Some time ago i blocked cookies for some testing purposes. Then i forgot to enable cookies again. Doing that now login works fine. Sorry for that.

For me google only shows one result in the mentioned link above. And this is the discussion about this problem https://de.wiktionary.org/wiki/Wiktionary:Fragen_zum_Wiktionary/Archiv/2020 not the link to the article, which would be https://de.wiktionary.org/wiki/Darweisung. The article was created on 7. Jan. 2020 and google still doesn't show a link to it, but shows a link to a discussion about this phenomenon which was started several months later on 23. May 2020.

See also this discussion in german wiktionary:
https://de.wiktionary.org/wiki/Wiktionary:Fragen_zum_Wiktionary#Nicht_von_Google_indiziert
The article "Darweisung" is created six months ago.
https://de.wiktionary.org/w/index.php?title=Darweisung&action=history
But Google founds nothing
https://www.google.com/search?q=%22Darweisung%22+site%3Awiktionary.org

I found two other characters which are effected by this conversion to uppercase. So far we have:

Char  Unicode Character
'ɐ'   LATIN SMALL LETTER TURNED A (U+0250)
'ɡ'   LATIN SMALL LETTER SCRIPT G (U+0261) not to be confused with ASCII 'g' 'LATIN SMALL LETTER G (U+0067)'
'ɪ'   LATIN LETTER SMALL CAPITAL I (U+026A)

These characters are mostly used in IPA-Notations and the effect came into german wiktionary between 2019-09-07T20:02:48 and 2019-09-09T18:10:14 (database timestamp)

For the Month May it works. BTW: I don't know how it works, but shouldn't the link you posted look like
2019-05-1~2019-05-31 instead of 2019-06-01 ?

Its in Special:GlobalPreferences. And i have no global preferences selected, so they are greyed.
Goto preferences. Select tab "User profile". In "Basic information" there is a line "Global preferences:" and a button "Set your global preferences". Press this button and "Global Preferences" will be opened. There in tab "Appearance" the jumping items can be found.

The reason why i didn't see the difference was a configured brightness level on my graphic card which was too high. So all gray levels between about 92% gray and 100% white appeared as 100 % white for me :)

I just tested this on an android tablet-pc and there i can see the gray background. So i used a color picker on my desktop-pc to investigate this on my uploaded screenshot. The color picker shows me different numeric values for foreground and background colors, but i can see no difference between these colors. So this seems to be a hardware problem of either my graphic-card or my monitor.

I don't think the search field has to be cleared. The filled search field was normal behaviour in prior software versions. Only the search suggestions should not be shown.

Thank you. There seems to be some archaic code in Common.js.

Another strange behaviour in https://de.wiktionary.org/wiki/Spezial:Suche is, that the cursor is blinking in the big input field in the middle, but input appears in the field on the upper right.

It still happens when i use the general search field, enter something, select one of the suggestions, goto the page, then select the browsers back button et voila the suggestion window opens again. Firefox 60.7.0esr (32-Bit)

I followed the link https://stats.wikimedia.org/v2/#/de.wiktionary.org
I got the "Monthly overview".
I selected "Active Editors".
I got the "Active editors" stats.
The time period here is "Apr 2017" to "Apr 2019" / Monthly
I select Metrics / "Top Editors".
Here the time period is displayed as "Apr 2019"
The edit count is 3739 Formatierer (where does this value come from?).
I tried to select a period but i can only select a single month.
So i selected "May 2019". Then i got the values of the table you cited.
The edit count is 342 Formatierer.
Then i changed the month back to "Apr 2019" and got the values of
my screenshot above.
The edit count is 1921 Formatierer.

Well, it seems to be more complicated and confusing than i thought.

If there is still not clear what to do, we want the apple-touch-icon.png, which is used on mobile devices, look the same as favicon.ico, which is used on desktop devices.

It is a normal file in Windows 7 64bit NTFS filesystem. But i used a trick to avoid bzip2 having to open the file. If bzip2 reads from stdin it works.

bzip2 -d < dewiki-20181101-pages-articles.xml.bz2 > out.xml

I made a test using bzip2 (the 64-bit version) for windows. It seems that it cannot handle files > 4GB.

bzip2 -dk "dewiki-20181101-pages-articles.xml.bz2"
bzip2: Input file dewiki-20181101-pages-articles.xml.bz2 is not a normal file.

What about this to avoid further user confusion:

1. Change file extension from .bz2 to .lbzip2 for the files where lbzip2 is used.
2. Add a notice on the download page that some decompressors have problems with these files.

Would be nice, if someone can tell us, which tool wikipedia is using to compress files and if something was changed in the generation of dumps between 20181001 and 20181020. And yes, 7zip in Windows has problems to uncompress some files. Bzip2 in linux has no problems. But i haven't testet ALL dumps and i never had problems to uncompress dewiktionary-YYYYMMDD-pages-articles.xml.bz2 with 7zip in windows. So it seems, that size matters.

I had the same problems starting with https://dumps.wikimedia.org/dewiki/20181020/dewiki-20181020-pages-articles.xml.bz2 So i asked developer of 7zip about this. He states bzip2 decompressor has a bug and lbzip2 compressor uses this. So he suggests not to use lbzip2 for compression. I do not know which tool wikipedia is using for compression, but it might be related. See discussion: https://sourceforge.net/p/sevenzip/bugs/2163/

So its easy to fix. Just move the classic edit toolbar back to core again.

Works for me :)

I tried
var cp = mw.util.addPortletLink("p-views", "", "Check", "ca-checkpage", ...
and
var cp = mw.util.addPortletLink("p-views", window.location.href, "Check", "ca-checkpage", ...
In the first case the main page is loaded, in the last case the current page is reloaded, but the intended function call is not executed, when clicking the button.

The gadget has to be activated in Einstellungen/Helferlein CheckPage. Then in every entry in namespace 0 an extra menu entry "Check" will appear. Clicking on it causes the de.wiktionary.org/wiki/null page to load.

I described it wrong. The favicon does not depend on the site you are looking at, but it depends on the operating system the browser you are looking from is installed. So if you are using a browser (say Firefox) on a mobile operating system (say Android) you will get an other favicon (named "Variante 1" in my link) than you will get in a browser (say Firefox) on a desktop operating system (say Windows) (Variante 2 in my link) What we want is, that all browsers on all operating systems get the same favicon (Variante 2). And to make it clear: There should also be no difference of the favicon when you are looking at the de.m.wiktionary.org or the de.wiktionary.org version of a page regardless which browser (operating system) you are using.

Expect the unexpected.

Oh, sorry for mixing that up. Knowing it, i can deal with it. Task can be closed.

Here it happend after or during insert of a new entry: https://de.wiktionary.org/w/index.php?title=Aufnahmef%C3%A4higkeit&action=history

This seems to be a general problem for all wikis. None of the links on the pages dumps.wikimedia.org/*/20171220/ can be found.

Same here in german wiktionary. See discussion: https://de.wiktionary.org/wiki/Wiktionary:Teestube#Pingen_scheint_.28wieder_einmal.29_nicht_zu_funktionieren
After changing my preferences it works for me, but nevertheless, there should be a general solution for all users, without the need for changing their preferences themself.

Seems like every edit adds another references tag: https://de.wiktionary.org/w/index.php?title=Fallstudie&diff=next&oldid=6189861

Your comment doesn't help. What should i have not done? Using the visual editor? Removing the "{" character? Or what else?

I can wait. Following code will do it and let the garbage collector free the memory automatically.

Ok, challenge accepted. I think the inefficency comes from the table.remove function. The longer the array is, more elements have to be shifted to the front of the array after removing the first element. As you said returning a single codepoint on every call without constructing the table would do the job. But you can also use a counter for returning the single elements from the array and free the memory of the array in a last step. Something like this.

In MediaWiki 1.29.0-wmf.7 this now works for strings longer than 8000 Codepoints, but the implementation still seems to be a bit inefficient, because now a string longer than about 30000 - 35000 codepoints causes an error due to cpu time limitations.

You are right. Thank you for pointing that out. At least i think i understood what preprocess really is doing. In this case, i have to change about 500 language templates according to your advice to get my module working as intended. These templates are very simple, so the change is easy, but time consuming. BUT if the templates i want to process are getting more complex, i have to - eventually recursively - splatter these <includeonly>safesubst:</includeonly> directions around, making the templates more unreadable.
Nevertheless it would be nice to have a function like the above mentioned frame:expand() that would do all that implicitly for me (and perhaps other developers).

Not really. What i do need is a version of frame:preprocess where i can control the mode of operation independent from the invocation mode of the module itself. Say a new function frame:expand, which will do that.