@Spinster, does what 0x010C proposes solve your problem?

This is how I experience this problem

In order to be clear, I attach this picture. Here I recorded "bahá’í" and "sabaot" (circled in red) but I do not know how to pronounce them. So I would like to make them "blue" again (like "afrikaans" that I skipped) and "green" like the others that are validated words. I guess at this stage the items are not yet created. So what I would like is to be able to "devalidate" these words (and so not to do it at the upload stage).

@Nuria, I guess you mix with T205769.
T205769 is about the "Top editors" view while this one (T205770) is about the "Top edited pages" view. How to unmerge both tickets?

As T188859 has been merged with this task several months ago, is there any progress on this topic? I think it would be really interesting to have this for the next Wikisats 2.

I do not have this problem anymore too. I use Mageia Linux 64-bits with Firefox 52.9.0

@GoranSMilovanovic there was indeed probably a mismatch with previous updates. Now (18:00 UTC), the ten first entries of the list are correct (present in simplewikt and not in frwikt). There is no "empty" entry anymore. Everything looks good.

@Lea_Lacroix_WMDE it seems that aaa on simplewikt is one of this page. We see clearly that it has been deleted in the past. This is not the cas for other pages, such as "aabi".

I still continue to think that these pages do not exist. I do not know where does its content come from but for sure it is not part of the page. For "aabi", for example, we can see this content here. Yet, from here, we see clearly that the page is a red link.
Moreover, we can see this text on all pages that do not exist. For example aaaa, aaaaa, ... have all the same content and do not exist on both simplewikt and frwikt. However, they are not listed by Wiktionary Cognate Dashboard whereas it is exactly the same case as "aabi". So if you are right, I expect to get a lot of pages present in simplewikt and not in frwikt. However, this is not the case.

Actually, sorry for the mismatch but I set frwikt as source and simplewikt as target. Just now, I get the following list: "aabi", "abasie", "abdicable", "abdiceerden", "abduceretur", "abdukcji", ...
From this list, only "abdicable" exists on simplewikt. All other words do not ("aabi", "abasie", "abdiceerden", "abduceretur", "abdukcji"). Meanwhile, "abasie" and "abdiceerden" exist on frwikt (although frwikt is the source). And "aabi", "abduceretur" and "abdukcji" do not exist on both simplewikt and frwikt.

@GoranSMilovanovic indeed, the update has fixed some mistakes. However, I still continue to think there is a problem with simplewikt. In the new update, the list is "abasias", "abbottonare", "abcédographie". "abasias" was good (I created the page on frwikt). But "abbottonare" does not exist on simplewikt but do exist on frwikt. The same for "abcédographie" (simplewikt and frwikt).
The fourth word: "abdicable" is good. It does exist on simplewikt and not on frwikt...

Hmmm, it seems there is a specificity for simplewikt. Indeed, if I go here, I see clearly that "대신에" do not exist (red link). The same for "Aako". I do not know why they have a behaviour compared to other Wiktionaries.

I think T166487 solves this request, isn't it?

Indeed, I am sorry. Hidden categories were not displayed because of my settings. If I enable this option, hidden categories are shown. This report can be closed.

In T150841#4245312, @Lea_Lacroix_WMDE wrote:

So if I understand correctly, there's not much we can do before the Wiktionaries agree on having a common template in their titles?

@GoranSMilovanovic @Lea_Lacroix_WMDE
Even if the current translation system "work", I think it should be improved. I think it is not possible to maintain such system over a long time. For example, what will happen when GoranSMilovanovic will not be there anymore or will not have time anymore to update translations?
In addition, I think some strings are missing (just switch to the FR language, and you will see several strings that still appear in English). This is quite difficult to find all the translatable string from the user point of view while it is easier from the developer point of view (wether we want to translate the whole interface).
A better solution, IMO, is to allow translating the interface from translatewiki. Is there any reason why not using translatewiki?
I understand that such solution require more development time but it appears to me to be a better long-term solution.
Should I open a new ticket for this request?

Another example

I created T201947 in order to follow my last request.

Wiktionary contributors might be interested to know which entries are the most popular so as to improve these pages first (add pronunciation, synonyms, etc). Since these entries exists on a large number of Wiktionaries, they might find a lot of information to add trough all the Wiktionary editions.

Is this ticket related to T195740? *I am not sure so I do not link both tickets but if you think so, please do it.

I have another request for this dashboard. Would it be possible to add a new tab (or to add within an existing tab), a list of the page that are the most linked over all the Wiktionaries? This is a kind of opposite of "I miss you". For example, we will have a list with "a" existing on 97 Wiktionaries ; "and", present on 80 Wiktionaries, etc. The list will be sorted from the entries that are the most linked to the ones less linked.

