https://bugzilla.wikimedia.org/show_bug.cgi?id=31063
--- Comment #10 from Daniel Friesen <[email protected]> 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
