https://bugzilla.wikimedia.org/show_bug.cgi?id=31063
--- Comment #14 from Daniel Friesen <[email protected]> 2011-10-26 09:54:32 UTC --- (In reply to comment #13) > 1. Having a nice editor for mw:Sidebar would be nice. But nothing in the > present format prevents this, it just does not happen due to resource > limitation. If it were not in Mediawiki: it would not be editable at all. The present format is a mess. And the checks to modify pages necessary for a Special: page to update the sidebar with our full functionality are insane. A special page updating a sidebar could potentially have to simultaneously edit a half dozen pages. Check that the current user has edit permissions on all of them, if an edit-conflict happens on ANY of them while it's editing it would have to figure out what to do with a half state, and it would have to output multiple entries into the rc instead of a single sane line showing the user has updated the sidebar. > 2. I don't think logging is a solution, it has not comparison function and is > generally rather intransparent. One of the reasons is that user contributions > and user logs must be checked separately, rather than being available in a > single list. Interestingly, in recent changes they are unified... Then file a bug asking for a 'user changes' page that unifies contribs and logs. And really do you need a comparison function for the change "Dantman added the Foo: namespace", or "Dantman enabled subpages on Help:"? By the way, namespace updates require checks into what pages are using the namespaces or prefix and a pile of database updates for any relevant pages. By the way, currently if you want to add a namespace you have to do those db updates manually. A Special: page would do these implicitly. But a MediaWiki: page wouldn't, and would expose a site admin to breakage that can only be fixed by someone with database access and in-depth knowledge of how to fix the issue. > 3. Wiki admins have neither fileserver nor database access in the > installations > I know. Since developers have these, they usually believe everyone else has as > well. I don't think files are good solution for interwiki. And some wiki are administrated by the user who does have fs access, who shouldn't have to do something as heavy as db or web stuff when file editing is easy for them. What I'm describing is a configurable multi-layered interwiki system. If file editing is easy for you, then use file editing tools. If you want Special: page editability use a layer with a database and use the Special: page that would come with that multi-layer change. In fact the editability would probably be done by implementing functions on read-write interwiki sources to make changes so any Special: page for editing interwikis could work with any read-write source whether it's database or file based. > (4. Yes, the interwiki table is broken, among other things because it manages > interlanguage and interwiki in a single table, which prevents sharing the > interwiki links by using a shared table. But, perhaps it might be more > difficult to update because it is is a non-wiki, classical database design of > a > dedicated table that is directly edited by third-party tools. If interwiki > were > harvested and opaque, the update may be more easy. But maybe not...) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