@GoranSMilovanovic thank you very much for the detailed explanations. Still few remarks

1. In the "Compare" tab, if I click on "Download (csv)" just before clicking on "Generate", I arrive on an error page saying that there is no such file. From an ergonomic point of view, I think this button should be disabled while the user has not yet click on the "Generate" button.

@GoranSMilovanovic, I tested the "new" version of the Dashboard prototype. I compared enwikt (source) and frwikt (target) and all the words that are listed point to https://fr.wiktionary.org/wiki/ (and not to https://en.wiktionary.org/wiki/xx). In addition, I still get disconnection after 2 or 3 minutes.

In T166487#4446003, @Pamputt wrote:

If I compare frwiktionary (source) and dewiktionary (target), the first link is "-". There is a problem because frwiktionary as also an entry for "-". Could you check?

In T166487#4446208, @GoranSMilovanovic wrote:

With the open (free) version of the Shiny Server we cannot change the session timeout parameter. However, I've managed to find a trick that should do. The session timeout is now extended to ridiculous ten minutes (no comparison will ever take so much time) and the problem should not resurface.

If I compare frwiktionary (source) and dewiktionary (target), the first link is "-". There is a problem because frwiktionary as also an entry for "-". Could you check?

For big Wiktionaries comparison, I do not manage to generate the list. For example if I select frwiktionary as a source and enwiktionary as a target, I systematically get a message on the bottom left saying "Disconnected from the server. Reload". Sometime I get a popup message withe following message (during the "Compring Wiktionaries" step):

Comparing frwiktionary and cawiktionary, I get as first result the word "??". This article exists on cawiktionary but the link given by Compare redirects on the main page of cawiktionary. Could you have a look on what is going wrong?

@GoranSMilovanovic I tried to test the Compare tab with frwiktionary as a source with some troubles. For example, with frwiktionary as source and aawiktionary as target, I get the following error message:

In T166487#4434060, @GoranSMilovanovic wrote:

@Lea_Lacroix_WMDE They have to contact me. Even better, when I complete the Dashboard documentation, they can suggest the translations for the interface there.

In T166487#4432182, @GoranSMilovanovic wrote:

@Pamputt

would it be possible to list all the articles in a given language that exist on another Wiktionary edition but not in the edition of this language.

If you mean a list of entries not present in some particular Wiktionaries, that is already found on the My Wiktionary tab. If you mean the possibility to show what entries are present in, say, Russian Wiktionary, but not available in French, and so for all language pairs: that is not possible at the moment. Theoretically we can do it, however, the implementation of that feature would call for a much more resourceful Dashboard back-end, and we must be savvy in that respect.

Let me explain with some examples
Let us say that I am interested in by the French Wiktionary. What I would like to know is all the French entries that are in the Russian Wiktionary and not yet present in the French Wiktionary. So for example is AAA is a French word but there is not yet any article on the French Wiktionary for this word, I would like to have a list of the other Wiktionaries that have this word in French (I want to know for the French in particular) So if AAA is present in the Russian Wiktionary for describing a word in German, I do not want to have this word in my list.
So basically, from My Wiktioanry tab, if I cnsider the pair frwikt and ruwikt, I would like to have the list of all the articles that have already an article on ruwikt, but not yet on the fr.wikt (currently the My Wiktionary only gives me a number, not a list of all these articles). And once I have the list, I would like to be able to filter to have only the French articles from ruwikt that do not have an article on frwikt.
So what I would like is probably closer "I miss you" than "My Wiktionary".
In "I miss you", it would mean to add a filter to select only the pages from ruwikt that have an entry in French (and so hide all the articles that are not described in French).
I hope it is clearer now, otherwise, ask me more details.

It works. Thanks for your help and sorry for the noise... This is now solved.

@Bawolff @bd808 indeed, the links you provide are what I was looking for. Sorry I couldn't find this on my own. I will try to remove my old ssh key and add a new one later today. I will keep you in touch.

No news about this issue since 2 weeks. Does anyone tell me whether my request is done at the right place?

@GoranSMilovanovic one comment about "I miss you". Would it be possible to remove the "Main_Page" and "main_Page" from the page title? They are present in most of the Wiktionary editions: fiwiktionary, frwiktionary, gnwiktionary and so on.

@GoranSMilovanovic very nice work.
In addition to Lea's request, would it be possible to list all the articles in a given language that exist on another Wiktionary edition but not in the edition of this language. For example, I would be nice to have a list of all French words that exist in a Wiktionary editions, but not in the French Wiktionary.

