If a parameter isn't defined in the TemplateData of the template, it will be deleted when ProveIt updates the reference. This is meant to normalize parameters, but it may also imply lost information. Should ProveIt be more conservative here and keep unregistered parameters?
Maybe we should highlight the unregistered parameters, and/or make them uneditable.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Unregistered parameters no longer deleted | wikipedia/gadgets/ProveIt | master | +48 -34 |
High priority, it is really bad when gadget will delete something without user actions.
I think ProveIt can just write a message, smth like this: 'Some unregistred parameters was deleted. Check the TemplateData of +TEMPLATENAME+ if it is wrong'
As a end user editor, I want unsupported parameters retained, along with their corresponding value, so that I do not lose data.
Otherwise... An editor edits an existing reference. He or she does not notice that a parameter name is an incorrect parameter name. The editor makes a change using the friendly ProveIt dialog and then clicks the ProveIt Update button. The parameters AND their data are gone, without warning or notice! IMHO, this sort of surprise is NOT OK. BTW, *IF* the editor happens to notice the problem, he or she would now have to go back to the un-edited version of the article and locate the parameters and data and copy/paste them back into the edit in progress in an attempt to recover the data.
An ideal handling would be to show the unsupported parameters near the top of the ProveIt dialog. Instead of displaying them as a label, show the unsupported parameter names as an editable textbox, perhaps with a pink background to highlight the situation.
PS I have no idea what sort of editor would make such a blunder. Certainly not someone as perfect as myself! :-)
John
@Arg342 I think the best way for this situation - add outdated parameters in TemplateData and mark them outdated then.
@Iniquity I agree that TemplateData should be updated to match the actual behavior of the template itself. I would still argue that this must be fixed, and that is should be fixed before making this version of ProveIt live.
It will take some time to go through the templates compare the code versus the template data to identify mismatches. It will even be a large effort to go through the monthly error reports to find current usages that are causing mismatches.
Even once the Template data is perfect, editors will make a freeform edit mistyping a parameter. If subsequently ProveIt is used, with the current behavior, well intentioned and possibly valuable data will be lost without warning. IMHO, this is unacceptable.
@Arg342 If we will have a parameter which need to be deleted and It will not put in TD we will be always have error message, and it is bad.
The more I look into this, the worse it gets! In the English Wikipedia, the cite templates supports many varieties of author<n> where <n> is an arbitrary number. Adding all these into TemplateData is a large undertaking, and in some cases will be so absurd that it may make the TemplateData so unwieldy as to become useless.
For example, in cite journal, there are articles with over 750 names! This would mean adding 1500 entries to TemplateData. (lastn, firstn times 750)
PLEASE fix this behavior of ProveIt so that data is not lost. Just pass them though for the moment if you have to. If you can display them in red as unknown, that would be even better. But please stop the potential data loss.
BTW, I have been working on cite book TemplateData. it is slow, but coming together.
@Arg342: The priority of this task got increased. As priority reflects reality and does not cause it, please elaborate why this task is more urgent than other tasks on the project workboard. Please do not change priority if it does not confirm with Setting Task Priorities. Resources of teams are limited when it comes to working on requests. We want to be realistic about communicating what is being worked on, to maximize the impact of changes. Practically, this often unfortunately means assigning a lower priority to many tasks.
If the priority was increased because you plan to work on this task please claim the task by setting yourself as assignee. Thank you for your help!
If you do not plan to work on this task yourself but feel that this task is urgent but being ignored by those with the actual power to put the task on their agenda, please discuss with the responsible developers.
@Aklapper: This really is pretty urgent now. I won't raise the priority again, but every day that this is not corrected and ProveIt is live, there is a good chance that Wikipedia is loosing data.
@Sophivorus: Please address this urgently: either 1) Disable ProveIt again until this is fixed, or 2) add code as a popup when an editor tries to use ProveIt warning of this behavior or 3) fix it as discussed.
It well and truly pains me to say this because I am a huge fan of the gadget, but right now ProveIt is working contrary to its intention with this bug.
Change 322269 had a related patch set uploaded (by Sophivorus):
Unregistered parameters no longer deleted
@Arg342 Fixed. I did some light testing but some real life one would be appreciated, cheers!