In the discussion part of the last link (French WP Village Pump) https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Le_Bistro/8_mai_2017#Discussion, it seems 3 users oppose it in the § starting "J'ai du mal" due to how it would interact with the existing practice using http://archive.wikiwix.com, though the clear majority is in favour.

Mentioned as a bug on the French WP VIllage Pump, the answer is that the bug is known since 2013.

Yes, the title was set by Whatamidoing (WMF), and the request is to do for frwiki here like for test wikis and MW.org.

I tried on the same (old) computer and I cannot reproduce this bug: now the previous screenshot looks like on this new screenshot, with the [?] tooltip on the right of the box and not over the "+" (add qualifier) or the "trash can" (remove). So I am not sure for all configurations, but for mine it seems the problem is solved, though I wonder how it happened and what has changed.

There are already partially functional gadgets on the French and the Russian Wikipedias.

I proposed this task for the 2016 Community Wishlist Survey, do not hesitate to improve and develop the formulation there.

I proposed this task for the 2016 Community Wishlist Survey, do not hesitate to improve and develop the formulation there.

See T124168.

@daniel Yes, that would be satisfying for Wikipedia users, but maybe not for Wikidata users who would like to have some way to enter a label in the user interface with the proper typography (French I^er, Spanish 3.^er etc.) and see it displayed in the title of the item and as a property value in other items.
As a comparison for English-language users, this is as if for some technical reason they could not use in Wikidata labels a character which is used in English typography but is not really pronounced, for instance the quote character ("): labels would still be quite readable, but users would like to get this fixed.

Another use case, several times discussed and used on frwiki, is image legends which frequently use wikitext on Wikipedia.

@daniel Markup in statement values is a different question (it has been raised a few times on frwiki e.g.. for image labels, which frequently use wikitext). This task is about what is displayed in Wikipedia by {{#property:}} or mw.wikibase.getEntity etc., that is labels, and about a very restricted use of html as you suggested.
If a "label with wikitext" multilingual wikitext property, when its value exists, could be used by {{#property:}} etc. instead of the label value, this could do the job but it would be a strange data structure, with the displayed label info coming both from the item label and from the value of a property.

To answer the request for a collection of use cases by @daniel in T43749#475002, what I had in mind so far is French abbreviations like Napoléon I^er, and titles like 1922 <i>Encyclopædia Britannica</i>, but more uses of simple html can certainly be found by other users.

In T131013#2244534, @Dbrant wrote:

It seems like what we have here is a conflict of use cases. According to the official guidelines, the purpose of the description is to "disambiguate items with the same or similar labels," which is subtly but crucially different from our use case of "a one-line summary of the subject."

@Stigmj on frwiki we now have to fix in this way templates that may be transcluded on thousands of pages (sorry I wrote model above but meant template = modèle in French), finding all such cases will probably not be easy due to the many syntactic possibilities of templates and modules.

Same with 2.png and 3.png as noticed on huwiki's Technical Village pump.

This change was the reason for an unexpected rendering of a WP model reported and corrected on the French WP Village Pump, and it was mentioned there that in order to know how much maintenance work this will need on WP, a count of such bare attributes for frwiki like it was done for frwikisource would be appreciated.

I stopped using Avast in October because of this bug, but a few weeks later I made a note (in order to comment here but then my navigator crashed and I forgot) that on this version of a user page I could not see images 1 and 2 and on all of these three pages I only saw text instead of the image even after ?action=purge, then 10 minutes later a new ?action=purge brought things back to normal.

On 10 June 2015 Lydia Pintscher (WMDE) wrote "On the specific topic [‎Site links to redirects]: Various people have said they have ideas how to solve it using arbitrary access. (...) This might well fail. Then we/I will have to reconsider." Now arbitrary access is here, is this issue going to be solved after due reconsideration, two years after the Wikidata community decided it?

Reported today on the French WP Village Pump.

This is maybe a different description which could be considered a different bug but: (both with Firefox 38 under Linux Mageia 4 and with Firefox 40 under Windows 10)

• when I click on the "See also" link in the description above to display it in a new tab, and just as Mandruss describes inside that link, I am taken to a place in the page several screens lower than the "Section link malfunction" section,
• the same thing happens when I reload the page with Ctrl-R, the only difference is that it can be seen better that the page is first taken to the right place for half a second and then to a different place (when opening a new tab this can be seen only sometimes),
• if from that place I use Ctrl-L to focus on the address bar and I press Enter, I am taken to the right place.