Last modified: 2011-03-13 18:05:02 UTC
I remember asking Starling about this a few years ago, and though I thought his answer was unsatisfactory, I suppose I figured it would have been corrected anyway. It hadn't come up again until recent discussion: > "...[It] might be called something like "Wikipedia:WikiProject [Scope]," though > the usage of the above terminology is attributable to a unfortunate convergence of > factors: > 1) An unfortunate technical/technocratic inability to use the word "Project" as a > namespace (which would produce something elegant like "Project:[Scope]") > " 2) A likewise unfortunate tendency to honor CamelCase as a kind of Wikipudlian > meme, and > 3) An equally unfortunate propensity we all have for using the word "wiki" in any > context imaginable. " > ( http://lists.wikimedia.org/pipermail/wikien-l/2009-May/100680.html ) AIUI, the reason is that the word "Project" is currently used as a standard substitute for a MediaWiki project's actual name, either because : * someone hasn't entered a unique or else local name when they install MW. * code usage, to refer to the main meta namespace. The first one is solved simply by requiring the input of a <s>project</s> wiki name, which isn't unreasonable. The second is solved simply by using something other than "project" as a token in code. If a token is required, something like "project_" "projectname" "meta" or "metaspace" could conceivably work just as well. Again, the idea is to free up "Project" for usage with actual subprojects, which is a more important usage of that namespace, IMHO. -SV
Changing it would break backwards compatibility with truckloads of links. I don't see this happening.
I recommend WONTFIX here. It's the canonical name for the namespace. Unless there's an _incredibly_ good reason to change it, it should not be done.
Namespace semantics on the ~4M-article-wiki may seem far less important than those objections that raise safewords like "code" or else the plight of ~138 MB MediaWiki installs and noob admins that can't even run a SQL patch, but those could be forgetting that its not about the code here: It's about the content. "Truckloads of links" - Any way to query how many? Are these the result of a bad coding practice wherein the code effects the content and becomes entangled with the content? Couldn't a reasonably simple SQL patch change the ubiquitous English word "Project" to something more code-cool like "P40J3C7." Which, for code-not-content purposes would work quite well, wouldn't it? "Breaks backwards compatibility" - This might be a bit overboard. In any case, AIUI, MediaWiki's first project is Wikipedia. En.wiki happens to be the dominant one, which more has truckloads of sub-Projects to consider, each of which has more content value than the hassles associated with a one-and-a-half-hour code fix. BTW, does this BUG not affect other language wikis, or does it affect just the English one? If the token in the code is the same untranslated English word "Project," other languages could still use their respective direct/near-direct translations: Projekti, 計劃, 计划, 方案, المشروع, projekt, projekt, projekt, projekto, suunnitelma, projet, Projekt, פרויקט , מיזם, terv, proyek, progetto, プロジェクト, 計画, けいかく, 계획, پرۆژه, projek, proġett, prosjekt, projekt, projeto, proiect, план, проект, proyecto, projekt, proje, prosiect... Any of which alternate tokens would be, at least for the purposes of my argument, better to use than the English/Dutch spelling. -Steven
MZ: "It's the canonical name for the namespace." "Canonical??" -Steven The Dude: "What are you, a ******* park ranger now?" Walter: "No, I'm..." The Dude: "Who gives a **** about the fucкing marmot!"
(In reply to comment #4) > MZ: "It's the canonical name for the namespace." > > "Canonical??" > > -Steven > > The Dude: "What are you, a ******* park ranger now?" > Walter: "No, I'm..." > The Dude: "Who gives a **** about the fucкing marmot!" > This doesn't even make sense. It is the canonical name, period. End of story. I agree with the suggestion for WONTFIX. Canonical namespace names should rarely (if ever) change. An exception to this was Image => File, but even Image was kept as an alias indefinitely, it wasn't freed up for general use. Changing a core namespace name just so one wiki can make use of a "Project" namespace is hardly a good reason, IMHO.
(In reply to comment #3) It's not about the code. It's about the content which have numerous links of the from [[Project:foo]], especially when linking to other projects. Taking that away, how would you link to those other projects in a general way? > "Breaks backwards compatibility" - This might be a bit overboard. In any case, > AIUI, MediaWiki's first project is Wikipedia. En.wiki happens to be the > dominant one, which more has truckloads of sub-Projects to consider, each of > which has more content value than the hassles associated with a > one-and-a-half-hour code fix. It's not about the code. Besides, most of us are volunteers. Comment #4 seems totally out of place. I'm predicting from that this discussion will lead to nowhere, so I will close the bug.
"This doesn't even make sense." Obviously you're not a golfer. "It is the canonical name, period. End of story." You sound so certain. "Canonical namespace names should rarely (if ever) change." Consider this one of those rare times. I assume of course that other canonical terms aren't likewise suffering any code-abuse. "Changing a core namespace name just so one wiki can make use of a "Project" namespace is hardly a good reason, IMHO." Well, en.wikipedia.org is not "just [] one wiki," IMHO. Its like twice as big as any other wiki, AIUI. So in that context, *not being able to use a canonical English word for its *canonical meaning, due to some overgeneralized reluctance or lack of creative solubility is hardly a good reason, IMHO. "It's about the content which have numerous links of the from [[Project:foo]], especially when linking to other projects. Taking that away, how would you link to those other projects in a general way? AIUI, this is never an issue anyway, though I would be happy to hear facts to the contrary. Liking cross-wiki to the Wikipedia namespace generally uses the form [[wikipedia:Wikipedia:Namespaces]], and not [[wikipedia:Project:Namespaces]]. I understand that cross-language reference to the meta pages in another wiki might use a "Project" shortcut because they might, for some obtuse reason, not know the actual translated name of the other wiki. But again, if we looked at the actual numbers I think it would be a non-issue. Besides, the issue of backward compatibility only goes so far. How far back are MediaWiki versions supported, in whole or part, such that the current codebase must resist any deviations from previous codebase? AIUI, its not a problem to do certain radical things like require a complete active reinstall upgrade, or to add new tables to the database. If my reference to Lebowski was out of place, then I apologise. That scripture seemed quite relevant to the above usage of a concretized pet concept. But I don't think the main points have been addressed here, so I think closing this tag with a couple of terse uberdefinitive statements was premature at best. -Steven
Enwiki is not the only wiki in existence, and it would do enwiki well to remember this. Changing "Project" -> "Something else" because enwiki wants a Project: namespace is _not_ a valid reason to break a canonical namespace. Even IF it were renamed to something else, I couldn't see it going forward without keeping Project: as a back-compat alias, rendering the original request moot anyway, because it wouldn't work. Reclosing WONTFIX.
I appreciate the responses. But just as a hypothetical, it would be great if one of you could list the general fixes that would have to be done in order for it to work. Suppose for a moment someone like myself wants to use that namespace in their own install, and wants to script the process so they don't have to repeat their work when they upgrade to MediaWiki_x. Suspend for a moment those objections which assume infeasibility, too much work, or "canonical" usage. What are the steps? How much work in man-hours would that be? -SV
All I know is I use [[Project:...|...]] a lot on my wikis, You never know one day you might decide on a better $wgSitename assuming the wiki hosting company is willing to change it for you, and you might not have _easy_ access for changing it in the million places you might have otherwise hardwired it in... Indeed, you might even decide to change the $wgLanguageCode. Thankfully Project can weather that too. Or I am editing on somebody else's wiki, and their $wgSitename is just too darn hard to type in. Sure, I worry in the back of my mind that [[Project|]] too will go belly up and one day I will be informed that for the last two weeks nobody could read my sites... but the later, the better,
(In reply to comment #10) > All I know is I use [[Project:...|...]] a lot on my wikis, > > You never know one day you might decide on a better $wgSitename > assuming the wiki hosting company is willing to change it for you, and > you might not have _easy_ access for changing it in the million places you > might have otherwise hardwired it in... > > Indeed, you might even decide to change the $wgLanguageCode. Thankfully > Project can weather that too. > > Or I am editing on somebody else's wiki, and their $wgSitename is just > too darn hard to type in. > > Sure, I worry in the back of my mind that [[Project|]] too will go belly > up and one day I will be informed that for the last two weeks nobody > could read my sites... but the later, the better, > Since Project is the canonical name of a core namespace, you can assume that *if* it's ever renamed (which will probably never happen), the old name will be kept as an alias for all eternity (the same applies to other core namespaces).
(In reply to comment #9) > But just as a hypothetical, it would be great if one of you could list the > general fixes that would have to be done in order for it to work. Bugzilla is not a support forum, so don't except an answer here.
"You never know one day you might decide on a better $wgSitename.." "Indeed, you might even decide to change the $wgLanguageCode.." "Or I am editing on somebody else's wiki, and their $wgSitename is just too darn hard to type in." Seems that the usage of some abstractions like $wgSiteMetaname and $wgSiteMetanameToken could allow for certain degrees of freedom. "Project" would be the default, and most would leave the default alone and thus not break compatibility. Certain narrow-use solo projects (like Wikipedia) could then use "Project" for its publically "canonical" meaning, rather than defer to the limitations imposed by its "canonical" hard-coded usage in private code. I'm still not clear what poor coding habits specifically would make this undesirable on WikiMedia wikis. That question at least would seem to fit within Bugzilla's mandate. :) -Steven
(In reply to comment #13) > ...I'm > still not clear what poor coding habits specifically would make this > undesirable on WikiMedia wikis. That question at least would seem to fit within > Bugzilla's mandate. :) I wish you wouldn't continue to infer that it has anything to do with "poor coding habits," because it doesn't. Every namespace is given a canonical name to refer to it. 'User', 'MediaWiki' and 'Category' are all canonical names too. 'Project' was chosen as the project namespace canonical name because it's sufficiently generic as to what the namespace is for. Granted, it may not have been the best choice, but it's there. As mentioned several times before: even if Project: was changed from the default (which can easily be done, the same process applied to Image -> File could be followed), it would still be retained for back-compat.
demon: "Every namespace is given a canonical name to refer to it. 'User', 'MediaWiki' and 'Category' are all canonical names too." Does your particular usage of the term "canonical" follow it's canonical meaning in general English usage? The term "canonical" is only meaningful within the context of a particular language system, to indicate that particular term has dominance in frequency and preference with regard to referencing a particular concept. You appear to be using the term to mean "canonical within MediaWiki's scripted conventions." I am instead suggesting that the term is "canonical within English," and not particularly within MediaWiki or its systems. Putting aside for a moment the fact that the system "English" (and its canon) supersedes MediaWiki's in terms of importance (though a Lojban speaker might consider English inferiour to Lojban) the system called "English Wikipedia" itself does exactly that anyway. demon: "I wish you wouldn't continue to infer that it has anything to do with "poor coding habits," because it doesn't." I may be wrong about this, but I am under the impression that programmers often pride themselves in their capacity to write abstracted functions, such that (ideally) all output can be handled via straight-forward objective abstracted functions. Am I am under the wrong impression in this regard? demon: "'Project' was chosen as the project namespace canonical name because it's sufficiently generic as to what the namespace is for. Granted, it may not have been the best choice, but it's there." I understand that a term may be "sufficiently generic." What I suggest is that you consider that such term is also "sufficiently English" such that English-speaking Wikipedians, not just MediaWiki sysadmins, might want to use it. demon: "As mentioned several times before: even if Project: was changed from the default (which can easily be done, the same process applied to Image -> File could be followed), it would still be retained for back-compat." I understand now that its "easily done" and that the only issue is simple backward compatibility. Is this as relevant to Wikipedia as much as it is to the non-WikiMedia MediaWiki installations? I think its only subjective to state that interwiki issues, particularly non-WikiMedia interwiki issues, are 'preventative,' when there are no actual data on such usage. In any case, changing something obviously means doing it right; gradually and over sufficient time as to allow people to accommodate. -SV
The point here is that fulfilling this request, while technically possible, is viewed as undesirable by pretty much all developers; that should mean something. Also, even *if* this weren't undesirable from a technical standpoint, this is a community issue and you'll need community consensus on the wiki in question before even submitting a bug.
