--- Timwi timwi@gmx.net wrote: > Andrew Dunbar wrote:
There's no need to be short-sighted and settle for quick fixes just because they are "a lot easier". I'm sure that's not the kind of thinking employed by the founders of the OED or Websters.
If Wiktionary is a good project, and I'm sure we all believe it is, then it will survive long
enough
for the real fixes to come along.
This is so typical. This argument is always going to brought up for everything that is not a complete miracle cure. Hence nothing will ever change and hence we will be stuck with the same problem forever just because people wouldn't accept at least a partial solution!
So basically you have made a prediction that nothing short of a miracle is capable of fixing the problem the proper way. Then you extend this into the future of all problems for all eternity. And this is to bolster support for your compromise solution.
From what you say in the following paragraph, it
seems that you expect these statements to be taken as grounded and probably true:
Cleaning up after the side-effects of the quick fix and cleaning up again in the future when a solid fix comes along will be a pointless drain on the time and patience of the contributors.
That is ungrounded and probably false. What you call a "quick fix" is a step in the right direction. Any "cleaning up" needed to do after the next fix (whether or not it is a miracle cure) will complement, and not override, replace, or render useless, the cleaning up needed now.
Since you have brought up "grounds" and true vs. false regarding the nature of your proposed change and its side-effects, I would call on you to please provide some grounds to support that these claims of yours:
a) that a real fix require a miracle b) that cleaning up won't be required
Also, going with the quick fix now will reduce our chances of getting the developers to implement a solid fix later on, because they will believe they had already fixed the problem.
You are forgetting that you already have no chance of getting a developer to do anything.
This is your argument, for which I am hoping you provide some grounds.
The only reason why we can do this now is because *the feature is already there*.
A feature with side-effects which, thankfully, have now Been discussed and commented on by several people.
I don't know why it was written (maybe for Toki Pona?), but we have it now, and we can flip a switch to make it work. I (not really a “developer”) have volunteered to write a script to do the moving in order to spare you from 40,000 page moves, but even without that script I am sure the Wiktionary userbase can fix all of that manually over time.
So you do know the switch is there. You don't know why the switch is there. You do know that a miracle is needed to make a better switch. You're not really a developer. You will write a script. Such a script does not need to be miraculous. My claims that cleanup after the script are ungrounded. You are sure we can avoid this non-developer script if we fix it ourselves over time. You are not prepared to wait time for a better fix.
It may be even more unfortunate that some feel the need to put down others rather than improve their arguments or consider that other opinions might be valid and not just the "contrary ignoramuses" who have been depicted in the email I'm replying to now.
I do think I have considered the arguments brought forward. I have thought about them as much as I could, and almost all of them struck me as separate issues that were not arguments against this particular change.
Well I hope I've clarified what hasn't been thought about Sufficiently. In the meantime I'm going to start looking at The Wiki code, and get in touch with some Wiki developers to see how feasible a good solutions would be.
Hippietrail.
___________________________________________________________ALL-NEW Yahoo! Messenger - sooooo many all-new ways to express yourself http://uk.messenger.yahoo.com