Well, depending on the language, tables of conjugation or declination of words can be very long.
So we decided for especially german words to have these tables in an extra namespace called "Flexion".

I am only interested in dewiktionary and this is okay now. But when i look at
https://dumps.wikimedia.org/backup-index.html
there are two failed dumps
2025-08-26 01:18:53 wikidatawiki: Partial dump, 1 item failed
2025-08-25 18:33:50 plwiki: Partial dump, 2 items failed

I found it:
in our common.css we had rules to suppress the arrow in some external links:

In safe mode there is a blue button with white text "Überprüfen ...". It seems to be white color on white background in non safe mode.

We get the same Error-Message if we try to add a Template to an article.

Well, most people of the german wiktionary community are not interested in technical discussions. So i waited three months before i started this request.
About the single letter namespace aliases:
I once wrote a gadget for enhanced typing in the search field of the wiktionary:
https://de.wiktionary.org/wiki/MediaWiki:Gadget-SearchPrefix.js
https://de.wiktionary.org/wiki/Hilfe:SearchPrefix
You can type "h:" in the searchfield and it will automaticly expand the namespace name. It speeds up typing. But it didn't work on mobile sites because of the overlay thingy that is used there for the searchfield. It only works with vector 2010 skin.
So i thought it would be a good idea to have aliases that will work on mobile and desktop sites. I didn't know that the mentioned prefixes are in use yet.

sha1 is redundant now?

Yes, at least it was a bit tricky. Because multiple people used multiple solutions following multiple strategies in multiple years for multiple browsers.

And in my opinion this bug is also a show-stopper for the corresponding MediaWiki software release, because the software is used on several platforms out in the world. If some of the admins uses the dump functionality for what purpose ever, MediaWiki will say: "Surprise, surprise, some of your data is lost, we knew this, but we didn't tell you. Take it as a funny challenge."

There should be no next dump until this is fixed. It just makes no sense.

I think the dump generation process should be stopped. All produced files with article content should be removed from the servers. A notice should be placed on the dump download pages that the 20240520 version is a failure. It makes no sense continuing a known errornous process and it can prevent wwc (world wide confusion).

Because someone asked me, a last notice: I think now, the problem was solved before by some repair-script. But it was forgotten to mention this here. Sortkeys of dewiki, enwiktionary and frwiktionary except commons are also ß-free now.

We changed a template (CH&LI) which was present in all pages containing an ß in german wiktionary, so that all related sortkeys were updated.

Yes, it is ok.

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