Cecil a écrit :
Have you actually read anything that has been said before? We don't accept the discrimination of the IPs in our community.
However, you accept the fact that IPs are not allowed to upload files. As a consequence, IPs are not allowed to start a new project at de.ws, because the rule is "no scan, no text". You never complained about that. Could you explain why ? More generally, there are dozens of things that IPs are not allowed to do in MediaWiki.
To your second option: how long will that work? With your next update you will most probably break all local programming again. And who should repair it each time after it is broken?
You seem to believe that I break things on purpose. This is not true. When I was maintaining code at de.ws, it is true that the local javascript sometimes was temporarily broken because of software updates, and that it had to be adapted. However, I was the person doing this, and I spent many hours just for de.ws. Maybe you could acknowledge this.
The second option that I mentioned means that you keep using ProofreadPage, without using the pagequality system that you do not like. However, if you do not trust me, if you really believe that I break things on purpose, then you should not use my software at all.
We now have found a user who can program in php (that's why we have the patch), but at least I don't know anyone for JavaScript since Xarax is gone. Or can you guarantee that with your future updates you will not destroy it or that in that case you will repair it again? And how are your plans for future development look like? Do you actually have any plans to let us know now what features/surprises we can expect in the future? After all until now your concept was to let us know about a feature on the day of the update, usually at a time when we already noticed that there had to be changes because something didn't work
Indeed I do have plans for future developments. I usually discuss them with the people on IRC, and at ws.org. Sometimes new javascript features are tested at fr.ws and en.ws, before I move them into the extension's javascript. Once new features are added to the code, they are publicly visible in svn, weeks before their activation, just like any other developer's work. Every software modification at Wikimedia is public.
However, I cannot make announcements in every language, and for the last few updates I did not make the effort to write in German.
New developments imply new bugs, and some maintenance. This is normal. I try to do my best to avoid bugs, but nobody is perfect.
If you are scared about future developments, if you want to use software that is perfectly stable and frozen, then you should not use ProofreadPage, because there will be future developments. I could even add that if you want to use something perfectly stable, then you should not use MediaWiki at all. :-)
In any case (your second option or us forking the extension) I would be very much for getting rid of the buttons. The reasons for it I already mentioned even though there was no reaction to it. They are after all very unfriendly when it comes to one very important principle of web-programming: web accessibility. Even if you are not disabled you have to click on them and look in the edit summary to learn what they do. But if you are disabled then they are a nightmare. And yes, I already had to explain to a user how to find them by theoretically parting the monitor in fields and telling the user in what field to look. And he was not even colour-blind in which case the buttons would loose any worth anyway (two buttons are red and one is green, by far the most common trouble-colours of colour-blindness).
sorry, but I did not know that you find these buttons unfriendly. If you are color blind, you can modify your CSS to change the colors, or to replace them with icons. I already explained how to do this in de.ws. If the problem is not color, but how to access them with keyboard instead of mouse, it is something that I can improve. I just need to know about it.
Now Cecil, I am very often available for discussion on IRC. I say this because you don't seem to be using this. However, the type of communication that you can have on IRC is very different than on a mailing list or wiki; some misunderstanding can be avoided by a more direct type of communication. I am willing to find a solution to your problem, and I would love to discuss with you more directly. The reason why I rejected your patch is not to harm you; I did this in order to protect the tool that I developed.
Thomas