The upstream ticket says that it is fixed for more than one year (at least since Firefox 51).
I use Firefox 60.0.2 and this issue is still present.

In T195740#4248752, @VIGNERON wrote:

Indeed, property is a good idea but how would you deal with Alptraum / Albtraum?

I would say Alptraum and Albtraum should be two Lexemes, not only one. And Form in Alptraum could be "Alptraums", "Alpträume", "Alpträumen" and so on. And the same for "Albtraum" with "Albtraums", "Albträume", "Albträumen" and so on.

In T195740#4237172, @VIGNERON wrote:

Tough questions.

Caveat: I'm not an expert (feel free to correct me), but I cam across several languages issues in my decade and half as Wikimedian.

My point of view is that the current system for the monolingual text is good but not enough for the lexemes needs. One (anecdotal) example, the 'fro' and 'frm' codes have been approved (in a week T181823, sometimes it can takes months), and they have added month ago but still not fully integrate (you need to enter the code itself, it's not possible to just add the name of the language). For items, I understand the caution and we can wait to be sure, but for lexemes this seem to slow to me.

I like the idea of « list of item that have instance of/subclass of language » but that's not enough as it didn't take into account the script.

In the end, I think the we need to go closer to the IETF BCP 47 system of tag (a world-wide standard, already used by a lot of online dictionaries and well documented, see BCP 47 text). We need several lists : one for language (ISO 639-1), one for territories (ISO 3166), one for script (ISO 15924, here the list is quite short) and maybe others subtags (dialects, variants and private uses). This is important for precisely reflect the lemmas, like French before or after the 1990 reform, German before/after the 1996 reform ; de-CH-1996 is gave as an example in the BCP 47 itself.

More importantly we need the ability to combine these lists like in the BCP 47.

Some example of why we need more flexibility and granularity:

• the Kazakh language, was written in Arab, then in Latn, then in Cyrl and now they are going back to Latn... 4 (or 5) scripts is probably a record but it's not unusual for a language to have at least two scripts (I'm thinking of Serbian sr-Latn and sr-Cyrl, or Chinese: zh-Hant and zh-Hans).
• one more extrem example: the Bornholm amulet has an inscription in Latin but written in runes. So if we want to model it correctly, we need the code "la-Runr". Runic latin is not common and have limited corpus but still, a wikidatian could want to work on that, and just add this word and move on (to an other strange epigraphy, like 4th century prototurkish written in Chinese characters).
  
  My view is more a technical one (a code is valid in his format), for the social and validation part (a code is valid regarding the content encoded), I'm not sure how to best handle it (should we let entirely to the community? and can it be articulate with the LangCom?)
  
  PS: anyhow, attention should be paid to the capitalization (ISO 639 is full lowercase, ISO 3166 is full uppercase and ISO 15924 has only the first letter in uppercase (the same letters can exists in different codes 'ca' for Catalan and 'CA' for Canada).

As explained in my prevuious message, I agree we need to specify at least language and script. For the rest (country, orthography reform, ...), I think the best way to store this kind of information is to use property in the lexeme itself. The advantages of the property is it is really flexible and so we can decide a psoteriori what kind of information we want to store in one lexeme.

I strongly support the Micru's proposal. Using item to identify language, dialect or whatever is plenty of advantages:

• it is really flexible. It is possible to use dialect, sub-dialect, language, proto-language, and so on
• it is clearly identified. One item identify uniquely only one language. Several codes may be used to identify the same language.
• it is already available and it will be maintained by the Wikidata community
• it avoids conflicts on the language that are included. For example: it already exists items for Serbian, Croatian, Montenegrin and Bosnian languages. They are considered by some linguists as only one language. Since some people would like to contribute in only one of these "languages", using items allow that directly. If we use code, how do we manage such case?

@Milimetric oh! Thanks for the explanation. I did not pay attention to this number underneath the graph. Indeed, this is the number I was looking for. So it is enough to me.

Hmm, actually I misunderstood. I was thinking it displays the total of the whole displayed value. For example in your screenshot, it means the sum of the views for the months of April, May, June, ... until February 2018. Is it possible to add this number?

Total views on a given period is basically the same information so I think it is enough for my purpose; I asked this request because I usually use this kind of statistics to know how many pages are viewed each day (or each month) in mean.

Note that @0x010C got a grant from WMF to develop Lingua Libre. This task is planned to be achieved in 2018.

Is there any update on this request?

Is this request still valid since there is now the Cognate extension which manage interwiki links