Waiting that this feature be implemented, it is already possible to "delete" a pronunciation during the "Recording" step. To do so, you can simply press the "Del" button, so that the pronunciation is deleted and you can re-record it directly.
That's said, I agree that this shortcut should be documented somewhere.

Hmmm, it is weird, I am not able to reproduce anymore. I was using Firefox ESR 60.0.8. The page was stable (I could scroll and see this effect) but when I reloaded the page, the bug dissapeared. So maybe it was a cache issue or something similar.

Oops, sorry for the noise. Thank you very much for the investigation of our problem. We will fix it on our wiki.

Just to be clear, we have two link: "Edit" and "Edit source". Clicking on "Edit" or "Edit source" beside a section always opens the Visual Editor (I expect that clicking on "Edit source" opens the wikicode editor). However, if one clicks on "Edit" in the tab on the top of the page, it will open the Visual Editor (as expected) and clicking on "Edit source" will open the wikicode editor (as expected).

In T212843#4912902, @deryckchan wrote:

This will address migration blocks like https://www.wikidata.org/wiki/Wikidata:Properties_for_deletion#Property:P2521, where the lack of a feature to call Lexemes in Wikipedias is blocking the migration of a property.

For the French Wiktionary, I do not know what will decide the community but if we decide one day to use the Lexeme data from Wikidata, it will be the most probably for the Forms (conjugation, inflection, declension, etc). I think we will never use the Senses. So what Mike Peel proposed just before makes sense for a full flexibility.

Indeed for the second point, it is indicated on P443 (Constrain section) that the lexeme has to be excluded (it makes sense). So Lingua Libre Bot should not add P407. That's said, it is not clear why the exclamation mark appears in Strom.

Not sure it should be marked as resolved because I do not see any new taks titled "[EPIC] Find best strategy for Visual Edidor Wiktionary configuration" or similar. This task should be opened first and linked to this task before closing this one.

For now, I have replaced "fr:Gwendoline Daudet" by "fr:Gwendoline_Daudet" and the link is now ok. But the problem remains.

There is some improvements on this. I do not see any issue anymore. Is it fixed?

With another property (P6614), I experienced a similar issue yesterday

Actually I just tried using Firefox 66.0 on Mageia Linux 64-bits and it worked. So it seems the problem occur sometimes, probably on some webbrowsers.

Indeed, the color is now there. Thanks

Not sure this issue is resolved. I still do not see the icon in red and blue (they remain grey).

In T217883#5011550, @Krenair wrote:

In T217883#5011518, @Aklapper wrote:

In T217883#5011452, @Pamputt wrote:

It means for everyone except logged-in user that have changed the skin in their preference.

@Pamputt: What does "changed the skin in their preference" mean exactly? Do you propose to overwrite the skin setting of every account that has set "Vector" as their skin on https://fr.wiktionary.org/wiki/Spécial:Préférences#mw-prefsection-rendering ? Wouldn't that mean that a lot of people would log in and suddenly see a completely different user interface without knowing why and not necessarily knowing how to revert (if they wanted), even those people who intentionally chose to prefer Vector over other skins? (Note that the Preferences unfortunately does not offer a "Use default skin" setting; you explicitly have to choose a skin...)

Pretty sure they're saying that everyone who hasn't selected a particular skin in preferences already would now get timeless, just they'd be able to change by going to preferences.

In T217883#5010779, @Aklapper wrote:

What does "default" mean? Logged-in users? Anonymous users? New logged-in users?

Another example in the Preferences menu, the banne "Lingua Libre is in open beta. Be aware that bugs can still occur. Please share your feedback here !" appears in English while all the rest of the interface is in French (in my case).

@Spinster, does what 0x010C proposes solve your problem? Can we close this task?

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?