In T406749#11256668, @ssastry wrote:

The revert is now deployed and I verified that all the above pages are fixed. Resolving now.

On nl.wiktionary, this template generates the Lint error for duplicate IDs, even though it doesn't assign HTML IDs. Could this result from using the same subheadings within the template? If so, why should this be an error? HTML does not preclude using the same header several times.

I did some research and discovered that the issue somehow has been solved for the Wiktionaries created in 2022 (up to Igbo, mentioned above). But in order for "agba" to show up in the list on the French page, I first had to perform a zero-edit on the page in Igbo.

To add some context to the preceding remark: Tyap and Dutch Wiktionary (Swánga̱lyiatwuki and WikiWoordenboek) are starting a cooperation project. But pages on Swánga̱lyiatwuki are somehow not accepted in the Cognate database. When we added a̱sa̱khwot on WikiWoordenboek, we got interwiki links to 4 other Wiktionaries, but not Swánga̱lyiatwuki, even though this is a Tyap word! Readers of Swánga̱lyiatwuki can see the pages with the same name on older Wiktionaries, but their contributions are simply ignored.

I would like to support Aram's request. If we are serious about being a movement open to newcomers and the underprivileged, how come we are unable to provide a basic functionality like interwiki links to new Wiktionaries? I feel that ending this type of digital apartheid should be a much higher priority.

In November nl.wiktionary had 8 million pageviews from Singapore, which were not considered "spiders" or "bots". Something similar appears in the statistics of other Wiktionaries. The subdivision by user agent on Wiktionaries has now become disinformation, which is the opposite of what our movement is aiming for. If rapid improvement is impossible, this subdivision needs to be discontinued.

To me, it seems difficult to combine 188 separate datasets myself: they will contain lots of duplicates, because a large part of the smaller wiktionaries will share the same missing entries. Would it be possible to combine proposal 1 with a comprehensive CSV that contains all entries that are part of at least one of the 188 CSVs in the first column and the total of Wiktionaries that have it in the second column? Because of the duplicates I expect the number of rows in this file to be significantly lower than 188,000.

I am a simple editor who volunteered to give feedback on the original Wiktionary Cognate Dashboard. We used it on Dutch Wiktionary as a means to help editors prioritizing new lemmas to add. As soon as I discovered it didn't work anymore, I have asked for a remedy 18 months ago. Is there someone who understands that it's really dispiriting to see the status changed from Open to Stalled, without a comprehensible explanation and no indication of the expected moment a solution will be implemented?

I already made a fix for the template "huidigbestand" itself. But to enable you to check the behavior of PAGESINCATEGORY I posted a simple test on the talkpage of -en.

As suffixes and interfixes typically start with a hyphen, this bug is visibly breaking a template nl.wiktionary has used for over a decade on hundreds of pages. As far as I can see, this is caused by the magic word PAGESINCATEGORY not recognizing - as a hyphen when used as part of a category name. This change wasn't properly prepared and ought to be reverted for now.

I noticed that the increase in Pageviews is not accompanied by a similar increase in Unique Devices. For online dictionaries, Pageviews per visit (~unique device) are typically between 2 and 3. I don't know if we could somehow filter out very large (e.g. >100) numbers of pageviews from a single device.

I noticed a similar pattern starting Jan 9th on at least 6 other wiktionaries: fr el de sv ca it.

I reported the problems with the Cognate dashboard over six months ago. It would be greatly appreciated if it made the "selection".

@ItamarWMDE Is it possible to be a little more specific about the intended timeframe? It would be useful to know when the new data analyst will begin and when s/he is expected to give an assessment of the time needed to restore the Cognate dashboard.

I would like to use the dashboard. Is there already a URL I could use?

@GoranSMilovanovic on October 31st you stated: I will see to take a look at it ASAP. On December 16th you suggested that a solution might have something to do with "ShinyProxy". Unfortunately there seems to be no one else around who is able to do something about it. Now other problems are added, which may or may not be related. Could you please find time to look at these problems soon, or find someone else who is able to do so?

@GoranSMilovanovic Is there a prognosis when this bug will be solved?

@Ladsgroup, this has been a minor nuisance for several years. Thanks for resolving it.

Dutch Wiktionary uses inline media captions on tens of thousands of pages in a similar way as described by @stjn above. The captions were intentionally added to improve usability. Starting a process where the easy way to get rid of an error message is simply removing this information, seems counterproductive to me.

I agree with the preceding remarks by Jonesey95.

@MusikAnimal Happy to inform you that the bot today made its first edit. Everything worked as expected, and I could simply replace the picture before it probably will get removed.

Thx! In my experience the (proposed) removals on commons of pictures used on WikiWoordenboek are about 20 per year in an unpredictable pattern. In fact, that is a major reason why this bot would be really useful for us. I will let you know if I spot any removal that the bot misses in the future.

@MusikAnimal : It is now nearly two months since you moved this task to "Needs Review/Feedback". Nothing seems to happen. What's wrong?

