[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 James Forrester jforres...@wikimedia.org changed: What|Removed |Added CC||jforres...@wikimedia.org See Also||https://bugzilla.wikimedia. ||org/show_bug.cgi?id=7803 -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #24 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-11-23 08:35:29 UTC --- (In reply to comment #23) No, that's not today's standard system, that's the verbose XML cult of thought. You mean the Internet and the Semantic Web (including other serializations than xml) is a cult? :-) Extension authors should have no reason to need to type in a full long uri every time they refer to a namespace. Absolutely no need, they would use a local variable name. Extensions shouldn't need to store something like that in a variable. And they WILL need to use it in multiple places in an extension so they WILL have to write it out multiple times. And the moment they store it into a SMW_PROPERTY like constant all of the extra value of that full uri practically disappears. Not to mention how decision on renaming extension pages or switching to a different system for extension management could affect something that should not be dependent on them. I don't understand the above. Say our extension is located at http://www.mediawiki.org/wiki/Extension:SemanticMediaWiki; and we decide to use the url as the property: http://www.mediawiki.org/wiki/Extension:SemanticMediaWiki#Property; But say we later decide to move SemanticMediaWiki to Semantic MediaWiki. Now the url we're using isn't actually the url that the extension uses. And we can't change that, because that's what we use as a unique identifier and if we change it MW will try to create a new namespace and make all our current content disappear. Likewise say we ditch the Extension: namespace and switch to some sort of dedicated system that has a special interface for managing extensions, versions, releases, etc... and say we use http://extensions.mediawiki.org/ for that. Now all the urls used in extensions are either incorrect or things break. Decisions like these shouldn't have an effect on something like the identifier used for an extension namespace. My assumption is that extensions need globally unique identifiers. Else you either have to create yet another global registry, or two extensions end up using the same identifier. Traditionally many domain specific registries existed, but I stand by my comment: increasingly we do switch these to URIs, whether it is photometadata, institutions, publications, authors, biological organism names, etc. It is not strictly a standard system - please excuse my lax use of language. But it is not a cult, it is a well reasoned, sane decision. Except we don't need unique identifier at the level of a url. In fact if we're going by the extension's MW.org page then of the identifier http://www.mediawiki.org/wiki/Extension:SemanticMediaWiki#Property; the entire http://www.mediawiki.org/wiki/Extension:; portion of that identifier is worthless. Quite frankly smw.* or maybe ext.smw.* is enough specificity for our purposes. Do remember that these keys we're using all just map to very non-unique things like Property:, Thread:, Video:, etc... That level of non-uniqueness is not going away, and all we need on top of that for keys is a little differentiation between different extensions, core, and site namespaces. And for those purposes the extension name is enough (and for well known extensions like Semantic MediaWiki short keys like smw are even enough). We haven't had an issue with conflicts. And DPL Wikimedia vs. DPL2 isn't a conflict, we'd probably 'want' those to use the same namespace. And there may be other cases where there's a reason for extensions to share a namespace key. -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063
Tim Starling tstarl...@wikimedia.org changed:
What|Removed |Added
CC||tstarl...@wikimedia.org
--- Comment #18 from Tim Starling tstarl...@wikimedia.org 2011-11-23 00:57:21
UTC ---
I support the idea of having all namespaces, including pre-defined system
namespaces like NS_USER, tracked by a table in the database.
For performance reasons, no functions should be called unconditionally on
startup, say from the file level of an extension setup file. It's not clear to
me whether Daniel imagines that MWNamespace::reserveExtensionNamespace() would
be called from such a context.
Having unique string keys would be useful, but I agree with Happy Melon in CR
r103893 that it's best to encapsulate them in an object for most interfaces,
rather than passing them raw. Instead of
MWNamespace::reserveExtensionNamespace(
'SMW_PROPERTY', 'content' ), we could have something like
MWNamespace::getInstance('SMW_PROPERTY')-getId().
I'd rather have some new scheme for namespace string keys, rather than
continuing the ugly all-caps style we have now. For example, the user namespace
could be called mw.user, user talk could be mw.user.talk, and
NS_SMW_PROPERTY could be smw.property.
--
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
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #19 from Brion Vibber br...@wikimedia.org 2011-11-23 01:03:25 UTC --- I fully endorse Tim's notes in comment 18. -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #20 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-11-23 03:16:43 UTC --- I guess I might have thought of extension registration being called in an extension setup function. Though perhaps making use of caching so after the actual registration it's lighter weight. But I'll consider thinking about some way around that. For namespaces inside configuration I did think about that. Even though we'll add a namespace manager I don't think we'll completely eliminate config variables right away. So I did consider an alternative ie: $wgMyExtsNamespaceSomething = array( mw.user = true, ); ie: In the mean time switching to string keys instead of integers inside config. As long as extensions are making use of abstract interfaces it should theoretically be possible for extensions to continue working, and core can also try to defer the lookup of the relevant int until needed. That is where my thought about two methods of code accidentally ending up with a string and an int that are supposed to be considered equivalent. -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #21 from Gregor Hagedorn g.m.haged...@gmail.com 2011-11-23 06:29:25 UTC --- (In reply to comment #18) I'd rather have some new scheme for namespace string keys, rather than continuing the ugly all-caps style we have now. For example, the user namespace could be called mw.user, user talk could be mw.user.talk, and NS_SMW_PROPERTY could be smw.property. Just a wild idea: todays standard system of handles are URI-based globally used identifiers. Ideally, any mediawiki extension should have a page on mediawiki.org in the Extension namespace. Make that the identifier... -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #22 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-11-23 06:44:30 UTC --- (In reply to comment #21) (In reply to comment #18) I'd rather have some new scheme for namespace string keys, rather than continuing the ugly all-caps style we have now. For example, the user namespace could be called mw.user, user talk could be mw.user.talk, and NS_SMW_PROPERTY could be smw.property. Just a wild idea: todays standard system of handles are URI-based globally used identifiers. Ideally, any mediawiki extension should have a page on mediawiki.org in the Extension namespace. Make that the identifier... No, that's not today's standard system, that's the verbose XML cult of thought. Extension authors should have no reason to need to type in a full long uri every time they refer to a namespace. Not to mention how decision on renaming extension pages or switching to a different system for extension management could affect something that should not be dependent on them. -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #23 from Gregor Hagedorn g.m.haged...@gmail.com 2011-11-23 07:21:57 UTC --- No, that's not today's standard system, that's the verbose XML cult of thought. You mean the Internet and the Semantic Web (including other serializations than xml) is a cult? :-) Extension authors should have no reason to need to type in a full long uri every time they refer to a namespace. Absolutely no need, they would use a local variable name. Not to mention how decision on renaming extension pages or switching to a different system for extension management could affect something that should not be dependent on them. I don't understand the above. My assumption is that extensions need globally unique identifiers. Else you either have to create yet another global registry, or two extensions end up using the same identifier. Traditionally many domain specific registries existed, but I stand by my comment: increasingly we do switch these to URIs, whether it is photometadata, institutions, publications, authors, biological organism names, etc. It is not strictly a standard system - please excuse my lax use of language. But it is not a cult, it is a well reasoned, sane decision. -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #8 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-10-26 06:32:04 UTC --- I had an extension to this idea in dumps/export/import. We update the dump format to also include the =USER =SMW_PROPERTY etc... key that the namespace was registered with. At that point, during an import we have the information we need to actually pre-register a namespace during an import. And it'll even work with extensions like SMW since the keys are preserved. The namespace will be imported, it'll work even if the extension is not installed. And when the extension is installed, it'll just pick up on the contents already in the namespace. Some of these ideas make me think that custom site namespaces should be registered with some sort of SITE_X key that carries the implication that the namespace was created for a site-specific purpose and the same key from two different wikis may not actually be equivalent in any way. -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #9 from Gregor Hagedorn g.m.haged...@gmail.com 2011-10-26 07:05:00 UTC --- I agree. Registering and exporting/importing symbolic names like name=SMW_PROPERTY would make a lot of sense and be more flexible than relying on the key=102 etc. numbers. The xml format extension would be trivial, but it may a deep change in import/export management. I don't think that SITE_001 is necessary, simply omitting the name attribute would suffice. For internal management, rather than adding a special table for this, I would prefer to add this to the MediaWiki: namespace. -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #10 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-10-26 07:31:39 UTC --- (In reply to comment #9) I agree. Registering and exporting/importing symbolic names like name=SMW_PROPERTY would make a lot of sense and be more flexible than relying on the key=102 etc. numbers. The xml format extension would be trivial, but it may a deep change in import/export management. I don't think that SITE_001 is necessary, simply omitting the name attribute would suffice. We might do that for export. I was considering it. Internally though I believe we may end up doing things like passing around the SMW_PROPERTY string instead of passing around 102 or whatever. Hence we may need something like SITE_X that carries that implication. We may just make one of those implications an implication that the ns does not output an identifier into export. For internal management, rather than adding a special table for this, I would prefer to add this to the MediaWiki: namespace. Hell no. - We should not need to load the whole i18n system before we load the namespace system. The namespace system should be lighter than that. The i18n system has a whole multi-layer structure (get messages from a cache, potentially share messages across multiple systems, get messages from MediaWiki: [this can be disabled too], get messages from i18n files, get messages from core i18n files). Namespace mapping should not be dependent on this. -- Actually I believe that the way that Wikimedia shares messages would make this impossible to work on WM as namespace info should be wiki-local. - Using a database table rather than pages means that we can actually table join it. Instead of the current substandard we have you could actually do a page, namespace join with something like `ns_id = page_namespace` and `title = CONCAT(ns_text, ':', page_title)` and get out a REAL title. - Storing this information in the user editable namespace also has other implications, like making it less efficient and requiring extra db queries to do something simple, and even worse has the potential to let a user completey break their wiki by screwing up something in the MediaWiki: namespace and make it impossible to correct without manual db tweaks. It's also a horrible interface for letting users configure their wiki. - The fact that a namespace registration system may register the ns number for MediaWiki: and that namespace registration may depend on extracting things from the MediaWiki: namespace means that we have a circular dependency. This is a horrible system design. Heck the i18n system defines aliases for namespaces which means that the namespace system might need to be loaded before the i18n system is loaded anyways. - MediaWiki: is an absolute horrible place for configuration. This is our i18n system, it's for translations, NOT for configuration. The i18n people hate the fact that this stuff is in there. And others of us want to kill off the i18n hacks we have and turn them into proper site configuration systems. -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #11 from Gregor Hagedorn g.m.haged...@gmail.com 2011-10-26 08:36:23 UTC --- That was a hornet nest, ok... I am almost convinced by the circular loading argument. Except I have a preference for wikis, that is: put things into a transparent, editable object repository and harvest from there. Like Categories and everything else. There is nothing wrong with having a namespace table, it could easily be harvested off MediaWiki: - except that would mean hardcoding the symbolic name for Mediawiki NS. Advantage: changes are tracked, editability is free (ultimately extensions should probably register their namespace, but for a long time this would require user interaction). I wish the same were true for the interwiki table: store as a transparent, changeable, version traceable object rather than as database table without version control and user interface. The present interwiki table, would be a bad example of how to manage namespaces. It is not included in import/export. It remains uneditable for how many years? 1000s of people trying to use mediawiki have to figure out which of http://www.mediawiki.org/wiki/Category:Interwiki_extensions they need to install. How many give up? I am adding bug 31951 to call for moving Extension:Interwiki to core, and bug 31955 to address the import/export question for interwiki. I am not a developer, only a mediawiki farm manager and applied user, so I fully accept your insight into the code structure which I don't have! -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #12 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-10-26 09:02:52 UTC --- (In reply to comment #11) That was a hornet nest, ok... I am almost convinced by the circular loading argument. Except I have a preference for wikis, that is: put things into a transparent, editable object repository and harvest from there. Like Categories and everything else. There is nothing wrong with having a namespace table, it could easily be harvested off MediaWiki: - except that would mean hardcoding the symbolic name for Mediawiki NS. Advantage: changes are tracked, editability is free (ultimately extensions should probably register their namespace, but for a long time this would require user interaction). There's nothing editable at all about formats like MediaWiki:Sidebar. They're horrible hacks with horrible interfaces for what could be a very user friendly special page. And while it's not versioning if we need it we already have a logging system. I wish the same were true for the interwiki table: store as a transparent, changeable, version traceable object rather than as database table without version control and user interface. The present interwiki table, would be a bad example of how to manage namespaces. It is not included in import/export. It remains uneditable for how many years? 1000s of people trying to use mediawiki have to figure out which of http://www.mediawiki.org/wiki/Category:Interwiki_extensions they need to install. How many give up? I am adding bug 31951 to call for moving Extension:Interwiki to core, and bug 31955 to address the import/export question for interwiki. I actually have a separate issue with interwiki. IMHO it shouldn't even be necessary to do database changes to change the interwiki table. For a simple wiki with fs access it should be as simple as editing a file. Default interwiki mappings should be done by referring to a core provided file as the default fallback instead of being inserted into the db on install. Wiki farms should be able to have a central interwiki database AND a local interwiki database with overrides, instead of being stuck with either a central one and no overrides or redundant local tables. etc... I am not a developer, only a mediawiki farm manager and applied user, so I fully accept your insight into the code structure which I don't have! -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #13 from Gregor Hagedorn g.m.haged...@gmail.com 2011-10-26 09:24:08 UTC --- 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. 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... 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. (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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #14 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #15 from Gregor Hagedorn g.m.haged...@gmail.com 2011-10-26 10:19:54 UTC --- 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. 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... 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. 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.) -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #16 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #17 from Gregor Hagedorn g.m.haged...@gmail.com 2011-10-26 12:57:20 UTC --- (this is getting a tad too philosophical and away from the original bug - this was namespaces, not interwiki :-) - but I cannot resist the temptation:) You describe a lock it down as safely as you can-approach of a tightly managed CMS system. And you think of server-side code php. I was thinking of javascript for the sidebar editor. I think the Mediawiki namespace then is ideal because it allows mediawiki developers to provide initial javascript AND the admins and community experts to override it, just like they can override non-fitting translations. Sorry for the excursion... And today is bug submission day for me it seems, so I submitted the more general enhancement request bug 31958 on this topic... Thanks for your patience and your continued good work on mediawiki! -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 Gregor Hagedorn g.m.haged...@gmail.com changed: What|Removed |Added CC||g.m.haged...@gmail.com --- Comment #4 from Gregor Hagedorn g.m.haged...@gmail.com 2011-09-30 08:23:03 UTC --- (In reply to comment #3) Different namespace numbers on different wikis shouldn't matter. I think it does if you manage multiple wikis. AFAIK in many places in the config the Namespace constants have to be used in ascending order. So config maintainers actually are NOT independent of which number is behind which symbolic constant. That makes configurations non-portable, unless you enforce a global namespace policy on all of your wikis. Am I correct? -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #5 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-09-30 08:35:32 UTC --- (In reply to comment #4) (In reply to comment #3) Different namespace numbers on different wikis shouldn't matter. I think it does if you manage multiple wikis. AFAIK in many places in the config the Namespace constants have to be used in ascending order. So config maintainers actually are NOT independent of which number is behind which symbolic constant. That makes configurations non-portable, unless you enforce a global namespace policy on all of your wikis. Am I correct? Could you come up with an example of where namespace numbers are required to be in ascending order. I don't see how our config requires that. -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #6 from Gregor Hagedorn g.m.haged...@gmail.com 2011-09-30 08:55:18 UTC --- Could you come up with an example of where namespace numbers are required to be in ascending order. I don't see how our config requires that. for example http://www.mediawiki.org/wiki/Manual:$wgNamespacesToBeSearchedHelp -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #7 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-09-30 09:16:32 UTC --- (In reply to comment #6) Could you come up with an example of where namespace numbers are required to be in ascending order. I don't see how our config requires that. for example http://www.mediawiki.org/wiki/Manual:$wgNamespacesToBeSearchedHelp That sounds messed up I don't see how that config's order should matter to the code that uses it. And if it does matter then that is a bug that should be fixed. Also with a namespace registry, namespaces would probably start to be managed by a user interface which would likely replace manual use of that config anyways. -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 MZMcBride b...@mzmcbride.com changed: What|Removed |Added CC||b...@mzmcbride.com --- Comment #2 from MZMcBride b...@mzmcbride.com 2011-09-23 22:53:09 UTC --- Roan says: TimedMediaHandler tried to do this (it picked the lowest free namespace number above 100 or something), and I made Michael take it out. The reason was that variable namespace numbers are very, very, bad: * It will usually result in the same namespace having different numbers on different wikis * If you add site-specific namespaces or install another extension using the same technique, the namespace number may change and all your pages will be messed up -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #3 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-09-23 23:11:00 UTC --- Different namespace numbers on different wikis shouldn't matter. On the second part dynamically registered namespaces should be in a separate area from site-specific ones. Heck with the string idea we might even be able to make new site specific namespaces dynamically registered. Also Brion brought up the idea of a namespace manager, if we do that then we won't have to worry about new site namespaces at all. As for old ones, we of course are going to need some sort of conversion process to migrate. Something like pre-registering old namespace numbers on upgrade. And the whole idea of a built-in registry is that installing/uninstalling extensions won't change the fact that a namespace was registered. Heck we can keep the namespace functioning even after the extension was deleted and force people to ACTUALLY delete contents of the namespace before de-registering. -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Priority|Unprioritized |Normal CC||m...@everybody.org -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added CC|m...@everybody.org | Severity|normal |enhancement -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 Chad H. innocentkil...@gmail.com changed: What|Removed |Added Priority|Normal |Low CC||innocentkil...@gmail.com -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #1 from Brion Vibber br...@wikimedia.org 2011-09-21 17:30:17 UTC --- Probably should resurrect the old NamespaceManager idea -- sane thing would be to actually have a table describing the namespaces and such. :) Looks like an old old version is sitting on bug 7803. -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
