https://bugzilla.wikimedia.org/show_bug.cgi?id=18793


stevertigo <stv...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |




--- Comment #7 from stevertigo <stv...@gmail.com>  2009-05-14 16:23:13 UTC ---
"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


-- 
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

Reply via email to