https://bugzilla.wikimedia.org/show_bug.cgi?id=31063
--- Comment #16 from Daniel Friesen <[email protected]> 2011-10-26 11:05:55 UTC --- (In reply to comment #15) > > 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. > > I cannot follow, I think the only distributed thing is the localization of > the menu into multiple languages, which, unless everything is changed, would > have to remain in Mediawiki NS. Yup, they're all in the MediaWiki: NS but when a translations are changed every relevant page has to be changed simultaneously. And the code has to take this into account. Additionally our permissions systems are per-page not per-namespace, and unless the code ensures that permissions are checked for each page individually it's not a proper core feature, it's a hack, and it doesn't follow the expectation that ACL extensions expect when they hook into our hooks for permissions tests. > And yes, the Sidebar page could be easier to parse and get a new syntax. But > that does not requiring to add a whole new set of tables for it. Create a > Mediawiki:Sidebar.json, which, if present, overrides any available Sidebar... Hell no. Not only is the i18n system not a configuration system, it's also not a place to include a very strict and technical format. It shouldn't be possible for a user to edit what the special page stores, accidentally screw up the syntax, and then make it so that the special page can't fix what they broke. By the way, php's json pretty printing isn't implemented till 5.4.0, and that is an alpha. No stable version of php has a native json encoder with the capability to pretty print json. So because there is no pretty printing, any json outputted by the Special: page into a .json i18n page will be in one long line, not pretty printed with each item on a separate line. So if you want comparison, a Sidebar.json will look like shit. Our 'diff' will be almost entirely useless for figuring out the difference between two versions of the sidebar. > > And really do you need a comparison function for the change "Dantman added > > the > > Foo: namespace", or "Dantman enabled subpages on Help:"? > > Of course not, I am referring to your proposal that logging does well enough > to > understand changes in interwiki. But perhaps you can get away with "Dantman > changed the interwiki prefix "en" from en.wikipedia to xxx." provided you can > filter all "interwiki" logs. Special:Log/interwiki One of the reasons logs are separate from contribs is because they have separate filtering features. Contribs can filter by namespace, logs can filter by type and title. > > 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 ... > > No objections if resources are available for both file and Special: page and > all use cases are covered - that would be great! > > (Just a thought: If file, please place an additional file in a place > specifiable in LocalSettings, rather than requiring to modify code-base > provided files (as currently, e.g. "mime.types"). The latter causes issues > with > wikifarms, svn-checkouts, updating, etc.) The plan I hoped for was to implement multiple interwiki source types. File (piped list, csv, json, xml, plist, etc...), Database (default database, separate database, separate database and user credentials), etc... and have a $wg variable like our $wgForeignFileRepos that lists multiple interwiki sources letting you use order to specify what sources override other sources. The default list would contain a file located inside core for our interwiki defaults. If you don't want those you'd just override the entire way and only specify sources you want yourself. If you want a file source you would add that to the list yourself including the path to that file yourself, so it's completely customizable. You could even implement wiki farm specifics by having a central interwiki source, a project wide interwiki source, and a wiki specific interwiki source. Any of those could be files or databases. -- 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
