I've appended "on Wikidata" to the title of this task to make it easier to find in searches, and also to make it clear that it is only proposed to turn it off on the one project not generally.

If this feature is added, removing an item that has been flagged as needing a citation should generate an edit summary that notes a citation was requested.

Please could you link to the relevant task where this was fixed and/or the relevant TemplateData documentation to help people if this happens again.

https://www.wikidata.org/w/index.php?title=Q5089194&type=revision&diff=325544717&oldid=314121367
This is another example of how assuming a precision is incorrect - the value given in the source is 135,000,000 gallons without specifying the level of precision. It is very unlikely to be either ±0 or ±1 gallon (although not impossible) however how many significant figures are there? - anywhere from 3 to 9 is possible and, without further investigation, unknowable.

It's now approaching two months since this was declined without adequate explanation and reopened pending that explanation. Please can we now have the reasoning (or a pointer to it) that led to the decline - this remains the biggest single hindrance to simple, intuitive use in my experience.

Thinking more about it, that you have had to have discussions about it in "dozens of places" (none of which are linked so we can verify this) suggests that actually there is a very strong desire for a two-box solution.

I'd like to third this question.
In informal discussions of VE this is one of the most frequent issues brought up. Indeed I'm astounded that anyone could be "happy" at this decision.

There is currently a property proposal for "Wikidata usage instructions" that is relevant to this task.

A small amount of further testing shows this isn't limited to Arabic as I get the same issue with Hebrew text in reference 18 (the second in the "History" section) at the Hebrew Language en.wp article on the Android app (same device as above, and on my girlfriend's different Samsung Android).

Re-reading this bug, it does seem that events have overtaken it.

I think one possible way of doing this would be to store in the local wiki page metadata the associated Wikidata ID. The existence of this could be used as a trigger to display the dialog suggested by Magioladitis above.

This appears to be a duplicate of T51772 but I'm not sure how to mark it as such in Phabricator.

One way around this /might/ be to search not on image title but on image description in the local language. i.e. for users on pt.wp display only images that have "testes" in the Portuguese description field. for users on e.g. ca.wp display only images that have "testes" in the Catalan description, etc. Obviously this requires there to be a pt, etc. description for useful files ( and there are fewer of these an en descirptions) and wont resolve issues of homographs or vandalism but it should (I think) otherwise resolve the issue reported here (and might even encourage more local language descriptions on Commons, which would be a nice side effect). This should be the only search done for automatic searches.

I'm very unclear what this is intending to achieve?
Is it intended to find socks of Orangemoody specifically? If so why - is there evidence that it is necessary?
Is it to find socks of any known paid editor? If so why restrict it to paid editors? Why not socks of any prolific sockpuppeter?
Is it to detect paid editing generally? If so, how do you propose to distinguish legitimate (i.e. disclosed) paid editors from those who are not disclosing their paid status, particularly as disclosure can be made on the userpage, edit summary or article talk page and there is no standard wording? How and why do you propose to distinguish between paid editors and non-paid editors who make similar edits (e.g. fans/enthusiasts of a subject)?

In T95425#1624288, @daniel wrote:

As far as I know, this is resolved for the editing use case. Rounding still applies for HTML output. I think this should be either reworded or closed.

This is still causing incorrect data to be displayed.
I've entered a value of 350±150 because the source gives a range of 200-500. However this is displayed as 400±200 which gives a range of 200-600 which is incorrect and misleading.

Speaking as someone who typical updates entries that are not scientific in nature, defaulting to any level of precision other than ±0 is incorrect and infuriating. When I enter a numerical value for something I want the displayed and stored data to match the input I give exactly. e.g. when I say the number of trains on a particular funicular railway is 2, assuming I mean 2±1 is incorrect. When I input the length of the Sheffield Supertram system as 29km, assuming I mean 29±1km is incorrect - I assume it's actually 29±0.5km but the source does not say. When I enter the width for 2134mm track gauge as 7ft, assuming I mean 7±1 ft is incorrect - the gauge is defined as a nominal 7ft exactly, with different actual spacing and different tolerances in specific applications.

To clarify this is happening with all templates, and on both en.wp and de.wp (I've not tested other projects)

I've managed to reproduce it (without saving) in the main namespace at it.wikipedia as well

I'm also seeing it when right-clicking on a template, using Firefox 38. I can't reproduce in Chromium Version 43.0.2357.81 Ubuntu 14.04 (64-bit)

If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g. {{# is never a template) or comparing it to a list of parser functions?

I don't know whether it is normal or not in other editors, but it is distinctly non-intuitive in the context of editing wikis. I'm a very experienced editor and have a higher degree of computer literacy than many users, and it took me a few minutes to work out that I needed to double click to edit the contents of a table cell.

In T53758#1088912, @Aklapper wrote:

• When the pre-formatted block follows a mutli-line template, that template is deleted and the contents of the pre-formatted block becomes normal text on the line above where the template as, appended to any text that was already there.

When exactly is "that template deleted"? Already by loading the page in VisualEditor? If so I fail to reproduce...

I don't recall this error, and I too can't reproduce anything now using Firefox 30. Given that it's been ~18 months since the report, it's likely this has been fixed by some other update in the meanwhile.