It is great to see that the final suggestion to update the instruction on the project page has had the desired result. I'm also grateful to @Aklapper for removing an inapplicable label. Which leaves us with the main question. We have tried to follow all instructions in good faith, is there still something we did wrong? Should I have pinged @MaxSem directly too?

@Jdlrobson Thanks for youruseful remarks. I was aware the the most important change is in MediaWiki:Mainpage, but I do expect that there might be a lot of bookmarks pointing to the present location. I wanted to be sure that the existence of a redirect won't mess things up.

@Jdlrobson : At nl.wiktionary a discussion at our Village Pump has resulted in this proposal for a new design. As far as I can see the user experience on mobile and normal site would become identical, except for the chrome and the font. As my experience in this field is limited, I would appreciate if you could check this design for major flaws.

Is this the cause for Recent Changes on nl.wiktionary showing just the message "Internal Error" (Interne fout)? This is blocking the patroling against spam and vandals, so it is an urgent problem.

I hadn't noticed that the default presentation has suddenly been changed from User to "User+Spider".

@GoranSMilovanovic, thanks for your replies. I now have a better understanding of the hub-tabs. After some pondering I feel the most useful parameter would be: the number of links divided by the total number of links for the target wiktionary. In connection with this approach, it would be better not to add a percentage of the total number of pages for the target wiktionary but present the percentage of the total number of links instead. So I amend my original suggestion made Jul 9, 11:03 PM. This would make the different presentations more consistent with one another. The amount of pages without any wikilinks has often to do with specific choices made by a wiktionary, like putting flected forms or different spelling or script on separate pages or not. These choices are not very relevant for interwikilinks and when comparing numbers of interwikilinks I expect more meaningful results when we ignore them.

Finally the Links Dataset. I understand why the lines are duplicated. Unfortunately the search function operates on all columns, making it difficult to create useful lists.

1. Assuming that the search-function is able to discern interpunction symbols, would it be possible to add a colon to all the language codes in the first column and a period to the codes in the second column (e.g. en: and en.)? It would still be possible to search on the present two or three letter codes, but by adding the colon or the period you could select "clean" lists.
2. To expand on this proposal: some of the two letter codes are part of the three letter codes. So it is impossible to select 'an' without selecting 'ang' en 'zh_min_nan' too. Using a semicolon and comma for codes having over two letters would create the possibility to select an: without selecting 'zh_min_nan;'

The "Hub tabs" are a little overcrowded. I suspect that most of the lines all are connected to the same top or bottom wiktionaries by size. Maybe it would be more informative if we could adjust for the size of the wiktionaries involved. What I forgot in my earlier remarks: wiktionaries are not just different in size, but they may also differ in the number of pages without any wikilink. On the other hand: although it is nice to know, I don't see a real practical use for this type of information anyway. Maybe we should just enjoy the pictures.

The My Wiktionary tab is interesting. Presently it only shows the absolute number of links. To me it would be useful if this was also expressed as a percentage of the number of "Good pages" in [http://wikistats.wmflabs.org/display.php?t=wt this table]: sometimes a high number is mainly the result of the target wiktionary having many pages, sometimes it really has to do with a strong overlap between projects, which would be indicated by differences in the percentages.

@GoranSMilovanovic I was referring to the additional request by Pamputt. It could be realised as a kind of filter on the results of "I miss you" showing only links to pages that contain a word in the language of the selected wiktionary. But I don't know whether this information is accessible in the Cognate database, because the interwikilinks only need the page title, not the page content.

@GoranSMilovanovic Thanks a lot! The "I miss you"-page is what I hoped for. Would it be possible to give the dashboard a format that could be transcluded in a Wiktionary page?

Thx, I'm starting to understand now.

There was another update, showing 1 stripped tag en 0 for both the misnested and obsolete tags. Only the Missing end tag remains stubbornly at 11, while the subpage is showing the correct number, 8.

The main page Special:LintErrors on Dutch Wiktionary has been updated this morning, showing as a new find an old page with both a misnested tag and an obsolete tag, which of course have been corrected by now. What puzzles me is that the counter for "Missing end tag" was and is at 11 pages, with the corresponding subpage only showing the 8 pages that have become our baseline. If it had been 10 I would consider it the result of rounding, but how do we get to 11?

For the record, looking at Special:LintErrors on Dutch Wiktionary the lag between a correction and an update presently seems to be 138 hours (nearly six days), while the subpages for particular errors are updating immediately.

Thanks for the interim solution. I have informed the WikiWoordenboek community and I will see if there is a fast way to purge all the pages involved.

At the moment editing a page on Dutch Wiktionary has the effect of removing all interwikilinks of that page. Both Cognate and the datacenter switch were presented with assurances that everything was well-prepared. The message concerning the datacenter switch mentioned that a big team was standing by to solve unexpected problems. I strongly support making this "Unbreak now!"